Transport Layer Security（トランスポート・レイヤー・セキュリティ、TLS）は、インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うためのプロトコルである。主な機能として、通信相手の認証、通信内容の暗号化、改竄の検出を提供する。TLSは非営利組織IETFによって策定された。
当プロトコルは（特に区別する場合を除いて）SSL (Secure Sockets Layer) と呼ばれることも多い。これは、TLSの元になったプロトコルがSSLでありプロトコル名を含めた歴史については、Eric Rescorla著,「マスタリングTCP/IP SSL/TLS編」,オーム社開発局（2003年） の2章6節が詳しい。、そのSSLという名称が広く普及していることによるただし、メールサーバーへの接続においてはTLS接続用のTCPポートにはじめからTLSで接続するSMTP over SSLと、通常のTCPポートにSMTP接続後にSTARTTLSコマンドによってセキュアな接続に切り替えるSTARTTLSという異なる接続方式があり、名称を使い分けることがある。詳しくは#アプリケーション層プロトコルへの適用の項目を参照されたい。。SSLはNetscapeが設計・開発した。当初のSSLを元にして、以後、SSL 2（1994年）、SSL 3（1995年）がそれぞれ前バージョンの欠陥や脆弱性を修正するものとして公開された。SSLを拡張して、TLS（1999年）、TLS 1.2（2008年）、TLS 1.3（2018年）が作られた。
2022年現在の最新版はTLS 1.3である。
概要 TLSは多くの場合、コネクション型のトランスポート層プロトコル（通常はTCP）とアプリケーション層の間で使われる。特にHTTPでの利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存せず、様々なアプリケーションにおいて使われている。TLS 1.1以降を元にしたプロトコルが、UDPやDCCPといったデータグラム型プロトコル上でも実装されており、こちらはDatagram Transport Layer Security (DTLS) として独立して標準化されている。
TLSはHTTPなどのアプリケーション層のプロトコルと組み合わせることで、HTTPSなどセキュアな通信プロトコルを実現している。そのようなプロトコルとして以下のものがある。
SSLと組み合わせたプロトコル ポート番号 元のプロトコル ポート番号 HTTPS 443 HTTP 80 SMTPS 465 SMTP 25 LDAPS 636 LDAP 389 FTPS (data) 989 FTP (data) 20 FTPS (control) 990 FTP (control) 21 IMAPS 993 IMAP 143 POP3S 995 POP3 110 DNS over TLS 853 DNS 53
アプリケーション層プロトコルへの適用 TLSは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。
既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとしてSTARTTLSが広まっているため、この方式自体をSTARTTLSと呼ぶこともある。
前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、平文で接続を開始する実装と共存できなくなるため、既存のポート番号とは別にTLS対応用のポート番号が必要となる。実態としては、SSL/TLSの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。ただし、この方式はバーチャルホストを構成する際に問題となる可能性がある。詳細は#バーチャルホストの節を参照。
なお、ポート番号を分ける方式をSSL、同一ポート番号で切替える方式（STARTTLS方式）をTLSと呼んでいる実装もある。TLS/SSLという用語の区別がプロトコルのバージョンを指しているか、アプリケーション層プロトコルへの適用方式を指しているかは、文脈で判断する必要がある。
セキュリティ上の考察 TLS適用の有無と使用アルゴリズムの強度 TLSを導入さえすればセキュリティが確保できるという認識は誤っている。TLS通信は、平文での通信に比べて（主に暗号化・復号時）余分な計算機能力を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、TLSが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。 thumb|Mozilla Firefoxにおける南京錠アイコンの例 World Wide Webでは、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信で TLS (HTTPS) が使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに南京錠のアイコンを表示したり、アドレスバーの色を変化させたりして、利用者に情報を提供していた。一方 Google は南京錠のアイコンが適切ではなくなったとして、Chrome での南京錠の表示を廃止した。背景として、HTTPS が普及したこと、南京錠アイコンの意味を正しく理解している人が少ないことを挙げている。さらに、Chrome では HTTPS を使っていない通信を行う前に警告画面を出すようにした。
また実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため、TLSを使用していても、システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある。このような場合もダイアログメッセージなどを使って利用者に警告すべきである。
証明書の正当性
TLSは公開鍵証明書を用いて認証を行い、なりすましを極力排除しようとする。しかしシステムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではない。
公開鍵証明書には認証局による電子署名が与えられる。その署名の正当性を評価するためには認証局の証明書が必要であり、最終的にはルート証明書と呼ばれる一群の証明書に行きつく。各システムは、認証局の証明書として信用できるルート証明書を、あらかじめ保持している。認証局は自身の秘密鍵を厳重に秘匿し、また証明書の発行にあたっては正当なサーバ管理者かどうか確認することが求められる。これらが保証されない認証局のルート証明書を組み込むことは、TLSにおける認証機能を破綻させることになる。仮に認証局自体は安全でも、入手したルート証明書が本当に意図する認証局のものかどうか判断することは難しいという点も注意すべきである。
TLSで認証を行うためには、認証局の署名に加えて、証明書の発行先を確認する必要がある。確認しない場合、サーバAの管理権限を持たない者がサーバBとして正当な証明書を取得し、その証明書を使ってサーバAを名乗ることができてしまう。TLS用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。
現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。セキュリティ研究者の高木浩光は、このような証明書のことを、オレオレ詐欺をもじって「オレオレ証明書」と呼んで批判している。
この検証は、システムに指示された接続先のホスト名と実際に接続した先のホスト名が一致することを検証しているのであり、利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある。
例として、利用者が意図する接続先であるサーバAがホスト名www.example.comでサービスを提供しており、攻撃者はサーバBおよびホスト名www.example.orgを取得している場合を考える。仮に攻撃者がDNS偽装に成功して、www.example.comへの接続をサーバBに導くことができたとしても、www.example.comのサーバ証明書を入手できないので、TLS接続を提供することはできない。しかし攻撃者も、www.example.orgのサーバ証明書を入手することはできる。したがって、サーバAに接続しようとしている利用者を、www.example.comではなくwww.example.orgへ接続させることができれば、クライアントからは正当な証明書を持ったサーバとしか見えない。
上記のような例も考慮した上で、利用者が意図している接続先かどうかを判断するためには、以下の2つの条件を満たす必要がある。
利用者は意図する接続先の正しいホスト名を知っている。 利用者は、現在システムに指示されている接続先が、自分の知っている正しいホスト名と一致していることを確認できる。
2は、情報処理推進機構 (IPA) が公開している「安全なウェブサイトの作り方」という文書の「フィッシング詐欺を助長しないための対策」に対応する。
乱数の品質 他の多くの近代暗号と同様に、TLSもまた、暗号としての強度は乱数の品質に依存している。桁数（ビット長）の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている（これは、公開鍵暗号システムにも言える）。もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、総当たり攻撃で解読される可能性が上昇する。通常は、これは実装の問題に起因している。
古い例では、Netscapeの初期の実装における乱数生成の脆弱性がある。プロセスIDや時刻から乱数を生成していることが判明し、これらの情報を取得できる場合には総当たり攻撃の所要時間が大幅に短くなるという問題があった。
2008年5月15日にはDebianが脆弱性に関する報告を発表した。OpenSSLライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536 (= 216) 通りの予測可能な物が生成されてしまった事を明らかにした（なお、この問題はOpenSSLそのものの脆弱性ではない）。この影響を受けるのはDebian sargeより後のバージョンのDebianと、それから派生したDamn Small Linux、KNOPPIX、Linspire、Progeny Debian、sidux、Ubuntu、UserLinux、Xandrosである。脆弱性のあるバージョンのOpenSSLは2006年9月17日に公開された。安定バージョンがリリースされた2007年4月8日以降は確実に影響を受ける。脆弱性のあるバージョンのOpenSSLで作られた鍵全て、SSH鍵、OpenVPN鍵、DNSSEC鍵、X.509証明書を生成するのに使われる鍵データ、およびSSL/TLSコネクションに使うセッション鍵等が影響を受ける。これらの鍵は65536通り全てを総当たり攻撃で試すだけでいずれの鍵が使われているか解読可能であり（SSHでは20分間で解読できたと報告されている）、また脆弱な鍵がインストールされたDebianを含む全てのオペレーティングシステムにおいて緊急の対応が必要であると専門家が注意を呼びかけている。生成された鍵に問題があるため、Debian GNU/Linuxで生成した鍵をMicrosoft Windowsのような非UNIXシステムに導入しているような場合も、この脆弱性の影響を受ける。具体的対応については、Debianの報告の他、JPCERTコーディネーションセンター (JPCERT/CC) の勧告等に従うべきである。
プロトコル概要 本説ではTLS 1.2の概要を説明する。
TLSには主なプロトコルとして暗号通信に必要な鍵 (master secret) を鍵共有してセッションを確立するTLSハンドシェイクプロトコルと、master secretを用いて暗号通信することで確立されたセッションにおけるコネクションをセキュアにするTLSレコードプロトコルがある。
その他に用いている暗号方式やハッシュ関数等のアルゴリズムを変更する Change Cipher Spec プロトコルと通信相手からの通信終了要求や何らかのエラーを通知する アラートプロトコルがある。
TLSハンドシェイクプロトコル
TLSハンドシェイクプロトコルは4つのフェーズに大別できる。
第一フェーズ 第一のフェーズではサーバ・クライアント間で通信に必要情報の合意を図る。このフェーズでは、まずクライアントからサーバにClientHelloが送信され、次にサーバからクライアントにServerHelloが送信される。
ClientHelloはTLSのバージョン、乱数、セッションID、通信に用いる暗号方式やハッシュアルゴリズムのリスト (cipher_suites)、通信内容の圧縮方法、および拡張領域の6つからなるRFC5246日本語訳「 TLS ハンドシェイク関連プロトコル」、IPA。2016年8月11日閲覧。乱数は鍵共有におけるリプレイ攻撃を防ぐためのものである。
ServerHelloもClientHelloと同様の6つからなっている（名称は一部異なる）。ServerHelloの主な目的は、ClientHelloで提示された選択肢の中でサーバにとって好ましいものを選択する事で、例えばClientHelloで提示されたcipher_suitesの中から、サーバが通信に使いたいcipher_suiteを一組選ぶ。乱数はClientHelloとは独立して選ぶ。これもリプレイ攻撃を回避するためである。セッションIDは特に問題がなければClientHelloと同一のものを返す。
第二フェーズ 第二フェーズではサーバからクライアントに対して鍵共有に必要な情報を送る。具体的にはサーバはCertificate、ServerKeyExchange、CertificateRequest、ServerHelloDoneを（第一フェーズServerHelloに引き続き）クライアントに送信する。
Certificateは鍵共有で用いる公開鍵とその証明書で別途取り決めがない限りX.509v3のフォーマットに従う。なお鍵共有方式としてDH_anonを用いている場合にはcertificateは必要ない。
ServerKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、という形のデータを送る。ここではサーバの秘密の乱数である。鍵共有プロトコルがDHE_DSS、DHE_RSA、DH_anonでは何らかのserver_key_exchangeを送るが、RSA、DH_DSS、DH_RSAでは何も送らない。
CertificateRequestはクライアントの公開鍵とその証明書を送ることを要求するためのもので、サーバが許容できる証明書の種別、ハッシュと署名方式、および認証局のリストからなっている。
そして最後にサーバ側からのメッセージ送信が終わった事を示すServerHelloDoneをクライアントに送る。
第三フェーズ 第三フェーズではクライアントからサーバに対して鍵共有に必要な情報を送る。具体的にはクライアントはCertificate、ClientKeyExchange、CertificateVerifyをサーバに送る。
Certificateは鍵共有で用いるクライアントの公開鍵とその証明書である。証明書はサーバから送られてきたCertificateRequestの条件を満たさねばならない。
ClientKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、という形のデータを送る。ここではクライアントの秘密の乱数である。
ここまでのプロトコルにより、サーバとクライアントの間でpremaster secretが共有された事になる。DH_anonであればpremaster secretはである。premaster secretを鍵にした擬似ランダム関数にServerHelloとClientHelloの乱数などを並べたものを入力した結果得られたものがmaster secretであるRFC5246日本語訳「 8. 暗号技術的計算」、IPA。2016年8月11日閲覧。
CertificateVerifyはクライアントが署名能力を持っていることを証明するためにこれまでTLSハンドシェイクプロトコルで送受信された全メッセージに対し、共有されたmaster secret で署名したものである。
第四フェーズ クライアントは必要ならChange Cipher Spec プロトコルのメッセージをサーバに送り、終了を意味するFinishedをサーバに送る。同様にサーバも必要ならChange Cipher Spec プロトコルのメッセージをクライアントに送り、終了を意味するFinishedをクライアントに送る。
TLSレコードプロトコル TLSレコードプロトコルはアプリケーション層から受け取った通信内容を214バイト以下のブロックに分解 (fragmentation) し、各ブロックを圧縮 (compress) し、圧縮されたブロックを認証暗号で暗号化するレコード Payload 防護を施した上で、通信内容を通信相手に送信するRFC5246日本語訳「6. TLS レコードプロトコル」、IPA。2016年8月11日閲覧。
認証暗号は、TLS 1.1まではMACをつけた後で共通鍵暗号化するMAC-then-Encrypt (MtE) のみが利用可能であった。TLS 1.2からは、AES-GCMのようなAEADに分類される認証暗号専用の暗号利用モードも利用可能になり、TLS 1.3ではAEADのみが利用可能となっている。
認証暗号にブロック暗号（AEAD以外）を選択した場合、TLS 1.1以降においてIVはTLSレコードプロトコルの送信者がランダムに選ぶ。ランダムなIVは、BEAST攻撃への対策として有効である。一方、認証暗号で用いる共通鍵はTLSハンドシェイクプロトコルで共有されたmaster secretを用いる。
バージョン コンピュータの計算能力の向上とともに、認証の突破、暗号の解読、改竄も以前よりは容易に行えるようになり、セキュリティ確保のための技術も厳しさを増している。
2017年現在では、TLS 1.2 以上のバージョンの実装が推奨され、TLS 1.1 以下のサポートを停止するサイトも出てきている。2021年3月にはにより、TLS 1.0〜TLS 1.1の使用禁止が求められている。
Defined バージョン 年 SSL 1.0 n/a SSL 2.0 1995 SSL 3.0 1996 TLS 1.0 1999 TLS 1.1 2006 TLS 1.2 2008 TLS 1.3 2018
SSL 1.0 ネットスケープコミュニケーションズ社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな脆弱性が発見され、破棄された。このため、2018年現在ではSSL 1.0を実装した製品はない。
SSL 2.0 ネットスケープコミュニケーションズ社はSSL 1.0の問題を修正して再設計し、1994年にSSL 2.0として発表した。また、同社のウェブブラウザであるNetscape Navigator 1.1においてSSL 2.0を実装した。
その後、SSL 2.0にもいくつかの脆弱性が発見され、SSL 3.0において修正された。SSL 2.0の脆弱性のひとつは、ネゴシエーションの情報を改竄すると、提示する選択肢のうち最弱のアルゴリズムを使わせることができ（ダウングレード攻撃）、改竄を受けたことを検出できないというものである。さらに悪いことに、この脆弱性を利用すると、双方がSSL 3.0をサポートしていてもSSL 2.0で接続させることさえ可能になる。
SSL 3.0ではSSL 2.0との互換性を提供するにあたり、乱数領域を使った細工を加えることで、このような攻撃を検出する仕組みを組み込んだ。しかしこの細工が無効にされているサーバ環境も存在し、クライアントから見るとSSL 2.0を無効にしない限りこの脆弱性の影響を受ける可能性を否定できない。SSL 3.0以降に対応した実装が十分に普及したものとして、Internet Explorer 7やMozilla Firefox 2、Opera 9などは、初期状態でSSL 2.0を無効にしている。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっている。
SSL 2.0にはチェーン証明書がなく、ルートCAから発行したSSLサーバ証明書しか使うことができない。
2011年3月、 によってSSL 2.0の使用は禁止された。
SSL 3.0 ネットスケープコミュニケーションズ社はSSL 2.0の問題を修正するとともに機能追加を行い、1995年にSSL 3.0を発表した。また、Netscape Navigator 2.0においてSSL 3.0を実装した。SSL 3.0の仕様書については、2011年にIETFから歴史的文書という扱いでとして公開された。
2014年10月にSSL 3.0の仕様上の脆弱性（POODLE攻撃）が発見されたため、SSL 3.0への対応を打ち切り、TLS 1.0以降のみ対応への移行が望まれている。2015年6月、 によってSSL 3.0の使用は禁止された。
SSLについては、使うべきではない。
TLS 1.0 IETFのTLSワーキンググループはとしてTLS 1.0を公表した。TLS 1.0の標準化作業は1996年に開始され、年内に完了する予定だったが、いくつかの問題に阻まれ、公表は1999年まで遅延した。
TLS 1.0が提供する機能はSSL 3.0とあまり変わらないが、アルゴリズムやルートCAの自己署名証明書の取扱いなどの仕様の詳細が変更されたことに加え、これまであまり実装されていなかった選択肢のいくつかが必須と定められた。このため、TLS 1.0を実装した製品が普及するまでには、さらに数年を要した。
2021年3月、によりTLS 1.0を使用しないことが呼びかけられている。
なおTLS 1.0はSSL 3.0より新しい規格であることを示すため、ネゴシエーションにおけるバージョン番号は3.1となっている。
TLS 1.1 2006年にとしてTLS 1.1が制定された。TLS 1.0からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。特にCBC攻撃に対する耐性を上げるため、初期化ベクトルを明示的に指定することにし、さらにパディングの処理も改善された。また、予期せぬ回線クローズ後に、セッションを再開できるようになった。共通鍵暗号アルゴリズムとしてAESが選択肢に加わった によって後付けでAESが追加されたTLS 1.0とは異なり、TLS 1.1を定義する A.5節ではが参照され、AESが当初から追加されている。
2021年3月、によりTLS 1.1を使用しないことが呼びかけられている。2024年10月より、WindowsはTLS 1.0、TLS 1.1をサポートしない旨を発表した。
ネゴシエーションにおけるバージョン番号は3.2となっている。
TLS 1.2 2008年8月にとしてTLS 1.2が制定された。ハッシュのアルゴリズムにSHA-256が追加されたほか、ブロック暗号について、従来のCBCモードだけではなく、GCM、CCMといった認証付き暗号を用いたcipher suiteが利用可能となった。また、AESに関する記述が自体に含まれるようになった。
ネゴシエーションにおけるバージョン番号は3.3となっている。
TLS 1.3 新たなTLSのバージョンとしてTLS 1.3が提案されてきたがdraft-ietf-tls-tls13-18 "IETF The Transport Layer Security (TLS) Protocol Version 1.3"、IETFは2018年3月23日に、ドラフト28を標準規格として承認し、同年8月10日にとして公開した。
TLS 1.2からの変更点としては、データ圧縮の非サポート、forward secrecyではないcipher suite（RSAのみを用いたもの）および認証付き暗号ではないcipher suite（CBCモードのブロック暗号やRC4を用いたもの）の廃止が挙げられる。なお名称をTLS 2.0やTLS 4等に変更することが検討されたが、最終的にTLS 1.3に落ち着いた。
暗号スイート TLSではハンドシェイクプロトコルのClientHello・ServerHelloで、以後の通信で用いる暗号スイート (ciphersuite) を決定する。TLS 1.2を策定しているでは、暗号スイートを以下のフォーマットで表現している：
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
これは次の意味である。 鍵共有方式として以下のものを用いる： EDH（Ephemeral Diffie-Hellman、後述）の通信に DSS署名したもの 認証暗号として平文にMACをつけた後に共通鍵暗号化する（いわゆるMAC-then-Encrypt (MtE) 型）のもので 共通鍵暗号としてCBCモードの256ビット鍵AESを用い、 MACとしてはSHA256ハッシュ関数をベースとしたHMACを用いる
TLS1.2では認証暗号としてMtE型のもののみならず、AES-GCMのような認証暗号専用に作られた暗号利用モードも用いる事ができるようになった。この場合MACはそもそも必要ない。
なお、RSA暗号とRSA署名を組み合わせる事で実現した鍵共有方式に対してはTLS_RSA_RSA_WITH…のようにRSAを2回書かず、TLS_RSA_WITH_…のように略記する。
鍵共有、共通鍵暗号、ハッシュ関数の全ての組み合わせが網羅されているわけではないので、同時に利用できない組み合わせも存在する。
鍵共有 SSL/TLS（の1つ以上のバージョンで）使用できる鍵共有方式は以下のとおりである。ここでDHはDiffie-Hellmanの事である。なおDH-ANON、ECDH-ANONは中間者攻撃に対して脆弱であることから安全とはみなされていない。
DH-ANON (Anonymous DH)、ECDH-ANON (Anonymous ECDH) はそれぞれ、送信データに署名する事なくDH鍵共有、ECDH鍵共有を行う方式である。 DHE-***はEphemeral DHと呼ばれるもので、鍵共有の際クライアント、サーバが、をランダムに選び、、を計算し、これらに署名文をつけた上で交換しあう方式である。、につける署名文を作成する署名方式は「***」の部分に記載されたものを使う。ECDHE-***はDHEの楕円DH版である。 DH-***はFixed DHもしくはnon-interactive DHと呼ばれるもので、Diffie-Hellmanで用いるパラメータ（クライアントの、サーバの）がクライアントやサーバの公開鍵として認証局から公開鍵証明書を受け取っているケースのDiffie-Hellman鍵共有である。、に対する公開鍵証明書内の署名文を作成する署名方式は「***」の部分に記載されたものを使う。ECDH-*** (Fixed ECDH) はFixed DHの楕円DH版である。