SSLハンドシェイクの失敗とは何ですか？

Scrapeless Scraping Browserは、ブラウザネイティブのTLSおよびレンダリングされたページの動作が必要なパブリックウェブワークフローのために、管理されたクラウドブラウザでブラウザセッションを実行します。

両方のピアが同意するまで暗号化は開始できません

SSLハンドシェイクの失敗は、クライアントとサーバーがHTTPSアプリケーションデータの流れを開始するために必要な交渉を完了できなかったことを意味します。現代のプロトコルはTLSですが、ブラウザのメッセージ、ライブラリ、およびサーバーログは依然としてSSLを一般的なラベルとして使用します。

ハンドシェイクはプロトコルパラメータを選択し、共有キーを確立し、証明書でサーバーを認証し、クライアントを認証する場合があります。これらの段階のいずれかでの失敗は、修正が異なっても一般的なメッセージを生成することがあります。証明書を変更してもプロトコルの不一致は修正されず、古いプロトコルを有効にすると、欠落した証明書チェーンに対処せずにセキュリティが弱まることがあります。

診断は実際のホスト名で接続を再現し、アラートと証明書チェーンを観察して、もう一つの現在のクライアントと比較し、サーバー側のTLSログを検査する必要があります。目標は、暗号ポリシーを変更する前に期待に合わなかった最初のハンドシェイクメッセージを特定することです。

SSLハンドシェイクの失敗の直接的な意味

SSLハンドシェイクの失敗は、TLSピアが認証されたキー確立を完了できず、暗号化されたセッションに必要なパラメータに合意できないときに発生します。 RFC 8446 は、TLS 1.3ハンドシェイクを認証されたキー交換として定義し、それによってセッションキー、交渉されたパラメータ、およびピアのアイデンティティが出力されます。

失敗はローカルかリモートである可能性があります。クライアントはサーバー証明書を拒否する場合がありますし、サーバーはクライアントのプロトコルの提案や証明書を拒否する場合があります。ロードバランサーがホスト名に対して間違った証明書を提示することがあるほか、検査プロキシが信頼の経路を変更することもあります。アプリケーションリクエストは通常、HTTPハンドラーに到達しません。

TLSハンドシェイクが停止できる場所

クライアントは、サポートされているバージョン、暗号オプション、拡張、および要求されたサーバー名を持つClientHelloから始まります。サーバーは互換性のあるパラメータを選択し、そのServerHelloを返します。許可されるバージョンまたはアルゴリズムがない場合、交渉はここで終了する可能性があります。

サーバーは次に、自身を証明書チェーンおよび対応するプライベートキーを保持している証拠とともに認証します。クライアントはチェーン、ホスト名、有効期間、署名ポリシー、信頼のアンカーを検証します。中間が欠落しているか、間違ったホスト名はHTTP開始前に接続を停止することができます。

一部のサービスでは、クライアント証明書を要求します。サーバーはそれを要求し、クライアントは適切な証明書を提示し、プライベートキーの所有を証明する必要があります。最後に、両方のピアはハンドシェイクの記録を確認し、トラフィックキーを導出します。これらの段階の近くのアラートは、原因を交渉、サーバーのアイデンティティ、クライアントのアイデンティティ、または整合性に絞ります。

一般的なSSLハンドシェイク失敗の原因

最も役立つカテゴリーは、互換性、サーバーのアイデンティティ、ホスト名のルーティング、クライアント認証、介入です。

最初の壊れたハンドシェイクステージを見つける

正確なホスト名で再現し、プロトコルや信頼設定を変更する前に両方のピアから証拠をキャプチャします。

1. 正確なクライアントエラーとサーバーアラートを記録します。 一般的なブラウザの表現は、同じ時間のライブラリコード、TLSアラート、サーバーログよりも役に立ちません。
2. 実際のホスト名を使用してください。 SNIとホスト名の検証を有効にした状態でテスト; IPにのみ接続すると、別の仮想ホストと証明書が選択される可能性があります。
3. 提示されたチェーンを検査します。 葉証明書、中間順序、ホスト名、名前、検証期間、発行者、署名、およびチェーンが信頼できるルートに到達しているかどうかを確認します。
4. 現在のクライアントを比較します。 最新のブラウザが動作するが古いランタイムが失敗する場合、サポートされているTLSバージョン、署名アルゴリズム、および信頼ストアを比較します。
5. サーバーの選択を確認します。 ロードバランサー、イングレス、および仮想ホストが要求された名前のために意図した証明書とTLSポリシーを選択することを確認してください。
6. クライアント証明書ポリシーをレビューします。 相互TLSの場合、要求された発行者、クライアント証明書の使用、チェーン、および秘密鍵アクセスを検査します。
7. 承認されたインスペクションを通じておよびその周りで比較します。 ネットワーク管理者とともに、企業のプロキシまたはセキュリティ製品が証明書またはハンドシェイクパスを変更しているかどうかを確認します。

