java - TLS连接中ServerHelloDone之后的SocketTimeoutException

Question

我有一台使用SSLServerSocket制成的服务器。该服务器从许多其他服务器接收连接。其他服务器来自第三方。除其中一台服务器外，它始终适用于所有服务器。典型的ssl调试日志如下所示：

WorkerThread-2, READ: Unknown-3.3 Handshake, length = 116
*** ClientHello, Unknown-3.3
RandomCookie:  GMT: 1513485218 bytes = { 151, 69, 77, 255, 242, 138, 61, 245, 71, 237, 98, 49, 92, 122, 152, 21, 229, 164, 150, 171, 11, 177, 238, 234, 63, 168, 90, 151 }
Session ID:  {}
Cipher Suites: [Unknown 0xc0:0x28, Unknown 0xc0:0x27, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, Unknown 0x0:0x3d, Unknown 0x0:0x3c, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp384r1, secp256r1}
Extension ec_point_formats, formats: [uncompressed]
Unsupported extension signature_algorithms, data: 00:12:06:01:06:03:04:01:05:01:02:01:04:03:05:03:02:03:02:02
Unsupported extension type_35, data:
Unsupported extension type_23, data:
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Created:  [Session-180, TLS_RSA_WITH_AES_128_CBC_SHA]
*** ServerHello, TLSv1
RandomCookie:  GMT: 1513485220 bytes = { 74, 28, 71, 12, 232, 178, 237, 132, 60, 224, 123, 53, 189, 12, 182, 240, 206, 94, 159, 96, 89, 29, 71, 144, 161, 254, 84, 32 }
Session ID:  {90, 54, 244, 164, 39, 152, 221, 223, 132, 77, 169, 99, 15, 202, 26, 191, 213, 70, 91, 125, 141, 91, 159, 248, 11, 145, 254, 187, 97, 178, 14, 233}
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
Cipher suite:  TLS_RSA_WITH_AES_128_CBC_SHA
*** Certificate chain
      [... certificate chain follows ...]
***
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:
<CN=QuoVadis Root CA 2 G3, O=QuoVadis Limited, C=BM>
<CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US>
    .... many more cert authorities
