PCAP での TLS ハンドシェイクの失敗: ClientHello、ServerHello、証明書、アラート、および証拠のリセット
ClientHello、ServerHello、証明書、アラート、TCP リセットの証拠を読み取ることで、パケット キャプチャでの TLS ハンドシェイクの失敗を診断する方法
TLS ハンドシェイクの失敗は、多くの場合、「SSL エラー」、「証明書の問題」、「ハンドシェイクの失敗」、または「接続のリセット」として報告されます。これらのメッセージは便利ですが、PCAP はハンドシェイクがどこで停止したかを示すことができます。その場所が重要です。
「ServerHello」の前の TLS 障害は、証明書検証アラートとは異なります。 「ClientHello」後の TCP リセットは、証明書交換後の致命的な TLS アラートとは異なります。パケット キャプチャ タイムラインによって境界を特定できます。
TCP接続から始める
TLS をデバッグする前に、TCP を確認します。
- SYN
- SYN/ACK
- ACK
- クライアントからのデータ
TCP が確立しない場合、これは TLS ハンドシェイクの失敗ではありません。それはルーティング、ファイアウォール、ポート、サーバー到達可能性、または TCP ポリシーです。
TCP が確立され、クライアントが「ClientHello」を送信すると、TLS が開始されます。
ClientHello はクライアントが提供したものを表示します
「ClientHello」により次のことが明らかになります。
- サポートされている TLS バージョン
- 提供される暗号スイート
- SNI ホスト名
- ALPNプロトコル
- サポートされているグループ
- 署名アルゴリズム
SNI が欠落している場合、サーバーはデフォルトの証明書を返すか、ハンドシェイクを拒否することがあります。クライアントが古いプロトコルまたは暗号のみを提供している場合、サーバーはハンドシェイクの失敗またはリセットで応答する可能性があります。
このため、キャプチャは古い組み込みクライアント、プロキシ、カスタム統合に役立ちます。
ServerHello または ServerHello なし
クライアントが ClientHello を送信しても ServerHello が到着しない場合は、次のように検査します。
- ファイアウォールまたはミドルボックスのドロップ
- サーバーポリシーがサイレント終了します
- 大きなハンドシェイク メッセージに関する MTU/パスの問題
- サーバーからの TCP リセット
- ロードバランサの動作
「ServerHello」が到着したら、選択したバージョンと暗号を検査します。サーバーの選択が、後の失敗の原因となる可能性があります。
アラートはノイズではなく証拠です
TLS アラートは非常に有益な情報を提供します。
- 不明な CA
- 不正な証明書
- ハンドシェイクの失敗
- プロトコルのバージョン
- 不正なパラメータ
- 閉じる 通知する
証明書配信後のクライアントからの致命的なアラートは、多くの場合、信頼チェーン、ホスト名の不一致、期限切れの証明書、またはサポートされていない証明書のプロパティを示します。 「ClientHello」の後のサーバーからの致命的なアラートは、暗号、プロトコル、SNI、クライアント証明書、またはポリシーを示している可能性があります。
キャプチャをトリミングするときにアラートを破棄しないでください。
PCAP 手術が適している場所
PCAP 手術は、エンジニアが TLS 会話を分離し、ハンドシェイクの証拠を保存するのに役立ちます。 TLS サポートに役立つ派生キャプチャには次のものが含まれます。
- TCPハンドシェイク
- ClientHello
- ServerHello (存在する場合)
- 証明書メッセージが存在する場合
- TLS アラート
- TCP リセット
- メッセージ間のタイミング
キャプチャをサニタイズする必要がある場合は注意してください。証明書の詳細、SNI、またはペイロード長を削除すると、失敗の原因が取り除かれる場合もあります。サニタイズの決定は、トラブルシューティングの目標と一致している必要があります。
「TLS ハンドシェイク失敗 pcap」、「ClientHello no ServerHello」、「SSL アラート不明 CA Wireshark」などの検索クエリの場合、答えはハンドシェイク境界内にあります。優れたパケット サージェリー ワークフローでは、その境界を隠すのではなく保持します。