TLSPackage后的java神秘字节

Question

我正在尝试创建一个从Java到Vala服务器的SSL TCP连接。 在我向服务器发送第二个包之前，一切正常。（同样，第一个包发送罚款）。 服务器只接收第二个包的第一个字节（在本例中为“1”），其他不接收， 但是，如果我连接到没有SSL的服务器，一切正常。 我认为服务器不是问题所在，因为来自另一个Vala客户机的所有其他连接都工作得很好

我使用的是未受信任的证书，因此我创建了一个自定义的TrustManager，并使用OpenJDK 7（基本操作系统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、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在这种情况下是否真的忽略了它