ハンドシェイクモデルは TLS 1.3仕様, Chromeの安全な接続ガイダンスは Chrome安全な接続ヘルプ, Mozillaの証明書エラー分類は Mozilla証明書エラーガイダンス 信頼の失敗から交渉を分離するのに役立ちます。

ユーザーのための安全なチェック

TLSの失敗は接続を保護するため、応答はその保護を保持しつつ、ローカル条件を孤立させる必要があります。

• デバイスの時計を確認します。 日付、時間、およびタイムゾーンは、証明書の有効性チェックのために正しい必要があります。
• ブラウザとオペレーティングシステムを更新します。 現在のクライアントは最新のプロトコルサポートと信頼ストアの更新を持っています。
• 他の信頼できるネットワークを比較します。 キャプティブポータル、VPN、またはインスペクションプロキシは、ハンドシェイクと提示された証明書を変更する可能性があります。
• 不明なルート証明書をインストールしないでください。 信頼する前に、管理者に職場または学校の証明書を確認してください。

サーバーサイドTLS修復

運営者は、モダンなプロトコルと証明書ポリシーを維持しながら、失敗したステージを修復する必要があります。

意図した証明書チェーン全体を提示し、正しいホスト名にバインドし、秘密鍵へのアクセスを確認します。すべてのエッジリージョンとロードバランサーリスナーをテストしてください。古いノードの1つが残りのフリートとは異なるアイデンティティを提示する可能性があります。

サポートされている最新クライアントとサーバーアルゴリズムの意図的な重複を維持します。古いランタイムが失敗する場合は、その実際のビジネスニーズをインベントリし、アップグレードしてください。広範な互換性のために廃止されたプロトコルや弱いアルゴリズムを復元することは、露出を増やし、プラットフォームポリシーに違反する可能性があります。

相互TLSの場合、受け入れられたクライアント発行者と使用要件を公開し、拒否理由を監視し、重複でクライアント証明書をローテーションします。ハンドシェイクメトリクスはHTTPメトリクスとは別に保管してください。失敗したTLSセッションはアプリケーションルートに到達しないためです。

ハンドシェイク失敗と証明書エラー

証明書の検証はハンドシェイクの一つの段階ですが、多くのハンドシェイク失敗は証明書の信頼の前または外で発生します。

ブラウザの自動化におけるTLSの失敗

その Scrapeless Scraping Browser は、パブリックウェブの取得のためにブラウザ環境を使用し、TLSとレンダリングの動作をブラウザベースのワークフローと合わせます。ジョブはターゲットホスト名、接続フェーズ、ブラウザエラー、最終ページの検証を記録する必要があります。

自動化を成功しているように見せるために証明書の検証を無効にしないでください。それはサーバーアイデンティティの保証を取り除き、認証情報や収集したデータを露出させる可能性があります。ターゲットに genuineな証明書の欠陥がある場合、ジョブをセキュア接続の失敗として分類し、サイトの所有者に連絡してください。

公開されたまたは認可されているターゲットのみを使用し、セッション認証情報をログに残さないようにしてください。管理されたブラウザはクライアント側の標準化を可能にしますが、ターゲットの許可モデルを変更したり、無効な証明書を信頼できるものにすることはありません。

ハンドシェイク段階を診断し、一般的なラベルを診断しないでください

SSLハンドシェイクの失敗は、TLSネゴシエーションが安全なアプリケーションセッションが確立される前に終了したことを意味します。プロトコルの互換性、暗号化ポリシー、SNIルーティング、サーバー証明書、クライアント証明書、および検査のそれぞれが異なる段階を止める可能性があります。

正確なホスト名で再現し、アラートとチェーンを確認し、現在のクライアントと比較し、サーバーログを相関させます。その段階を修復しながら、証明書の検証と最新のプロトコルポリシーを有効に保ちます。