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

Scrapeless プロキシは、安全なターゲット接続が依然として正常な TLS ネゴシエーションを必要とする HTTP クライアント向けにルーティングを提供します。

SSL ハンドシェイクの失敗とは、クライアントとセキュアなピアが、安全な接続を確立するために必要なネゴシエーションを完了できなかったことを意味します。モダンな HTTPS は TLS を使用しますが、古い「SSL」という呼称はエラーメッセージ内で依然として一般的です。失敗は、プロトコルの互換性、サーバーの識別情報、クライアント認証、あるいは交換の中断などに関係し得るため、どのアラートが出たかと、どの段階まで処理が完了しているかによって、調査内容が決まります。

TLS ハンドシェイクが確立するもの

TLS ハンドシェイクは、クライアントとサーバーによって使用される、合意されたセキュリティコンテキストを確立します。これには、互換性のあるプロトコルの選択と、選択されたモードに必要な認証が含まれます。このやり取りが完了できない場合、通常の保護されたアプリケーションデータは意図したとおりに処理を続行できません。

The TLS プロトコルおよびハンドシェイク仕様 ネゴシエーションとアラートの動作を定義します。アラートは有用な証拠を提供することがありますが、アプリケーションログにおける「ハンドシェイク失敗」は、多くの場合、より具体的な問題を包み隠しているラッパーにすぎません。根本的な原因と、クライアントが証明書を受け取ったか、プロトコルをネゴシエートしたかどうかを保持してください。

接続に TLS が使用されている場合でも、ユーザー向けメッセージやライブラリ名の中では「SSL」という用語が残っています。エラー文言だけを根拠に、最新のエンドポイントが古い SSL プロトコルを実行していると早合点してはいけません。障害においてプロトコルバージョンが重要である場合は、実際のクライアントおよびサーバーの構成を確認してください。

収集プログラムにとって、ハンドシェイクの失敗は接続診断の結果です。これはターゲットアプリケーションから返される HTTP ステータスではなく、有効な空リソースの証拠でもありません。安全な接続および必要なコンテンツチェックが完了するまでは、ソースレコードは未受け入れのままにしておく必要があります。

プロトコル互換性と誤ったリスナー

TLS のネゴシエーションには、クライアントとセキュアピアの間で互換性のある選択が必要です。クライアントがサポートしていない設定に制限されたサーバーは、アプリケーションデータが交換される前に失敗する可能性があります。広く「すべてのバージョンを有効にする」という修正をそのまま適用するのではなく、特定のクライアントビルドとアクティブなリスナーのサポートされている設定を比較してください。

誤ったリスナーは、同様の高レベルの症状を引き起こす可能性があります。クライアントが TLS を想定しているのに、設定されたポートがプレーンな HTTP や別のプロトコルを提供している場合、有用な証明書の証拠を提示できる前に通信が失敗する可能性があります。サービスのスキームとアクティブなリスナーを組み合わせて検証してください。ポート番号だけでは、プロトコルを保証できません。

所有者が管理するエンドポイントの場合、接続を受け取るエッジまたはリバースプロキシを調査します。アプリケーションの内部リスナーは、外部のセキュアリスナーとは異なる場合があります。デプロイメントでは、アプリケーションコードは正しく構成されていても、パブリックな終端レイヤーが互換性のない設定を提示していることがあります。失敗しているクライアントが実際に遭遇しているピアを診断してください。

古いアルゴリズムを一括して再有効化するのではなく、現在サポートされているセキュリティ設定を使用してください。互換性の欠陥は、想定されているクライアントとサービスを、許容可能な共通設定に揃えることで修正するのが最善です。将来のイメージやエッジの変更によって、この不一致が黙って再び持ち込まれないよう、最終的なポリシーは文書化しておいてください。

証明書の検証は、ハンドシェイク失敗の一因となり得る

クライアントが自身のポリシーに基づいてサーバーを認証できない場合、証明書検証によってハンドシェイクが中断されることがあります。要求されたホスト名、有効期間、または発行者パスに対して証明書が不適合となる可能性があります。これは、一般的なハンドシェイク失敗よりも原因を限定した診断です。

