TLS接続のServerHelloDone後のSocketTimeoutException

Question

SSLServerSocketを使用して作成されたサーバーがあります。サーバーは他の多くのサーバーから接続を受け取ります。他のサーバーは第三者のものです。そのうちの1つを除き、常にすべてのサーバーでうまく動作します。一般的な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 

握手が通常のようだあなたが見ることができるように、サーバーは、証明書によって認証するクライアントが要求し、クライアントはそれを送信します。しかし、（私はにはアクセスできません）サードパーティのサーバの1つだけ、次のようなハンドシェイクが進む：

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) 

あなたが見ることができるように、inmediatelyをServerHelloDone後にクライアントからの応答が到着しないとソケットタイムアウトが発生します。実際、タイムアウトは常にわずか1.5秒後です。ハンドシェイク開始後。

なぜこのような短時間の後にソケットのタイムアウトが発生するのですか？私はサーバーの中に何かがクライアントのために大丈夫ではないと思うが、何ができるか分からない。障害を正当化する2つのsslデバッグログの間に大きな違いがありますか？私は運がない時間にインターネットで検索してきました。

Answer 1

メタ：答えはありませんが、コメントは長すぎます。私は数日後に削除されます。

多くのプロトコルでは、送信ユニットの「飛行」は、一緒に送信される複数のユニットのグループです。 SSL/TLSハンドシェークプロトコルでは、クライアントは1つのメッセージ（ClientHello）を送信し、サーバーは最初の飛行である複数のメッセージを送信します。クライアントの飛行は簡単です（1つのメッセージ）。 ServerHello always、Certificate通常、ServerKeyExchange、CertificateRequestまれに、ServerHelloDoneは常にあります。この後、通常、クライアントは複数のメッセージの2番目のフライトを送信し、次にサーバーは2番目のフライトを送信します。以前のバージョンでは、rfc5246 (scroll down)またはそれに相当するページ36の図を参照してください。

明らかに、この最初の飛行について何か問題が発生しました。原因はののメッセージの1つであるか、または単一のTLSレコードまたは数個の連続したものからなる低レベル（TCP）送信のいずれかである可能性があります。あなたのケースでは、ログの行ごとに

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

TLSハンドシェイクメッセージは、レコードにパックすることができますが、TLSレコードが16384に制限されているし、あなたの最初のフライトの組み合わせメッセージがそう、それは二つのレコードが必要であることを超えて、二つのレコードです。通常、 'wire'（物理的または論理的なネットワーク）レベルでしか見えないTCP動作の痕跡を見ると、区別するのに役立ちます。

TCPはあまりにも複雑なプロトコルで、私がここで説明するのは難しいです。 「TCP/IP」プロトコルファミリや「スタック」についてはおそらく何百もの書籍があり、おそらく何百万ものウェブサイトがあります。私のお金のためにwikipediaは非常に厳密かつ徹底的でありながら、まだまだ難しいことではありません。しかし、いったん接続が確立されるとすぐに、一方のエンドポイントがこのデータを正しく受信すると、あるエンドポイントが（1つ以上のセグメントサイズのデータ​​グラムで、この場合はTLSレコードの上位レベルのデータユニットと一致しない）通常、「ACK」値が送信されたデータの「SEQ」値の範囲を超えて増分されたTCPヘッダで応答する。このようなACK値が表示された場合、送信されたデータがリモートシステムのTLSエンドポイントに配信されたことがわかります。フライト全体に対してACKが表示されたら、フライトが配信されたことがわかります。リモートエンドポイントはメッセージを処理します。

OTOHこのようなACKが表示されない場合は、リモートホストがデータセグメントを受信しなかったことを意味します。過去にはこれはリンクのエラーや遅延による損失を意味することもありましたが、リンクがほとんど常に信頼性が高く高速な現代インターネットでは、ほとんどの場合、データはが破棄されたことを意味します。。特に、システム、リモートシステム、または「MTU」サイズ、つまり「最大伝送ユニット」の間のネットワークリンクのいずれかに不一致があると、データグラムが破棄される可能性があります。送信に失敗しました。 TCPには、PMTU（path MTU）ディスカバリと呼ばれるこれを修正するためのメカニズムがありますが、ICMPに依存します。現代のインターネットでは、多くの人がICMPをブロックします。

Wireshark（Windows、Mac、および一部のLinux/Unix）は、ネットワークデータをキャプチャしてデコードする（非常に）完全なGUIベースのツールです。 tcpdumpは、通常はLinuxを含むいくつかのUnixの同じ目的のためのより基本的なコマンドラインツールです。他のいくつかのUnixには、異なる名前と異なる詳細を持つ同様のツールがあります。あなたは私が特定ではなかったので、あなたが使用しているOSについて言及していませんでした。

tcpdumpデフォルトでは、IPヘッダーとTCPヘッダーがデコードされるため、IPレベルでそれぞれの方向を念頭に置いて、各行=パケットのseqとackの値を調べるだけです。ホストとネットワーク上に同時に他のアクティビティがある場合は、tcpdumpにはどのパケットをキャプチャして表示するかをフィルタするオプションが用意されているため、読みやすくなっています。 tcpdumpには、表示するのではなく、ファイル（通常はsomething.pcapという名前）にキャプチャするオプションもあります。 Wiresharkは通常、フレームごとに複数のプロトコルレイヤをデコードします。したがって、各パケットのパケット詳細ペインで 'インターネットプロトコル'と '伝送制御プロトコル'レイヤーを調べる必要があります。キャプチャファイルと同様にの表示に保存でき、キャプチャ中と表示中の両方をフィルタリングする（異なる）オプションがあります。自分でトレースを見つけられない場合は、tcpdumpまたは同等のテキスト出力をQに入れても十分ですが、バイナリpcapファイルをどこかにアクセス可能にする必要があります。