ネットワーク●●●○○

TLS

通信を暗号化するプロトコル。公開鍵暗号で鍵を交換し、共通鍵で高速に暗号化する。

概要

TLS(Transport Layer Security)は、ネットワーク通信を暗号化し、盗聴・改ざん・なりすましから守るプロトコルです。HTTPSの「S」の中身がこれで、HTTPに限らず、メール(SMTP)やデータベース接続など、さまざまなプロトコルの下敷きとして使われています。TCP/IPのトランスポート層とアプリケーション層の間に挟まる「暗号化の層」と考えると位置づけが掴みやすいです。

TLSの設計の核心は、二種類の暗号方式の合わせ技にあります。接続の最初に公開鍵暗号を使って安全に「共通鍵」を共有し(この手順をハンドシェイクと呼びます)、以降の通信はその共通鍵による高速な暗号化で行います。安全な鍵交換ができるが遅い公開鍵暗号と、高速だが鍵の受け渡しが課題の共通鍵暗号——それぞれの長所だけを組み合わせた構成です。

なお「SSL」は前身の名前です。現在動いている実体はほぼすべてTLSですが、「SSL証明書」「SSL化」という呼び名だけが慣習として残っています。

なぜ生まれたか

インターネットの基盤プロトコルであるTCP/IPは、性善説の研究ネットワークで生まれたため、暗号化の仕組みを持ちません。パケットは経路上のあらゆる機器から平文で読め、書き換えも可能です。1990年代にWebで商取引が始まると、これは「カード番号が経路上で盗み放題」という深刻な問題になりました。

そこでNetscape社が1994年にSSL(Secure Sockets Layer)を開発します。重要な設計判断は、HTTPを改造するのではなく「TCPとアプリケーションの間に挟まる汎用の暗号化層」として作ったことでした。おかげでHTTP以外のプロトコルもそのまま安全化でき、アプリケーションは暗号の詳細を知らずに済みます。SSL 3.0を土台に標準化団体IETFが引き継いで1999年に改名したものがTLS 1.0で、以降、脆弱性への対応と高速化を重ねて現在のTLS 1.3(2018年)に至ります。

詳細

ハンドシェイク — 接続確立の往復

TLSの心臓部がハンドシェイクです。ここで「相手が本物か」の確認と「今後使う共通鍵」の合意を行います。流れを順に追うと次のようになります。

サーバクライアントサーバクライアント証明書を検証して相手が本物か確認双方が共有した秘密から共通鍵を導出ClientHello 対応する暗号方式の候補と乱数ServerHello 選んだ方式 + 証明書 + 鍵交換パラメータ鍵交換を完了以降のデータは共通鍵で暗号化以降のデータは共通鍵で暗号化

TLS 1.3ではこのハンドシェイクの往復が1回に短縮されています。

まずクライアントが、自分の使える暗号方式の一覧を添えて挨拶します(ClientHello)。サーバは使う方式を選んで応答し、あわせてサーバ証明書を送ります。クライアントは証明書を検証して相手が本物であることを確かめたうえで、公開鍵暗号の技術(現在は主にECDHEという鍵交換方式)を使って、盗聴者には割り出せない形で双方が同じ秘密の値に到達します。この値から共通鍵を導出したら、ハンドシェイクは完了です。以降のアプリケーションデータはすべてこの共通鍵で暗号化され、さらにメッセージ認証(改ざん検知)が付与されます。改ざん検知にはハッシュ化の技術が使われています。

証明書とPKI — 「本物である」ことの保証

暗号化だけでは不十分です。偽サーバと「安全に」暗号化通信をしてしまっては意味がないため、相手の本人性を保証する仕組みが要ります。それがサーバ証明書と認証局(CA)です。証明書は「この公開鍵はこのドメインの持ち主のものである」とCAが電子署名した文書で、クライアントは署名を信頼済みのルートCAまで連鎖的に検証します。この信頼のインフラ全体をPKI(公開鍵基盤)と呼びます。CAはドメインの所有確認をしてから証明書を発行するため、攻撃者は正規ドメインの証明書を手に入れられない——これがなりすまし防止の根拠です。

バージョンと設定の実務

TLSにはバージョンの歴史がそのまま脆弱性の歴史として刻まれています。SSL 3.0(POODLE攻撃)、TLS 1.0/1.1(BEAST等)はすでに危険とされ、主要ブラウザでは無効化済みです。現役はTLS 1.2と1.3で、特に1.3は危険な古い暗号方式を仕様から削除し、ハンドシェイクを1往復(さらに再接続時は0往復=0-RTT)に短縮した大幅な改良版です。サーバを構築する際は「TLS 1.2以上のみ許可し、推奨される暗号スイートを使う」が基本線になります。

実務での使いどころと落とし穴

実務では、TLSを自分で実装することはまずなく、「どこで終端するか」と「証明書をどう管理するか」が主な関心事になります。多くの構成ではリバースプロキシロードバランサCDNがTLSを終端し、アプリケーション本体は平文で受けます。証明書はLet’s Encryptなどで自動更新するのが定石で、「証明書の期限切れでサービス全断」は今なお定番の障害です。もうひとつの重要な応用がmTLS(相互TLS)で、通常はサーバ側だけが証明書を示すところを、クライアントにも証明書を要求して双方向に認証します。マイクロサービス間の通信の保護によく使われます。

ハンドシェイクには往復(レイテンシ)のコストがあることも覚えておく価値があります。接続を張り直すたびにこのコストを払うため、接続の使い回しやセッション再開の仕組みが性能に効いてきます。HTTP/3では、この層をQUICとしてUDP上に統合し、トランスポートと暗号化のハンドシェイクを一体化する方向に進化しています。