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秒后aprox。握手开始后。

为什么套接字在这么短的时间后超时？我认为服务器问候中的某些东西对客户来说并不合适，但我不知道它是什么。您是否看到两个ssl调试日志之间存在任何明显差异，证明失败是正确的？我一直在互联网上搜索几个小时而没有运气。

Answer 1

Meta：不是答案，但是评论的时间太长了;我会在几天后删除。

在许多协议中，a＆＃39;航班＆＃39;传输单元是一组一起发送的单元。在SSL / TLS握手协议中，客户端发送一条消息（ClientHello），然后服务器发送多条消息，这是第一次飞行，并且由于客户端的航班很简单（一条消息），我只需标记服务器＆＃39第一次飞行是第一次飞行。它总是包含ServerHello，通常是Certificate，有时是ServerKeyExchange，很少是CertificateRequest，总是是ServerHelloDone。通常在此之后，客户端发送第二个航班的几个消息，然后服务器再次发送第二个航班。请参阅rfc5246 (scroll down)第36页上的图表或早期版本中的等效图表。

显然，这次首飞的事情引起了一个问题;原因可能是 in 中的消息之一，或者是由单个TLS记录或几个连续记录组成的低级别（TCP）传输;在你的情况下，它是两条记录，按日志行

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

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

如果您还不知道TCP，那么我在这里解释的协议太复杂了。可能有数百本关于“TCP / IP”的书籍。协议系列或堆栈＆＃39;，很可能是数百万个网站。因为我的钱wikipedia相当严谨和彻底，同时仍然不是非常困难。但简而言之，一旦建立了连接，当一个端点发送一些数据时（在一个或多个段大小的数据报中，如果另一个端点正确接收到这些数据，则不一定与TLS记录中的高级数据单元相匹配）通常会响应一个TCP标头，其中包含“确认”。值增加超过＆＃39; SEQ＆＃39;传输数据中的值。如果我们确实看到了这样的ACK值，那么我们知道传输的数据已经传送到远程系统上的TLS端点，如果您看到整个航班的ACK，我们就知道航班已经交付，任何紧接着的后续问题都是由于远程端点处理消息。

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

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

默认情况下，

tcpdump解码IP和TCP标头，因此您可以简单地查看每个line =数据包显示的seq和ack值，同时牢记每个IP级别的方向;如果您的主机和网络上同时存在其他活动，tcpdump可以选择过滤捕获和显示的数据包，使其更易于阅读。 tcpdump还可以选择捕获一个或多个文件（通常名为something.pcap）而不是显示。 Wireshark通常会为每个帧解码多个协议层，因此您需要查看“互联网协议”＆＃39;和传输控制协议＆＃39;每个数据包的数据包详细信息窗格中的图层;它可以保存到捕获文件以及显示，并具有（不同的）选项，可以在捕获和显示时进行过滤。如果您无法自己找出跟踪，那么在Q中放置tcpdump或等效文本输出可能就足够了，但可能需要将二进制pcap文件放在可访问的位置。

TLS连接中ServerHelloDone之后的SocketTimeoutException

1 个答案: