TLS: すべての南京錠アイコンの背後にあるプロトコル

12 最小読み取り暗号化

Transport Layer Security は、2026 年の HTTPS、最新の電子メール、VPN、メッセージング アプリ、およびほとんどのインターネット トラフィックの暗号化基盤です。これは 1994 年に Netscape の SSL として始まり、それ以来 8 回静かにアップグレードされてきました。これは、ハンドシェイクがどのように機能するか、TLS 1.3 で何が変更されたか、それを形作った攻撃、そしてハンドシェイクが次にどこへ向かうのかという技術的な説明です。

記事全文は以下に英語で記載されています。

SSL → TLS: 時系列のストーリー

Netscape Communications は、最新の Netscape Navigator ブラウザでオンライン ショッピングを保護するために、1994 年に最初の SSL 実装を構築しました。 SSL 1.0 には重大な欠陥があったため、一般にリリースされることはありませんでした。 1995 年 2 月に出荷された SSL 2.0 はすぐに破られ、1996 年にほぼ全面的に書き換えられた SSL 3.0 が続きました。

1999 年に IETF がこのプロトコルを引き継ぎ、Netscape 製品からオープン スタンダードへの移行を示すために Transport Layer Security に名前を変更しました。それ以降のバージョン履歴:

  • TLS 1.0 (1999 年 1 月、RFC 2246) — 基本的に SSL 3.1.
  • TLS 1.1 (2006 年 4 月、RFC 4346) — 明示的な初期化によって CBC 攻撃から保護Vectors.
  • TLS 1.2 (2008 年 8 月、RFC 5246) — AEAD 暗号、SHA-256、構成可能な署名アルゴリズムを追加しました。
  • TLS 1.3 (2018 年 8 月、RFC 8446) — 大幅な再設計。従来の不要なものを削除し、転送秘密保持を義務付け、ハンドシェイク遅延を削減しました。

SSL 3.0 は、POODLE の後、2015 年 6 月に正式に非推奨になりました (RFC 7568)。 TLS 1.0 および 1.1 は 2021 年 3 月に非推奨になりました (RFC 8996)。 2026 年には、最新のサーバーは TLS 1.2 以下のものを拒否し、TLS 1.3 を優先する必要があります。

ハンドシェイクの実際の仕組み

すべての TLS 接続は、暗号スイートの合意、サーバーの ID の証明、残りのセッションの共有キーの導出という 3 つのことを行うハンドシェイクで始まります。

TLS 1.2ハンドシェイク (古典的なフロー)

  1. ClientHello: クライアントは、サポートされている TLS バージョン、暗号スイート、および乱数を送信します。
  2. ServerHello: サーバーは 1 つの暗号スイートを選択し、そのランダムな番号を送信します。 number.
  3. Certificate: サーバーは、クライアントが ID を検証できるように、X.509 証明書チェーンを送信します。
  4. ServerKeyExchange: サーバーは、Diffie-Hellman 公開キー (一時キー用) を送信します。 Exchange).
  5. ClientKeyExchange: クライアントは DH 公開キーを送信します。これで、両方の側が同じ共有秘密を取得します。
  6. 終了: トランスクリプト全体で MAC を送信することで、双方がハンドシェイクを確認します。

これは、最初のアプリケーション バイトが流れるまでに 2 往復かかります。遅延 100 ミリ秒のリンクでは、新しい HTTPS 接続は実際のコンテンツが移動するまでに 200 ミリ秒かかります。

TLS 1.3 ハンドシェイク (最新のフロー)

TLS 1.3 では、共通のハンドシェイクが 1 往復に集約されます。 case:

  1. ClientHello: クライアントがサポートするすべての暗号グループのクライアントの DH 公開キーが含まれます。
  2. ServerHello + その他すべて: サーバーはグループを選択し、その DH 公開キー、証明書、および完了をすべて 1 つに送信します。 Flight.
  3. Client が検証し、独自の Finished.

1 往復、2 便で応答します。セッション再開 (0-RTT) を使用すると、クライアントは最初のメッセージでデータの送信を開始することもできます。ただし、その初期データの一部の前方秘密保持プロパティが犠牲になります。

TLS 1.3 で削除されたもの

TLS 1.3 のもう 1 つの大きな動きは削除です。出力されました:

  • 静的 RSA キー交換 (前方秘密鍵の破棄).
  • CBC モード暗号 (BEAST および Lucky Thirteen に対して脆弱).
  • RC4 ストリーム暗号 (破られてから長い間).
  • MD5 および SHA-1 ハッシュ署名.
  • ネゴシエーション (ハンドシェイク後の認証に置き換えられました).
  • 圧縮 (CRIME クラスの攻撃).
  • カスタム Diffie-Hellman パラメーター (ログジャム修正).

暗号スイート リストは、TLS 1.2 の ~300 から、 TLS 1.3では5。首吊りロープが少なくなります。

TLS

  • BEAST (2011) を形成した攻撃履歴 — TLS 1.0 の CBC モードでの選択平文攻撃。明示的な IVs.
  • CRIME (2012) によって 1.1 以降で修正されました。セッション Cookie を回復するために TLS 圧縮を使用しました。圧縮を無効にすることで修正されました。
  • BREACH (2013) — CRIME と同等の HTTP レベルの圧縮。機密応答の HTTP 圧縮を無効にすることで軽減されます。
  • Heartbleed (2014 年 4 月) — TLS 仕様の問題ではなく、OpenSSL のバグ。秘密鍵を含むサーバーメモリの漏洩。 Web 上での大量の証明書ローテーション イベント。
  • POODLE (2014 年 10 月) — SSL 3.0 フォールバックを悪用しました。
  • Logjam (2015) — 小規模な Diffie-Hellman グループ (特に IPsec/IKE で広く使用されている 1024 ビット グループ 2) が国家攻撃者の手の届く範囲にあることを示しました。業界全体で大規模なグループと楕円曲線への強制的な移行 DH.
  • Lucky Thirteen (2013) — CBC モードでのタイミング攻撃。 OpenSSL などのライブラリ レベルの修正。

各攻撃によりプロトコルが強化されました。 TLS 1.3 では、これらのクラスのほとんどは設計上不可能です。

認証局と信頼の問題

TLS 認証は、ブラウザーがデフォルトで信頼する認証局 (CA) に依存します。 2019 年以降の市場シェアのトップ 3 は、IdenTrust、DigiCert、Sectigo です。 2016 年に開始された無料の自動 CA である Let's Encrypt は、HTTPS 史上最大の導入推進を推進しました。

構造的な弱点: 信頼できる CA であれば、どのドメインに対しても証明書を発行できます。侵害された CA または強制された CA が、銀行向けに有効な証明書を作成する可能性があります。これを検出するために、Certificate Transparency (CT) ログ (これまでに発行されたすべての証明書の追加専用のパブリック レコード) が導入されました。ブラウザは、証明書を受け入れる前に CT ログに証明書が表示されることを要求するようになりました。

CA/ブラウザ フォーラムは、2029 年までに証明書の最大有効期間を 47 日に短縮することを承認し、侵害された CA が損害を与える可能性がある期間を短縮しました。

暗号化された Client Hello (ECH)

古典的な TLS の漏洩の 1 つは、サーバー名表示です。 ClientHello の (SNI) フィールド。サーバーが正しい証明書を提示できるように、接続先のホスト名をサーバーに伝えます。 SNI は平文であるため、接続の残りの部分が暗号化されている場合でも、ネットワーク オブザーバーはアクセスするすべてのドメインを学習します。

Encrypted Client Hello (ECH) (以前の ESNI 提案の進化版) は、宛先が DNS 経由で公開する公開キーを使用して SNI を暗号化します。 Cloudflare と Apple は ECH サポートを出荷しました。 Firefox と Chrome は 2024 年までこれを有効に展開し、デフォルトでオンになる方向に進んでいます。敵対的なネットワーク上のユーザーにとって、ECH はユニバーサル HTTPS に次ぐプライバシー アップグレードです。

DTLS — UDP

