TLS打包后的神秘字节

Question

我正在尝试创建从Java到Vala Server的SSL TCP连接。一切正常，直到我将第二个程序包发送到服务器。 （第一个数据包也可以发送）。服务器仅接收第二个程序包的第一个字节（在本例中为“ 1”），除此之外，但是，如果我不使用SSL连接到服务器，则一切正常。我认为服务器不是问题，因为来自另一个Vala客户端的所有其他连接都运行良好。

我使用的是不受信任的证书，所以我创建了一个自定义的TrustManager，并且正在使用OpenJDK 7（基本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：进行多次接收。

像TCP一样的TLS / SSL被定义为流服务，并且不能保证保留记录边界，仅按顺序传递字节-否则，请指出错误。例如，在TCP或TLS / SSL中，如果一方执行3个发送操作，每个发送操作1000个字节，并且接收方执行一系列接收操作，则那些接收方可能会接收500、700、1200和600字节。通常，接收方必须如有必要，进行多次接收以接收多于一个字节的数据结构。这可以使用分隔符（例如SMTP）来完成：将标头读取为行，直到获得空行；将正文（数据）读取为仅由“点”（。）组成的行。或简单地算一下：继续阅读，直到总共获得N个字节。例如，HTTP和HTTPS都使用这两种方式（在某些情况下甚至更多）。

在实践中，TCP实现通常会分割大于1000个字节的数据，这是由于它们分割数据以进行传输和重新组装的方式。因此，大约在1982年以后尚未了解此问题的TCP程序员从经验中学到了“继续阅读直到完成”的知识。]

但是从历史上看，SSL / TLS实现大多为[[did]保留记录边界，最大约16k字节，这再次是由于该协议在内部工作的方式。结果，许多没有阅读规范的程序员错误地认为SSL / TLS是一种记录服务。这是2011年the BEAST attack的结果，在某些（相当有限的情况下）可能会破坏使用带有CBC模式密码的SSLv3或TLSv1.0发送的加密数据，因为这些协议通过链接IV来实现CBC模式。从一个数据记录到下一个。由包括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在这种情况下是否确实忽略了它。