The TLS サービス ID 仕様 意図されたサービス名と、安全なピアによって提示されるアイデンティティとの関係を説明します。失敗したリクエストで使用されたホスト名は、そのまま正確に保持してください。同じアドレスに別のサービス名で接続すると、異なるアイデンティティコンテキストが露出する可能性があり、自動的に同等のテストとして扱ってはなりません。

クライアントは証明書を受け取ってからそれを拒否する場合もあれば、証明書が受信される前にネゴシエーションが失敗する場合もあります。この違いを記録してください。失敗が証明書の証拠が存在する前に発生した場合、有効期限切れの証明書を報告することはサポートされていない結論です。検証で明示的に不一致や発行者の問題が報告された場合は、そのチェックを直接調査してください。

curl における TLS 証明書の検証 クライアントの信頼設定が重要である理由を示しています。ブラウザ、コマンドラインクライアント、コンテナランタイムは、異なる信頼ソースを使用することがあります。検証動作を変更する前に、各クライアントが実際に何を受信し、何を信頼したのかを比較してください。ブラウザでのアクセスが成功したからといって、HTTP クライアントが自身の証明書エラーを無視する必要があるわけではありません。

クライアント証明書と相互認証

TLS サーバーは、クライアントに証明書による認証を要求することができます。この要件は、プロキシパスワードや通常のウェブサイトへのログインとは別のものです。クライアント証明書が存在しない、不適切である、または認可されていない場合、サーバー証明書が有効であっても、安全なセッションが完了しないことがあります。

クライアント証明書を提供する前に、そのサービスの文書化された認証要件を確認してください。自社が所有する内部 API の場合、承認されたシークレット管理メカニズムを通じて、証明書および対応する秘密鍵が、想定されたプロセスから利用可能であることを検証してください。証明書ファイルだけでは、クライアントがその秘密鍵を使用できることは保証されません。

クライアント認証情報は、認可されたサービスの範囲内に限定して保持してください。秘密鍵をサポート記録に書き出したり、一般的なブラウザ自動化ログに記録したりしてはいけません。有用なインシデント記録では、鍵マテリアルを公開することなく、設定済み証明書の秘密ではない参照情報、サービス要件、およびエラーカテゴリを特定できるようにする必要があります。

一般公開されているサードパーティリソースにおいて、予期しないクライアント証明書の要件が発生した場合は、誤ったエンドポイントか、制限されたサービス境界を示している可能性があります。想定されている公開URLとアクセス要件を確認してください。コレクターは、匿名ルーティングによってハンドシェイクを修正できると仮定するのではなく、そのアクセス条件を記録すべきです。

プロキシルート上でセキュアピアを特定する

プロキシルートには、複数のセキュア接続が含まれる場合があります。TLS を扱うプロキシには、クライアントからプロキシへのセキュアなやり取りがあり、HTTPS ターゲットには、多くの場合トンネル内部で行われるターゲットとのセキュアなやり取りがあります。承認された検査ゲートウェイは、セキュアなトラフィックを終端し、再作成することができます。ハンドシェイクに失敗したピアに名前を付けてください。

以下を日本語に翻訳してください。 TLS インスペクションと不透明トンネルの区別 そのトポロジーを解釈するうえで有用なコンテキストを与える。通常のトンネルは、ターゲットの TLS エンドポイントでなくても、暗号化されたターゲットバイト列を転送できる。トンネルが開く前の障害はプロキシのセットアップに属し、その時点以降の障害はターゲットとのセキュアなやり取りに関係しうる。

It looks like your message got cut off before including the text you want translated. Please send the English text you’d like translated into Japanese, and I’ll follow your rules exactly. スクレイプレスプロキシ接続の構成 ゲートウェイのトランスポートおよび認証値を確立するためです。宛先の HTTPS スキームは、安全なゲートウェイスキームを自動的には選択しません。クライアントのプロキシ構成とサポートされているリスナーとの不一致により、期待されるハンドシェイクシーケンスが開始されない場合があります。

ゲートウェイ段階とトンネル段階を確認したら、ターゲットの TLS 結果を検査してください。ターゲットのホスト名、セキュアなピア ID、証明書の結果、および利用可能であればアラートまたはクライアントエラーを記録します。目的は、プロキシルート全体を「SSL が壊れている」という一言で片付けてしまうのではなく、どの接続が失敗したのかを保持することです。

ハンドシェイクの失敗を隣接するイベントと比較する

ハンドシェイクの失敗は広範なカテゴリであるため、隣接する段階との比較によって、次に行うべき作業が本当に TLS の診断かどうかを判断するのに役立ちます。

名前解決に失敗すると、安全な接続が試行されない場合があります。プロキシが CONNECT を拒否した場合、ターゲットとのハンドシェイクが開始されないことがあります。TLS が完了し、ターゲットがアプリケーションのエラーステータスを送信した場合、それは HTTP の結果です。各観測結果は、それが発生した段階にとどめておいてください。

セットアップ中のタイムアウトには、タイミングとピアからの証拠も必要です。これは特定の暗号方式や証明書の問題を特定するものではありません。クライアント側の締め切り時間と、計測されたセットアップフェーズを比較し、レスポンスやアラートが存在したかどうかを確認してください。応答のないやり取りと、明示的なネゴシエーション拒否は異なる種類の証拠です。

セキュア接続診断レコードを構築する

SSL ハンドシェイクの失敗に関する有用な記録には、ターゲットのオーソリティ、実際のセキュアピア、ルート、クライアントビルド、および最後に完了したステージが含まれます。公開されている場合は、元のエラーと証明書検証カテゴリを追加します。HTTP に到達しなかった通信については、推測した HTTP ステータスを保存しないようにします。

自前のインフラストラクチャの場合、クライアントイベントをエッジおよびサーバーの TLS ログと相関させます。同じ意図されたサービス構成の下で、失敗しているクライアントと正常に動作しているクライアントを比較します。もし違いがある場合は、プロトコルサポート、信頼ソース、クライアント認証、およびそれぞれのクライアントが実際に到達したエンドポイントを調査します。これらの違いを利用して、検証可能な仮説を選びます。

Web コレクションでは、ハンドシェイク診断を抽出出力とは分離して保持してください。セキュア接続の失敗によって、ソースの最後の有効なレコードを削除したり、エラーページを含む代替レコードを作成したりしてはいけません。失敗したキャプチャイベントを保存し、ワークフローが新たな受理された証拠を取得するまで、既知のソース状態を維持してください。

次のテキストを英語から日本語に翻訳してください。 ルール: 1. 翻訳されたテキストのみを出力してください — 説明や余分なコードフェンスは不要です。 2. Markdown/HTML 構造（見出し、リスト、リンク、表）をそのまま正確に保持してください。 3. @@CODEBLOCK_0@@ や @@INLINECODE_0@@ のようなプレースホルダー・トークンは、一切変更せずそのまま残し、翻訳・並べ替え・結合・再整形をしないでください。 4. ``` のコードフェンスを追加・削除せず、通常のテキストをコードブロックで囲まないでください。 スクレイプレスプロキシネットワーク 独自の TLS 検証を維持しつつ、マネージドなルーティングを必要とするクライアントに適合します。 現在の Scrapeless のプラン ルートおよびトラフィック要件に対して。マネージドルーティングは、制御された比較のために使用されるパスを変更することはできますが、宛先のセキュアな構成が正しいことを保証することはできません。

意図されたセキュリティポリシーとの完全なネゴシエーション

SSL ハンドシェイクの失敗を解決するとは、クライアントと想定された安全なピアが、互換性があり認証された交換を完了することを意味します。証拠から示されているリスナー、プロトコル設定、サービス ID、信頼ソース、またはクライアント証明書設定を修正してください。

検証を有効にして必須ルート経由で元のリソースを検証します。次に、HTTP レスポンスとコンテンツの同一性を確認します。ハンドシェイクの成功は必要な接続マイルストーンですが、利用可能なソースキャプチャには、その後の段階も完了する必要があります。