ネットミリしらINTERNET KNOWLEDGE LIBRARY

用語辞典・通信プロトコル

TLS

TLSとは

TLSは、ネットワーク通信を暗号化し、改ざん検知や相手確認を提供するセキュリティプロトコルです。正式名称はTransport Layer Security（トランスポート・レイヤー・セキュリティ）で、ティーエルエスと読みます。

現在のTLS 1.3では、最初のhandshake（ハンドシェイク）で暗号方式、鍵材料、サーバー証明書、署名を交換・検証し、双方だけが導出できる通信鍵を作ります。その後、アプリのデータをレコードとして暗号化し、改ざんを検出します。

証明書に入った公開鍵で通信本文を直接すべて暗号化するのではなく、証明書で相手を確かめ、一時鍵交換から導いた対称鍵で大量の通信を保護するのが基本です。

候補と一時鍵を交換し、証明書・署名を検証して、双方で同じ通信鍵を導く完成した通信鍵そのものをネットワークへ送らず、以後のレコードを方向別の鍵で守る
クライアントが暗号候補と一時鍵を送り、サーバーが選択結果、一時鍵、証明書連鎖、署名証明を返し、名前・時刻・信頼を検証して双方が同じ通信鍵を導き、双方向のデータを完全性付きレコードへ分けて保護するTLSの図解
図1図は公開鍵証明書を使う代表的なサーバー認証です。事前共有鍵やクライアント証明書など、用途に応じた認証方法もあります。

TLS 1.3のハンドシェイクは、合意・認証・鍵導出を順に結び付ける

途中の一項目だけでなく、それまでの交換全体を署名とFinishedで検証する鍵交換と認証を結び付けることで、途中の第三者への接続すり替えを防ぐ
  1. Hello
    候補と鍵共有を提示

    ClientHelloが対応版、暗号スイート、一時公開値、拡張を提示する

  2. Select
    条件を選択

    ServerHelloが版・暗号とサーバー側一時公開値を選び、共有秘密を導く

  3. Identify
    証明書を検証

    接続先名、有効期間、用途、信頼の連鎖をクライアントが確認する

  4. Prove
    秘密鍵所持を証明

    CertificateVerifyの署名が、証明書の公開鍵と交換内容へ対応するか確かめる

  5. Finish
    交換全体を確認

    Finishedがハンドシェイク記録の完全性と同じ鍵を持つことを相互に確認する

  6. Protect
    アプリデータを保護

    方向別のトラフィック鍵でレコードを暗号化し、改ざんを検出する

図2TLS 1.3ではServerHelloより後の多くのハンドシェイク情報も暗号化されます。ネットワーク上の並びを単純な平文交換と考えません。

一時鍵交換は、記録された通信を将来の秘密鍵漏えいから守りやすくする

代表的なECDHE（Elliptic Curve Diffie-Hellman Ephemeral／エリプティック・カーブ・ディフィー・ヘルマン・エフェメラル）では、接続ごとの一時秘密値から共有秘密を導きます。公開値を観測しても、一時秘密値なしに同じ共有秘密を求めることは困難です。

接続後に一時秘密値を捨てれば、後日サーバー証明書の秘密鍵が漏れても、過去に記録された通信を一括復号されにくくなります。これをforward secrecy（フォワード・シークレシー／前方秘匿性）と呼びます。秘密鍵漏えい後のなりすましを防ぐには、証明書失効・鍵交換など別対応が必要です。

レコード層は、暗号化と改ざん検出を一体で行う

TLS 1.3はAEAD（Authenticated Encryption with Associated Data／オーセンティケーテッド・エンクリプション・ウィズ・アソシエーテッド・データ）方式を使い、内容の機密性と完全性を同時に提供します。レコードごとに鍵と番号から一意のノンスを作り、同じ鍵・ノンスの再利用を避けます。

改ざんされたレコードは復号結果をアプリへ渡さず、接続を失敗させます。ただし長さやタイミングなど外側の特徴は残ります。TLSが守る範囲は、TLSへ渡されたデータからTLS終端点までであり、終端後の保存、ログ、画面表示はアプリ側の保護です。

通常はサーバーを認証し、クライアント認証は用途に応じて追加する

WebのTLSでは、サーバーが証明書を提示し、クライアントが接続先名を確認するのが基本です。利用者のログインはTLSの内側でパスワード、パスキー、Cookieなどを使います。TLSサーバー認証とWebアカウント認証は別段階です。

mTLS（mutual TLS／ミューチュアル・ティーエルエス／相互TLS）では、サーバーもクライアント証明書を要求し、双方を証明書で認証します。社内APIや機器間通信で使われますが、発行、秘密鍵保護、失効、利用者との対応付けを運用する必要があります。

再開は待ち時間を減らすが、0-RTTデータには再送の可能性がある

以前の接続から発行されたチケットを使うsession resumption（セッション・リザンプション／接続再開）では、証明書認証結果などを引き継ぎ、新しい通信鍵を導いて交換量を減らします。チケットは秘密情報として期限・ローテーションを管理します。

TLS 1.3の0-RTT（ゼロ・ラウンドトリップ・タイム）早期データは、ハンドシェイク完了前にアプリデータを送れますが、攻撃者が再送するリプレイへの一般的な保護が弱くなります。購入確定や送金など、繰り返すと結果が変わる操作には安易に使いません。

TLSをどの通信へ載せるかは、アプリケーションプロトコルが決める

HTTPSのHTTP/1.1・HTTP/2では通常TCP上でTLSを使います。HTTP/2などの選択にはALPN（Application-Layer Protocol Negotiation／アプリケーション・レイヤー・プロトコル・ネゴシエーション）拡張を使い、TLSハンドシェイク内で上位プロトコルを合意します。

QUICはTLS 1.3のハンドシェイクをQUIC内部へ統合し、通常のTLSレコード層をそのまま使う構成ではありません。「TLSを使用」の一行だけで判断せず、版、証明書検証、暗号設定、終端位置、再開、上位プロトコルとの結合方法を確認します。

仕様の確認資料：RFC 9846「The Transport Layer Security Protocol Version 1.3」、RFC 9525「Service Identity in TLS」、RFC 7301「TLS ALPN Extension」

関連用語

データセンターMTUTCPHTTPHTTPSSSLQUICHTTP/2HTTP/3FTPS