とことこロゴス
メニュー

TLS

読み：てぃーえるえす　／　英語表記：Transport Layer Security

通信の暗号化、改ざんの検知、通信相手の認証を行うプロトコル。HTTPSをはじめ、メールやVPNなど多くの通信の安全を支えている。

イマシルちゃんの解説

TLSは、通信の盗み見や書き換えを防ぐためのプロトコルだよ。
たとえばHTTPSでは、ブラウザが接続先の身元を示すサーバ証明書を確かめて、意図した相手につながっているかを確認するんだ。
双方で暗号化に使う共通鍵も用意し、やり取りするデータを第三者に読まれにくくするよ。
途中で内容が書き換えられたことも検知できるから、通信中の情報を守れるんだ。
ただし安全な通信ができることと、お店そのものが信用できることは別だから、買い物では接続先を選ぶことも大切だよ。

より深い解説

定義

TLS（Transport Layer Security）は、TCPなどのトランスポート層の上で、通信を保護するプロトコルである。前身はSSLで、現在使われているのはTLS 1.2（RFC 5246）とTLS 1.3（RFC 8446）。SSL 2.0、SSL 3.0、TLS 1.0、TLS 1.1は、脆弱性のため使用が禁止・非推奨になっている。

TLSが提供するもの

機能実現する技術
機密性（盗聴の防止）共通鍵暗号方式（AESなど）による暗号化
完全性（改ざんの検知）メッセージ認証（AES-GCMなどの認証付き暗号）
認証（なりすましの防止）代表例はデジタル証明書によるサーバの認証。事前共有鍵で認証するモードもある

データの意味を第三者に読ませない処理が暗号化、途中で変更されていないか確認する処理が改ざん検知、意図した相手か確かめる処理が認証である。それぞれ目的が異なる。安全な通信路を作っても、アプリケーション内のアクセス権限や、保存後のデータまで自動的に保護されるわけではない。

ハンドシェイクの流れ（TLS 1.3の概要）

証明書認証と一時的なDH鍵共有を使う通常の接続は、次のように進む。

  1. クライアントがClientHelloで、対応するバージョン・暗号スイートの候補・鍵共有の公開値などを送る。
  2. サーバがServerHelloで使用する方式と公開値を返す。双方は鍵材料を共有し、それ以降のハンドシェイクを保護する鍵を導く。
  3. サーバが、暗号化したEncryptedExtensions、Certificate、CertificateVerify、Finishedなどを送る。証明書と、それに対応する秘密鍵による署名で相手を確認できるようにする。
  4. クライアントが証明書の信頼、接続先の名前、有効期間などを検証し、署名とFinishedも確認する。必要ならクライアント認証を行い、クライアントもFinishedを返す。
  5. それまでの鍵材料から導出した共通鍵でアプリケーションデータを保護する。送信方向ごとに異なる鍵を使う。

暗号スイートは、使用する暗号処理の組合せを指定する識別子である。クライアントが候補を出し、サーバが両者で使えるものを選ぶ。TLS 1.2のスイートは鍵交換・認証などの種類も含むが、TLS 1.3では主にAEADアルゴリズムとハッシュ関数を指定し、鍵共有や署名の方式は別に合意する。

このように証明書認証と一時的なDH鍵共有を使う接続では、公開鍵を使う処理を鍵共有や認証に用い、データ本体は高速な共通鍵暗号で保護する。両方を組み合わせる方式をハイブリッド暗号方式という。後述のPSKだけを使うモードまで、公開鍵暗号を必ず使うという意味ではない。

TLS 1.3での主な変更点

TLS 1.3で鍵を共有する方法

一時的な有限体DHをDHE、楕円曲線を使う一時的なDHをECDHEという。両者をまとめて(EC)DHEと表す。接続ごとに新しい秘密の値を使い、終了後に破棄することで、長期の認証鍵が後から漏れても過去の通信を守る前方秘匿性を得る。

TLS 1.3の基本的な鍵交換モードは、次の三つに整理される。

モード鍵材料の作り方前方秘匿性
(EC)DHE一時的なDHで共有し、証明書などで認証するある
PSKだけ事前に共有した秘密や再開用の秘密から導くない
PSKと(EC)DHEの組合せ共有済みの秘密に新しいDHの結果を組み合わせる通常の接続データにはある

PSKはPre-Shared Keyの略で、あらかじめ共有する秘密を表す。TLS 1.3を使うだけで、どのモード・どのデータにも前方秘匿性があるとはいえない。特に0-RTTの早期データは前方秘匿性を持たず、再送攻撃への対策もアプリケーション側に必要になる。

データを安全に保護する方式

AEADはAuthenticated Encryption with Associated Dataの略で、暗号化とメッセージ認証を組み合わせて扱う方式である。TLS 1.3ではレコードの保護にAEADを使う。代表例にはAES-GCM、AES-CCM、ChaCha20-Poly1305がある。

送信側は鍵・ノンス・平文・関連データから、暗号文と認証タグを作る。関連データは暗号化しないまま完全性だけを保護する情報で、TLS 1.3ではレコードヘッダーが該当する。受信側はタグを検証し、検証に失敗したデータを正しい平文として受け入れない。

ここでいうメッセージ認証は、鍵を共有する相手が作った保護データかを確かめる処理である。証明書で組織やサーバの身元を確かめる認証とは役割が異なる。また、通常のハッシュ値を添えるだけでは、攻撃者も計算し直せるため同じ効果を得られない。

アプリケーションのプロトコルを選ぶ

HTTPSと同じポートでHTTP/1.1とHTTP/2のどちらを使うか決めるため、TLSにはALPN（Application-Layer Protocol Negotiation）という拡張がある。クライアントはClientHelloで、例えばh2とhttp/1.1のような候補を提示し、サーバが対応する一つを選ぶ。

TLS 1.2では選択結果をServerHelloの拡張で、TLS 1.3では暗号化されたEncryptedExtensionsで返す。選ぶ対象はアプリケーション層プロトコルであり、暗号スイートやTLSのバージョンではない。HTTP/2をhttpsのURIで利用するときは、この仕組みでh2を合意する。

バージョンとアルゴリズムの両方を確認する

MD5やSHA-1は、特に衝突に対する安全性が失われており、古い署名方式などを継続して使う根拠にはできない。TLS 1.2以降では、それらに依存しない署名・ハッシュ・暗号の組合せを選べる。TLS 1.3は選択肢をさらに整理している。

ただしバージョン番号だけで構成の安全性は決まらない。TLS 1.2でも許可する暗号スイートや署名方式、証明書検証が不適切なら問題が残る。衝突耐性の問題と、HMACなど別の用途の安全性も同一視せず、用途に対応した現在の要件を確認する。

押さえておきたい点

クライアントの確認と鍵の保管

個人の認証に使うクライアント証明書と対応する秘密鍵は、PCだけでなく、ICカードやセキュリティトークンに格納する構成もある。秘密鍵を外へ取り出さず、カード内で署名処理を行う方式なら、証明書だけをコピーされても本人として認証できない。

利用には対応する読み取り装置やソフトウェア、サービス側の信頼設定が必要である。証明書という公開情報を持っていることだけで、本人と判定するわけではない。

なお、接続先をドメイン名で検証する場合と、IPアドレスで検証する場合も区別する。後者では、そのIPアドレスに対応した証明書の識別情報が必要になるため、アドレス変更時には証明書も確認する。

参考資料

実際の試験ではここに出る！全28問

ネットワークスペシャリスト

午前Ⅱ
午後Ⅰ
午後Ⅱ

テクニカルエンジニア（ネットワーク）

午前

この用語が出てくる記事

↑