TLS-Package之后的神秘字节

我正在尝试创建从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 ：做多次接收。

像TCP这样的TLS / SSL被定义为流服务 ，并不保证保留记录边界，只保证按顺序传递字节 – 或者如果不可能，则指出错误。 例如，在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年的BEAST攻击 ，这种情况发生了变化，在某些（相当有限的）情况下，可能会破坏使用SSLv3或TLSv1.0和CBC模式密码发送的加密数据，因为这些协议通过链接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及更高版本不需要它，但目前我无法validationJSSE在这种情况下是否实际省略了它。