DTLS 用の TLS (データグラム TLS) は、UDP 上で動作する TLS バリアントです。これは、WebRTC (ブラウザ ビデオ/音声)、QUIC の基礎となるセキュリティ、およびいくつかの VPN プロトコルを強化します。 DTLS 1.3 (RFC 9147、2022) は、TLS 1.3 のハンドシェイクと暗号の最新化に一致します。

ポスト量子 TLS

Diffie-Hellman 鍵交換 (TLS 前方秘密保持の基礎) は、十分な大きさの量子コンピューターによって解読可能です。この修正は、古典的なアルゴリズム (X25519) とポスト量子候補 (通常は ML-KEM-768、以前は Kyber として知られていた) を組み合わせたハイブリッド鍵交換です。

Chrome は、2024 年後半にデフォルトで X25519MLKEM768 ハイブリッドを有効にしました。Cloudflare、Apple iCloud、およびいくつかの VPN プロバイダーが 2025 年まで出荷しました。より広範なロールアウトにより、今日のトラフィックが保護されます。 「今すぐ収穫し、後で復号化する」攻撃 - 攻撃者は今日暗号化されたトラフィックを記録し、量子コンピューターを待ってから復号化します。

ブラウザーが実際に使用している TLS を確認する方法

ブラウザーのアドレス バーの南京錠をクリックします。最新のブラウザでは、プロトコルのバージョン、暗号スイート、証明書の詳細が表示されます。 TLS 1.0 または 1.1 が表示される場合、サイトは非推奨の構成を使用しています。 AES-256-GCM または ChaCha20-Poly1305 を使用した TLS 1.3 が表示される場合は、最新の暗号化を使用しています。

コンパニオン テクノロジ HTTPS (HTTPS の説明 で説明されている ) は、Web を TLS でラップするものです。この 2 つの用語は口語的に同じ意味で使用されることがよくありますが、TLS は基礎となる暗号プロトコルです。 HTTPS は単なる HTTP-over-TLS.

です

よくある質問

SSLとTLSの違いは何ですか?
歴史的には同じことです。 SSL は Netscape の名前です。 TLS は、1999 年に開始された IETF 標準化された後継です。TLS は 25 年以上実際のプロトコルであり続けていますが、現代の口語的な使用法では、すべてを「SSL」と呼ぶことがよくあります。現在のすべての安全な Web 接続は TLS 1.2 または TLS 1.3 を使用します。
TLS 1.3 のほうが速いのはなぜですか?
最初のメッセージでクライアントの DH 公開キーを送信し、サーバーの応答を他のすべてのハンドシェイク状態にバンドルすることで、ハンドシェイクを 2 往復から 1 ラウンド (1-RTT) に短縮します。セッションの再開では、最初のメッセージ (0-RTT) でアプリケーション データの送信を開始することもできます。 100 ミリ秒の遅延リンクでは、最初の接続で 200 ミリ秒の改善が見られます。
TLS 1.2 は 2026 年でも安全ですか?
はい、適切に構成されていれば: AES-GCM または ChaCha20-Poly1305 暗号、前方機密性のための ECDHE キー交換、CBC モード暗号なし、RC4 なし、SSL 3.0 フォールバックなし。 TLS 1.3 は、不適切なオプションを削除することにより、構成リスクを完全に排除します。
暗号化クライアント Hello とは何ですか?
TLS ハンドシェイクの Server Name Indication (SNI) フィールドを暗号化する拡張機能。 ECH がないと、接続の残りの部分が暗号化されている場合でも、ネットワークはアクセスするすべてのドメインを確認できます。 ECH (および初期の ESNI) はメタデータの最後の部分を隠し、1994 年に始まった TLS のプライバシー ストーリーを完成させます。
TLS は量子的に安全ですか?
まだデフォルトではありませんが、展開中です。標準の X25519 楕円曲線 Diffie-Hellman は、理論的には十分な大きさの量子コンピューターによって解読可能です。ハイブリッド X25519MLKEM768 モード (2024 年後半から Chrome のデフォルト、ブラウザのサポートが拡大) は、古典アルゴリズムとポスト量子アルゴリズムを組み合わせているため、将来の量子攻撃に対してもトラフィックは安全に保たれます。
TLS の説明: すべての南京錠アイコンの背後にあるプロトコル | VPNマスタープロ