TLS-Package 后的神秘字节答案

【问题标题】：Mysterious byte after TLS-PackageTLS-Package 后的神秘字节
【发布时间】：2015-10-27 00:24:49
【问题描述】：

我正在尝试创建从 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();
    }
}

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

【问题讨论】：

getAcceptedIssuers() 不能返回 null：请参阅 Javadoc。不要使用这种根本不安全的代码。你在哪里证明数据没有被正确接收？接收代码？
@EJP 我不认为 API 需要它，但实际上 getAcceptedIssuers 并没有在客户端中使用，所以这个错误永远不会被咬

标签： java ssl vala

【解决方案1】：

TLDR：进行多次接收。

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

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

但从历史上看，SSL/TLS 实现大多确实保留了大约 16k 字节的记录边界，这也是由于协议内部的工作方式。结果，许多没有阅读规范的程序员错误地认为 SSL/TLS 是一种记录服务。由于 2011 年 the BEAST attack 导致这种情况发生了变化，在某些（相当有限的）情况下，它可能会破坏使用 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 及更高版本不需要它，但目前我无法验证 JSSE 在这种情况下是否真的省略了它。

【讨论】：