TLS ハンドシェイク.

TLS ハンドシェイクは、アプリケーションデータを送る前にプロトコルバージョン、暗号スイート、サーバの身元、セッション鍵を交渉します。TLS 1.2(RFC 5246)ではハンドシェイクは 2 ラウンドトリップを要し、ClientHello、ServerHello、Certificate、ServerKeyExchange に加え、交渉されたトランスクリプトを確認する Finished のペアを使います。TLS 1.3(RFC 8446、2018 年)はこれを 1 ラウンドトリップに短縮し、ServerHello 以降のすべてを暗号化し、旧来のプリミティブ(RC4、AEAD なしの CBC モード、静的 RSA 鍵交換、圧縮)を排除し、0-RTT 再開をサポートします。これは高速ですがリプレイに対して脆弱なため、冪等なリクエストのみを運ぶべきです。

どちらの現代バージョンも前方秘匿性のためにエフェメラルな (EC)DHE を必須とし、信頼チェーンをたどって検証される X.509 証明書によってサーバを認証します。ハンドシェイクのトランスクリプトハッシュと Finished の MAC は、歴史的にダウングレード攻撃や再ネゴシエーション攻撃を破ってきた要素です。POODLE(2014 年)は被害者を SSL 3.0 の CBC パディングへ強制的に引き下げました。FREAK と Logjam(2015 年)はエクスポートグレードの RSA/DH を強要し、BEAST は TLS 1.0 の CBC IV を悪用しました。TLS 1.3 ではサーバのランダム値に組み込まれたダウングレード保護のセンチネルが、改ざんを知らせるようになりました。運用上重要なその他の障害モードには、弱いまたは非推奨の暗号スイート、期限切れや誤発行の証明書、OCSP ステープリングの欠如、共有基盤における SNI と証明書の不一致などがあります。

sequenceDiagram
  participant C as クライアント
  participant S as サーバ
  C->>S: ClientHello バージョン 暗号スイート 鍵共有
  S->>C: ServerHello 選択スイート 鍵共有
  S->>C: Certificate + CertificateVerify
  S->>C: Finished
  Note over C,S: 両者が (EC)DHE で対称鍵を導出
  C->>S: Finished
  C->>S: 暗号化されたアプリケーションデータ