官方的Oracle SSLSocketClient.java演示代码不安全吗？

Question

从这个链接中，给出了SSLSocketClient.java的演示：

import java.net.*;
import java.io.*;
import javax.net.ssl.*;

/*
 * This example demostrates how to use a SSLSocket as client to
 * send a HTTP request and get response from an HTTPS server.
 * It assumes that the client is not behind a firewall
 */

public class SSLSocketClient {

    public static void main(String[] args) throws Exception {
        try {
            SSLSocketFactory factory =
                (SSLSocketFactory)SSLSocketFactory.getDefault();
            SSLSocket socket =
                (SSLSocket)factory.createSocket("www.verisign.com", 443);

            /*
             * send http request
             *
             * Before any application data is sent or received, the
             * SSL socket will do SSL handshaking first to set up
             * the security attributes.
             *
             * SSL handshaking can be initiated by either flushing data
             * down the pipe, or by starting the handshaking by hand.
             *
             * Handshaking is started manually in this example because
             * PrintWriter catches all IOExceptions (including
             * SSLExceptions), sets an internal error flag, and then
             * returns without rethrowing the exception.
             *
             * Unfortunately, this means any error messages are lost,
             * which caused lots of confusion for others using this
             * code.  The only way to tell there was an error is to call
             * PrintWriter.checkError().
             */
            socket.startHandshake();

            PrintWriter out = new PrintWriter(
                                  new BufferedWriter(
                                  new OutputStreamWriter(
                                  socket.getOutputStream())));

            out.println("GET / HTTP/1.0");
            out.println();
            out.flush();

            /*
             * Make sure there were no surprises
             */
            if (out.checkError())
                System.out.println(
                    "SSLSocketClient:  java.io.PrintWriter error");

            /* read response */
            BufferedReader in = new BufferedReader(
                                    new InputStreamReader(
                                    socket.getInputStream()));

            String inputLine;
            while ((inputLine = in.readLine()) != null)
                System.out.println(inputLine);

            in.close();
            out.close();
            socket.close();

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

我有两个问题：

1. 根据该官方文档，如果我们使用的是原始SSLSocketFactory而不是HttpsURLConnection，则握手过程中没有强制执行的主机名验证。因此，主机名验证应手动进行。

在使用原始SSLSocket和SSLEngine类时，您应该在发送任何数据之前始终检查对等方的凭据。SSLSocket和SSLEngine类不会自动验证URL中的主机名是否与对等方凭据中的主机名匹配。如果未验证主机名，应用程序可能会利用URL欺骗进行攻击。从JDK 7开始，endpoint识别/验证过程可以在SSL/TLS握手期间处理。请参阅SSLParameters.GetEndPointIdentificationAlgorithm方法。

这是否意味着演示不安全？

我在Java 7中看到一个添加主机名验证的解决方案是：

SSLParameters sslParams=新SSLParameters（）；SSLParams.SetEndPointIDentificationAlgorithm（“HTTPS”）；sslsocket.setsslparameters（sslParams）；

当算法指定为“HTTPS”时，握手将验证主机名。否则（算法仅使用原始SSLSockeFactory为空），则根本没有调用主机名验证。我很好奇我能不能把它修成下面的样子：

SSLSocketFactory factory =
                    (SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket socket =
                    (SSLSocket)factory.createSocket("www.verisign.com", 443);
HostnameVerifier hv = HttpsURLConnection.getDefaultHostnameVerifier();
if(!hv.verify(socket.getSession().getPeerHost(),socket.getSession())){
    threw CertificateException("Hostname does not match!")
}

我看到HttpSurlConnection.getDefaultHostNameVerifier()可以返回一个默认的HostnameVerifier，我可以用它来做验证吗？我看到很多人在谈论使用自定义HostNameVerifier。我不明白，如果有一个默认的，为什么我们需要自定义它？

Answer 1

作为一个边缘的答案，但太长的评论。

（1）是的，对于HTTPS（如您所引用的那一段之后的段落所指出的），这是一个安全缺陷；这个例子可能是在Java 7之前写的，之后就没有更新过。您可以提交一个bug报告供他们更新。（当然，有些使用SSL/TLS的应用程序不验证主机名，比如SNMPS和LDAPS，甚至没有URL，但仍然可以使用Java JSSE实现。）

（2）HTTP错误或差也：

>

PrintWriter使用JVM的lineSeparator，它因平台而异，但HTTP标准（RFCs 2068、2616、7230)要求所有平台上的请求头都需要CRLF，尽管一些服务器（可能包括google）将按照传统的Postel格言“在发送的内容中保守，在接收的内容中自由”接受仅-LF；

读取端假设所有数据都是面向行的，并且不会因为规范化EOL而受损，这对于HTTP头和一些主体是正确的，比如当请求没有接受（或接受编码）时，您将从大多数Web服务器获得的text/html（但不保证）；

读取端还假设所有数据都可以安全地从JVM缺省的“charset”解码并重新编码为该缺省的“charset”；对于HTTP头（实际上是7位ASCII）是这样的，但不是很多/大多数主体：特别是，将8859或类似于UTF8的处理会破坏它的大部分，而将UTF8处理为8859或CP1252则会mojibrake它。

(3)HTTP/1.0已经过时了，尽管它仍然受到广泛的支持，而且演示也要简单得多，所以我还是不提这个问题。