Question

我正在尝试创建从Java到Vala服务器的SSL TCP连接。一切正常，直到我发送第二个包到服务器。（也是第一个包发送正常）。服务器只接收第二个包的第一个字节（在本例中为“1”），没有别的，但如果我连接到没有SSL的服务器一切正常。我认为服务器不是问题，因为来自另一个Vala客户端的每个其他连接都运行良好。

我使用的是不受信任的证书，所以我创建了一个自定义的TrustManager，我正在使用OpenJDK 7（Elementary OS - Linux）。这是我的代码：

//Main:
SSLHandler handler = new SSLHandler();
handler.createSecureSocket("localhost", 7431);

byte[] data = {1,4,1,1,1,1};
handler.getOutputStream().write(data);
handler.getOutputStream().write(data);

// SSLHandler
public class SSLHandler {

    // SSL Socket erstellen
    SSLSocket sslSocket;

    public void createSecureSocket(String ip, int port) throws UnknownHostException, IOException, KeyManagementException, NoSuchAlgorithmException {

        SSLSocketFactory factory = (SSLSocketFactory) new DefaultTrustManager().createSSLFactory("TLS");

        sslSocket = (SSLSocket) factory.createSocket(ip, port);
    }

    public OutputStream getOutputStream() throws IOException {
        return sslSocket.getOutputStream();
    }

    public InputStream getInputStream() throws IOException {
        return sslSocket.getInputStream();
    }

}

//Custom Trust Manager
public class DefaultTrustManager implements X509TrustManager {

    @Override
    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {}

    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {}

    @Override
    public X509Certificate[] getAcceptedIssuers() {
        return null;
    }

    public SSLSocketFactory createSSLFactory(String protocol) throws NoSuchAlgorithmException, KeyManagementException {
        SSLContext sslContext = SSLContext.getInstance(protocol);

        TrustManager[] byPassTrustManager = new TrustManager[] {this};

        sslContext.init(null, byPassTrustManager, new SecureRandom());

        return sslContext.getSocketFactory();
    }
}

有人知道这个问题的解决方案吗？

Answer 1

TLDR ：多次接收。

TLS / SSL（如TCP）被定义为流服务，并不保证保留记录边界，只保证按顺序传递字节 - 或者如果不可能，请指明错误。例如，在TCP或TLS / SSL中，如果一方执行3次发送操作，每次1000字节，并且接收器执行一系列接收操作，则这些操作可能会收到500,700,700和600字节。通常，接收器必须在必要时进行多次接收以接收多于一个字节的数据结构。这可以通过分隔符来完成，例如SMTP：继续阅读，直到你获得CRLF终止的一系列行（名义上，Postelian接收者可能接受其他行）。或者只是计数：继续阅读，直到你得到总共N个字节。例如，HTTP和HTTPS使用这两种方式（在某些情况下更多）。

实际上，TCP实现通常会将大于大约1000字节的数据拆分，因为它们将数据分段传输并重新组合。因此，大约在1982年之前没有教过这个问题的TCP程序员已经从经验中学到了“继续阅读直到完成”。

但是历史上SSL / TLS实现大多数确实保留了大约16k字节的记录边界，这也是由于协议在内部工作的方式。因此，许多没有阅读规范的程序员错误地认为SSL / TLS是一项记录服务。这在2011年the BEAST attack的结果发生了变化，在某些（相当有限的）情况下可能会破坏使用SSLv3或TLSv1.0使用CBC模式密码发送的加密数据，因为这些协议通过链接实现CBC模式IV从一个数据记录到下一个。由许多堆栈（包括Java JSSE）实现的对BEAST的一种防御是在两个（或更多）部分中传输每个数据记录，使得敏感部分的IV不能提前看到;非正式的共识是使用1个字节，然后（最多）使用剩余的n-1个字节。请参阅https://security.stackexchange.com/questions/63215/why-does-firefox-split-https-request。

请注意，此防御仅在SSL连接中的第二次和后续写入时完成，因为第一次使用基于KDF的IV，而不是链接，仅用于CBC模式密码套件，因为只有它们在此链接IV时尚。并且TLSv1.1及更高版本不需要它，但目前我无法验证JSSE是否在这种情况下实际省略了它。

TLS-Package之后的神秘字节

1 个答案: