TLS は HTTPS 接続をどのように実際に保護するのか

「HTTPS は暗号化されている」と言う人もいますが、本当に興味深いのは、ネットワークを介して、聞いている可能性のある多くの人々の間で、会ったことのない 2 人のインターネット上の見知らぬ者が、どのように共有シークレットについて合意するかです。それが TLS が行うことであり、ネットワーキング、Web 開発、またはセキュリティに関わる場合は、メカニクスを理解する価値があります。

ハンドシェイク、ステップバイステップ

ブラウザが https://example.com に接続すると、大まかに以下のことが起こります (ほとんどのサイトで現在使用されている TLS 1.3):

1. ClientHello — ブラウザがサポートされている暗号スイート、ランダム nonce、および鍵交換のための鍵共有の予想 (X25519 または secp256r1 などを使用) を送信します。
2. ServerHello — サーバーが暗号スイートを選択し、独自の鍵共有を送信し、その証明書とその証明書に対応する秘密鍵を保持していることを証明する署名を返します。
3. 鍵導出 — 両側は、鍵共有に対する Diffie-Hellman スタイルの数学を使用して同じ共有シークレットを独立して計算します。どちらもシークレット自体を送信することはなく、それは導出され、送信されません。
4. Finished メッセージ — 両側は、ハンドシェイク トランスクリプト全体の MAC を送信することで、ハンドシェイクが改ざんされていないことを確認します。

その後、共有シークレットから導出された対称鍵を使用してすべてが暗号化されます。通常は AES-128-GCM または ChaCha20-Poly1305 です。TLS 1.3 は TLS 1.2 の 2 ラウンドトリップ ハンドシェイクを事実上 1 ラウンドトリップに削減しました。これは大規模な場合の実際のレイテンシの勝利です。

証明書が暗号化よりも重要な理由

身元確認なしの暗号化は無意味です — 攻撃者を含む誰でも暗号化チャネルを設定できます。証明書は、公開鍵をドメイン名に結びつけるものであり、Let's Encrypt や DigiCine のような認証局 (CA) によって署名されています。

ブラウザは、OS またはブラウザトラストストアに組み込まれたルート CA の固定リストを信頼します。サーバーの証明書は、中間証明書を経由して、それらのルートの 1 つまでチェーン化します。チェーンが検証されない場合、または証明書内のドメインがリクエストしたドメインと一致しない場合、赤い警告ページが表示されます。このチェーンオブトラストモデルが実際のセキュリティ境界です — CA の署名鍵を盗まれると、任意のドメインの有効な証明書を生成できます。これが CA 侵害が重大インシデントとして扱われる理由です。

対称と非対称の暗号化がここで何をしているか

非対称暗号化 (RSA または楕円曲線) は遅く、費用がかかるため、TLS はハンドシェイク中のみ使用します — サーバーを認証し、共有シークレットの確立を支援するためです。それが完了すると、実際のデータ (HTML、JSON など) はすべて高速対称暗号化で暗号化されます。このハイブリッドアプローチは、SSH、PGP、およびほとんどの実際の暗号化システムで見られる同じパターンです: 身元と鍵交換のための非対称、バルクデータのための対称。

前方秘匿性は関連する詳細であり、知る価値があります: 共有シークレットがセッションごとに新しく生成された ephemeral Diffie-Hellman 鍵共有から得られるため、誰かがトラフィックを記録し、後でサーバーの秘密鍵を盗んだとしても、古いセッションを復号化することはできません。そのプロパティは、古い RSA のみの鍵交換には存在しませんでした。

自分で確認する

緑色の南京錠アイコンを盲目的に信頼する必要はありません。以下を実行します:

openssl s_client -connect example.com:443 -tls1_3

これにより、ネゴシエートされた暗号スイート、証明書チェーン、およびハンドシェイクが実際に完了したかどうかが表示されます。ブラウザが見るもののより迅速な確認については、curl -v https://example.com は HTTP レスポンスの前に TLS バージョンと証明書の詳細を出力します。

Chrome または Firefox を起動する前に SSLKEYLOGFILE 環境変数をエクスポートすれば、Wireshark で独自のトラフィックを復号化することもできます — TLS の問題をデバッグするには、推測の代わりに実際に有用です。

これが実際に失敗する場所

ほとんどの実世界の HTTPS の失敗は暗号化破壊ではなく、操作的です: 期限切れの証明書、誤設定された中間チェーン、古い TLS バージョンに閉じ込められたクライアント、混合コンテンツ (HTTPS ページが HTTP リソースを読み込んでいる)。最新の TLS 1.3 に対する実際のプロトコルレベルの攻撃は、仕様が SSL 3.0 と初期 TLS を悩ませたほとんどのパディングオラクルとダウングレードトリックを閉じたため、稀です。弱点は通常、エンドポイントです — 侵害された CA、盗まれた秘密鍵、またはユーザーが通すべきでない証明書警告をクリックしています。

さらに詳しく知りたい場合、Korra Studio のネットワーキングと暗号化セグメントは、基盤となる Diffie-Hellman 数学とパケットレベルのプロトコル分析をより詳細にカバーしています。