WorkerThread-2, WRITE: TLSv1 Handshake, length = 16384
*** ServerHelloDone
WorkerThread-2, WRITE: TLSv1 Handshake, length = 1403
WorkerThread-2, READ: TLSv1 Handshake, length = 3983
*** Certificate chain
chain [0] = [
    ... client certificate chain follows
...
    ... connection proceeds normally and suceeds

如您所见，握手似乎是正常的，服务器请求客户端通过证书进行身份验证，然后客户端将其发送。但是，对于仅一台第三方服务器（我无权访问），握手过程如下：

WorkerThread-2, READ: TLSv1 Handshake, length = 159
*** ClientHello, Unknown-3.3
RandomCookie:  GMT: -750761141 bytes = { 238, 28, 230, 74, 9, 73, 28, 198, 222, 183, 234, 204, 37, 117, 50, 44, 71, 133, 93, 240, 66, 157, 241, 152, 75, 168, 0, 174 }
Session ID:  {}
Cipher Suites: [Unknown 0xc0:0x2b, Unknown 0xc0:0x2f, Unknown 0xcc:0xa9, Unknown 0xcc:0xa8, Unknown 0xc0:0x2c, Unknown 0xc0:0x30, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, Unknown 0x0:0x9c, Unknown 0x0:0x9d, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
Compression Methods:  { 0 }
Extension renegotiation_info, renegotiated_connection: <empty>
Unsupported extension server_name, [host_name: smtp3.myserverdns.com]
Unsupported extension type_23, data:
Unsupported extension type_35, data:
Unsupported extension signature_algorithms, data: 00:12:04:03:08:04:04:01:05:03:08:05:05:01:08:06:06:01:02:01
Extension ec_point_formats, formats: [uncompressed]
Extension elliptic_curves, curve names: {unknown curve 29, secp256r1, secp384r1}
***
%% Created:  [Session-189, TLS_RSA_WITH_AES_128_CBC_SHA]
*** ServerHello, TLSv1
RandomCookie:  GMT: 1513485240 bytes = { 91, 241, 167, 85, 144, 140, 202, 57, 192, 1, 43, 95, 77, 164, 68, 210, 170, 37, 114, 50, 237, 255, 17, 205, 131, 74, 242, 21 }
Session ID:  {90, 54, 244, 184, 141, 168, 116, 151, 23, 155, 13, 108, 239, 23, 28, 117, 51, 182, 85, 174, 138, 132, 254, 29, 235, 231, 30, 184, 40, 27, 38, 145}
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
Cipher suite:  TLS_RSA_WITH_AES_128_CBC_SHA
*** Certificate chain
chain [0] = [
[
  [... certificate chain follows ...]
***
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:
<CN=QuoVadis Root CA 2 G3, O=QuoVadis Limited, C=BM>
<CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US>
    .... many more cert authorities
WorkerThread-2, WRITE: TLSv1 Handshake, length = 16384
*** ServerHelloDone
WorkerThread-2, WRITE: TLSv1 Handshake, length = 1403
WorkerThread-2, handling exception: java.net.SocketTimeoutException: Read timed out
WorkerThread-2, called close()
WorkerThread-2, called closeInternal(true)
WorkerThread-2, SEND TLSv1 ALERT:  warning, description = close_notify
WorkerThread-2, WRITE: TLSv1 Alert, length = 2
WorkerThread-2, called close()
WorkerThread-2, called closeInternal(true)
WorkerThread-2, called close()
WorkerThread-2, called closeInternal(true)

如您所见，在 ServerHelloDone之后，客户端没有响应立即到达，并且套接字超时发生。实际上，超时总是在大约1.5秒后进行。握手开始后。

为什么这么短的时间后套接字超时？我认为服务器问候中的某些内容对客户端来说不行，但是我不知道该怎么办。您是否看到两个ssl调试日志之间的任何显着差异证明了失败？我已经在互联网上搜索了好几个小时，没有运气。

Answer 1

Meta：不是答案，但是评论太长；我将在几天后删除。

在许多协议中，传输单元的“飞行”是一组一起发送的几个单元。在SSL / TLS握手协议中，客户端发送一条消息（ClientHello），然后服务器发送多条消息，这是其第一次飞行，并且由于客户端的飞行是微不足道的（一条消息），因此我仅将服务器的第一次飞行标记为第一次飞行。它总是由ServerHello，通常是Certificate，有时是ServerKeyExchange，很少有CertificateRequest以及ServerHelloDone组成。在此之后，客户端通常会发送多个消息的第二个航班，然后服务器发送第二个航班同上。请参见第36页的rfc5246 (scroll down)图表或早期版本中的等效图表。

显然，第一次飞行引起了一些问题。原因可能是其中的消息之一，也可能是由单个TLS记录或几个连续的TLS记录组成的较低层（TCP）传输；在您的情况下，每个日志行有两个记录

... WRITE: TLSv1 Handshake, length = 16384
... WRITE: TLSv1 Handshake, length = 1403

可以将TLS握手消息打包到记录中，但是TLS记录限制为16384，并且第一次飞行的合并消息超出了该范围，因此需要两个记录。查看通常仅在“有线”（物理或逻辑网络）级别可见的TCP行为的痕迹可以帮助我们区分。

TCP协议太复杂了，如果您还不了解，我在这里无法解释。可能有数百本关于“ TCP / IP”协议族或“堆栈”的书，甚至还有数百万个网站。对我来说， wikipedia相当严格和透彻，但仍然没有疯狂的困难。但是简而言之，一旦建立连接，当一个端点发送了一些数据（在一个或多个段大小的数据报中，在本例中为TLS记录时，它们不一定与上层数据单元匹配）时，如果另一端点正确接收到该数据，通常将以TCP报头作为响应，在该TCP报头中，“ ACK”值已增加到传输数据中“ SEQ”值的范围之外。如果确实看到这样的ACK值，那么我们就知道传输的数据已传递到远程系统上的TLS端点，并且如果您看到整个飞行的ACK，我们就知道该飞行已经传递，并且任何紧随其后的问题都是由于远程端点处理消息。

OTOH，如果我们没有看到这样的ACK，则意味着远程主机未接收到数据段。在过去，这有时意味着由于链接错误或延迟而造成的损失，但是在现代Internet上，链接几乎总是可靠且快速的，几乎总是意味着数据被丢弃。特别是，如果您的系统，远程系统或两者之间的任何网络链接之间由于“ MTU”大小（即“最大传输单位”）不匹配，则可能导致数据报被丢弃，因此传输失败。 TCP具有一种旨在纠正此问题的机制，称为PMTU（路径MTU）发现，但是它依赖于ICMP，并且在现代Internet中，许多人阻止ICMP是因为他们通常（但并非总是错误地）认为这是一个安全问题。

Wireshark（在Windows，Mac和某些Linux / Unix上）是一个（非常）基于GUI的工具，用于捕获和解码网络数据。 tcpdump是在某些Unix（通常包括Linux）上用于相同目的的更基本的命令行工具；其他一些Unix也使用类似的工具，但名称和细节有所不同。您没有提及正在使用的操作系统，所以我没有具体说明。

tcpdump默认情况下会解码IP和TCP标头，因此您可以简单地查看每个line = packet所显示的seq和ack值，并牢记每个在IP级别上的方向；如果主机和网络上同时存在其他活动，则 tcpdump可以过滤并捕获并显示哪些数据包，从而使读取变得非常容易。 tcpdump还具有捕获到一个或多个文件（通常称为something.pcap）而不显示的选项。 Wireshark通常为每个帧解码多个协议层，因此您需要在数据包详细信息窗格中为每个数据包查看“ Internet协议”和“传输控制协议”层。它既可以保存到显示文件中，也可以保存到显示文件中，并且具有（不同的）选项可以在捕获和显示时进行过滤。如果您自己无法弄清轨迹，则将 tcpdump或等效文本输出放在Q中可能就足够了，但是可能需要将二进制pcap文件放在可访问的位置。