コンテンツにスキップ

「Transport Layer Security」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集
削除された内容 追加された内容
ビジュアルウィキテキスト
→‎TLS 1.1: Windows
 
(100人を超える利用者による、間の565版が非表示)
1行目: 1行目:

{{複数の問題

'''Secure Socket Layer '''（セキュアソケットレイヤー、'''SSL'''）とは、[[ネットスケープ・コミュニケーションズ|Netscape Communications]]社によって開発された[[OSI参照モデル#トランスポート層|トランスポート層]]に位置する[[通信プロトコル|プロトコル]]（[[ソケット]]・[[ライブラリ]]）で、[[暗号化]]と[[認証]]により[[コンピュータセキュリティ|セキュリティ]]を要求される通信のための'''手段を提供'''する。一般的には、[[クレジットカード]]情報や[[個人情報]]の遣り取りなど、セキュリティ上で必要な場合に利用される。

|出典の明記=2021-04

|更新=2021-04}}

{{IPstack}}

{{インターネットセキュリティプロトコル}}<!-- Edit the stack image at: Template:IPstack -->

'''Transport Layer Security'''（トランスポート・レイヤー・セキュリティ、'''TLS'''）は、[[インターネット]]などの[[コンピュータネットワーク]]において[[セキュア通信|セキュリティを要求される通信]]を行うための[[通信プロトコル|プロトコル]]である。主な機能として、通信相手の[[認証]]、通信内容の[[暗号|暗号化]]、[[改竄]]の検出を提供する。TLSは非営利組織[[Internet Engineering Task Force|IETF]]によって策定された。


当プロトコルは（特に区別する場合を除いて）'''SSL''' ('''Secure Sockets Layer''') と呼ばれることも多い。これは、TLSの元になったプロトコルがSSLであり<ref>プロトコル名を含めた歴史については、Eric Rescorla著,「マスタリングTCP/IP SSL/TLS編」,オーム社開発局（2003年）ISBN 4-274-06542-1 の2章6節が詳しい。</ref>、そのSSLという名称が広く普及していることによる<ref>ただし、メールサーバーへの接続においてはTLS接続用のTCPポートにはじめからTLSで接続するSMTP over SSLと、通常のTCPポートにSMTP接続後にSTARTTLSコマンドによってセキュアな接続に切り替えるSTARTTLSという異なる接続方式があり、名称を使い分けることがある。詳しくは[[#アプリケーション層プロトコルへの適用]]の項目を参照されたい。</ref>。SSLは[[ネットスケープコミュニケーションズ|Netscape]]が設計・開発した<ref name="saito">{{cite book|和書 |title=マスタリングTCP/IP情報 セキュリティ編 |edition=第2版 |pages=178-179 |author=齋藤 孝道 |date=2022-06-28 |publisher=[[オーム社]]}}</ref>。当初のSSLを元にして、以後、SSL 2（1994年）、SSL 3（1995年）がそれぞれ前バージョンの欠陥や脆弱性を修正するものとして公開された。SSLを拡張して、TLS（1999年）、TLS 1.2（2008年）、TLS 1.3（2018年）が作られた<ref name="saito" />。

暗号化は[[共通鍵暗号]]が使われる。また、データ送受信者のなりすましを防ぐため、

'''CA'''(Certification Authority)による保証が必要。


2004年1月現在の最新バージョンは、SSL3.0。

2022年現在の最新版はTLS 1.3である。


== 概要 ==

== TLS(Transport Layer Security) ==

TLSは多くの場合、コネクション型の[[トランスポート層]]プロトコル（通常は[[Transmission Control Protocol|TCP]]）と[[アプリケーション層]]の間で使われる。特に[[Hypertext Transfer Protocol|HTTP]]での利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存せず、様々なアプリケーションにおいて使われている。TLS 1.1以降を元にしたプロトコルが、[[User Datagram Protocol|UDP]]や[[Datagram Congestion Control Protocol|DCCP]]といった[[データグラム]]型プロトコル上でも実装されており、こちらは[[Datagram Transport Layer Security]] (DTLS) として独立して標準化されている。

'''Transport Layer Security'''は、SSL3.0のバージョンアップ版にあたり、RFC 2246においてTLS1.0として規定されている。


TLSはHTTPなどのアプリケーション層のプロトコルと組み合わせることで、[[HTTPS]]などセキュアな通信プロトコルを実現している。そのようなプロトコルとして以下のものがある。

SSL/TLSともにソケット・ライブラリにより実装されるため、[[OSI参照モデル#アプリケーション層|アプリケーション層]]のプロトコルを選ばないと言う特長がある。[[Secure HyperText Transfer Protocol|https]]だけでなく、ftps、telnets、pop3sなどがある。


{| class="wikitable"

<スタブ>

|-

! SSLと組み合わせたプロトコル !! ポート番号 !! 元のプロトコル !! ポート番号

|-

| [[HTTPS]] || 443 || [[Hypertext Transfer Protocol|HTTP]] || 80

|-

| [[SMTPS]] || 465 || [[Simple Mail Transfer Protocol|SMTP]] || 25

|-

| [[LDAPS]] || 636 || [[Lightweight Directory Access Protocol|LDAP]] || 389

|-

| [[FTPS]] (data) || 989 || [[File Transfer Protocol|FTP]] (data) || 20

|-

| FTPS (control) || 990 || FTP (control) || 21

|-

| [[IMAPS]] || 993 || [[Internet Message Access Protocol|IMAP]] || 143

|-

| [[POP3S]] || 995 || [[Post Office Protocol|POP3]] || 110

|}


=== アプリケーション層プロトコルへの適用 ===

== セキュリティ上の考察 ==

TLSは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、[[クレジットカード]]情報や[[個人情報]]、その他の機密情報を通信する際の手段として活用されている。

SSL/TLS を導入さえすればセキュリティーが確保できると言う誤解は多く, その場合偽サイトを作られる可能性がある。SSL/TLS はセキュリティーを確保する'''手段は提供'''するが, 実際に確保されるには利用者が鍵の真贋を見分ける必要がある。

多くの場合利用者は確認方法を知らないので確認方法を手引きする必要があるものと思われるが, 逆に確認をさせないようにデザインされているサイトが横行している。これでは偽者との通信を保護することになりかねない。（cf.[[フィッシング (詐欺)|フィッシング]]）


既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとして<code>STARTTLS</code>が広まっているため、この方式自体を[[STARTTLS]]と呼ぶこともある。

== 関連記事 ==

前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、平文で接続を開始する実装と共存できなくなるため、既存の[[ポート番号]]とは別にTLS対応用のポート番号が必要となる。実態としては、SSL/TLSの最初の適用例である[[HTTPS]]をはじめとして、前者の方式を使うことが多い。ただし、この方式はバーチャルホストを構成する際に問題となる可能性がある。詳細は[[#バーチャルホスト]]の節を参照。

なお、ポート番号を分ける方式をSSL、同一ポート番号で切替える方式（STARTTLS方式）をTLSと呼んでいる実装もある<ref>{{Cite web |url=http://wiki2.dovecot.org/SSL |title=SSL |work=Dovecot Wiki |quote=SSL and TLS terms are often used in confusing ways |accessdate=2015-01-10}}</ref>。TLS/SSLという用語の区別がプロトコルのバージョンを指しているか、アプリケーション層プロトコルへの適用方式を指しているかは、文脈で判断する必要がある。

=== セキュリティ上の考察 ===

==== TLS適用の有無と使用アルゴリズムの強度 ====

TLSを導入さえすればセキュリティが確保できるという認識は誤っている。TLS通信は、[[平文]]での通信に比べて︵主に[[暗号化]]・[[復号]]時︶余分な[[計算時間|計算機能力]]を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、TLSが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。

[[ファイル:Firefox-SSL-padlock.png|thumb|Mozilla Firefoxにおける南京錠アイコンの例]]

[[World Wide Web]]では、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信で TLS (HTTPS) が使用されているか把握することが重要になる。多くの[[ウェブブラウザ]]は、画面のどこかに[[南京錠]]の[[アイコン]]を表示したり、[[アドレスバー]]の色を変化させたりして、利用者に情報を提供していた。一方 Google は南京錠のアイコンが適切ではなくなったとして、Chrome での南京錠の表示を廃止した<ref>

{{Cite Web

|title=Google Chrome、南京錠アイコンを2023年9月に廃止

|url=https://news.mynavi.jp/techplus/article/20230504-2671546/

|date=2023-5-4

|accessdate=2024-3-11

}}</ref>。背景として、HTTPS が普及したこと、南京錠アイコンの意味を正しく理解している人が少ない<ref>

{{Cite Web

|title=大多数の人は、ウェブブラウザの南京錠アイコンが何を意味するのか理解していない

|url=https://texal.jp/the-majority-of-people-do-not-know-what-the-padlock-icon-on-their-internet-browser-means/

|date=2023-11-23

|accessdate=2024-3-11

}}</ref>ことを挙げている。さらに、Chrome では HTTPS を使っていない通信を行う前に警告画面を出すようにした<ref>

{{Cite Web

|title=すべての「Chrome」をHTTPSファーストに、Googleが本腰を入れる

|url=https://forest.watch.impress.co.jp/docs/news/1524675.html

|date=2023-8-18

|accessdate=2024-3-11

}}</ref>。

また実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため、TLSを使用していても、システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある。このような場合もダイアログメッセージなどを使って利用者に警告すべきである。

==== 証明書の正当性 ====

{{Main|認証局}}

TLSは公開鍵証明書を用いて認証を行い、[[なりすまし]]を極力排除しようとする。しかしシステムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではない。

[[公開鍵証明書]]には認証局による電子署名が与えられる。その署名の正当性を評価するためには認証局の証明書が必要であり、最終的には[[ルート証明書]]と呼ばれる一群の証明書に行きつく。各システムは、認証局の証明書として信用できるルート証明書を、あらかじめ保持している。認証局は自身の秘密鍵を厳重に秘匿し、また証明書の発行にあたっては正当なサーバ管理者かどうか確認することが求められる。これらが保証されない認証局のルート証明書を組み込むことは、TLSにおける認証機能を破綻させることになる。仮に認証局自体は安全でも、入手したルート証明書が本当に意図する認証局のものかどうか判断することは難しいという点も注意すべきである。


TLSで認証を行うためには、認証局の署名に加えて、証明書の発行先を確認する必要がある。確認しない場合、サーバAの管理権限を持たない者がサーバBとして正当な証明書を取得し、その証明書を使ってサーバAを名乗ることができてしまう。TLS用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。


現実には﹁正当な﹂サーバであっても、これらの検証において﹁問題がある﹂と判断される証明書を使って運用されているサーバが少なからず存在する。セキュリティ研究者の[[高木浩光]]は、このような証明書のことを、[[振り込め詐欺|オレオレ詐欺]]をもじって﹁[[オレオレ証明書]]﹂と呼んで批判している<ref>{{Cite web|和書

|author=高木 浩光

|authorlink=高木浩光

|date=2007-11-17

|url=http://takagi-hiromitsu.jp/diary/20071117.html#p02

|title=オレオレ証明書の区分 第三版

|work=高木浩光＠自宅の日記

|accessdate=2010-01-03

}}</ref>。

この検証は、システムに指示された接続先のホスト名と実際に接続した先のホスト名が一致することを検証しているのであり、利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある。

例として、利用者が意図する接続先であるサーバ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) が公開している「安全なウェブサイトの作り方」<ref>{{Cite web|和書

|date=2008-06-11

|url=https://www.ipa.go.jp/security/vuln/websecurity.html

|title=「安全なウェブサイトの作り方　改訂第3版」を公開

|publisher=独立行政法人 [[情報処理推進機構]]

|accessdate=2010-01-03

}}</ref>という文書の「[[フィッシング (詐欺)|フィッシング]]詐欺を助長しないための対策」に対応する。

==== 乱数の品質 ====

他の多くの近代暗号と同様に、TLSもまた、暗号としての強度は乱数の品質に依存している。桁数（[[ビット]]長）の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている（これは、[[公開鍵暗号]]システムにも言える）。もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、[[総当たり攻撃]]で解読される可能性が上昇する。通常は、これは実装の問題に起因している。

古い例では、Netscapeの初期の実装における乱数生成の脆弱性がある。[[プロセス識別子|プロセスID]]や時刻から乱数を生成していることが判明し、これらの情報を取得できる場合には総当たり攻撃の所要時間が大幅に短くなるという問題があった<ref>{{Cite web

|author=Ian Goldberg

|coauthors=David Wagner

|date=1996-01-01

|url=http://www.ddj.com/windows/184409807

|title=Randomness and the Netscape Browser

|publisher=Dr. Dobb's

|language=英語

|accessdate=2010-01-03

}}</ref>。

[[2008年]][[5月15日]]には[[Debian]]が脆弱性に関する報告<ref>{{Cite web|和書

|date=2008-05-15

|url=http://www.debian.or.jp/blog/openssl_package_and_its_vulnerability.html

|title=OpenSSL パッケージの脆弱性とその影響について（SSH鍵、SSL証明書等）

|publisher=[[Debian]] JP Project

|accessdate=2010-01-03

}}</ref>を発表した。[[OpenSSL]]ライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536 (= 2<sup>16</sup>) 通りの予測可能な物が生成されてしまった事を明らかにした<ref>{{Cite web

|date=2008-05-15

|url=http://www.securityfocus.com/archive/1/492112/30/0/threaded

|title=Debian generated SSH-Keys working exploit

|publisher=SecurityFocus

|accessdate=2010-01-03

}}</ref>︵なお、この問題はOpenSSLそのものの脆弱性ではない︶。この影響を受けるのはDebian sargeより後のバージョンのDebianと、それから派生した[[Damn Small Linux]]、[[KNOPPIX]]、[[Linspire]]、[[Progeny Debian]]、[[sidux]]、[[Ubuntu]]、[[UserLinux]]、[[Xandros]]である。脆弱性のあるバージョンのOpenSSLは[[2006年]][[9月17日]]に公開された。安定バージョンがリリースされた[[2007年]][[4月8日]]以降は確実に影響を受ける。脆弱性のあるバージョンのOpenSSLで作られた鍵全て、[[Secure Shell|SSH]]鍵、[[OpenVPN]]鍵、[[DNS Security Extensions|DNSSEC]]鍵、[[X.509]]証明書を生成するのに使われる鍵データ、およびSSL/TLSコネクションに使うセッション鍵等が影響を受ける。これらの鍵は65536通り全てを総当たり攻撃で試すだけでいずれの鍵が使われているか解読可能であり︵SSHでは20分間で解読できたと報告されている︶、また脆弱な鍵がインストールされたDebianを含む全ての[[オペレーティングシステム]]において緊急の対応が必要であると専門家が注意を呼びかけている。生成された鍵に問題があるため、Debian GNU/Linuxで生成した鍵を[[Microsoft Windows]]のような非UNIXシステムに導入しているような場合も、この脆弱性の影響を受ける。具体的対応については、Debianの報告の他、[[JPCERT/CC]]の勧告<ref>{{Cite web|和書

|date=2008-05-19

|url=http://www.jpcert.or.jp/at/2008/at080008.txt

|title=Debian GNU/Linux に含まれる OpenSSL/OpenSSH の脆弱性に関する注意喚起

|publisher=[[JPCERT/CC]]

|accessdate=2010-01-03

}}</ref>等に従うべきである。

== プロトコル概要 ==

本説ではTLS 1.2の概要を説明する。

TLSには主なプロトコルとして暗号通信に必要な鍵 ('''master secret''') を[[鍵共有]]して[[セッション]]を確立する'''TLSハンドシェイクプロトコル'''と、master secretを用いて暗号通信することで確立されたセッションにおける[[コネクション]]をセキュアにする'''TLSレコードプロトコル'''がある。

その他に用いている暗号方式やハッシュ関数等のアルゴリズムを変更する '''Change Cipher Spec プロトコル'''と通信相手からの通信終了要求や何らかのエラーを通知する '''アラートプロトコル'''がある。

=== TLSハンドシェイクプロトコル ===

TLSハンドシェイクプロトコルは4つのフェーズに大別できる。

{|

|-

| rowspan="20" align="center" |

{| border="0" style="border-top:1px solid black; border-right:1px solid black; border-bottom:2px solid black; border-left:1px solid black;"

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|クライアント

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|}

|（第一フェーズ）

| rowspan="20" align="center" |

{| border="0" style="border-top:1px solid black; border-right:1px solid black; border-bottom:2px solid black; border-left:1px solid black;"

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;&nbsp;&nbsp;サーバ&nbsp;&nbsp;&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|-

|&nbsp;

|}

|-

|─ClientHello───→

|-

|←ServerHello────

|-

| &nbsp;

|-

|（第二フェーズ）

|-

|←Certificate────

|-

|←ServerKeyExchange─

|-

|←CertificateRequest──

|-

|←ServerHelloDone──

|-

| &nbsp;

|-

|（第三フェーズ）

|-

|─Certificate───→

|-

|─ClientKeyExchange→

|-

|─CertificateVerify─→

|-

| &nbsp;

|-

|（第四フェーズ）

|-

|─Change Cipher Spec→

|-

|─Finished─────→

|-

|←Change Cipher Spec─

|-

|←Finished──────

|}

==== 第一フェーズ ====

第一のフェーズではサーバ・クライアント間で通信に必要情報の合意を図る。このフェーズでは、まずクライアントからサーバに'''ClientHello'''が送信され、次にサーバからクライアントに'''ServerHello'''が送信される<ref name="RFC5246-7" />。

ClientHelloはTLSのバージョン、乱数、セッションID、通信に用いる暗号方式やハッシュアルゴリズムのリスト ('''cipher_suites''')、通信内容の圧縮方法、および拡張領域の6つからなる<ref name="RFC5246-7">[https://web.archive.org/web/20220819105818/https://www.ipa.go.jp/security/rfc/RFC5246-07JA.html RFC5246日本語訳「 TLS ハンドシェイク関連プロトコル」]、IPA。2016年8月11日閲覧</ref>。乱数は鍵共有におけるリプレイ攻撃を防ぐためのものである。


ServerHelloもClientHelloと同様の6つからなっている︵名称は一部異なる︶<ref name="RFC5246-7" />。ServerHelloの主な目的は、ClientHelloで提示された選択肢の中でサーバにとって好ましいものを選択する事で、例えばClientHelloで提示されたcipher_suitesの中から、サーバが通信に使いたいcipher_suiteを一組選ぶ<ref name="RFC5246-7" />。乱数はClientHelloとは独立して選ぶ<ref name="RFC5246-7" />。これもリプレイ攻撃を回避するためである。セッションIDは特に問題がなければClientHelloと同一のものを返す。

==== 第二フェーズ ====

第二フェーズではサーバからクライアントに対して鍵共有に必要な情報を送る。具体的にはサーバは'''Certificate'''、'''ServerKeyExchange'''、'''CertificateRequest'''、'''ServerHelloDone'''を（第一フェーズServerHelloに引き続き）クライアントに送信する<ref name="RFC5246-7" />。

Certificateは鍵共有で用いる公開鍵とその証明書で別途取り決めがない限り[[X.509|X.509v3]]のフォーマットに従う<ref name="RFC5246-7" />。なお鍵共有方式としてDH_anonを用いている場合にはcertificateは必要ない<ref name="RFC5246-7" />。

ServerKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、{{math|''g''<sup>''x''</sup> mod ''p''}}という形のデータを送る。ここで{{mvar|x}}はサーバの秘密の乱数である。鍵共有プロトコルがDHE_DSS、DHE_RSA、DH_anonでは何らかのserver_key_exchangeを送るが、RSA、DH_DSS、DH_RSAでは何も送らない<ref name="RFC5246-7" />。

CertificateRequestはクライアントの公開鍵とその証明書を送ることを要求するためのもので、サーバが許容できる証明書の種別、ハッシュと署名方式、および[[認証局]]のリストからなっている<ref name="RFC5246-7" />。

そして最後にサーバ側からのメッセージ送信が終わった事を示すServerHelloDoneをクライアントに送る。

==== 第三フェーズ ====

第三フェーズではクライアントからサーバに対して鍵共有に必要な情報を送る。具体的にはクライアントは'''Certificate'''、'''ClientKeyExchange'''、'''CertificateVerify'''をサーバに送る<ref name="RFC5246-8" />。

Certificateは鍵共有で用いるクライアントの公開鍵とその証明書である。証明書はサーバから送られてきたCertificateRequestの条件を満たさねばならない。

ClientKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、{{math|''g''<sup>''y''</sup> mod ''p''}}という形のデータを送る。ここで{{mvar|y}}はクライアントの秘密の乱数である。

ここまでのプロトコルにより、サーバとクライアントの間で'''premaster secret'''が共有された事になる。DH_anonであればpremaster secretは{{math|''g''<sup>''xy''</sup> mod ''p''}}である。premaster secretを鍵にした[[擬似ランダム関数]]にServerHelloとClientHelloの乱数などを並べたものを入力した結果得られたものが'''master secret'''である<ref name="RFC5246-8">[https://web.archive.org/web/20220419005948/https://www.ipa.go.jp/security/rfc/RFC5246-08JA.html RFC5246日本語訳「 8. 暗号技術的計算」]、IPA。2016年8月11日閲覧</ref>。

CertificateVerifyはクライアントが署名能力を持っていることを証明するためにこれまでTLSハンドシェイクプロトコルで送受信された全メッセージに対し、共有されたmaster secret で署名したものである<!--という意味だと理解したがよくわからず。誰か詳しい人フォローして下さい。-->{{要検証|date=2016年8月}}<ref name="RFC5246-7" />。

==== 第四フェーズ ====

クライアントは必要ならChange Cipher Spec プロトコルのメッセージをサーバに送り、終了を意味するFinishedをサーバに送る。同様にサーバも必要ならChange Cipher Spec プロトコルのメッセージをクライアントに送り、終了を意味するFinishedをクライアントに送る<ref name="RFC5246-7" />。

=== TLSレコードプロトコル ===

TLSレコードプロトコルはアプリケーション層から受け取った通信内容を2<sup>14</sup>バイト以下のブロックに'''分解''' (fragmentation) し、各ブロックを'''圧縮''' (compress) し、圧縮されたブロックを[[認証付き暗号|認証暗号]]で暗号化する'''レコード Payload 防護'''を施した上で、通信内容を通信相手に送信する<ref name="RFC5246-6">[https://web.archive.org/web/20220507084749/https://www.ipa.go.jp/security/rfc/RFC5246-06JA.html RFC5246日本語訳「6. TLS レコードプロトコル」]、IPA。2016年8月11日閲覧</ref>。


認証暗号は、TLS 1.1まではMACをつけた後で共通鍵暗号化するMAC-then-Encrypt (MtE) のみが利用可能であった。TLS 1.2からは、[[Advanced Encryption Standard|AES]]-[[Galois/Counter Mode|GCM]]のようなAEADに分類される認証暗号専用の[[暗号利用モード]]も利用可能になり<ref name="RFC5246-6" />、TLS 1.3ではAEADのみが利用可能となっている。

認証暗号にブロック暗号（AEAD以外）を選択した場合、TLS 1.1以降において[[初期化ベクトル|IV]]はTLSレコードプロトコルの送信者がランダムに選ぶ<ref name="RFC5246-6" />。ランダムなIVは、[[#BEAST攻撃|BEAST攻撃]]への対策として有効である。一方、認証暗号で用いる共通鍵はTLSハンドシェイクプロトコルで共有されたmaster secretを用いる。

== バージョン ==

コンピュータの計算能力の向上とともに、認証の突破、暗号の解読、改竄も以前よりは容易に行えるようになり、セキュリティ確保のための技術も厳しさを増している。

'''2017年現在では、TLS 1.2 以上のバージョンの実装が推奨され、TLS 1.1 以下のサポートを停止するサイトも出てきている'''<ref>{{Cite web|和書|url=https://blogs.technet.microsoft.com/jpsecurity/2017/07/11/tlsmigration/ |title=IT 管理者向け - TLS 1.2 への移行を推奨しています |publisher=[[マイクロソフト]] [[TechNet]] |date=2017-07-11 |accessdate=2018-05-12}}</ref><ref>{{Cite web|和書|url=https://knowledge.symantec.com/jp/support/ssl-certificates-support/index?vproductcat=V_C_S&vdomain=VERISIGN.JP&page=content&actp=CROSSLINK&id=ALERT1980&locale=ja_JP&redirected=true |title=TLS1.0 サポート停止におけるシステムメンテナンスのお知らせ |publisher=[[シマンテック]] |date=2016-02-19 |accessdate=2018-05-12}}</ref><ref>{{Cite web|和書|url=https://security.yahoo.co.jp/news/tls12.html |title=2018年6月1日以降、古いブラウザー、パソコン、スマートフォンなどでは、Yahoo! JAPANのウェブサービスが順次ご利用いただけなくなります。|publisher=[[Yahoo! JAPAN]] |accessdate=2018-05-23}}</ref>。2021年3月には{{IETF RFC|8996}}により、TLS 1.0〜TLS 1.1の使用禁止が求められている。

{| class="wikitable" style="float:right; margin-left:9px;"

|-

! colspan=2 | 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 (ネットスケープコミュニケーションズ)|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を無効にしない限りこの脆弱性の影響を受ける可能性を否定できない<ref>{{Cite web|和書

|author=大岩 寛

|date=2005-10-13

|url=http://www.oiwa.jp/~yutaka/tdiary/20051013.html#p01

|title=<nowiki>[Security]</nowiki> SSL 2.0 version rollback の件のFAQ

|work=おおいわのこめんと

|accessdate=2010-01-03

}}</ref>。SSL 3.0以降に対応した実装が十分に普及したものとして、[[Internet Explorer|Internet Explorer 7]]や[[Mozilla Firefox|Mozilla Firefox 2]]、[[Opera|Opera 9]]などは、初期状態でSSL 2.0を無効にしている<ref>{{Cite web|和書

|author=Eric Lawrence

|date=2006-01-31

|url=http://www.microsoft.com/japan/msdn/ie/expie/ie7_https_imps.aspx

|title=Internet Explorer 7 における HTTPS セキュリティの強化点

|publisher=マイクロソフト

|accessdate=2010-01-03

}}</ref><ref>{{Cite web|和書

|date=2009-07-06

|url=http://support.mozilla.com/ja/kb/%E3%82%B5%E3%82%A4%E3%83%88%E3%81%8C%E5%8F%A4%E3%81%8F%E3%81%A6%E5%AE%89%E5%85%A8%E3%81%A7%E3%81%AA%E3%81%84%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AE+SSL+%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%9F%E3%82%81%E3%80%81%E5%AE%89%E5%85%A8%E3%81%AA%E6%8E%A5%E7%B6%9A%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%9B%E3%82%93%E3%81%A7%E3%81%97%E3%81%9F

|title=サイトが古くて安全でないバージョンの SSL プロトコルを使用しているため、安全な接続ができませんでした

|work=Firefox サポート

|accessdate=2010-01-03

}}</ref><ref>{{Cite web|和書

|url=http://jp.opera.com/docs/specs/opera9/#network

|title=Opera 9 のサポートするウェブ標準ならびに仕様

|publisher=Opera Software ASA.

|accessdate=2010-01-03

}}</ref>。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっている<ref>{{Cite web|和書

|author=勝村 幸博

|date=2006-06-02

|url=https://xtech.nikkei.com/it/article/NEWS/20060602/239846/

|title=「SSL 2.0だけに対応したWebサイトはわずか0.1％」---ネットクラフト

|publisher=[[日経BP]] IT pro

|accessdate=2010-01-03

}}</ref>。

SSL 2.0にはチェーン証明書がなく、[[ルート証明書|ルートCA]]から発行したSSLサーバ証明書しか使うことができない。

2011年3月、{{IETF RFC|6176}} によって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]]から歴史的文書という扱いで{{IETF RFC|6101}}として公開された。


2014年10月にSSL 3.0の仕様上の脆弱性︵[[#POODLE攻撃|POODLE攻撃]]︶が発見されたため、SSL 3.0への対応を打ち切り、TLS 1.0以降のみ対応への移行が望まれている。2015年6月、{{IETF RFC|7568}} によってSSL 3.0の使用は禁止された。

'''SSLについては、使うべきではない'''。

=== TLS 1.0 ===

[[Internet Engineering Task Force|IETF]]のTLSワーキンググループは{{IETF RFC|2246}}としてTLS 1.0を公表した。TLS 1.0の標準化作業は[[1996年]]に開始され、年内に完了する予定だったが、いくつかの問題に阻まれ、公表は[[1999年]]まで遅延した。

TLS 1.0が提供する機能はSSL 3.0とあまり変わらないが、アルゴリズムやルートCAの[[自己署名証明書]]の取扱いなどの仕様の詳細が変更されたことに加え、これまであまり実装されていなかった選択肢のいくつかが必須と定められた。このため、TLS 1.0を実装した製品が普及するまでには、さらに数年を要した。

2021年3月、{{IETF RFC|8996}}によりTLS 1.0を使用しないことが呼びかけられている。

なおTLS 1.0はSSL 3.0より新しい規格であることを示すため、ネゴシエーションにおけるバージョン番号は3.1となっている。

=== TLS 1.1 ===

[[2006年]]に{{IETF RFC|4346}}としてTLS 1.1が制定された。TLS 1.0からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。特にCBC攻撃に対する耐性を上げるため、[[初期化ベクトル]]を明示的に指定することにし、さらにパディングの処理も改善された。また、予期せぬ回線クローズ後に、セッションを再開できるようになった。共通鍵暗号アルゴリズムとして[[Advanced Encryption Standard|AES]]が選択肢に加わった<ref>{{IETF RFC|3268}} によって後付けでAESが追加されたTLS 1.0とは異なり、TLS 1.1を定義する {{IETF RFC|4346}} A.5節では{{IETF RFC|3268}}が参照され、AESが当初から追加されている</ref>。


2021年3月、{{IETF RFC|8996}}によりTLS 1.1を使用しないことが呼びかけられている。2024年10月より、[[Windows]]はTLS 1.0、TLS 1.1をサポートしない旨を発表した<ref>{{Cite web|url=https://forest.watch.impress.co.jp/docs/news/1605556.html|title=Microsoft、﹁TLS 1.0﹂﹁TLS 1.1﹂対応を終了 ～2024年10月31日以降、利用不可|accessdate=2024-07-05|publisher=ITmedia}}</ref>。

ネゴシエーションにおけるバージョン番号は3.2となっている。

=== TLS 1.2 ===

[[2008年]]8月に{{IETF RFC|5246}}としてTLS 1.2が制定された。ハッシュのアルゴリズムに[[SHA-2|SHA-256]]が追加されたほか、[[ブロック暗号]]について、従来の[[暗号利用モード#CBC|CBCモード]]だけではなく、[[Galois/Counter Mode|GCM]]、[[Counter with CBC-MAC|CCM]]といった[[認証付き暗号]]を用いたcipher suiteが利用可能となった。また、AESに関する記述が{{IETF RFC|5246}}自体に含まれるようになった。

ネゴシエーションにおけるバージョン番号は3.3となっている。

=== TLS 1.3 ===

新たなTLSのバージョンとしてTLS 1.3が提案されてきたが<ref>[//tools.ietf.org/html/draft-ietf-tls-tls13-18 draft-ietf-tls-tls13-18 "[[IETF]] The Transport Layer Security (TLS) Protocol Version 1.3"]</ref>、IETFは2018年3月23日に、ドラフト28を標準規格として承認し<ref>{{Cite web|和書|url=https://jp.techcrunch.com/2018/03/24/2018-03-23-the-web-will-soon-be-a-little-safer-with-the-approval-of-this-new-security-standard/ |title=IETFがTLS 1.3を承認、悪質なハッカーや盗聴者が仕事をしづらくなる仕掛けを盛り込む |date=2018-03-24 |publisher=[[TechCrunch]] Japan |accessdate=2018-05-12}}</ref><ref>{{Cite web|和書|url=https://japan.zdnet.com/article/35116733/| title=IETFがTLS 1.3を承認--安全性や速度向上、課題も| date=2018-03-27| publisher=[[ZDNet]] |accessdate=2018-05-12}}</ref>、同年8月10日に{{IETF RFC|8446}}として公開した<ref>{{Cite news|url=https://forest.watch.impress.co.jp/docs/news/1138657.html|title=IETF、「TLS 1.3」を正式リリース ～「Firefox」「Google Chrome」は最終草案に対応|agency=[[窓の杜]]|date=2018-08-20|accessdate=2019-11-12}}</ref>。

TLS 1.2からの変更点としては、[[データ圧縮]]の非サポート、[[forward secrecy]]ではないcipher suite（RSAのみを用いたもの）および[[認証付き暗号]]ではないcipher suite（[[暗号利用モード#CBC|CBCモード]]の[[ブロック暗号]]や[[RC4]]を用いたもの）の廃止が挙げられる。なお名称をTLS 2.0やTLS 4等に変更することが検討されたが、最終的にTLS 1.3に落ち着いた。

== 暗号スイート ==

TLSではハンドシェイクプロトコルのClientHello・ServerHelloで、以後の通信で用いる暗号スイート (ciphersuite) を決定する。TLS 1.2を策定している{{IETF RFC|5246}}では、暗号スイートを以下のフォーマットで表現している：

TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

これは次の意味である。

* 鍵共有方式として以下のものを用いる：

** EDH（Ephemeral Diffie-Hellman、後述）の通信に

** [[Digital Signature Algorithm|DSS]]署名したもの

* 認証暗号として平文にMACをつけた後に共通鍵暗号化する（いわゆるMAC-then-Encrypt (MtE) 型）のもので

** 共通鍵暗号として[[暗号利用モード#Cipher Block Chaining (CBC)|CBCモード]]の256ビット鍵[[Advanced Encryption Standard|AES]]を用い、

** MACとしては[[SHA-2|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'''と呼ばれるもので、鍵共有の際クライアント、サーバが{{mvar|x}}、{{mvar|y}}をランダムに選び、{{mvar|g<sup>x</sup>}}、{{mvar|g<sup>y</sup>}}を計算し、これらに署名文をつけた上で交換しあう方式である。{{mvar|g<sup>x</sup>}}、{{mvar|g<sup>y</sup>}}につける署名文を作成する署名方式は「***」の部分に記載されたものを使う。'''ECDHE-***'''はDHEの楕円DH版である。

* '''DH-***'''は'''Fixed DH'''もしくは'''non-interactive DH'''と呼ばれるもので、Diffie-Hellmanで用いるパラメータ（クライアントの{{mvar|g<sup>x</sup>}}、サーバの{{mvar|g<sup>y</sup>}}）がクライアントやサーバの公開鍵として認証局から公開鍵証明書を受け取っているケースのDiffie-Hellman鍵共有である。{{mvar|g<sup>x</sup>}}、{{mvar|g<sup>y</sup>}}に対する公開鍵証明書内の署名文を作成する署名方式は「***」の部分に記載されたものを使う。'''ECDH-***''' ('''Fixed ECDH''') はFixed DHの楕円DH版である。

* '''RSA-***'''はランダムに選んだ共有鍵をサーバの公開鍵でRSA暗号化し、暗号文を「***」で指定された署名方式で署名したものをClientKeyExchangeにおいてクライアントがサーバに送る方式である。（ServerKeyExchangeでは何も送らない）。

いずれの鍵共有においても共有された鍵 (premaster secret) を用いた擬似ランダム関数にクライアントが選んだ乱数とサーバが選んだ乱数等を並べたものを入力する事で最終的なmaster secretを得る。これによりリプレイ攻撃を防いでいる。

これらの鍵共有方式の対応状況は以下のとおりである：

{| class="wikitable" style="text-align:center"

|+ TLSの各バージョンで使用できる認証・鍵交換アルゴリズム

! アルゴリズム !! SSL 2.0 !! SSL 3.0 !! TLS 1.0 !! TLS 1.1 !! TLS 1.2 !! TLS 1.3 !! 状況

|-

! {{partial|[[RSA暗号|RSA]]}}

| {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{N/a|非対応}} || rowspan="19" | TLS 1.2向けにRFCで定義済み

|-

! {{partial|[[ディフィー・ヘルマン鍵共有|DH]]-[[RSA暗号|RSA]]}}

| {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{N/a|非対応}}

|-

! {{yes|[[ディフィー・ヘルマン鍵共有|DHE]]-[[RSA暗号|RSA]] ([[forward secrecy]])}}

| {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}}

|-

! {{partial|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDH]]-[[RSA暗号|RSA]]}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{N/a|非対応}}

|-

! {{yes|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDHE]]-[[RSA暗号|RSA]] ([[forward secrecy]])}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}}

|-

! {{partial|[[ディフィー・ヘルマン鍵共有|DH]]-[[Digital Signature Algorithm|DSS]]}}

| {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{N/a|非対応}}

|-

! {{yes|[[ディフィー・ヘルマン鍵共有|DHE]]-[[Digital Signature Algorithm|DSS]] ([[forward secrecy]])}}

| {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{N/a|非対応}}<ref>{{cite web|url=https://www.ietf.org/mail-archive/web/tls/current/msg17680.html|title=Consensus: remove DSA from TLS 1.3|date=2015-09-17|accessdate=2015-09-19|author=Sean Turner}}</ref>

|-

! {{partial|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDH]]-[[楕円曲線DSA|ECDSA]]}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{N/a|非対応}}

|-

! {{yes|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDHE]]-[[楕円曲線DSA|ECDSA]] ([[forward secrecy]])}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}}

|-

! {{partial|{{仮リンク|事前共有鍵|en|Pre-shared key|label=PSK}}}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} ||

|-

! {{partial|{{仮リンク|事前共有鍵|en|Pre-shared key|label=PSK}}-[[RSA暗号|RSA]]}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} ||

|-

! {{partial|[[ディフィー・ヘルマン鍵共有|DHE]]-{{仮リンク|事前共有鍵|en|Pre-shared key|label=PSK}} ([[forward secrecy]])}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}}

|-

! {{partial|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDHE]]-{{仮リンク|事前共有鍵|en|Pre-shared key|label=PSK}} ([[forward secrecy]])}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}}

|-

! {{partial|{{仮リンク|Secure Remote Password protocol|en|Secure Remote Password protocol|label=SRP}}}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} ||

|-

! {{partial|{{仮リンク|Secure Remote Password protocol|en|Secure Remote Password protocol|label=SRP}}-[[Digital Signature Algorithm|DSS]]}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} ||

|-

! {{partial|{{仮リンク|Secure Remote Password protocol|en|Secure Remote Password protocol|label=SRP}}-[[RSA暗号|RSA]]}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} ||

|-

! {{partial|[[ケルベロス認証|KRB5]]}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} ||

|-

! {{no|[[ディフィー・ヘルマン鍵共有|DH]]-[[匿名|ANON]]（安全ではない）}}

| {{N/A|非対応}} || {{No|対応}} || {{No|対応}} || {{No|対応}} || {{No|対応}} ||

|-

! {{no|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDH]]-[[匿名|ANON]]（安全ではない）}}

| {{N/A|非対応}} || {{N/A|非対応}} || {{No|対応}} || {{No|対応}} || {{No|対応}} ||

|-

! {{yes|[[GOST規格|GOST R 34.10-94 / 34.10-2001]]<ref name="GOST"/>}}

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || || RFC草稿で提案中

|}


{{仮リンク|事前共有鍵|en|Pre-shared key}}を用いた TLS_PSK、{{仮リンク|Secure Remote Password protocol|en|Secure Remote Password protocol}}を用いた TLS_SRP、[[ケルベロス認証]]を用いた KRB5 も存在する。

[[独立国家共同体]]の[[GOST規格]]によって規定された鍵共有アルゴリズムであるGOST R 34.10も提案されている（同じGOST規格による暗号化・改竄検出アリゴリズムとの組み合わせに限定）<ref name="GOST">[//tools.ietf.org/html/draft-chudov-cryptopro-cptls-04 draft-chudov-cryptopro-cptls-04 - GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)]</ref>。

=== 認証暗号 ===

==== 共通鍵暗号 ====

認証暗号に用いる[[共通鍵暗号]]として以下のものがある。

{| class="wikitable" style="text-align:center"

|+ TLS/SSLの各バージョンで使用できる暗号化アルゴリズム

! colspan="3" | 暗号化 !! colspan="6" | プロトコルバージョン !! rowspan="2" | 状況

|-

! 種類 !! アルゴリズム !! 暗号強度 (bit) !! SSL 2.0 !! SSL 3.0<br /><ref group="注" name="{{IETF RFC|5746}}">[[#再ネゴシエーション脆弱性|再ネゴシエーション脆弱性]]への対応のため、{{IETF RFC|5746}} への対応が必要</ref><ref group="注">{{IETF RFC|5746}} への対応はSSL 3.0の仕様を逸脱するが、ほとんどの実装では対応したうえで仕様からの逸脱にも対処している</ref><ref group="注" name="BEAST">SSL 3.0およびTLS 1.0は[[#BEAST攻撃|BEAST攻撃]]に対して脆弱であり、クライアント側、サーバ側での対応が必要。[[#ウェブブラウザ]]節を参照</ref><ref group="注" name="POODLEciphertable">SSL 3.0は[[#POODLE攻撃|POODLE攻撃]]に対して脆弱であり、クライアント側、サーバ側での対応が必要。[[#ウェブブラウザ]]節を参照</ref> || TLS 1.0<br /><ref group="注" name="{{IETF RFC|5746}}"/><ref group="注" name="BEAST"/> !! TLS 1.1<br /><ref group="注" name="{{IETF RFC|5746}}"/> !! TLS 1.2<br /><ref group="注" name="{{IETF RFC|5746}}"/> !! {{nowrap|TLS 1.3}}

|-

! rowspan="14" | [[ブロック暗号]]<br />（[[暗号利用モード]]）

! [[Advanced Encryption Standard|AES]] [[Galois/Counter Mode|GCM]]<ref>{{IETF RFC|5288}}, {{IETF RFC|5289}}</ref><ref group="注" name="AEAD">GCM、CCMなどのAEAD（認証付き暗号モード）は、TLS 1.2以降のみで利用可能</ref>

| rowspan="3" | 256, 128

| {{n/a}} || {{n/a}} || {{n/a}} || {{n/a}} || {{yes|安全}} || {{yes|安全}} || rowspan="9" | TLS 1.2向けにRFCで定義済み

|-

! [[Advanced Encryption Standard|AES]] [[Counter with CBC-MAC|CCM]]<ref>{{IETF RFC|6655}}, {{IETF RFC|7251}}</ref><ref group="注" name="AEAD"/>

| {{n/a}} || {{n/a}} || {{n/a}} || {{n/a}} || {{yes|安全}} || {{yes|安全}}

|-

! [[Advanced Encryption Standard|AES]] [[暗号利用モード#CBC|CBC]]<ref group="注" name="Lucky13"/>

| {{n/a}} || {{n/a}} || {{partial|実装による}} || {{yes|安全}} || {{yes|安全}} || {{n/a}}

|-

! [[Camellia]] [[Galois/Counter Mode|GCM]]<ref>{{IETF RFC|6367}}</ref><ref group="注" name="AEAD"/>

| rowspan="2" | 256, 128

| {{n/a}} || {{n/a}} || {{n/a}} || {{n/a}} || {{yes|安全}} || {{n/a}}

|-

! [[Camellia]] [[暗号利用モード#CBC|CBC]]<ref>{{IETF RFC|5932}}および{{IETF RFC|6367}}</ref><ref group="注" name="Lucky13"/>

| {{n/a}} || {{n/a}} || {{partial|実装による}} || {{yes|安全}} || {{yes|安全}} || {{n/a}}

|-

! [[ARIA (暗号)|ARIA]] [[Galois/Counter Mode|GCM]]<ref name="ARIA">{{IETF RFC|6209}}</ref><ref group="注" name="AEAD"/>

| rowspan="2" | 256, 128

| {{n/a}} || {{n/a}} || {{n/a}} || {{n/a}} || {{yes|安全}} || {{n/a}}

|-

! [[ARIA (暗号)|ARIA]] [[暗号利用モード#CBC|CBC]]<ref name="ARIA"/><ref group="注" name="Lucky13"/>

| {{n/a}} || {{n/a}} || {{partial|実装による}} || {{yes|安全}} || {{yes|安全}} || {{n/a}}

|-

! [[SEED (暗号)|SEED]] [[暗号利用モード#CBC|CBC]]<ref>{{IETF RFC|4162}}</ref><ref group="注" name="Lucky13"/>

| 128

| {{n/a}} || {{n/a}} || {{partial|実装による}} || {{yes|安全}} || {{yes|安全}} || {{n/a}}

|-

! [[トリプルDES|3DES EDE]] [[暗号利用モード#CBC|CBC]]<ref group="注" name="Lucky13">CBCモードは、サイドチャネル攻撃への対処が不十分な実装では[[#パディング攻撃|Lucky Thirteen攻撃]]に対して脆弱である</ref>

| 112{{refn|group="注"|3DESの鍵長は168ビットであるが実質的な暗号強度は112ビットであり<ref name="NIST_SP_800-57">{{cite web|url=http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf|title=NIST Special Publication 800-57 ''Recommendation for Key Management &mdash; Part 1: General (Revised)''|format=PDF|date=2007-03-08|accessdate=2014-07-03}}</ref>、2013年時点で最低限必要とされる128ビットに不足している<ref>{{cite web|url=https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf|title=SSL/TLS Deployment Best Practices|format=PDF|author=Qualys SSL Labs|accessdate=19 November 2013}}</ref>}}

| {{no|安全ではない}} || {{no|安全ではない}} || {{partial|強度不足、実装による}} || {{partial|強度不足}} || {{partial|強度不足}} || {{n/a}}

|-

! {{仮リンク|GOST 28147-89|en|GOST (block cipher)}} [[暗号利用モード#CTR|CNT]]<ref name="GOST"/>

| 256

| {{N/a}} || {{N/a}} || {{yes|安全}} || {{yes|安全}} || {{yes|安全}} || {{n/a}} || RFC草稿で提案中

|-

! [[International Data Encryption Algorithm|IDEA]] [[暗号利用モード#CBC|CBC]]<ref group="注" name="Lucky13"/><ref group="注" name="removal by TLS1.2">IDEA、DESはTLS 1.2で廃止された</ref>

| 128

| {{no|安全ではない}} || {{no|安全ではない}} || {{partial|実装による}} || {{yes|安全}} || {{n/a}} || {{n/a}} || rowspan="2" | TLS 1.2で廃止

|-

! rowspan="2" | [[Data Encryption Standard|DES]] [[暗号利用モード#CBC|CBC]]<ref group="注" name="Lucky13"/><ref group="注" name="removal by TLS1.2"/>

| {{0}}56

| {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{n/a}} || {{n/a}}

|-

| {{0}}40<ref group="注" name="EXPORT">40ビットのセキュリティ強度を持つCipher Suiteは、[[アメリカ合衆国]]による[[アメリカ合衆国からの暗号の輸出規制|高強度暗号アルゴリズムの輸出規制]]を回避するために設計された。これらはTLS 1.1以降では利用が禁止されている。</ref>

| {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{n/a}} || {{n/a}} || {{n/a}} || rowspan="2" | TLS 1.1以降で利用禁止

|-

! [[RC2]] [[暗号利用モード#CBC|CBC]]<ref group="注" name="Lucky13"/>

| {{0}}40<ref group="注" name="EXPORT"/>

| {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{n/a}} || {{n/a}} || {{n/a}}

|-

! rowspan="3" | [[ストリーム暗号]]

! [[ChaCha20]]+[[Poly1305]]<ref name="ChaCha20">{{IETF RFC|7905}}</ref><ref group="注" name="AEAD"/>

| 256

| {{n/a}} || {{n/a}} || {{n/a}} || {{n/a}} || {{yes|安全}} || {{yes|安全}} || TLS 1.2向けにRFCで定義済み

|-

! rowspan="2" | [[RC4]]<ref group="注" name="RC4">{{IETF RFC|7465}} により、すべてのバージョンのTLSにおいてRC4の利用は禁止された（[[#RC4|RC4攻撃]]）</ref>

| 128

| {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{n/a}} || rowspan="2" | 全バージョンにおいて利用禁止

|-

| {{0}}40<ref group="注" name="EXPORT"/>

| {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{n/a}} || {{n/a}} || {{n/a}}

|-

! 暗号化なし

! Null<ref group="注">認証のみで暗号化は行われない。</ref>

| -

| {{n/a}} || {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{n/a}} || TLS 1.2向けにRFCで定義済み

|}

{{Reflist|group="注"}}


[[Advanced Encryption Standard|AES]] CBCはTLS 1.0を定義する {{IETF RFC|2246}} には含まれていないが、{{IETF RFC|3268}} で追加された。TLS 1.1を定義する {{IETF RFC|4346}} からは {{IETF RFC|3268}} が参照されており、さらにTLS 1.2では定義である {{IETF RFC|5246}} にAES CBCに関する記述が取り込まれた。また、[[認証付き暗号]]による[[Advanced Encryption Standard|AES]] [[Galois/Counter Mode|GCM]] ({{IETF RFC|5288}}, {{IETF RFC|5289}})、[[Advanced Encryption Standard|AES]] [[Counter with CBC-MAC|CCM]] ({{IETF RFC|6655}}, {{IETF RFC|7251}}) が追加されている。[[International Data Encryption Algorithm|IDEA]] CBC、[[Data Encryption Standard|DES]] CBCはTLS 1.2で廃止された︵{{IETF RFC|5469}} に解説がある︶。

[[ブロック暗号]]の[[暗号利用モード#CBC|CBCモード]]での利用については、TLS 1.0以前において[[#BEAST攻撃|BEAST攻撃]]と呼ばれる攻撃が可能であることが明らかとなっており、クライアント側、サーバ側での対応が必要とされている。TLS 1.1以降ではこの攻撃への根本的な対処として[[初期化ベクトル]]を明示的に指定し、パディングの処理が改善された。ブロック暗号であっても[[Galois/Counter Mode|GCM]]、[[Counter with CBC-MAC|CCM]]などの[[認証付き暗号]]を用いる場合にはこれらの攻撃を受けない。

[[ストリーム暗号]]である[[RC4]]は前述のBEAST攻撃を受けることはないが、RC4には仕様上の脆弱性が存在する（[[#RC4|RC4攻撃]]）。2015年2月、TLSのすべてのバージョンにおいてRC4の利用を禁止する {{IETF RFC|7465}} が公開された。ストリーム暗号である[[ChaCha20]]と認証のための[[Poly1305]]を組み合わせたChaCha20+Poly1305が {{IETF RFC|7905}} として標準化されている。


いくつかの国家標準に基づく暗号化アルゴリズムもTLSで利用可能であり、[[日本]]の[[CRYPTREC]]による推奨暗号である[[Camellia]]︵CBCモード‥{{IETF RFC|4132}}、{{IETF RFC|5932}}、{{IETF RFC|6367}}、GCM‥{{IETF RFC|6367}}︶、[[大韓民国|韓国]]の情報通信標準規格に採用されている[[SEED (暗号)|SEED]]︵CBCモード‥{{IETF RFC|4162}}︶、[[ARIA (暗号)|ARIA]]︵CBCモードおよびGCM‥{{IETF RFC|6209}}︶が追加されている。また、[[独立国家共同体]]の[[GOST規格]]によって規定された暗号化アルゴリズムであるGOST 28147-89も提案されている<ref name="GOST"/>。


SSLが設計された当時は、[[アメリカ合衆国]]によって[[アメリカ合衆国からの暗号の輸出規制|高強度暗号アルゴリズムの輸出が規制されていた]]。そのため、全世界で共通して利用できるアルゴリズムとして、DES・[[RC2]]・RC4に関して暗号強度を40ビットに制限したものが導入されていた。これらはTLS 1.1以降では利用が禁止されている。

また、鍵共有のみを行い暗号化は行わないこと (NULL) も可能であるが、平文でのやりとりとなることから安全とはみなされていない。

==== MAC ====

TLS/SSLの各バージョンで使用できるMACの選択肢は以下のとおりである。下欄の「AEAD」（Authenticated Encryption with Associated Data、認証暗号）は、共通鍵暗号として認証暗号を選んでいるのでMACを用いない事を意味する。

{| class="wikitable" style="text-align:center"

|+ TLS/SSLの各バージョンで使用できる改竄検出

! アルゴリズム !! SSL 2.0 !! SSL 3.0 !! TLS 1.0 !! TLS 1.1 !! TLS 1.2 !! {{nowrap|TLS 1.3}}!! 状況

|-

! [[HMAC]]-[[MD5]]

| {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{No|非対応}} || rowspan="4" | TLS 1.2向けにRFCで定義済み

|-

! [[HMAC]]-[[SHA-1|SHA1]]

| {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{No|非対応}}

|-

! [[HMAC]]-[[SHA-2|SHA256/384]]

| {{No|非対応}} || {{No|非対応}} || {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{No|非対応}}

|-

! [[認証付き暗号|AEAD]]

| {{No|非対応}} || {{No|非対応}} || {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}}

|-

! {{仮リンク|GOST 28147-89|en|GOST (block cipher)|label=GOST 28147-89 IMIT}}<ref name="GOST"/>

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{No|非対応}} || rowspan="2" | RFC草稿で提案中

|-

! {{仮リンク|GOST R 34.11-94|en|GOST (hash function)}}<ref name="GOST"/>

| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{No|非対応}}

|}

[[独立国家共同体]]の[[GOST規格]]によって規定されたアルゴリズムであるGOST 28147-89に基づくMACおよび、GOST R 34.11も提案されている（同じGOST規格による鍵共有・暗号化アリゴリズムとの組み合わせに限定）<ref name="GOST"/>。

== 実装 ==

=== ウェブサイト ===

{|class="wikitable" style="text-align: center;"

|+ウェブサイトにおけるTLS/SSLの対応状況

|-

!プロトコル

!ウェブサイトにおけるサポート<ref name="trustworthy_ssl_pulse">2023年11月3日現在 {{cite web|url=https://www.ssllabs.com/ssl-pulse/|title=SSL Pulse: Survey of the SSL Implementation of the Most Popular Web Sites|accessdate=2023-12-09}}</ref>

!セキュリティ<ref name="trustworthy_ssl_pulse"/><ref name="community.qualys">{{cite web|url=https://blog.qualys.com/ssllabs/2013/03/19/rc4-in-tls-is-broken-now-what|accessdate=2018-09-10|publisher=Qualsys SSL Labs|author=ivanr|title=RC4 in TLS is Broken: Now What?}}</ref>

|-

!SSL 2.0

|0.2%

|{{No|安全ではない}}

|-

!SSL 3.0

|1.7%

|{{No|安全ではない}}<ref name="poodle_pdf" />

|-

!TLS 1.0

|29.5%

|{{Partial|暗号アルゴリズム<ref group="注" name="ciphers">[[#暗号スイート]]を参照のこと</ref>および脆弱性への対処<ref group="注" name="mitigations">[[#ウェブブラウザ]]および[[#TLS/SSLの既知の脆弱性]]を参照のこと</ref>による}}

|-

!TLS 1.1

|31.8%

|{{Partial|暗号アルゴリズム<ref group="注" name="ciphers"/>および脆弱性への対処<ref group="注" name="mitigations"/>による}}

|-

!TLS 1.2

|99.9%

|{{Partial|暗号アルゴリズム<ref group="注" name="ciphers"/>および脆弱性への対処<ref group="注" name="mitigations"/>による}}

|-

!TLS 1.3

|66.2%

|{{Yes|安全}}

|}

; 注

{{Reflist|group="注"}}

=== ウェブブラウザ ===

2021年1月現在、主要なウェブブラウザの最新版ではTLS 1.2、1.3が既定で有効であるが、過去のバージョンのOS向けなどサポートが継続しているウェブブラウザのいくつかのバージョンではそうではない。

* TLS 1.3に対応しているが既定で無効：Internet Explorer 11（Windows 10 バージョン1903以降）

* TLS 1.3に未対応：Internet Explorer 11（Windows 10 バージョン1903より前）

TLS 1.0、1.1は脆弱性が危惧され<ref>{{Cite web|和書|url=https://forest.watch.impress.co.jp/docs/news/1148035.html |title=「Microsoft Edge」と「Internet Explorer 11」でTLS 1.0/1.1がデフォルト無効化へ |date=2018-10-16 |accessdate=2021-01-01}}{{Cite web|和書|url=https://forest.watch.impress.co.jp/docs/news/1148101.html |title=「Google Chrome」「Firefox」「Safari」もTLS 1.0/1.1のサポートを廃止へ |date=2018-10-16 |accessdate=2021-01-01}}</ref>、2020年から無効化が実施され始めている<ref>{{Cite web|和書|url=https://www.cybertrust.co.jp/blog/ssl/regulations/tls-july-update.html |title=主要ブラウザーの TLS 1.0/1.1 無効化について（続報） |date=2020-07-28 |accessdate=2021-01-01}}</ref>。

既知の脆弱性のいくつかへの対応は十分ではない。

* [[#POODLE攻撃|POODLE攻撃]]への対応：いくつかのブラウザではTLS_FALLBACK_SCSVを実装済みでSSL 3.0へのフォールバックを抑止することが可能となっているが、これはクライアント側だけでなくサーバ側での対応も必要である。SSL 3.0そのものの無効化、"anti-POODLE record splitting"の実装、あるいはSSL 3.0におけるCBCモードのcipher suiteの無効化が根本的な対策となる。

** Google Chrome：完了（バージョン33においてTLS_FALLBACK_SCSVを実装、バージョン39においてSSL 3.0へのフォールバックを無効化、バージョン40においてSSL 3.0を既定で無効化。バージョン44においてSSL 3.0のサポートを廃止）

** Mozilla Firefox：完了（バージョン34においてSSL 3.0を既定で無効化およびSSL 3.0へのフォールバックを無効化、バージョン35においてTLS_FALLBACK_SCSVを実装。延長サポート版でもESR 31.3においてSSL 3.0を無効化およびTLS_FALLBACK_SCSVを実装。バージョン39においてSSL 3.0のサポートを廃止）

** Internet Explorer：部分的（バージョン11のみ、2015年2月のアップデートにおいて保護モードにおけるSSL 3.0へのフォールバックを既定で無効化。2015年4月にSSL 3.0自体を既定で無効化。バージョン10以前では対策は講じられていない）

** Opera：完了（バージョン20においてTLS_FALLBACK_SCSVを実装、バージョン25において"anti-POODLE record splitting"を実装、バージョン27においてSSL 3.0を既定で無効化。バージョン31においてSSL 3.0のサポートを廃止）

** Safari‥完了︵[[OS X Mountain Lion|OS X v10.8]]以降およびiOS 8.1以降のみ、POODLEへの対策としてSSL 3.0においてCBCモードのcipher suiteを無効化した。これによりPOODLEの影響を受けることはなくなるが、SSL 3.0においてCBCモードを無効化したことで、脆弱性が指摘されているRC4しか利用できなくなるという問題が生じている。[[OS X El Capitan|OS X v10.11]]およびiOS 9においてSSL 3.0のサポートを廃止︶

* [[#RC4|RC4攻撃]]への対応

** Google Chromeでは、バージョン43以降はホストがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限りRC4を用いたCipher Suiteがフォールバックとして利用されるようになった。バージョン48以降では、RC4を用いたCipher Suiteのすべてが既定で無効化された。

** Firefoxでは、バージョン36以降はホストがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限りRC4を用いたCipher Suiteがフォールバックとして利用されるようになった。バージョン44以降では、RC4を用いたCipher Suiteのすべてが既定で無効化された。

** Operaでは、バージョン30以降はホストがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限りRC4を用いたCipher Suiteがフォールバックとして利用されるようになった。バージョン35以降では、RC4を用いたCipher Suiteのすべてが既定で無効化された。

** Windows 7 / Server 2008 R2およびWindows 8 / Server 2012向けのInternet Explorerでは、RC4の優先度を最低としている。Windows 8.1 / Server 2012 R2向けのInternet Explorer 11およびWindows Phone 8.1向けのInternet Explorer Mobile 11およびWindows 10向けのEdgeでは、ホストが他のアルゴリズムに非対応の場合のフォールバックを除きRC4を無効としている（Windows 7 / Server 2008 R2およびWindows 8 / Server 2012向けのInternet Explorerでもレジストリからフォールバックを除きRC4を無効化することが可能）。2016年8月の月例アップデートにおいて、Inter Explorer 11およびEdgeにおいてRC4を用いたCipher Suiteのすべてが既定で無効化。

<!--**Safariでは、iOS 9.3においてRC4を用いたCipher Suiteのサポートが廃止された。-->

* [[#FREAK|FREAK攻撃]]への対応:

** [[Android (オペレーティングシステム)|Android]] 4以前の[[Androidブラウザ|標準ブラウザ]]はFREAK攻撃に対して脆弱である。

** Internet Explorer 11 MobileはFREAK攻撃に対して脆弱である。

** Google Chrome（Windows版を除く）、Internet Explorer、Safari（デスクトップ版、iOS版）、Opera（Windows版を除く）はFREAK攻撃に対して対応済みである。

** Mozilla Firefox、Google Chrome（Windows版）、Opera（Windows版）はFREAK攻撃の影響を受けない。

<div style="height:auto; overflow: auto; text-align: left">

{{clear}}

{{ウェブブラウザにおけるTLS/SSLの対応状況の変化}}

</div>

=== ライブラリ ===

{{main|en:Comparison of TLS implementations}}

TLS/SSLライブラリの多くは[[オープンソースソフトウェア]]である。

{| class="wikitable" style="text-align: center; font-size: smaller;"

|+ ライブラリにおけるTLS/SSLの対応状況

|-

! 実装

! SSL 2.0（安全ではない）

! SSL 3.0（安全ではない）

! TLS 1.0

! TLS 1.1

! TLS 1.2

! TLS 1.3

|-

! [[Botan]]

| {{Yes|非対応}}

| {{Yes|非対応}}<ref name="Botan 1.11.13">{{cite web|url=http://botan.randombit.net/relnotes/1_11_13.html|title=Version 1.11.13, 2015-01-11 — Botan|date=2015-01-11|accessdate=2015-01-17}}</ref>

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

|

|-

! {{仮リンク|cryptlib|en|cryptlib}}

| {{Yes|非対応}}

| {{No|既定で有効}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

|

|-

! [[GnuTLS]]

| {{Yes|非対応}}<ref group="注" name="a">後方互換性の確保のため、SSL 2.0に非対応あるいは既定で無効の場合にもSSL 2.0 client helloはサポートされる。</ref>

| {{Yes|既定で無効}}<ref name=GnuTLS-3.4.0>{{cite web|url=http://lists.gnutls.org/pipermail/gnutls-devel/2015-April/007535.html|title=[gnutls-devel] GnuTLS 3.4.0 released|date=2015-04-08|accessdate=2015-04-16}}</ref>

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{Partial|対応<small>(ドラフト版)</small>}}<ref>{{Cite web|title=Add TLS v1.3 as an option by SparkiDev · Pull Request #661 · wolfSSL/wolfssl|url=https://github.com/wolfSSL/wolfssl/pull/661|website=GitHub|accessdate=2020-03-30|language=en}}</ref>

|-

! {{仮リンク|Java Secure Socket Extension|en|Java Secure Socket Extension}}

| {{Yes|非対応}}<ref group="注" name="a" />

| {{Yes|既定で無効}}<ref>{{cite web|url=http://www.oracle.com/technetwork/java/javase/8u31-relnotes-2389094.html|title=Java™ SE Development Kit 8, Update 31 Release Notes|accessdate=2015-01-22}}</ref>

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

|-

! [[LibreSSL]]

| {{Yes|非対応}}<ref name="OpenBSD5.6">{{cite web|url=https://marc.info/?l=openbsd-announce&m=141486254309079&w=2|title=OpenBSD 5.6 Released|date=2014-11-01|accessdate=2015-01-20}}</ref>

| {{Yes|既定で無効}}<ref name=libressl-2.3>{{cite web| title = LibreSSL 2.3.0 Released| url = https://marc.info/?l=openbsd-announce&m=144304330731220| date = 2015-09-23| accessdate = 2015-09-24}}</ref>

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

|

|-

! {{仮リンク|MatrixSSL|en|MatrixSSL}}

| {{Yes|非対応}}

| {{Yes|コンパイル時点で既定で無効}}<ref name="Matrix-POODLE">{{cite web|url=http://www.matrixssl.org/news.html|title=MatrixSSL - News|accessdate=2014-11-09}}</ref>

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{Partial|対応<small>(ドラフト版)</small>}}

|-

! {{仮リンク|mbed TLS|en|mbed TLS}}

| {{Yes|非対応}}

| {{Yes|既定で無効}}<ref name=mbed-2.0>{{cite web | title = mbed TLS 2.0.0 released | url = https://tls.mbed.org/tech-updates/releases/mbedtls-2.0.0-released | date = 2015-07-10 | accessdate = 2015-07-14}}</ref>

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

|

|-

! [[Network Security Services]]

| {{Yes|既定で無効}}{{refn|group="注"|name="b"|サーバ側でのSSL 2.0 client helloの受け取りのみサポートされる<ref name=NSS-3.24>{{cite web|url=https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.24_release_notes|work=Mozilla Developer Network|title=NSS 3.24 release notes|publisher=Mozilla|accessdate=2016-06-19}}</ref>}}

| {{Yes|既定で無効}}<ref name=NSS-3.19>{{cite web|url=https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.19_release_notes|work=Mozilla Developer Network|title=NSS 3.19 release notes|publisher=Mozilla|accessdate=2015-05-06}}</ref>

| {{Yes|対応}}

| {{Yes|対応}}<ref name="NSS-3.14">{{cite web|url=https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14_release_notes|work=Mozilla Developer Network|title=NSS 3.14 release notes|publisher=Mozilla|accessdate=2014-07-02}}</ref>

| {{Yes|対応}}<ref name="NSS-3.15.1">{{cite web|url=https://developer.mozilla.org/en-US/docs/NSS/NSS_3.15.1_release_notes|work=Mozilla Developer Network|title=NSS 3.15.1 release notes|publisher=Mozilla|accessdate=2014-07-02}}</ref>

| {{Yes|対応}}<ref>{{Cite web|url=https://lists.gnupg.org/pipermail/gnutls-devel/2018-July/008584.html|title=[gnutls-devel] gnutls 3.6.3|date=Mon Jul 16 08:51:21 CEST 2018|accessdate=2020-03-30|first=Nikos|last=Mavrogiannopoulos}}</ref>

|-

! [[OpenSSL]]

| {{Yes|既定で無効}}<ref>{{cite web|url=https://www.openssl.org/news/changelog.html#x29|title=Changes between 0.9.8n and 1.0.0 [29 Mar 2010]|accessdate=2016-02-11}}</ref>

| {{No|既定で有効}}

| {{Yes|対応}}

| {{Yes|対応}}<ref name="openssl-1.0.1-note">{{cite web|title = Major changes between OpenSSL 1.0.0h and OpenSSL 1.0.1 [14 Mar 2012]|url = https://www.openssl.org/news/openssl-1.0.1-notes.html|date = 2012-03-14| accessdate = 2015-01-20}}</ref>

| {{Yes|対応}}<ref name="openssl-1.0.1-note" />

| {{Yes|対応}}<ref>{{Cite web|title=NSS 3.39 release notes|url=https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.39_release_notes|website=MDN Web Docs|accessdate=2020-03-30|language=en}}</ref>

|-

! {{仮リンク|RSA BSAFE|en|RSA BSAFE}}<ref name="RSABSAFETECH">{{cite web|title = RSA BSAFE Technical Specification Comparison Tables|url = http://www.emc.com/collateral/data-sheet/11433-bsafe-tech-table.pdf|format=PDF|accessdate=2015-01-22}}</ref>

| {{Yes|非対応}}

| {{No|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{Partial|未対応}}

|-

! [[SChannel|SChannel XP/2003]]<ref name="XP2003schannel">[http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx TLS cipher suites in Microsoft Windows XP and 2003]</ref>

| {{partial|IE 7から既定で無効}}

| {{No|既定で有効}}

| {{partial|IE 7から既定で有効}}

| {{No|非対応}}

| {{No|非対応}}

| {{No|非対応}}

|-

! [[SChannel|SChannel Vista/2008]]<ref name="Vista2008schannel">[http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651%28v=vs.85%29.aspx SChannel Cipher Suites in Microsoft Windows Vista]</ref>

| {{Yes|既定で無効}}

| {{No|既定で有効}}

| {{Yes|対応}}

| {{No|非対応}}

| {{No|非対応}}

| {{No|非対応}}

|-

! [[SChannel|SChannel 7/2008R2]]<ref name="Windows7schannel">[http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx TLS Cipher Suites in SChannel for Windows 7, 2008R2, 8, 2012]</ref>

| {{Yes|既定で無効}}

| {{partial|IE 11から既定で無効}}

| {{Yes|対応}}

| {{partial|IE 11から既定で有効}}

| {{partial|IE 11から既定で有効}}

| {{No|非対応}}

|-

! [[SChannel|SChannel 8/1012]]<ref name="Windows7schannel"/>

| {{Yes|既定で無効}}

| {{No|既定で有効}}

| {{Yes|対応}}

| {{partial|既定で無効}}

| {{partial|既定で無効}}

| {{No|非対応}}

|-

! [[SChannel|SChannel 8.1/2012R2, 10 v1507/v1511]]<ref name="Windows7schannel"/>

| {{Yes|既定で無効}}

| {{partial|IE 11から既定で無効}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{No|非対応}}

|-

! [[SChannel|SChannel 10 v1607/2016]]<ref name="Windows10schannel">{{cite web|title = Protocols in TLS/SSL (Schannel SSP) |url = https://msdn.microsoft.com/en-us/library/windows/desktop/mt808159.aspx |accessdate=2017-06-08 }}</ref>

| {{Yes|非対応}}

| {{Yes|既定で無効}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{No|非対応}}

|-

! Secure Transport OS X v10.2-10.8 / iOS 1-4

| {{No|対応}}

| {{No|対応}}

| {{Yes|対応}}

| {{No|非対応}}

| {{No|非対応}}

|

|-

! Secure Transport OS X v10.9-10.10 / iOS 5-8

| {{yes|非対応}}{{refn|group="注"|name="c"|[[OS X Mavericks|OS X v10.9]]以降でSSL 2.0非対応。OS X v10.11以降およびiOS 9以降でSSL 3.0非対応。OS X v10.9およびiOS 5以降以降でTLS 1.1、1.2に対応<ref>{{cite web|url=http://developer.apple.com/library/ios/technotes/tn2287/|work=iOS Developer Library|title=Technical Note TN2287: iOS 5 and TLS 1.2 Interoperability Issues|publisher=Apple Inc.|accessdate=2014-07-02}}</ref><ref>[https://dev.ssllabs.com/ssltest/clients.html]</ref>}}

| {{No|対応}}

| {{Yes|対応}}

| {{Yes|対応}}<ref group="注" name="c" />

| {{Yes|対応}}<ref group="注" name="c" />

|

|-

! Secure Transport OS X v10.11 / iOS 9

| {{yes|非対応}}

| {{Yes|非対応}}<ref group="注" name="c" />

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

|

|-

! SharkSSL

| {{Yes|非対応}}

| {{Yes|既定で無効}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

|

|-

! [[wolfSSL]]

| {{Yes|非対応}}

| {{Yes|既定で無効}}<ref name=wolfSSL-3.6.6>{{cite web|url=http://wolfssl.com/wolfSSL/Blog/Entries/2015/8/24_wolfSSL_3.6.6_is_Now_Available.html|title=<nowiki>[wolfssl] wolfSSL 3.6.6 Released</nowiki>|date=2015-08-20|accessdate=2015-08-25}}</ref>

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}

| {{Yes|対応}}<ref name="wolfSSL TLS 1.3 support">{{cite web|url=https://www.wolfssl.com/docs/tls13|title=TLS 1.3 Protocol Support|access-date=2022-09-06}}</ref>

|-

|-class="sortbottom"

! 実装

! SSL 2.0（安全ではない）

! SSL 3.0（安全ではない）

! TLS 1.0

! TLS 1.1

! TLS 1.2

! TLS 1.3

|}

; 注

{{Reflist|group="注"}}

== 課題 ==

=== バーチャルホスト ===

TLSは、TCP/IPネットワークでホスト名ベースの[[バーチャルホスト]]を構成する際に問題となる。TCP/IPでは通信を開始する前にホスト名を[[名前解決|解決]]し、実際には[[IPアドレス]]とポート番号で接続先を識別している。このためTLSのネゴシエーションの時点では、バーチャルホストのうちどのホスト名を期待しているのか判断できず、ホスト名ごとに異なるサーバー証明書を使い分けることができない。

TLSの拡張機能を定義する{{IETF RFC|6066}}では、ネゴシエーション時にホスト名を伝える手段として[[Server Name Indication]] (SNI) を規定している。用例としては、[[HTTP]]の最新バージョンである[[HTTP/2]]においてTLSを利用する際はSNIの利用が必須とされている。

一方、証明書を使い分けず、1つの証明書を複数のバーチャルホストで使い回す方式も広く利用されている。[[X.509]]証明書のフォーマットについて記述した[[RFC5280]]では、発行先ホスト名を保持するsubjectAltNameはひとつの証明書に複数のエントリを作成できると規定している。これを利用して、ホストに収容されたすべてのバーチャルホストに対応したsubjectAltNameを保持する証明書をクライアントに提示すれば良い。

また、発行先ホスト名に[[ワイルドカード (情報処理)|ワイルドカード]]を使う方法も考えられる。HTTP over SSL/TLS (HTTPS) を定義する{{IETF RFC|2818}}は、ワイルドカードの適用について記述している。バーチャルホストの対象が、ひとつのドメイン名の中のホストであれば、この方法で対応できる場合もある。

どの方法も実装によって対応状況にバラつきがあり、環境によっては使えない可能性がある。なおIPアドレスベースのバーチャルホストであれば、ネゴシエーションの時点で確実にどのバーチャルホストを期待しているか判断できるので、問題なく証明書を使い分けることができる。

== TLS/SSLの既知の脆弱性 ==

TLS/SSLに対する攻撃のうち主なものを以下に挙げる。2015年2月に、TLS/SSLに対する既知の攻撃についての情報をまとめた{{IETF RFC|7457}}がIETFから公開されている。

=== 暗号の危殆化を利用したもの ===

TLS 1.2ではすでに危殆化したRC4、MD5、SHA1が選択可能であり、この事が脆弱性の原因となっている。

MD5はすでに衝突が容易に見つかるレベルまで危殆化しているため、これを利用した'''SLOTH攻撃''' (CVE-2015-7575) が知られている。

SHA1もFreestart Collision<ref>[https://eprint.iacr.org/2015/967 Freestart collision for full SHA-1] ''Marc Stevens and Pierre Karpman and Thomas Peyrin EUROCRYPT 2016''</ref>が見つかっており安全ではない。

==== RC4 ====

RC4もTLSのすべてのバージョンにおいて利用を禁止する{{IETF RFC|7465}}が公開された。[[Mozilla]]および[[マイクロソフト]]ではRC4を無効化することを推奨している<ref>{{cite web|url=https://wiki.mozilla.org/Security/Server_Side_TLS|title=Mozilla Security Server Side TLS Recommended Configurations|accessdate=2015-01-03|publisher=Mozilla}}</ref><ref>{{cite web|url=http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx|title=Security Advisory 2868725: Recommendation to disable RC4|accessdate=2013-12-13|date=2013-11-12|publisher=マイクロソフト}}</ref><ref>{{Cite web|和書|url=http://technet.microsoft.com/ja-jp/security/advisory/2868725|title=マイクロソフト セキュリティ アドバイザリ (2868725)　RC4 を無効化するための更新プログラム|accessdate=2013-12-13|date=2013-11-13|publisher=マイクロソフト}}</ref><ref>[//tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 draft-popov-tls-prohibiting-rc4-02]</ref>。


[[RC4]]そのものに対する攻撃法は多く報告されているが、TLS/SSLにおいてRC4を用いたCipher Suiteについては、その脆弱性に対処されており安全であると考えられていた。2011年には、ブロック暗号のCBCモードの取り扱いに関する脆弱性であったBEAST攻撃への対応策の一つとして、ストリーム暗号であるためその影響を受けないRC4に切り替えることが推奨されていた<ref>[http://serverfault.com/questions/315042/ security – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune – Server Fault<!-- Bot generated title -->]</ref>。しかし、2013年にTLS/SSLでのRC4への効果的な攻撃が報告され、BEASTへの対応としてRC4を用いることは好ましくないとされた<ref name="community.qualys2">{{cite web|url=https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what|title=RC4 in TLS is Broken: Now What?|accessdate=2013-07-30|author=ivanr|publisher=Qualsys Security Labs}}</ref>。RC4に対する攻撃は、AlFardan、Bernstein、Paterson、Poettering、Schuldtによって報告された。新たに発見されたRC4の鍵テーブルにおける統計的な偏り<ref>{{cite journal|author=Pouyan Sepehrdad, Serge Vaudenay, Martin Vuagnoux|year=2011|title=Discovery and Exploitation of New Biases in RC4|url=http://link.springer.com/chapter/10.1007%2F978-3-642-19574-7_5|journal=Lecture Notes in Computer Science|volume=6544|pages=74–91|doi=10.1007/978-3-642-19574-7_5}}</ref>を利用し、平文の一部を回復可能であるというものである<ref>{{cite web|url=http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html|title=Attack of the week: RC4 is kind of broken in TLS|accessdate=2014-06-24|author=Green, Matthew|work=Cryptography Engineering}}</ref><ref>{{cite web|url=http://www.isg.rhul.ac.uk/tls/|title=On the Security of RC4 in TLS|accessdate=2014-06-24|author=Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt|publisher=Royal Holloway University of London}}</ref>。この攻撃では、13 × 2<sup>20</sup>の暗号文を用いることで128ビットのRC4が解読可能であることが示され、2013年の[[USENIX]]セキュリティシンポジウムにおいて﹁実現可能﹂と評された<ref>{{cite journal|last=AlFardan|first=Nadhem J.|date=8 July 2013|title=On the Security of RC4 in TLS and WPA|url=http://www.isg.rhul.ac.uk/tls/RC4biases.pdf|accessdate=2014-06-24|format=PDF|first2=Daniel J.|last2=Bernstein|first3=Kenneth G.|last3=Paterson|first4=Bertram|last4=Poettering|first5=Jacob C. N.|last5=Schuldt}}</ref><ref>{{cite conference|last=AlFardan|last2=Bernstein|last3=Paterson|last4=Poettering|last5=Schuldt|first=Nadhem J.|first2=Daniel J.|first3=Kenneth G.|first4=Bertram|first5=Jacob C. N.|date=15 August 2013|url=https://www.usenix.org/sites/default/files/conference/protected-files/alfardan_sec13_slides.pdf|page=51|title=On the Security of RC4 in TLS|conference=22nd [[USENIX]] Security Symposium|format=PDF|accessdate=2014-06-24|quote=Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical}}</ref>。2013年現在では、[[アメリカ国家安全保障局|NSA]]のような機関であればTLS/SSLを利用したとしてもRC4を解読可能であるとの疑惑がある<ref name="Leyden20130906">{{cite web|url=http://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_bullrun_analysis/|title=That earth-shattering NSA crypto-cracking: Have spooks smashed RC4?|accessdate=2013-12-13|author=John Leyden|date=2013-09-06|publisher=The Register}}</ref>。

2015年現在ではクライアントのほとんどは既にBEASTへの対処が完了していることから、RC4はもはや最良の選択肢ではなくなっており、TLS 1.0以前においてもCBCモードを用いることがより良い選択肢となっている<ref>{{cite web|url=https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf|title=SSL/TLS Deployment Best Practices|accessdate=2014-06-24|author=Qualys SSL Labs|format=PDF}}</ref>。

=== ダウングレード攻撃 ===

==== {{Anchors|FREAK|Logjam|ダウングレード攻撃}}FREAK および Logjam ====

{{main|FREAK}}

かつて[[アメリカ合衆国からの暗号の輸出規制]]が厳しかった時期に、規制を回避するために一時的に512ビットのRSA鍵を生成して、そちらで通信を行うというような手法が存在した<ref>{{Cite book ja-jp|author=Eric Rescorla|translator=齋藤孝道、古森貞、鬼頭利之|year=2003|title=マスタリングTCP/IP SSL/TLS編|publisher=オーム社|isbn=978-4274065422|ref=master|page=128}}</ref>。この手法については、一時的な公開鍵を[[素因数分解]]することが可能であれば[[中間者攻撃]]が成立することが1998年時点で指摘されていたが<ref>前掲「マスタリングTCP/IP SSL/TLS編」、p. 191。</ref>、コンピュータの性能向上、[[クラウドコンピューティング]]の普及により素因数分解が個人レベルですら現実的となったこと、さらに[[2015年]]には、[[OpenSSL]]、[[Safari]]、[[Android (オペレーティングシステム)|Android]]などでは'''輸出用でない'''暗号スイートでも512ビットの一時鍵を受け入れてしまう実装となっていたことが判明し、'''FREAK''' (Factoring RSA Export Keys)<ref>[http://www.security-next.com/056462 暗号化通信に脆弱性「FREAK」が判明 - 盗聴や改ざんのおそれ] Security NEXT、2015年3月5日閲覧。</ref>として問題が再浮上している。

対策としては、すでに脆弱となっている輸出対応暗号の無効化、クライアント側では規格書通り、輸出暗号以外で一時的RSA鍵を使わないようにする<ref>[https://github.com/openssl/openssl/commit/ce325c60c74b0fa784f5872404b722e120e5cab0 Only allow ephemeral RSA keys in export ciphersuites.] OpenSSLのGithubツリー、2014年10月24日（2015年3月5日閲覧）</ref>、ということが挙げられる。

2015年5月、'''Logjam'''と呼ばれる脆弱性が発見された。これも、FREAKと同様に輸出用の512ビットの一時鍵を受け入れてしまうものである<ref>{{cite web|url=http://arstechnica.com/security/2015/05/https-crippling-attack-threatens-tens-of-thousands-of-web-and-mail-servers/|title=HTTPS-crippling attack threatens tens of thousands of Web and mail servers|accessdate=2015-05-22|author=Dan Goodin|date=2015-05-20|publisher=Ars Technica}}</ref>。FREAKとは異なり、LogjamはTLSプロトコル自体の脆弱性である。発見時点において、主要なブラウザのすべてがLogjamに対して脆弱である。

==== バージョンロールバック攻撃 ====

'''False Start'''<ref>{{cite web|url=//tools.ietf.org/html/draft-bmoeller-tls-falsestart-00|title=Transport Layer Security (TLS) False Start|accessdate=2014-06-24|author=A. Langley|coauthors=N. Modadugu, B. Moeller|year=2012|month=6|work=Internet Engineering Task Force|publisher=IETF}}</ref>（[[Google Chrome]]で有効化された<ref>{{cite web|url=http://www.conceivablytech.com/3299/products/false-start-google-proposes-faster-web-chrome-supports-it-already|title=False Start: Google Proposes Faster Web, Chrome Supports It Already|accessdate=2014-06-24|archiveurl=https://web.archive.org/web/20101007061707/http://www.conceivablytech.com/3299/products/false-start-google-proposes-faster-web-chrome-supports-it-already/|archivedate=2010-10-07|last=Wolfgang|first=Gruener}}</ref>）やSnap StartといったTLS/SSLを高速化する変法は、攻撃者が一定条件下において本来利用可能なTLS/SSLのバージョンよりも低いバージョンでTLS/SSL接続を行うよう仕向けること<ref>{{cite web|url=http://www.ietf.org/mail-archive/web/tls/current/msg06933.html|title=Limited rollback attacks in False Start and Snap Start|accessdate=2014-06-24|last=Brian|first=Smith}}</ref>や、クライアントからサーバへ送られる利用可能なCipher Suiteの一覧を改竄し、より低い暗号強度やより弱い暗号化アルゴリズム・鍵交換アルゴリズムを使用するよう仕向けること<ref>{{cite web|url=http://www.carbonwind.net/blog/post/Random-SSLTLS-101-False-Start.aspx|title=False Start|accessdate=2014-06-24|work=Random SSL/TLS 101|last=Adrian|first=Dimcev}}</ref>が可能であると報告されている。さらに、特定の環境においては、攻撃者がオフラインで暗号化に用いられた鍵を回復し、暗号化されたデータにアクセスすることも可能であることが[[Association for Computing Machinery]] (ACM) のコンピュータセキュリティカンファレンスで報告された<ref>{{cite book|author=Mavrogiannopoulos, Nikos and Vercautern, Frederik and Velchkov, Vesselin and Preneel, Bart|title=A cross-protocol attack on the TLS protocol. Proceedings of the 2012 ACM conference on Computer and communications security|url=https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf|format=PDF|year=2012|pages=62–72|isbn=978-1-4503-1651-4}}</ref>。

=== Mac-then-Encrypt型の認証暗号に関するもの ===

==== {{Anchors|BEAST}}BEAST攻撃 ====

2011年9月23日、暗号研究者のThai DuongとJuliano Rizzoが、'''BEAST''' ('''Browser Exploit Against SSL/TLS''')<ref name="DuongRizzo">{{cite web|url=https://bug665814.bugzilla.mozilla.org/attachment.cgi?id=540839|title=Here Come The ⊕ Ninjas|accessdate=2014-06-24|author=Thai Duong and Juliano Rizzo|date=2011-05-13}}</ref> と呼ばれるTLS 1.0における[[ブロック暗号]]の[[暗号利用モード#CBC|CBCモード]]の取り扱いに関する脆弱性のコンセプトを[[Javaアプレット]]の[[同一生成元ポリシー]]違反によって実証した<ref name="DanGoodin">{{cite web|url=http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/|title=Hackers break SSL encryption used by millions of sites|accessdate=2014-06-24|author=Dan Goodin|date=2011-09-19}}</ref><ref name="combinator">{{cite web|url=http://news.ycombinator.com/item?id=3015498|title=Y Combinator comments on the issue|accessdate=2014-06-24|date=2011-09-20}}</ref>。この脆弱性そのものは2002年にPhillip Rogawayによって発見されていた<ref>{{cite web|url=http://www.openssl.org/~bodo/tls-cbc.txt|title=Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures|accessdate=2014-06-24|date=2004-05-20|archiveurl=https://web.archive.org/web/20120630143111/http://www.openssl.org/~bodo/tls-cbc.txt|archivedate=2012-06-30}}</ref>が、2011年の発表までは実用的な[[エクスプロイト]]は報告されていなかった。

2006年に発表されたTLS 1.1においてBEASTへの脆弱性は修正されていたが、2011年の実証までTLS 1.1への対応はクライアント、サーバの双方でほとんど進んでいなかった。


Google ChromeおよびFirefoxはBEASTによる影響を直接的に受けることはないが<ref name="ChromeBEAST2">{{Cite web|和書|url=http://googlechromereleases.blogspot.jp/2011/10/chrome-stable-release.html|title=Chrome Stable Release|accessdate=2015-02-01|date=2011-10-25|work=Chrome Releases|publisher=Google}}</ref><ref name="FirefoxBEAST2">{{Cite web|和書|url=http://www.mozilla.jp/blog/entry/7289/|title=TLS 暗号化通信に対する攻撃の Firefox への影響|accessdate=2015-02-01|date=2011-09-28|work=Mozilla Japan ブログ|publisher=Mozilla Japan}}</ref>、MozillaはTLS/SSLのためのライブラリである[[Network Security Services]] (NSS) に対して、BEASTおよびそれに類似した[[選択平文攻撃]]に対するTLS 1.0以前で有効な対応策を2011年に施した。NSSは、[[Mozilla Firefox]]などのMozillaのソフトウェアだけでなく、[[Google Chrome]]など他のブラウザでも用いられているライブラリである。NSSでのTLS 1.1以降への対応は2012年までずれこみ、FirefoxでTLS 1.1以降を既定で利用可能となったのは2014年のバージョン27である。

[[マイクロソフト]]は2012年1月10日にSecurity Bulletin MS12-006を発表し、Windowsで用いられているライブラリである[[SChannel]]に対して修正を加えた<ref>{{cite web|url=http://technet.microsoft.com/en-us/security/bulletin/ms12-006|title=Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)|accessdate=2014-06-24|date=2012-01-10}}</ref>。[[Microsoft Windows 7|Windows 7]]以降では、TLS 1.1以降が利用可能である。


[[Apple]]製品では、[[macOS]]ではv10.9においてTLS 1.1以降への対応およびTLS 1.0以前におけるBEAST脆弱性への対応がなされているが、v10.8以前では、TLS 1.1以降への対応、TLS 1.0以前におけるBEAST脆弱性への対応のいずれも行われていない。[[iOS]]では、5以降ではTLS 1.1以降が利用可能であるが、TLS 1.0以前におけるBEAST脆弱性への対応は行われていない。iOS 7ではじめてTLS 1.0以前におけるBEAST脆弱性への対応が行われた。

=== {{Anchors|パディングオラクル攻撃}}パディング攻撃 ===

TLSの初期のバージョンはパディングオラクル攻撃に対して脆弱であることが2002年に報告された。

==== {{Anchors|Lucky Thirteen|Lucky Thirteen攻撃}}Lucky Thirteen ====

2013年には、'''Lucky Thirteen'''攻撃︵[[:en:Lucky Thirteen attack|英語版]]︶と呼ばれる新たなパディング攻撃が報告されている。2014年現在では、多くの実装においてLucky Thirteen攻撃に対して対応済みである。

==== {{Anchors|POODLE}}POODLE攻撃 ====

2014年9月15日、[[Google]]の研究者によって、SSL 3.0の設計に脆弱性が存在することが発表された<ref>{{Cite web|和書|url=https://internet.watch.impress.co.jp/docs/news/671482.html|title=Google、SSL 3.0の脆弱性「POODLE」を公表、SSL 3.0は今後サポート廃止の意向 -INTERNET Watch|accessdate=2014-10-16|date=2014-10-15}}</ref> ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 CVE-2014-3566])。これは、SSL 3.0においてブロック暗号を[[暗号利用モード#CBC|CBCモード]]で使用した際に[[#パディング攻撃|パディング攻撃]]が可能となるものであり、'''POODLE''' ('''Padding Oracle On Downgraded Legacy Encryption''') と名付けられた。平均してわずか256回のリクエストで暗号文の1バイトの解読が可能となる<ref name="poodle_pdf">{{cite web|url=https://www.openssl.org/~bodo/ssl-poodle.pdf|title=This POODLE Bites: Exploiting The SSL 3.0 Fallback|accessdate=2014-10-15|author=Bodo Möller, Thai Duong and Krzysztof Kotowicz|format=PDF}}</ref><ref name="poddle2">{{cite web|url=http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html|title=This POODLE bites: exploiting the SSL 3.0 fallback|accessdate=2014-10-15|author=Bodo Möller|date=October 14, 2014}}</ref>。CVE IDは[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 CVE-2014-3566]である。


この脆弱性はSSL 3.0の仕様のみに存在するものでありTLS 1.0以降に影響はないが、主要なすべてのブラウザではTLSでのハンドシェイクが失敗した場合にSSL 3.0での接続にダウングレードする。そのため、攻撃者は[[#バージョンロールバック攻撃|バージョンロールバック攻撃]]によってSSL 3.0での接続を行わせることでこの脆弱性を利用可能となる<ref name="poodle_pdf" /><ref name="poddle2" />。

POODLE攻撃への根本的な対処法は、少なくともクライアント、サーバのどちらかでSSL 3.0を無効化することである。しかし、古いクライアント、サーバなどではTLS 1.0以降に対応していないため、互換性を考慮してSSL 3.0を無効化できない場合がある。そこで、POODLEの発見者は、TLS_FALLBACK_SCSV<ref name="ietf-tls-downgrade-scsv">{{IETF RFC|7507}}</ref>の実装を推奨している。この実装によりTLSからSSL 3.0へのフォールバックが抑止されるが<ref name="poodle_pdf" /><ref name="poddle2" />、これはクライアント側だけでなくサーバ側の対応も必要である。

[[Google Chrome]]ブラウザやGoogleサービスのサーバは既にTLS_FALLBACK_SCSVに対応しており、加えて数か月以内にこれらクライアント、サーバからSSL 3.0のサポートを除去する予定である<ref name="poddle2" />。2014年11月リリースのバージョン39においてSSL 3.0へのフォールバックを、2015年1月リリースのバージョン40においてSSL 3.0そのものを既定で無効化している。


[[Opera]]もGoogle Chromeと同様にTLS_FALLBACK_SCSVを実装済みであるほか、バージョン25において"anti-POODLE record splitting"と呼ばれる異なる対策を実装した<ref name="opera25">{{cite web|url=http://blogs.opera.com/security/2014/10/security-changes-opera-25-poodle-attacks/|title=Security changes in Opera 25; the poodle attacks|accessdate=2014-10-18|author=Molland, Håvard|date=2014-10-15|publisher=[[Opera (web browser)|Opera]]}}</ref>。

Mozillaでは2014年12月リリースの[[Mozilla Firefox]] 34およびESR 31.3からSSL 3.0を無効化したほか、Firefox 35においてTLS_FALLBACK_SCSVをサポートした<ref name="mozilla-poodle">{{cite web|url=https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/|title=The POODLE Attack and the End of SSL 3.0|accessdate=2014-10-15|date=2014-10-14}}</ref>。

マイクロソフトでは、グループポリシーからSSL 3.0を無効化する方法を公開しているほか<ref name="microsoft-poodle">{{Cite web|和書|url=https://technet.microsoft.com/ja-jp/library/security/3009008|title=SSL 3.0 の脆弱性により、情報漏えいが起こる|accessdate=2014-10-15|date=2014-10-15}}</ref>、10月29日にWindows Vista、Server 2003およびそれ以降のIEにおいてSSL 3.0を無効化する"Fix it"を公開し、数か月以内にIEおよびマイクロソフトのオンラインサービスにおいてSSL 3.0を既定で無効化する方針を表明した<ref name="microsoft-Oct29">{{cite web|url=http://blogs.technet.com/b/msrc/archive/2014/10/29/security-advisory-3009008-released.aspx|title=Security Advisory 3009008 revised|accessdate=2014-10-30|date=2014-10-29|work=Microsoft TechNet|publisher=マイクロソフト}}</ref>。2015年2月のアップデートにおいて、IE 11の保護モードにおいてSSL 3.0へのフォールバックを既定で無効化した<ref>{{cite web|url=http://blogs.msdn.com/b/ie/archive/2014/12/09/december-2014-internet-explorer-security-updates-amp-disabling-ssl-3-0-fallback.aspx|title=December 2014 Internet Explorer security updates & disabling SSL 3.0 fallback|accessdate=2015-02-12|author=Oot, Alec|date=December 9, 2014|publisher=マイクロソフト}}</ref>。加えて、2015年4月にIE 11においてSSL 3.0自体を既定で無効化した<ref>{{Cite web|和書|url=https://technet.microsoft.com/ja-jp/library/security/3009008.aspx|title=SSL 3.0 の脆弱性により、情報漏えいが起こる|accessdate=2015-04-16|date=2015-04-15|publisher=セキュリティ TechCenter}}</ref>。


[[Safari]]︵OS X v10.8以降およびiOS 8.1以降︶では、POODLEへの対策としてSSL 3.0においてCBCモードのcipher suiteを無効化した<ref>http://support.apple.com/kb/HT6531</ref><ref>http://support.apple.com/kb/HT6541</ref>。これによりPOODLEの影響を受けることはなくなるが、SSL 3.0においてCBCモードを無効化したことで、脆弱性が指摘されている[[RC4]]しか利用できなくなるという問題が生じている。


サーバ側では、[[Network Security Services|NSS]]が2014年10月3日にリリースされたバージョン3.17.1および10月27日にリリースされた3.16.2.3でTLS_FALLBACK_SCSVに対応したほか<ref>{{cite web|url=https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.17.1_release_notes|title=NSS 3.17.1 release notes|accessdate=2014-10-20|date=2014-10-03|publisher=Mozilla}}</ref><ref>{{cite web|url=https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.16.2.3_release_notes|title=NSS 3.16.2.3 release notes|accessdate=2014-10-27|date=2014-10-27|publisher=Mozilla}}</ref>、2015年4月までにSSL 3.0を既定で無効化する予定である<ref>{{cite web|url=https://groups.google.com/forum/?hl=ja#!topic/mozilla.dev.tech.crypto/G6c2bguhacM|title=Disable SSL 3 by default in NSS in April 2015.|accessdate=2014-10-27|date=2014-10-27|publisher=mozilla.dev.tech.crypto}}</ref>。[[OpenSSL]]は、10月15日リリースのバージョン1.0.1j、1.0.0、0.9.8zcでTLS_FALLBACK_SCSVに対応した<ref>{{cite web|url=https://www.openssl.org/news/secadv_20141015.txt|title=OpenSSL Security Advisory [15 Oct 2014]|accessdate=2014-10-20|date=2014-10-15|publisher=OpenSSL}}</ref>。[[LibreSSL]]では、10月16日リリースのバージョン2.1.1でSSL 3.0を既定で無効化した<ref>{{cite web|url=https://marc.info/?l=openbsd-announce&m=141347213320729&w=2|title=LibreSSL 2.1.1 released.|accessdate=2014-10-20|date=2014-10-16|publisher=LibreSSL}}</ref>。


2014年12月8日に、SSL 3.0ではなくTLS 1.0から1.2に対して有効なPOODLE攻撃の変法が報告された。この変法はTLSの仕様においてサーバ側に要求されているパディングのチェックを正しく行わない実装において、SSL 3.0を無効にしていたとしてもPOODLE攻撃が可能となるというものである<ref name="poodleagain">{{cite web|url=https://www.imperialviolet.org/2014/12/08/poodleagain.html|title=The POODLE bites again|accessdate=2014-12-10|author=Langley, Adam|date=2014-12-08}}</ref>。すなわち、SSL 3.0に対するものが仕様そのものの脆弱性であるのに対し、TLS 1.0以降に対するものは不適切な実装による脆弱性である。SSL Pulseでは、公開前の時点でHTTPS対応のサーバのうちおよそ10%がこの変法に対して脆弱であるとしている<ref>{{cite web|url=https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls|title=Poodle Bites TLS|accessdate=201-12-10|author=Ristic, Ivan|date=2014-12-08}}</ref>。この変法のCVE IDは[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8730 CVE-2014-8730]である。この変法では、SSL 3.0へダウングレードさせる必要がなくTLS 1.2のままで攻撃が可能であるなど、オリジナルのSSL 3.0に対するPOODLE攻撃よりも実行が容易であるとされる<ref>{{cite web|url=http://freedomhacker.net/nasty-poodle-variant-bypasses-tls-crypto-hitting-major-sites-3506/|title=Nasty POODLE Variant Bypasses TLS Crypto Affecting Over 10 Percent of the Web|accessdate=2014-12-10|author=Stosh, Brandon|date=2014-12-08}}</ref>。

=== 圧縮サイドチャネル攻撃 ===

TLS1.2では平文を圧縮した後に暗号化を施す。しかし圧縮後の平文のビット長さは圧縮前の平文に依存し、しかも暗号文のビット長は暗号化する文書＝圧縮後の平文のビット長に依存するので、暗号文長から平文の情報が攻撃者に漏れてしまう。この事実を利用した攻撃を'''圧縮サイドチャネル攻撃'''という。TLS1.2には以下の様な圧縮サイドチャネル攻撃が知られている。

==== {{Anchors|CRIME攻撃|CRIME}}CRIME攻撃 ====

2012年にBEAST攻撃の報告者によって、TLSにおいてデータ圧縮が有効な場合において、本来第三者に対して秘密であるべきCookieの内容が回復可能となる'''CRIME'''︵'''Compression Ratio Info-leak Made Easy''', [[:en:CRIME|英語版]]︶が報告された<ref>{{cite web|url=http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/|title=Crack in Internet's foundation of trust allows HTTPS session hijacking|accessdate=2014-06-24|author=Dan Goodin|date=2012-09-13|publisher=Ars Technica}}</ref><ref>{{cite web|url=http://threatpost.com/en_us/blogs/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312|title=CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions|accessdate=2014-06-24|author=Dennis Fisher|date=September 13, 2012|publisher=ThreatPost}}{{dead link|date=2014年5月}}</ref>。ウェブサイトでのユーザ認証に使われているCookieの内容を回復されることで、[[セッションハイジャック]]が可能となる。2012年9月にはMozilla FirefoxおよびGoogle ChromeにおいてCRIMEへの対応が実施された。また、マイクロソフトによればInternet ExplorerはCRIMEの影響を受けない。

CRIMEの報告者によって、CRIMEがTLS以外にもデータ圧縮を利用する[[SPDY]]や[[Hypertext Transfer Protocol|HTTP]]といったプロトコルにも広く適用可能であることが示されていたにもかかわらず、クライアント、サーバのいずれにおいてもTLSやSPDYに対する修正しか行われず、HTTPに対する修正は行われなかった。

==== {{Anchors|BREACH攻撃|BREACH}}BREACH攻撃 ====

2013年に、HTTPでのデータ圧縮をターゲットとした'''BREACH'''（'''Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext''', [[:en:BREACH (security exploit)|英語版]]）と呼ばれるCRIME攻撃の変法が報告された。BREACH攻撃では、ログイントークン、メールアドレスなどの個人情報をわずか30秒で取得可能であり、不正なリンクを訪れさせたり、正当なウェブページに不正なコンテンツを挿入することも可能であった<ref name="Gooin20130801">{{cite web|url=http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/|title=Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages|accessdate=2014-06-24|date=2013-08-01|work=Ars Technica|publisher=Condé Nast|last=Goodin|first=Dan}}</ref>。使用するアルゴリズム、Cipher Suiteを問わず、すべてのバージョンのTLS/SSLに対してBREACH攻撃は適用可能である<ref>{{cite web|url=http://www.theregister.co.uk/2013/08/02/breach_crypto_attack/|title=Step into the BREACH: New attack developed to read encrypted web data|accessdate=2014-06-24|date=2013-08-02|work=The Register|last=Leyden|first=John}}</ref>。TLSでのデータ圧縮やSPDYでのヘッダ圧縮を無効とすることで容易に回避可能であったCRIMEとは異なり、BREACHを回避するためにはHTTPでのデータ圧縮を無効にする必要があるが、通信速度の向上のためにほぼすべてのサーバがHTTPデータ圧縮を有効としている現状では、これを無効化することは現実的ではない<ref name="Gooin20130801" />。

=== その他 ===

==== 再ネゴシエーション脆弱性 ====

2009年11月4日、SSL 3.0以降の再ネゴシエーション機能を利用して、クライアントからのリクエストの先頭に[[中間者攻撃|中間者]]が任意のデータを挿入できるという脆弱性が報告された<ref>{{Cite web|last=Ray|first=Marsh|coauthors=Steve Dispensa|date=2009-11-04|url=http://extendedsubset.com/Renegotiating_TLS.pdf|title=Renegotiating TLS|format=PDF|language=英語|accessdate=2010-02-13}}</ref><ref>{{Cite web|和書|date=2009-11-13|url=https://jvn.jp/cert/JVNVU120541/index.html|title=JVNVU#120541 SSL および TLS プロトコルに脆弱性|work=Japan Vulnerability Notes|publisher=JPCERT/CC and IPA|accessdate=2010-02-13}}</ref>。プロトコル自体の脆弱性であり、すべての実装が影響を受ける。


この脆弱性への簡単な対策は、サーバにおいて再ネゴシエーションを禁止することである。根本対応としては、TLS Extensionを使った安全な再ネゴシエーション手順が{{IETF RFC|5746}}として提案されている。この脆弱性を利用した中間者攻撃では、サーバが{{IETF RFC|5746}}に対応しない限りクライアントは再ネゴシエーションが発生したことを検出できないので、クライアント側のみで対応することは不可能である。

==== 切り詰め攻撃 ====

TLSでの切り詰め攻撃では、ユーザがウェブサービスからログアウトすることを妨害し、意図せずログインしたままとすることが可能である。ユーザからログアウト要求が送信されたときに、攻撃者が偽の[[Transmission Control Protocol|TCP]] FINメッセージ（これ以上データを送信しない）を平文で挿入する。このメッセージを受けたサーバでは、ユーザから送られたログアウト要求を受け取らないため、ユーザの意図とは異なりログイン状態が維持される<ref name="register20130801">{{cite web|title=Gmail, Outlook.com and e-voting 'pwned' on stage in crypto-dodge hack|url=http://www.theregister.co.uk/2013/08/01/gmail_hotmail_hijacking/|work=The Register|accessdate=2014-06-24|author=John Leyden|date=2013-08-01}}</ref>。

2013年の報告<ref>{{cite web|title=BlackHat USA Briefings|url=https://www.blackhat.com/us-13/briefings.html#Smyth|work=Black Hat 2013|accessdate=2014-06-24}}</ref>では、この攻撃への対応として、[[Gmail]]や[[Hotmail]]などのウェブサービスでは、ログアウトが正常に完了した旨のページを表示するようになった。これにより、ログアウトしたか否かをユーザが確認することが可能となり、攻撃者によってログイン状態のアカウントを悪用される危険性が軽減される。

この攻撃では目標のコンピュータにマルウェアなどを導入する必要はないが、攻撃者が目標とサーバの間の回線に割り込むことが可能であること<ref name="register20130801"/>と、目標のコンピュータに物理的にアクセス可能であることが求められる。

=== 実装上の脆弱性をついたもの ===

==== {{Anchors|Heartbleed}}ハートブリード ====

{{main|ハートブリード}}

ハートブリード（{{Lang-en-short|Heartbleed}}）は、2014年に発覚した[[OpenSSL]]ライブラリのバージョン1.0.1から1.0.1fの間で発見された深刻なセキュリティ脆弱性である。この脆弱性を利用することで、TLS/SSLによって保護されているはずの情報を盗むことが可能である。

このバグでは、インターネット上の誰もが、脆弱性のあるOpenSSLを利用しているシステムのメモリにアクセスすることが可能となり、サービスプロバイダの認証やデータの暗号化に用いられている秘密鍵、ユーザのアカウントおよびパスワード、実際にやり取りされたデータなどを取得できる。これにより、メッセンジャーサービス、電子メールの盗聴、データの盗難、なりすましなどが可能となる。

=== ウェブサイトの統計 ===

Trustworthy Internet Movementは、TLS/SSLに対する攻撃に対して脆弱なウェブサイトの統計を発表している。2019年8月における統計は以下の通りである<ref name="trustworthy_ssl_pulse"/>。

{|class="wikitable" style="text-align: center;"

|+'''TLS/SSLに対する攻撃に脆弱なウェブサイトの統計（括弧内は前月との差）'''

|-

!rowspan="2"|攻撃

!colspan="4"|セキュリティ

|-

!安全ではない

!状況による

!安全

!その他

|-

![[#再ネゴシエーション脆弱性|再ネゴシエーション脆弱性]]

|{{No|0.3%<br /><small>安全ではない再ネゴシエーションに対応</small>}}

|{{Partial|0.1%<br /><small>両方に対応</small>}}

|{{Yes|98.4%<br /><small>安全な再ネゴシエーションに対応</small>}}

|1.1%<br /><small>再ネゴシエーション非対応</small>

|-

![[Transport Layer Security#RC4|RC4攻撃]]

|{{No|1.2%<br /><small>最新のブラウザで利用可能なRC4 Suiteをサポート</small>}}

|{{Partial|12.1%<br /><small>RC4 Suiteのいくつかをサポート</small>}}

|{{Yes|86.7%<br /><small>RC4によるCipher Suite非サポート</small>}}

|{{N/A}}

|-

![[#CRIME攻撃|CRIME攻撃]]

|{{No|0.6%<br /><small>脆弱</small>}}

|{{N/A}}

|{{N/A}}

|{{N/A}}

|-

![[#ハートブリード|ハートブリード]]

|{{No|&lt;0.1%<br /><small>脆弱</small>}}

|{{N/A}}

|{{N/A}}

|{{N/A}}

|-

![[OpenSSL#CCS Injection Vulnerability|CCS Injection Vulnerability]]

|{{No|0.2%<br /><small>脆弱かつ悪用可能</small>}}

|{{Partial|1.2%<br /><small>脆弱だが悪用不可能</small>}}

|{{Yes|96.9%<br /><small>脆弱ではない</small>}}

|1.7%<br /><small>不明</small>

|-

![[#POODLE攻撃|TLSへのPOODLE攻撃]]<br /><small>SSL 3.0へのPOODLE攻撃は含まない</small>

|{{No|0.3%<br /><small>脆弱かつ悪用可能</small>}}

|{{N/A}}

|{{Yes|99.5%<br /><small>脆弱ではない</small>}}

|0.2%<br /><small>不明</small>

|-

![[#ダウングレード攻撃|プロトコルダウングレード]]

|{{No|11.3%<br /><small>TLS_FALLBACK_SCSV非サポート</small>}}

|{{N/A}}

|{{Yes|71.6%<br /><small>TLS_FALLBACK_SCSVサポート</small>}}

|17.0%<br /><small>不明</small>

|}

== 参考文献 ==

* {{Cite book|和書

|author=Eric Rescorla

|others=齊藤孝道・鬼頭利之・古森貞監訳

|title=マスタリングTCP/IP SSL/TLS編

|edition=第1版第1刷

|date=2003-11-28

|publisher=オーム社

|isbn=4-274-06542-1

}}

== 脚注 ==

{{Reflist|2}}

== 関連項目 ==

{{Wiktionary pipe|SSL}}

* [[HTTPS]]

* [[Datagram Transport Layer Security]]

* [[FTPS]]

* [[Secure Shell|SSH]]

* [[Secure Shell|SSH]]

* [[GnuTLS]]

* [[Network Security Services]]

* [[OpenSSL]]

* [[フィッシング (詐欺)|フィッシング]]

* [[Extended Validation 証明書]] (EV SSL)

* [[認証局]]

* [[SSLオフロード]]


== 外部リンク ==

== 外部リンク ==

{{外部リンクの注意|section=1|date=2021年9月}}

* [http://wp.netscape.com/eng/ssl3/ SSL3.0 SPECIFICATION(英語)]

=== 標準化 ===

*RFC 2246 - The TLS Protocol Version 1.0

* 2018年9月時点での最新版

** {{IETF RFC|8446}}: "The Transport Layer Security (TLS) Protocol Version 1.3".

* 過去の版

** {{IETF RFC|2246}}: "The TLS Protocol Version 1.0".

** {{IETF RFC|4346}}: "The Transport Layer Security (TLS) Protocol Version 1.1".

** {{IETF RFC|5246}}: "The Transport Layer Security (TLS) Protocol Version 1.2".

** {{IETF RFC|8996}}: "Deprecating TLS 1.0 and TLS 1.1"

* SSLは標準化されていない

** {{cite web|last=Hickman |first=Kipp E.B.|title=The SSL Protocol |url=https://tools.ietf.org/html/draft-hickman-netscape-ssl-00 |date=April 1995 |accessdate=July 31, 2013}} This Internet Draft defines the now completely broken SSL 2.0.

** {{IETF RFC|6101}}: "The Secure Sockets Layer (SSL) Protocol Version 3.0".

* TLS 1.0の拡張

** {{IETF RFC|2595}}: "Using TLS with IMAP, POP3 and ACAP". Specifies an extension to the IMAP, POP3 and ACAP services that allow the server and client to use transport-layer security to provide private, authenticated communication over the Internet.

** {{IETF RFC|2712}}: "Addition of [[ケルベロス認証|Kerberos]] Cipher Suites to Transport Layer Security (TLS)". The 40-bit cipher suites defined in this memo appear only for the purpose of documenting the fact that those cipher suite codes have already been assigned.

** {{IETF RFC|2817}}: "Upgrading to TLS Within HTTP/1.1", explains how to use the [[HTTP/1.1 Upgradeヘッダー|Upgrade mechanism in HTTP/1.1]] to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same ''well known'' port (in this case, http: at 80 rather than https: at 443).

** {{IETF RFC|2818}}: "HTTP Over TLS", distinguishes secured traffic from insecure traffic by the use of a different 'server port'.

** {{IETF RFC|3207}}: "SMTP Service Extension for Secure SMTP over Transport Layer Security". Specifies an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet.

** {{IETF RFC|3268}}: "AES Ciphersuites for TLS". Adds [[Advanced Encryption Standard]] (AES) cipher suites to the previously existing symmetric ciphers.

** {{IETF RFC|3546}}: "Transport Layer Security (TLS) Extensions", adds a mechanism for negotiating protocol extensions during session initialisation and defines some extensions. Made obsolete by {{IETF RFC|4366}}.

** {{IETF RFC|3749}}: "Transport Layer Security Protocol Compression Methods", specifies the framework for compression methods and the [[Deflate|DEFLATE]] compression method.

** {{IETF RFC|3943}}: "Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)".

** {{IETF RFC|4132}}: "Addition of [[Camellia]] Cipher Suites to Transport Layer Security (TLS)".

** {{IETF RFC|4162}}: "Addition of [[SEED (暗号)|SEED]] Cipher Suites to Transport Layer Security (TLS)".

** {{IETF RFC|4217}}: "Securing [[FTPS|FTP with TLS]]".

** {{IETF RFC|4279}}: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", adds three sets of new cipher suites for the TLS protocol to support authentication based on pre-shared keys.

* TLS 1.1の拡張

** {{IETF RFC|4347}}: "[[Datagram Transport Layer Security]]" specifies a TLS variant that works over datagram protocols (such as UDP).

** {{IETF RFC|4366}}: "Transport Layer Security (TLS) Extensions" describes both a set of specific extensions and a generic extension mechanism.

** {{IETF RFC|4492}}: "[[楕円曲線暗号|Elliptic Curve Cryptography]] (ECC) Cipher Suites for Transport Layer Security (TLS)".

** {{IETF RFC|4680}}: "TLS Handshake Message for Supplemental Data".

** {{IETF RFC|4681}}: "TLS User Mapping Extension".

** {{IETF RFC|4785}}: "Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)".

** {{IETF RFC|5054}}: "Using the [[Secure remote password protocol|Secure Remote Password]] (SRP) Protocol for TLS Authentication". Defines the [[TLS-SRP]] ciphersuites.

** {{IETF RFC|5077}}: "Transport Layer Security (TLS) Session Resumption without Server-Side State".

** {{IETF RFC|5081}}: "Using [[OpenPGP]] Keys for Transport Layer Security (TLS) Authentication", obsoleted by {{IETF RFC|6091}}.

* TLS 1.2の拡張

** {{IETF RFC|5288}}: "AES [[Galois/Counter Mode|Galois Counter Mode]] (GCM) Cipher Suites for TLS".

** {{IETF RFC|5469}}: "DES and IDEA Cipher Suites for Transport Layer Security (TLS)"

** {{IETF RFC|5289}}: "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)".

** {{IETF RFC|5487}}: "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode"

** {{IETF RFC|5489}}: "ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)"

** {{IETF RFC|5746}}: "Transport Layer Security (TLS) Renegotiation Indication Extension".

** {{IETF RFC|5878}}: "Transport Layer Security (TLS) Authorization Extensions".

** {{IETF RFC|5932}}: "Camellia Cipher Suites for TLS"

** {{IETF RFC|6042}}: "Transport Layer Security (TLS) Authorization Using KeyNote".

** {{IETF RFC|6066}}: "Transport Layer Security (TLS) Extensions: Extension Definitions", includes [[Server Name Indication]] and [[Online Certificate Status Protocol|OCSP]] stapling.

** {{IETF RFC|6091}}: "Using [[OpenPGP]] Keys for Transport Layer Security (TLS) Authentication".

** {{IETF RFC|6176}}: "Prohibiting Secure Sockets Layer (SSL) Version 2.0".

** {{IETF RFC|6209}}: "Addition of the [[ARIA (暗号)|ARIA]] Cipher Suites to Transport Layer Security (TLS)".

** {{IETF RFC|6347}}: "Datagram Transport Layer Security Version 1.2".

** {{IETF RFC|6358}}: "Additional Master Secret Inputs for TLS"

** {{IETF RFC|6367}}: "Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)".

** {{IETF RFC|6460}}: "Suite B Profile for Transport Layer Security (TLS)".

** {{IETF RFC|6655}}: "AES-[[Counter with CBC-MAC|CCM]] Cipher Suites for Transport Layer Security (TLS)".

** {{IETF RFC|6961}}: "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension"

** {{IETF RFC|7027}}: "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)".

** {{IETF RFC|7250}}: "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"

** {{IETF RFC|7251}}: "AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS".

** {{IETF RFC|7301}}: "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension".

** {{IETF RFC|7366}}: "[[Encrypt-then-MAC]] for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)".

** {{IETF RFC|7465}}: "Prohibiting RC4 Cipher Suites".

** {{IETF RFC|7507}}: "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks".

** {{IETF RFC|7568}}: "Deprecating Secure Sockets Layer Version 3.0".

** {{IETF RFC|7627}}: "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension".

** {{IETF RFC|7685}}: "A Transport Layer Security (TLS) ClientHello Padding Extension".

** {{IETF RFC|7905}}: "ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)".

** {{IETF RFC|7918}}: "Transport Layer Security (TLS) False Start"

** {{IETF RFC|7919}}: "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)".

** {{IETF RFC|7924}}: "Transport Layer Security (TLS) Cached Information Extension"

** {{IETF RFC|7925}}: "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things"

** {{IETF RFC|8442}}: "ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2"

** {{IETF RFC|8422}}: "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier"

** {{IETF RFC|8701}}: "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility"

** {{IETF RFC|8492}}: "Secure Password Ciphersuites for Transport Layer Security (TLS)"

* TLS 1.3の拡張

** {{IETF RFC|8449}}: "Record Size Limit Extension for TLS"

** {{IETF RFC|8672}}: "TLS Server Identity Pinning with Tickets"

** {{IETF RFC|8734}}: "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3"

** {{IETF RFC|8879}}: "TLS Certificate Compression"

** {{IETF RFC|8902}}: "TLS Authentication Using Intelligent Transport System (ITS) Certificates"

** {{IETF RFC|8998}}: "ShangMi (SM) Cipher Suites for TLS 1.3"

* TLSを含むカプセル化

** {{IETF RFC|5216}}: "The [[Extensible Authentication Protocol|EAP]]-TLS Authentication Protocol"

** {{IETF RFC|8472}}: "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation"

* X.509 (PKIX)との関係性

** {{IETF RFC|6125}}: "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"

** {{IETF RFC|7633}}: "X.509v3 Transport Layer Security (TLS) Feature Extension"

* その他

** {{IETF RFC|5705}}: "Keying Material Exporters for Transport Layer Security (TLS)"

** {{IETF RFC|7457}}: "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)"

** {{IETF RFC|7525}}: "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"

** {{IETF RFC|8447}}: "IANA Registry Updates for TLS and DTLS"

** {{IETF RFC|8448}}: "Example Handshake Traces for TLS 1.3"

** {{IETF RFC|8744}}: "Issues and Requirements for Server Name Identification (SNI) Encryption in TLS"

=== IANA ===

* [https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml Transport Layer Security (TLS) Parameters]

* [https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml Transport Layer Security (TLS) Extensions]


{{OSI}}

[[Category:通信プロトコル]]

{{SSL/TLS}}

[[Category:セキュリティ技術|せきゆあそけつとれいや]]

{{エクスプロイト}}


{{DEFAULTSORT:Transport Layer Security}}

[[en:Transport_Layer_Security]]

[[Category:Transport Layer Security|*]]

[[fi:TLS]]

[[Category:アプリケーション層プロトコル]]

[[fr:Secure_socket_layer]]

[[Category:コンピュータ・ネットワーク・セキュリティ]]

[[pt:SSL]]

[[Category:セキュア通信]]

{{Comp-stub}}

[[Category:電子商取引]]

[[Category:インターネット標準]]

[[Category:RFC|5246]]

2024年7月5日 (金) 01:31時点における最新版

TCP/IP群
アプリケーション層
カテゴリ
トランスポート層
カテゴリ
インターネット層
カテゴリ
リンク層
カテゴリ
インターネットセキュリティ
プロトコル
キーマネジメント
アプリケーション層
DNS
インターネット層

Transport Layer Security︵トランスポート・レイヤー・セキュリティ、TLS︶は、インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うためのプロトコルである。主な機能として、通信相手の認証、通信内容の暗号化、改竄の検出を提供する。TLSは非営利組織IETFによって策定された。

当プロトコルは︵特に区別する場合を除いて︶SSL (Secure Sockets Layer) と呼ばれることも多い。これは、TLSの元になったプロトコルがSSLであり[1]、そのSSLという名称が広く普及していることによる[2]。SSLはNetscapeが設計・開発した[3]。当初のSSLを元にして、以後、SSL 2︵1994年︶、SSL 3︵1995年︶がそれぞれ前バージョンの欠陥や脆弱性を修正するものとして公開された。SSLを拡張して、TLS︵1999年︶、TLS 1.2︵2008年︶、TLS 1.3︵2018年︶が作られた[3]。

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

アプリケーション層プロトコルへの適用

[編集]

TLSは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。

既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層︵通常はTCP︶の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとしてSTARTTLSが広まっているため、この方式自体をSTARTTLSと呼ぶこともある。

前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、平文で接続を開始する実装と共存できなくなるため、既存のポート番号とは別にTLS対応用のポート番号が必要となる。実態としては、SSL/TLSの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。ただし、この方式はバーチャルホストを構成する際に問題となる可能性がある。詳細は#バーチャルホストの節を参照。

なお、ポート番号を分ける方式をSSL、同一ポート番号で切替える方式︵STARTTLS方式︶をTLSと呼んでいる実装もある[4]。TLS/SSLという用語の区別がプロトコルのバージョンを指しているか、アプリケーション層プロトコルへの適用方式を指しているかは、文脈で判断する必要がある。

セキュリティ上の考察

[編集]

TLS適用の有無と使用アルゴリズムの強度

[編集]

TLSを導入さえすればセキュリティが確保できるという認識は誤っている。TLS通信は、平文での通信に比べて︵主に暗号化・復号時︶余分な計算機能力を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、TLSが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。
Mozilla Firefoxにおける南京錠アイコンの例
World Wide Webでは、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信で TLS (HTTPS) が使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに南京錠のアイコンを表示したり、アドレスバーの色を変化させたりして、利用者に情報を提供していた。一方 Google は南京錠のアイコンが適切ではなくなったとして、Chrome での南京錠の表示を廃止した[5]。背景として、HTTPS が普及したこと、南京錠アイコンの意味を正しく理解している人が少ない[6]ことを挙げている。さらに、Chrome では HTTPS を使っていない通信を行う前に警告画面を出すようにした[7]。

また実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため、TLSを使用していても、システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある。このような場合もダイアログメッセージなどを使って利用者に警告すべきである。

証明書の正当性

[編集]
詳細は「認証局」を参照

TLSは公開鍵証明書を用いて認証を行い、なりすましを極力排除しようとする。しかしシステムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではない。

公開鍵証明書には認証局による電子署名が与えられる。その署名の正当性を評価するためには認証局の証明書が必要であり、最終的にはルート証明書と呼ばれる一群の証明書に行きつく。各システムは、認証局の証明書として信用できるルート証明書を、あらかじめ保持している。認証局は自身の秘密鍵を厳重に秘匿し、また証明書の発行にあたっては正当なサーバ管理者かどうか確認することが求められる。これらが保証されない認証局のルート証明書を組み込むことは、TLSにおける認証機能を破綻させることになる。仮に認証局自体は安全でも、入手したルート証明書が本当に意図する認証局のものかどうか判断することは難しいという点も注意すべきである。

TLSで認証を行うためには、認証局の署名に加えて、証明書の発行先を確認する必要がある。確認しない場合、サーバAの管理権限を持たない者がサーバBとして正当な証明書を取得し、その証明書を使ってサーバAを名乗ることができてしまう。TLS用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。

現実には﹁正当な﹂サーバであっても、これらの検証において﹁問題がある﹂と判断される証明書を使って運用されているサーバが少なからず存在する。セキュリティ研究者の高木浩光は、このような証明書のことを、オレオレ詐欺をもじって﹁オレオレ証明書﹂と呼んで批判している[8]。

この検証は、システムに指示された接続先のホスト名と実際に接続した先のホスト名が一致することを検証しているのであり、利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある。

例として、利用者が意図する接続先であるサーバ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) が公開している﹁安全なウェブサイトの作り方﹂[9]という文書の﹁フィッシング詐欺を助長しないための対策﹂に対応する。

乱数の品質

[編集]

他の多くの近代暗号と同様に、TLSもまた、暗号としての強度は乱数の品質に依存している。桁数︵ビット長︶の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている︵これは、公開鍵暗号システムにも言える︶。もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、総当たり攻撃で解読される可能性が上昇する。通常は、これは実装の問題に起因している。

古い例では、Netscapeの初期の実装における乱数生成の脆弱性がある。プロセスIDや時刻から乱数を生成していることが判明し、これらの情報を取得できる場合には総当たり攻撃の所要時間が大幅に短くなるという問題があった[10]。

2008年5月15日にはDebianが脆弱性に関する報告[11]を発表した。OpenSSLライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536 (= 216) 通りの予測可能な物が生成されてしまった事を明らかにした[12]︵なお、この問題は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/CCの勧告[13]等に従うべきである。

プロトコル概要

[編集]

本説ではTLS 1.2の概要を説明する。

TLSには主なプロトコルとして暗号通信に必要な鍵 (master secret) を鍵共有してセッションを確立するTLSハンドシェイクプロトコルと、master secretを用いて暗号通信することで確立されたセッションにおけるコネクションをセキュアにするTLSレコードプロトコルがある。

その他に用いている暗号方式やハッシュ関数等のアルゴリズムを変更する Change Cipher Spec プロトコルと通信相手からの通信終了要求や何らかのエラーを通知する アラートプロトコルがある。

TLSハンドシェイクプロトコル

[編集]

TLSハンドシェイクプロトコルは4つのフェーズに大別できる。

 
 
 
 
 
 
 
 
 
クライアント
 
 
 
 
 
 
 
 
 
 
 
（第一フェーズ）
 
 
 
 
 
 
 
 
 
   サーバ   
 
 
 
 
 
 
 
 
 
 
 
─ClientHello───→
←ServerHello────
 
（第二フェーズ）
←Certificate────
←ServerKeyExchange─
←CertificateRequest──
←ServerHelloDone──
 
（第三フェーズ）
─Certificate───→
─ClientKeyExchange→
─CertificateVerify─→
 
（第四フェーズ）
─Change Cipher Spec→
─Finished─────→
←Change Cipher Spec─
←Finished──────

第一フェーズ

[編集]

第一のフェーズではサーバ・クライアント間で通信に必要情報の合意を図る。このフェーズでは、まずクライアントからサーバにClientHelloが送信され、次にサーバからクライアントにServerHelloが送信される[14]。

ClientHelloはTLSのバージョン、乱数、セッションID、通信に用いる暗号方式やハッシュアルゴリズムのリスト (cipher_suites)、通信内容の圧縮方法、および拡張領域の6つからなる[14]。乱数は鍵共有におけるリプレイ攻撃を防ぐためのものである。

ServerHelloもClientHelloと同様の6つからなっている︵名称は一部異なる︶[14]。ServerHelloの主な目的は、ClientHelloで提示された選択肢の中でサーバにとって好ましいものを選択する事で、例えばClientHelloで提示されたcipher_suitesの中から、サーバが通信に使いたいcipher_suiteを一組選ぶ[14]。乱数はClientHelloとは独立して選ぶ[14]。これもリプレイ攻撃を回避するためである。セッションIDは特に問題がなければClientHelloと同一のものを返す。

第二フェーズ

[編集]

第二フェーズではサーバからクライアントに対して鍵共有に必要な情報を送る。具体的にはサーバはCertificate、ServerKeyExchange、CertificateRequest、ServerHelloDoneを︵第一フェーズServerHelloに引き続き︶クライアントに送信する[14]。

Certificateは鍵共有で用いる公開鍵とその証明書で別途取り決めがない限りX.509v3のフォーマットに従う[14]。なお鍵共有方式としてDH_anonを用いている場合にはcertificateは必要ない[14]。

ServerKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、gx mod pという形のデータを送る。ここでxはサーバの秘密の乱数である。鍵共有プロトコルがDHE_DSS、DHE_RSA、DH_anonでは何らかのserver_key_exchangeを送るが、RSA、DH_DSS、DH_RSAでは何も送らない[14]。

CertificateRequestはクライアントの公開鍵とその証明書を送ることを要求するためのもので、サーバが許容できる証明書の種別、ハッシュと署名方式、および認証局のリストからなっている[14]。

そして最後にサーバ側からのメッセージ送信が終わった事を示すServerHelloDoneをクライアントに送る。

第三フェーズ

[編集]

第三フェーズではクライアントからサーバに対して鍵共有に必要な情報を送る。具体的にはクライアントはCertificate、ClientKeyExchange、CertificateVerifyをサーバに送る[15]。

Certificateは鍵共有で用いるクライアントの公開鍵とその証明書である。証明書はサーバから送られてきたCertificateRequestの条件を満たさねばならない。

ClientKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、gy mod pという形のデータを送る。ここでyはクライアントの秘密の乱数である。

ここまでのプロトコルにより、サーバとクライアントの間でpremaster secretが共有された事になる。DH_anonであればpremaster secretはgxy mod pである。premaster secretを鍵にした擬似ランダム関数にServerHelloとClientHelloの乱数などを並べたものを入力した結果得られたものがmaster secretである[15]。

CertificateVerifyはクライアントが署名能力を持っていることを証明するためにこれまでTLSハンドシェイクプロトコルで送受信された全メッセージに対し、共有されたmaster secret で署名したものである[要検証 – ノート][14]。

第四フェーズ

[編集]

クライアントは必要ならChange Cipher Spec プロトコルのメッセージをサーバに送り、終了を意味するFinishedをサーバに送る。同様にサーバも必要ならChange Cipher Spec プロトコルのメッセージをクライアントに送り、終了を意味するFinishedをクライアントに送る[14]。

TLSレコードプロトコル

[編集]

TLSレコードプロトコルはアプリケーション層から受け取った通信内容を214バイト以下のブロックに分解 (fragmentation) し、各ブロックを圧縮 (compress) し、圧縮されたブロックを認証暗号で暗号化するレコード Payload 防護を施した上で、通信内容を通信相手に送信する[16]。

認証暗号は、TLS 1.1まではMACをつけた後で共通鍵暗号化するMAC-then-Encrypt (MtE) のみが利用可能であった。TLS 1.2からは、AES-GCMのようなAEADに分類される認証暗号専用の暗号利用モードも利用可能になり[16]、TLS 1.3ではAEADのみが利用可能となっている。

認証暗号にブロック暗号︵AEAD以外︶を選択した場合、TLS 1.1以降においてIVはTLSレコードプロトコルの送信者がランダムに選ぶ[16]。ランダムなIVは、BEAST攻撃への対策として有効である。一方、認証暗号で用いる共通鍵はTLSハンドシェイクプロトコルで共有されたmaster secretを用いる。

バージョン

[編集]

コンピュータの計算能力の向上とともに、認証の突破、暗号の解読、改竄も以前よりは容易に行えるようになり、セキュリティ確保のための技術も厳しさを増している。

2017年現在では、TLS 1.2 以上のバージョンの実装が推奨され、TLS 1.1 以下のサポートを停止するサイトも出てきている[17][18][19]。2021年3月にはRFC 8996により、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を無効にしない限りこの脆弱性の影響を受ける可能性を否定できない[20]。SSL 3.0以降に対応した実装が十分に普及したものとして、Internet Explorer 7やMozilla Firefox 2、Opera 9などは、初期状態でSSL 2.0を無効にしている[21][22][23]。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっている[24]。

SSL 2.0にはチェーン証明書がなく、ルートCAから発行したSSLサーバ証明書しか使うことができない。

2011年3月、RFC 6176 によって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から歴史的文書という扱いでRFC 6101として公開された。

2014年10月にSSL 3.0の仕様上の脆弱性︵POODLE攻撃︶が発見されたため、SSL 3.0への対応を打ち切り、TLS 1.0以降のみ対応への移行が望まれている。2015年6月、RFC 7568 によってSSL 3.0の使用は禁止された。

SSLについては、使うべきではない。

TLS 1.0

[編集]

IETFのTLSワーキンググループはRFC 2246としてTLS 1.0を公表した。TLS 1.0の標準化作業は1996年に開始され、年内に完了する予定だったが、いくつかの問題に阻まれ、公表は1999年まで遅延した。

TLS 1.0が提供する機能はSSL 3.0とあまり変わらないが、アルゴリズムやルートCAの自己署名証明書の取扱いなどの仕様の詳細が変更されたことに加え、これまであまり実装されていなかった選択肢のいくつかが必須と定められた。このため、TLS 1.0を実装した製品が普及するまでには、さらに数年を要した。

2021年3月、RFC 8996によりTLS 1.0を使用しないことが呼びかけられている。

なおTLS 1.0はSSL 3.0より新しい規格であることを示すため、ネゴシエーションにおけるバージョン番号は3.1となっている。

TLS 1.1

[編集]

2006年にRFC 4346としてTLS 1.1が制定された。TLS 1.0からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。特にCBC攻撃に対する耐性を上げるため、初期化ベクトルを明示的に指定することにし、さらにパディングの処理も改善された。また、予期せぬ回線クローズ後に、セッションを再開できるようになった。共通鍵暗号アルゴリズムとしてAESが選択肢に加わった[25]。

2021年3月、RFC 8996によりTLS 1.1を使用しないことが呼びかけられている。2024年10月より、WindowsはTLS 1.0、TLS 1.1をサポートしない旨を発表した[26]。

ネゴシエーションにおけるバージョン番号は3.2となっている。

TLS 1.2

[編集]

2008年8月にRFC 5246としてTLS 1.2が制定された。ハッシュのアルゴリズムにSHA-256が追加されたほか、ブロック暗号について、従来のCBCモードだけではなく、GCM、CCMといった認証付き暗号を用いたcipher suiteが利用可能となった。また、AESに関する記述がRFC 5246自体に含まれるようになった。

ネゴシエーションにおけるバージョン番号は3.3となっている。

TLS 1.3

[編集]

新たなTLSのバージョンとしてTLS 1.3が提案されてきたが[27]、IETFは2018年3月23日に、ドラフト28を標準規格として承認し[28][29]、同年8月10日にRFC 8446として公開した[30]。

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を策定しているRFC 5246では、暗号スイートを以下のフォーマットで表現している‥ 
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と呼ばれるもので、鍵共有の際クライアント、サーバがx、yをランダムに選び、gx、gyを計算し、これらに署名文をつけた上で交換しあう方式である。gx、gyにつける署名文を作成する署名方式は﹁***﹂の部分に記載されたものを使う。ECDHE-***はDHEの楕円DH版である。
●DH-***はFixed DHもしくはnon-interactive DHと呼ばれるもので、Diffie-Hellmanで用いるパラメータ︵クライアントのgx、サーバのgy︶がクライアントやサーバの公開鍵として認証局から公開鍵証明書を受け取っているケースのDiffie-Hellman鍵共有である。gx、gyに対する公開鍵証明書内の署名文を作成する署名方式は﹁***﹂の部分に記載されたものを使う。ECDH-*** (Fixed ECDH) はFixed DHの楕円DH版である。
●RSA-***はランダムに選んだ共有鍵をサーバの公開鍵でRSA暗号化し、暗号文を﹁***﹂で指定された署名方式で署名したものをClientKeyExchangeにおいてクライアントがサーバに送る方式である。︵ServerKeyExchangeでは何も送らない︶。
いずれの鍵共有においても共有された鍵 (premaster secret) を用いた擬似ランダム関数にクライアントが選んだ乱数とサーバが選んだ乱数等を並べたものを入力する事で最終的なmaster secretを得る。これによりリプレイ攻撃を防いでいる。

これらの鍵共有方式の対応状況は以下のとおりである‥
TLSの各バージョンで使用できる認証・鍵交換アルゴリズム
アルゴリズム SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 状況
RSA 対応 対応 対応 対応 対応 非対応 TLS 1.2向けにRFCで定義済み
DH-RSA 非対応 対応 対応 対応 対応 非対応
DHE-RSA (forward secrecy) 非対応 対応 対応 対応 対応 対応
ECDH-RSA 非対応 非対応 対応 対応 対応 非対応
ECDHE-RSA (forward secrecy) 非対応 非対応 対応 対応 対応 対応
DH-DSS 非対応 対応 対応 対応 対応 非対応
DHE-DSS (forward secrecy) 非対応 対応 対応 対応 対応 非対応[31]
ECDH-ECDSA 非対応 非対応 対応 対応 対応 非対応
ECDHE-ECDSA (forward secrecy) 非対応 非対応 対応 対応 対応 対応
PSK（英語版） 非対応 非対応 対応 対応 対応
PSK（英語版）-RSA 非対応 非対応 対応 対応 対応
DHE-PSK（英語版） (forward secrecy) 非対応 非対応 対応 対応 対応 対応
ECDHE-PSK（英語版） (forward secrecy) 非対応 非対応 対応 対応 対応 対応
SRP（英語版） 非対応 非対応 対応 対応 対応
SRP（英語版）-DSS 非対応 非対応 対応 対応 対応
SRP（英語版）-RSA 非対応 非対応 対応 対応 対応
KRB5 非対応 非対応 対応 対応 対応
DH-ANON（安全ではない） 非対応 対応 対応 対応 対応
ECDH-ANON（安全ではない） 非対応 非対応 対応 対応 対応
GOST R 34.10-94 / 34.10-2001[32] 非対応 非対応 対応 対応 対応 RFC草稿で提案中

事前共有鍵（英語版）を用いた TLS_PSK、Secure Remote Password protocol（英語版）を用いた TLS_SRP、ケルベロス認証を用いた KRB5 も存在する。

独立国家共同体のGOST規格によって規定された鍵共有アルゴリズムであるGOST R 34.10も提案されている（同じGOST規格による暗号化・改竄検出アリゴリズムとの組み合わせに限定）[32]。

認証暗号

[編集]

共通鍵暗号

[編集]

認証暗号に用いる共通鍵暗号として以下のものがある。

TLS/SSLの各バージョンで使用できる暗号化アルゴリズム
暗号化 プロトコルバージョン 状況
種類 アルゴリズム 暗号強度 (bit) SSL 2.0 SSL 3.0
[注 1][注 2][注 3][注 4]		 TLS 1.0
[注 1][注 3]		 TLS 1.1
[注 1]		 TLS 1.2
[注 1]		 TLS 1.3
ブロック暗号
（暗号利用モード） 		AES GCM[33][注 5] 256, 128 N/A N/A N/A N/A 安全 安全 TLS 1.2向けにRFCで定義済み
AES CCM[34][注 5] N/A N/A N/A N/A 安全 安全
AES CBC[注 6] N/A N/A 実装による 安全 安全 N/A
Camellia GCM[35][注 5] 256, 128 N/A N/A N/A N/A 安全 N/A
Camellia CBC[36][注 6] N/A N/A 実装による 安全 安全 N/A
ARIA GCM[37][注 5] 256, 128 N/A N/A N/A N/A 安全 N/A
ARIA CBC[37][注 6] N/A N/A 実装による 安全 安全 N/A
SEED CBC[38][注 6] 128 N/A N/A 実装による 安全 安全 N/A
3DES EDE CBC[注 6] 112[注 7] 安全ではない 安全ではない 強度不足、実装による 強度不足 強度不足 N/A
GOST 28147-89（英語版） CNT[32] 256 N/A N/A 安全 安全 安全 N/A RFC草稿で提案中
IDEA CBC[注 6][注 8] 128 安全ではない 安全ではない 実装による 安全 N/A N/A TLS 1.2で廃止
DES CBC[注 6][注 8] 056 安全ではない 安全ではない 安全ではない 安全ではない N/A N/A
040[注 9] 安全ではない 安全ではない 安全ではない N/A N/A N/A TLS 1.1以降で利用禁止
RC2 CBC[注 6] 040[注 9] 安全ではない 安全ではない 安全ではない N/A N/A N/A
ストリーム暗号 ChaCha20+Poly1305[41][注 5] 256 N/A N/A N/A N/A 安全 安全 TLS 1.2向けにRFCで定義済み
RC4[注 10] 128 安全ではない 安全ではない 安全ではない 安全ではない 安全ではない N/A 全バージョンにおいて利用禁止
040[注 9] 安全ではない 安全ではない 安全ではない N/A N/A N/A
暗号化なし Null[注 11] - N/A 安全ではない 安全ではない 安全ではない 安全ではない N/A TLS 1.2向けにRFCで定義済み


(一)^ abcd再ネゴシエーション脆弱性への対応のため、RFC 5746 への対応が必要

(二)^ RFC 5746 への対応はSSL 3.0の仕様を逸脱するが、ほとんどの実装では対応したうえで仕様からの逸脱にも対処している

(三)^ abSSL 3.0およびTLS 1.0はBEAST攻撃に対して脆弱であり、クライアント側、サーバ側での対応が必要。#ウェブブラウザ節を参照

(四)^ SSL 3.0はPOODLE攻撃に対して脆弱であり、クライアント側、サーバ側での対応が必要。#ウェブブラウザ節を参照

(五)^ abcdeGCM、CCMなどのAEAD︵認証付き暗号モード︶は、TLS 1.2以降のみで利用可能

(六)^ abcdefghCBCモードは、サイドチャネル攻撃への対処が不十分な実装ではLucky Thirteen攻撃に対して脆弱である

(七)^ 3DESの鍵長は168ビットであるが実質的な暗号強度は112ビットであり[39]、2013年時点で最低限必要とされる128ビットに不足している[40]

(八)^ abIDEA、DESはTLS 1.2で廃止された

(九)^ abc40ビットのセキュリティ強度を持つCipher Suiteは、アメリカ合衆国による高強度暗号アルゴリズムの輸出規制を回避するために設計された。これらはTLS 1.1以降では利用が禁止されている。

(十)^ RFC 7465 により、すべてのバージョンのTLSにおいてRC4の利用は禁止された︵RC4攻撃︶

(11)^ 認証のみで暗号化は行われない。


AES CBCはTLS 1.0を定義する RFC 2246 には含まれていないが、RFC 3268 で追加された。TLS 1.1を定義する RFC 4346 からは RFC 3268 が参照されており、さらにTLS 1.2では定義である RFC 5246 にAES CBCに関する記述が取り込まれた。また、認証付き暗号によるAES GCM (RFC 5288, RFC 5289)、AES CCM (RFC 6655, RFC 7251) が追加されている。IDEA CBC、DES CBCはTLS 1.2で廃止された︵RFC 5469 に解説がある︶。

ブロック暗号のCBCモードでの利用については、TLS 1.0以前においてBEAST攻撃と呼ばれる攻撃が可能であることが明らかとなっており、クライアント側、サーバ側での対応が必要とされている。TLS 1.1以降ではこの攻撃への根本的な対処として初期化ベクトルを明示的に指定し、パディングの処理が改善された。ブロック暗号であってもGCM、CCMなどの認証付き暗号を用いる場合にはこれらの攻撃を受けない。

ストリーム暗号であるRC4は前述のBEAST攻撃を受けることはないが、RC4には仕様上の脆弱性が存在する︵RC4攻撃︶。2015年2月、TLSのすべてのバージョンにおいてRC4の利用を禁止する RFC 7465 が公開された。ストリーム暗号であるChaCha20と認証のためのPoly1305を組み合わせたChaCha20+Poly1305が RFC 7905 として標準化されている。

いくつかの国家標準に基づく暗号化アルゴリズムもTLSで利用可能であり、日本のCRYPTRECによる推奨暗号であるCamellia︵CBCモード‥RFC 4132、RFC 5932、RFC 6367、GCM‥RFC 6367︶、韓国の情報通信標準規格に採用されているSEED︵CBCモード‥RFC 4162︶、ARIA︵CBCモードおよびGCM‥RFC 6209︶が追加されている。また、独立国家共同体のGOST規格によって規定された暗号化アルゴリズムであるGOST 28147-89も提案されている[32]。

SSLが設計された当時は、アメリカ合衆国によって高強度暗号アルゴリズムの輸出が規制されていた。そのため、全世界で共通して利用できるアルゴリズムとして、DES・RC2・RC4に関して暗号強度を40ビットに制限したものが導入されていた。これらはTLS 1.1以降では利用が禁止されている。

また、鍵共有のみを行い暗号化は行わないこと (NULL) も可能であるが、平文でのやりとりとなることから安全とはみなされていない。

MAC

[編集]

TLS/SSLの各バージョンで使用できるMACの選択肢は以下のとおりである。下欄の「AEAD」（Authenticated Encryption with Associated Data、認証暗号）は、共通鍵暗号として認証暗号を選んでいるのでMACを用いない事を意味する。

TLS/SSLの各バージョンで使用できる改竄検出
アルゴリズム SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 状況
HMAC-MD5 対応 対応 対応 対応 対応 非対応 TLS 1.2向けにRFCで定義済み
HMAC-SHA1 非対応 対応 対応 対応 対応 非対応
HMAC-SHA256/384 非対応 非対応 非対応 非対応 対応 非対応
AEAD 非対応 非対応 非対応 非対応 対応 対応
GOST 28147-89 IMIT（英語版）[32] 非対応 非対応 対応 対応 対応 非対応 RFC草稿で提案中
GOST R 34.11-94（英語版）[32] 非対応 非対応 対応 対応 対応 非対応

独立国家共同体のGOST規格によって規定されたアルゴリズムであるGOST 28147-89に基づくMACおよび、GOST R 34.11も提案されている（同じGOST規格による鍵共有・暗号化アリゴリズムとの組み合わせに限定）[32]。

実装

[編集]

ウェブサイト

[編集]
ウェブサイトにおけるTLS/SSLの対応状況
プロトコル ウェブサイトにおけるサポート[42] セキュリティ[42][43]
SSL 2.0 0.2% 安全ではない
SSL 3.0 1.7% 安全ではない[44]
TLS 1.0 29.5% 暗号アルゴリズム[注 1]および脆弱性への対処[注 2]による
TLS 1.1 31.8% 暗号アルゴリズム[注 1]および脆弱性への対処[注 2]による
TLS 1.2 99.9% 暗号アルゴリズム[注 1]および脆弱性への対処[注 2]による
TLS 1.3 66.2% 安全
注
  1. ^ a b c #暗号スイートを参照のこと
  2. ^ a b c #ウェブブラウザおよび#TLS/SSLの既知の脆弱性を参照のこと

ウェブブラウザ

[編集]

2021年1月現在、主要なウェブブラウザの最新版ではTLS 1.2、1.3が既定で有効であるが、過去のバージョンのOS向けなどサポートが継続しているウェブブラウザのいくつかのバージョンではそうではない。

●TLS 1.3に対応しているが既定で無効‥Internet Explorer 11︵Windows 10 バージョン1903以降︶
●TLS 1.3に未対応‥Internet Explorer 11︵Windows 10 バージョン1903より前︶
TLS 1.0、1.1は脆弱性が危惧され[45]、2020年から無効化が実施され始めている[46]。

既知の脆弱性のいくつかへの対応は十分ではない。

●POODLE攻撃への対応‥いくつかのブラウザではTLS_FALLBACK_SCSVを実装済みでSSL 3.0へのフォールバックを抑止することが可能となっているが、これはクライアント側だけでなくサーバ側での対応も必要である。SSL 3.0そのものの無効化、"anti-POODLE record splitting"の実装、あるいはSSL 3.0におけるCBCモードのcipher suiteの無効化が根本的な対策となる。
●Google Chrome‥完了︵バージョン33においてTLS_FALLBACK_SCSVを実装、バージョン39においてSSL 3.0へのフォールバックを無効化、バージョン40においてSSL 3.0を既定で無効化。バージョン44においてSSL 3.0のサポートを廃止︶
●Mozilla Firefox‥完了︵バージョン34においてSSL 3.0を既定で無効化およびSSL 3.0へのフォールバックを無効化、バージョン35においてTLS_FALLBACK_SCSVを実装。延長サポート版でもESR 31.3においてSSL 3.0を無効化およびTLS_FALLBACK_SCSVを実装。バージョン39においてSSL 3.0のサポートを廃止︶
●Internet Explorer‥部分的︵バージョン11のみ、2015年2月のアップデートにおいて保護モードにおけるSSL 3.0へのフォールバックを既定で無効化。2015年4月にSSL 3.0自体を既定で無効化。バージョン10以前では対策は講じられていない︶
●Opera‥完了︵バージョン20においてTLS_FALLBACK_SCSVを実装、バージョン25において"anti-POODLE record splitting"を実装、バージョン27においてSSL 3.0を既定で無効化。バージョン31においてSSL 3.0のサポートを廃止︶
●Safari‥完了︵OS X v10.8以降およびiOS 8.1以降のみ、POODLEへの対策としてSSL 3.0においてCBCモードのcipher suiteを無効化した。これによりPOODLEの影響を受けることはなくなるが、SSL 3.0においてCBCモードを無効化したことで、脆弱性が指摘されているRC4しか利用できなくなるという問題が生じている。OS X v10.11およびiOS 9においてSSL 3.0のサポートを廃止︶
●RC4攻撃への対応
●Google Chromeでは、バージョン43以降はホストがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限りRC4を用いたCipher Suiteがフォールバックとして利用されるようになった。バージョン48以降では、RC4を用いたCipher Suiteのすべてが既定で無効化された。
●Firefoxでは、バージョン36以降はホストがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限りRC4を用いたCipher Suiteがフォールバックとして利用されるようになった。バージョン44以降では、RC4を用いたCipher Suiteのすべてが既定で無効化された。
●Operaでは、バージョン30以降はホストがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限りRC4を用いたCipher Suiteがフォールバックとして利用されるようになった。バージョン35以降では、RC4を用いたCipher Suiteのすべてが既定で無効化された。
●Windows 7 / Server 2008 R2およびWindows 8 / Server 2012向けのInternet Explorerでは、RC4の優先度を最低としている。Windows 8.1 / Server 2012 R2向けのInternet Explorer 11およびWindows Phone 8.1向けのInternet Explorer Mobile 11およびWindows 10向けのEdgeでは、ホストが他のアルゴリズムに非対応の場合のフォールバックを除きRC4を無効としている︵Windows 7 / Server 2008 R2およびWindows 8 / Server 2012向けのInternet Explorerでもレジストリからフォールバックを除きRC4を無効化することが可能︶。2016年8月の月例アップデートにおいて、Inter Explorer 11およびEdgeにおいてRC4を用いたCipher Suiteのすべてが既定で無効化。
●FREAK攻撃への対応:
●Android4以前の標準ブラウザはFREAK攻撃に対して脆弱である。
●Internet Explorer 11 MobileはFREAK攻撃に対して脆弱である。
●Google Chrome︵Windows版を除く︶、Internet Explorer、Safari︵デスクトップ版、iOS版︶、Opera︵Windows版を除く︶はFREAK攻撃に対して対応済みである。
●Mozilla Firefox、Google Chrome︵Windows版︶、Opera︵Windows版︶はFREAK攻撃の影響を受けない。

ウェブブラウザにおけるTLS/SSLの対応状況の変化
ウェブブラウザ バージョン プラットフォーム SSLプロトコル TLSプロトコル 証明書のサポート 脆弱性への対応[注 1] プロトコル選択[注 2]
SSL 2.0
(安全ではない) 		SSL 3.0
(安全ではない) 		TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 EV[注 3][47] SHA-2[48] ECDSA[49] BEAST
[注 4] 		CRIME
[注 5] 		POODLE
(SSLv3)
[注 6] 		RC4
[注 7] 		FREAK
[50][51] 		Logjam
Google Chrome
(Chrome for Android)
[注 8]
[注 9] 		1–9 Windows (7以降)
macOS (OS X v10.10以降)
Linux
Android (4.4以降)
iOS (10.0以降)
ChromeOS 		既定で無効 既定で有効 対応 非対応 非対応 非対応 対応
(デスクトップ版) 		OSがSHA-2対応の場合[48] OSがECC対応の場合[49] 影響なし[56] 脆弱
(HTTPS) 		脆弱 脆弱 脆弱
(Windows版を除く) 		脆弱 可[注 10]
10–20 非対応[57] 既定で有効 対応 非対応 非対応 非対応 対応
(デスクトップ版) 		OSがSHA-2対応の場合[48] OSがECC対応の場合[49] 影響なし 脆弱
(HTTPS/SPDY) 		脆弱 脆弱 脆弱
(Windows版を除く) 		脆弱 可[注 10]
21 非対応 既定で有効 対応 非対応 非対応 非対応 対応
(デスクトップ版) 		OSがSHA-2対応の場合[48] OSがECC対応の場合[49] 影響なし 対策済[58] 脆弱 脆弱 脆弱
(Windows版を除く) 		脆弱 可[注 10]
22–25 非対応 既定で有効 対応 対応[59] 非対応[59][60][61][62] 非対応 対応
(デスクトップ版) 		OSがSHA-2対応の場合[48] OSがECC対応の場合[49] 影響なし 対策済 脆弱 脆弱 脆弱
(Windows版を除く) 		脆弱 一時的[注 11]
26–29 非対応 既定で有効 対応 対応 非対応 非対応 対応
(デスクトップ版) 		OSがSHA-2対応の場合[48] OSがECC対応の場合[49] 影響なし 対策済 脆弱 脆弱 脆弱
(Windows版を除く) 		脆弱 一時的[注 11]
30–32 非対応 既定で有効 対応 対応 対応[60][61][62] 非対応 対応
(デスクトップ版) 		OSがSHA-2対応の場合[48] OSがECC対応の場合[49] 影響なし 対策済 脆弱 脆弱 脆弱
(Windows版を除く) 		脆弱 一時的[注 11]
33–37 非対応 既定で有効 対応 対応 対応 非対応 対応
(デスクトップ版) 		OSがSHA-2対応の場合[48] OSがECC対応の場合[49] 影響なし 対策済 部分的に対策済[注 12] 優先度最低[65][66][67] 脆弱
(Windows版を除く) 		脆弱 一時的[注 11]
38, 39 非対応 既定で有効 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 部分的に対策済 優先度最低 脆弱
(Windows版を除く) 		脆弱 一時的[注 11]
40 非対応 既定で無効[64][68] 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 対策済[注 13] 優先度最低 脆弱
(Windows版を除く) 		脆弱 可[注 14]
41, 42 非対応 既定で無効 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 対策済 優先度最低 対策済 脆弱 可[注 14]
43 非対応 既定で無効 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 対策済 フォールバックの場合のみ[注 15][69] 対策済 脆弱 可[注 14]
44–47 非対応 非対応[70] 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 影響なし フォールバックの場合のみ[注 15] 対策済 対策済[71] 一時的[注 11]
48, 49 非対応 非対応 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 影響なし 既定で無効[注 16][72][73] 対策済 対策済 一時的[注 11]
50–53 非対応 非対応 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 対応 影響なし 対策済 影響なし 既定で無効[注 16][72][73] 対策済 対策済 一時的[注 11]
54–66 非対応 非対応 対応 対応 対応 既定で無効
(ドラフト版) 		対応
(デスクトップ版) 		対応 対応 影響なし 対策済 影響なし 既定で無効[注 16][72][73] 対策済 対策済 一時的[注 11]
67–69 非対応 非対応 対応 対応 対応 対応
(ドラフト版) 		対応
(デスクトップ版) 		対応 対応 影響なし 対策済 影響なし 既定で無効[注 16][72][73] 対策済 対策済 一時的[注 11]
70–79 80 非対応 非対応 対応 対応 対応 対応 対応
(デスクトップ版) 		対応 対応 影響なし 対策済 影響なし 既定で無効[注 16][72][73] 対策済 対策済 一時的[注 11]
Android ブラウザ[74] Android 1.0, 1.1, 1.5, 1.6, 2.0–2.1, 2.2–2.2.3 非対応 既定で有効 対応 非対応 非対応 非対応 不明 非対応 非対応 不明 不明 脆弱 脆弱 脆弱 脆弱 不可
Android 2.3–2.3.7, 3.0–3.2.6, 4.0–4.0.4 非対応 既定で有効 対応 非対応 非対応 非対応 不明 対応[48] Android 3.0以降[75] 不明 不明 脆弱 脆弱 脆弱 脆弱 不可
Android 4.1–4.3.1, 4.4–4.4.4 非対応 既定で有効 対応 既定で無効[76] 既定で無効[76] 非対応 不明 対応 対応[49] 不明 不明 脆弱 脆弱 脆弱 脆弱 不可
Android 5.0-5.0.2 非対応 既定で有効 対応 対応[76][77] 対応[76][77] 非対応 不明 対応 対応 不明 不明 脆弱 脆弱 脆弱 脆弱 不可
Android 5.1-5.1.1 非対応 不明 対応 対応 対応 非対応 不明 対応 対応 不明 不明 影響なし フォールバックの場合のみ[注 15] 対策済 対策済 不可
Android 6.0-7.1.2 非対応 不明 対応 対応 対応 非対応 不明 対応 対応 不明 不明 影響なし 既定で無効 対策済 対策済 不可
Android 8.0-9.0 非対応 非対応[78] 対応 対応 対応 非対応 不明 対応 対応 不明 不明 影響なし 既定で無効 対策済 対策済 不可
Android 10.0 非対応 非対応 対応 対応 対応 対応 不明 対応 対応 不明 不明 影響なし 既定で無効 対策済 対策済 不可
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない) 		SSL 3.0
(安全ではない) 		TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 EV証明書 SHA-2証明書 ECDSA証明書 BEAST CRIME POODLE
(SSLv3) 		RC4 FREAK Logjam プロトコル選択
Mozilla Firefox
(Firefox for Mobile)
[注 17] 		1.0 Windows (7以降)
macOS (OS X v10.9以降)
Linux
Android (4.1以降)
Firefox OS
iOS (10.3以降)
Maemo

ESR:
Windows (7以降)
macOS (OS X v10.9以降)
Linux 		既定で有効[79] 既定で有効[79] 対応[79] 非対応 非対応 非対応 非対応 対応[48] 非対応 影響なし[80] 影響なし 脆弱 脆弱 影響なし 脆弱 可[注 10]
1.5 既定で有効 既定で有効 対応 非対応 非対応 非対応 非対応 対応 非対応 影響なし 影響なし 脆弱 脆弱 影響なし 脆弱 可[注 10]
2 既定で無効[79][81] 既定で有効 対応 非対応 非対応 非対応 非対応 対応 対応[49] 影響なし 影響なし 脆弱 脆弱 影響なし 脆弱 可[注 10]
3–7 既定で無効 既定で有効 対応 非対応 非対応 非対応 対応 対応 対応 影響なし 影響なし 脆弱 脆弱 影響なし 脆弱 可[注 10]
8–10
ESR 10 		非対応[81] 既定で有効 対応 非対応 非対応 非対応 対応 対応 対応 影響なし 影響なし 脆弱 脆弱 影響なし 脆弱 可[注 10]
11–14 非対応 既定で有効 対応 非対応 非対応 非対応 対応 対応 対応 影響なし 脆弱
(SPDY)[58] 		脆弱 脆弱 影響なし 脆弱 可[注 10]
15–22
ESR 17.0–17.0.10 		非対応 既定で有効 対応 非対応 非対応 非対応 対応 対応 対応 影響なし 対策済 脆弱 脆弱 影響なし 脆弱 可[注 10]
ESR 17.0.11 非対応 既定で有効 対応 非対応 非対応 非対応 対応 対応 対応 影響なし 対策済 脆弱 優先度最低[82][83] 影響なし 脆弱 可[注 10]
23 非対応 既定で有効 対応 既定で無効[84] 非対応 非対応 対応 対応 対応 影響なし 対策済 脆弱 脆弱 影響なし 脆弱 可[注 18]
24, 25.0.0
ESR 24.0–24.1.0 		非対応 既定で有効 対応 既定で無効 既定で無効[86] 非対応 対応 対応 対応 影響なし 対策済 脆弱 脆弱 影響なし 脆弱 可[注 18]
25.0.1, 26
ESR 24.1.1–24.8.1 		非対応 既定で有効 対応 既定で無効 既定で無効 非対応 対応 対応 対応 影響なし 対策済 脆弱 優先度最低[82][83] 影響なし 脆弱 可[注 18]
27–33
ESR 31.0–31.2 		非対応 既定で有効 対応 対応[87][88] 対応[89][88] 非対応 対応 対応 対応 影響なし 対策済 脆弱 優先度最低 影響なし 脆弱 可[注 18]
34, 35
ESR 31.3–31.7 		非対応 既定で無効[90][91] 対応 対応 対応 非対応 対応 対応 対応 影響なし 対策済 対策済[注 19] 優先度最低 影響なし 脆弱 可[注 18]
ESR 31.8 非対応 既定で無効 対応 対応 対応 非対応 対応 対応 対応 影響なし 対策済 対策済 優先度最低 影響なし 対策済[94] 可[注 18]
36–38
ESR 38.0 		非対応 既定で無効 対応 対応 対応 非対応 対応 対応 対応 影響なし 対策済 対策済 フォールバックの場合のみ[注 15][95] 影響なし 脆弱 可[注 18]
ESR 38.1–38.8 非対応 既定で無効 対応 対応 対応 非対応 対応 対応 対応 影響なし 対策済 対策済 フォールバックの場合のみ[注 15] 影響なし 対策済[94] 可[注 18]
39–43 非対応 非対応[96] 対応 対応 対応 非対応 対応 対応 対応 影響なし 対策済 影響なし フォールバックの場合のみ[注 15] 影響なし 対策済[94] 可[注 18]
44–48
ESR 45.0 		非対応 非対応 対応 対応 対応 非対応 対応 対応 対応 影響なし 対策済 影響なし 既定で無効[注 16][97][98][99][100] 影響なし 対策済 可[注 18]
49–59
ESR 52 		非対応 非対応 対応 対応 対応 既定で無効
(実験的)[101] 		対応 対応 対応 影響なし 対策済 影響なし 既定で無効[注 16]/ 影響なし 対策済 可[注 18]
60–62
ESR 60 		非対応 非対応 対応 対応 対応 対応(ドラフト版) 対応 対応 対応 影響なし 対策済 影響なし 既定で無効[注 16]/ 影響なし 対策済 可[注 18]
63–73
ESR 68.0–68.5 		非対応 非対応 対応 対応 対応 対応 対応 対応 対応 影響なし 対策済 影響なし 既定で無効[注 16]/ 影響なし 対策済 可[注 18]
ESR 68.6
74 非対応 非対応 既定で無効 既定で無効 対応 対応 対応 対応 対応 影響なし 対策済 影響なし 既定で無効[注 16]/ 影響なし 対策済 可[注 18]
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない) 		SSL 3.0
(安全ではない) 		TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 EV証明書 SHA-2証明書 ECDSA証明書 BEAST CRIME POODLE
(SSLv3) 		RC4 FREAK Logjam プロトコル選択
Microsoft Internet Explorer
[注 20] 		1 Windows 3.1, 95, NT[注 21],[注 22]
System 7, Mac OS 		TLS/SSL非対応
2 対応 非対応 非対応 非対応 非対応 非対応 非対応 非対応 非対応 SSLv3/TLSv1非対応 脆弱 脆弱 脆弱 不明
3 対応 対応[104] 非対応 非対応 非対応 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 N/A
4, 5 Windows 3.1, 95, 98, NT[注 21],[注 22]
System 7, Mac OS, Mac OS X
Solaris
HP-UX 		既定で有効 既定で有効 既定で無効[104] 非対応 非対応 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 可[注 10]
6 Windows 98, Me
Windows NT[注 21], 2000[注 22] 		既定で有効 既定で有効 既定で無効[104] 非対応 非対応 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 可[注 10]
6 Windows XP[注 22] 既定で有効 既定で有効 既定で無効 非対応 非対応 非対応 非対応 対応[注 23][105] 非対応 対策済 影響なし 脆弱 脆弱 脆弱 脆弱 可[注 10]
6 Server 2003[注 22] 既定で有効 既定で有効 既定で無効 非対応 非対応 非対応 非対応 対応[注 23][105] 非対応 対策済 影響なし 脆弱 脆弱 対策済[108] 対策済[109] 可[注 10]
7, 8 Windows XP[注 22] 既定で無効[110] 既定で有効 対応[110] 非対応 非対応 非対応 対応 対応[注 23][105] 非対応 対策済 影響なし 脆弱 脆弱 脆弱 脆弱 可[注 10]
7, 8 Server 2003[注 22] 既定で無効[110] 既定で有効 対応[110] 非対応 非対応 非対応 対応 対応[注 23][105] 非対応 対策済 影響なし 脆弱 脆弱 対策済[108] 対策済[109] 可[注 10]
7, 8, 9[111] Windows Vista 既定で無効[110] 既定で有効 対応[110] 非対応 非対応 非対応 対応 対応[注 23][105] 対応[49] 対策済 影響なし 脆弱 脆弱 対策済[108] 対策済[109] 可[注 10]
Server 2008
8, 9, 10 Windows 7 既定で無効 既定で有効 対応 既定で無効[112] 既定で無効[112] 非対応 対応 対応 対応 対策済 影響なし 脆弱 優先度最低[113][注 24] 対策済[108] 対策済[109] 可[注 10]
Server 2008 R2
10 Windows 8 既定で無効 既定で有効 対応 既定で無効[112] 既定で無効[112] 非対応 対応 対応 対応 対策済 影響なし 脆弱 優先度最低[113][注 24] 対策済[108] 対策済[109] 可[注 10]
10 Server 2012
11 Windows 7 既定で無効 既定で無効[注 25] 対応 対応[115] 対応[115] 非対応 対応 対応 対応 対策済 影響なし 対策済[注 25] 優先度最低[113][注 24] 対策済[108] 対策済[109] 可[注 10]
Server 2008 R2
11 Windows 8.1 既定で無効 既定で無効[注 25] 対応 対応[115] 対応[115] 非対応 対応 対応 対応 対策済 影響なし 対策済[注 25] 既定で無効[注 16][119][120]}} 対策済[108] 対策済[109] 可[注 10]
Server 2012 R2
11 Windows 10 既定で無効 既定で無効 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 可[注 10]
Server 2016
Microsoft Edge[注 26]
およびInternet Explorer (フォールバックとして)
[注 20] 		IE 11 12–13[注 27] Windows 10
v1507–v1511 		既定で無効 既定で無効 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 可[注 10]
Windows 10
LTSB 2015 (v1507)
11 14–18 Windows 10
v1607–v1803 		非対応[122] 既定で無効 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 可[注 10]
11 18 Windows 10
v1809 		非対応 既定で無効 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 可[注 10]
11 18 Windows 10
v1903 		非対応 既定で無効 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 可[注 10]
11 Windows 10
LTSB 2016 (v1607) 		非対応 既定で無効 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 可[注 10]
11 Windows Server 2016
v1607 (LTSB) 		非対応 既定で無効 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 可[注 10]
11 Windows Server 2019
v1809 (LTSC) 		非対応 既定で無効 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 可[注 10]
11 18 Windows 10
v1909 		非対応 既定で無効 対応 対応 対応 既定で無効
(実験的) 		対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 可[注 10]
Microsoft Internet Explorer Mobile
[注 20] 		7, 9 Windows Phone 7, 7.5, 7.8 既定で無効[110] 既定で有効 対応 非対応
[要出典] 		非対応
[要出典] 		非対応 非対応
[要出典] 		対応 対応[75] 不明 影響なし 脆弱 脆弱 脆弱 脆弱 要サードパーティ製ツール[注 28]
10 Windows Phone 8 既定で無効 既定で有効 対応 既定で無効[124] 既定で無効[124] 非対応 非対応
[要出典] 		対応 対応[125] 対策済 影響なし 脆弱 脆弱 脆弱 脆弱 要サードパーティ製ツール[注 28]
11 Windows Phone 8.1 既定で無効 既定で有効 対応 対応[126] 対応[126] 非対応 非対応
[要出典] 		対応 対応 対策済 影響なし 脆弱 フォールバックの場合のみ[注 15][119][120] 脆弱 脆弱 要サードパーティー製ツール[注 28]
Microsoft Edge
[注 20] 		13[注 26] Windows 10 Mobile
v1511 		既定で無効 既定で無効 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 不可
14, 15 Windows 10 Mobile
v1607–v1709 		非対応[122] 既定で無効 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済 既定で無効[注 16] 対策済 対策済 不可
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない) 		SSL 3.0
(安全ではない) 		TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 EV証明書 SHA-2証明書 ECDSA証明書 BEAST CRIME POODLE
(SSLv3) 		RC4 FREAK Logjam プロトコル選択
Opera
(Opera Mobile)
(Prestoおよびそれ以前)
[注 29] 		1, 2 Windows
OS X
Linux
Android
Symbian S60
Maemo
Windows Mobile 		TLS/SSL非対応[127]
3 対応[128] 非対応 非対応 非対応 非対応 非対応 非対応 非対応 非対応 SSLv3/TLSv1非対応 脆弱 不明 不明 N/A
4 対応 対応[129] 非対応 非対応 非対応 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 不明 不明 不明
5 既定で有効 既定で有効 対応[130] 非対応 非対応 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 不明 不明 可[注 10]
6, 7 既定で有効 既定で有効 対応[130] 非対応 非対応 非対応 非対応 対応[48] 非対応 脆弱 影響なし 脆弱 脆弱 不明 不明 可[注 10]
8 既定で有効 既定で有効 対応 既定で無効[131] 非対応 非対応 非対応 対応 非対応 脆弱 影響なし 脆弱 脆弱 不明 不明 可[注 10]
9 既定で無効[132] 既定で有効 対応 対応 非対応 非対応 v9.5より対応
(デスクトップ版) 		対応 非対応 脆弱 影響なし 脆弱 脆弱 不明 不明 可[注 10]
10–11.52 非対応[133] 既定で有効 対応 既定で無効 既定で無効[133] 非対応 対応
(デスクトップ版) 		対応 非対応 脆弱 影響なし 脆弱 脆弱 不明 不明 可[注 10]
11.60–11.64 非対応 既定で有効 対応 既定で無効 既定で無効 非対応 対応
(デスクトップ版) 		対応 非対応 対策済[134] 影響なし 脆弱 脆弱 不明 不明 可[注 10]
12–12.14 非対応 既定で無効[注 30] 対応 既定で無効 既定で無効 非対応 対応
(デスクトップ版) 		対応 非対応 対策済 影響なし 対策済[注 30] 脆弱 不明 対策済[136] 可[注 10]
12.15–12.17 非対応 既定で無効 対応 既定で無効 既定で無効 非対応 対応
(デスクトップ版) 		対応 非対応 対策済 影響なし 対策済 部分的に対策済[137][138] 不明 対策済[136] 可[注 10]
12.18 非対応 既定で無効 対応 対応[139] 対応[139] 非対応 対応
(デスクトップ版) 		対応 対応[139] 対策済 影響なし 対策済 既定で無効[注 16][139] 対策済[139] 対策済[136] 可[注 10]
Opera
(Opera Mobile)
(WebKit/Blink)
[注 31] 		14–16 Windows (7以降)
macOS (Mac OS X v10.10以降)
Linux
Android (4.4以降) 		非対応 既定で有効 対応 対応[142] 非対応[142] 非対応 対応
(デスクトップ版) 		OSがSHA-2対応の場合[48] OSがECC対応の場合[49] 影響なし 対策済 脆弱 脆弱 脆弱
(Windows版を除く) 		脆弱 一時的[注 11]
17–19 非対応 既定で有効 対応 対応[143] 対応[143] 非対応 対応
(デスクトップ版) 		OSがSHA-2対応の場合[48] OSがECC対応の場合[49] 影響なし 対策済 脆弱 脆弱 脆弱
(Windows版を除く) 		脆弱 一時的[注 11]
20–24 非対応 既定で有効 対応 対応 対応 非対応 対応
(デスクトップ版) 		OSがSHA-2対応の場合[48] OSがECC対応の場合[49] 影響なし 対策済 部分的に対策済[注 32] 優先度最低[144] 脆弱
(Windows版を除く) 		脆弱 一時的[注 11]
25, 26 非対応 既定で有効[注 33] 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 対策済[注 34] 優先度最低 脆弱
(Windows版を除く) 		脆弱 一時的[注 11]
27 非対応 既定で無効[68] 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 対策済[注 35] 優先度最低 脆弱
(Windows版を除く) 		脆弱 可[注 36]
(デスクトップ版)
28, 29 非対応 既定で無効 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 対策済 優先度最低 対策済 脆弱 可[注 36]
(デスクトップ版)
30 非対応 既定で無効 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 対策済 フォールバックの場合のみ[注 15][69] 対策済 対策済[136] 可[注 36]
(デスクトップ版)
31–34 非対応 非対応[70] 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 影響なし フォールバックの場合のみ[注 15][69] 対策済 対策済 一時的[注 11]
35, 36 非対応 非対応 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 OSがECC対応の場合[49] 影響なし 対策済 影響なし 既定で無効[注 16][72][73] 対策済 対策済 一時的[注 11]
37–40 非対応 非対応 対応 対応 対応 非対応 対応
(デスクトップ版) 		対応 対応 影響なし 対策済 影響なし 既定で無効[注 16][72][73] 対策済 対策済 一時的[注 11]
41–56 非対応 非対応 対応 対応 対応 既定で無効
(ドラフト版) 		対応
(デスクトップ版) 		対応 対応 影響なし 対策済 影響なし 既定で無効[注 16][72][73] 対策済 対策済 一時的[注 11]
57–66 67 非対応 非対応 対応 対応 対応 対応 対応
(デスクトップ版) 		対応 対応 影響なし 対策済 影響なし 既定で無効[注 16][72][73] 対策済 対策済 一時的[注 11]
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない) 		SSL 3.0
(安全ではない) 		TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 EV証明書 SHA-2証明書 ECDSA証明書 BEAST CRIME POODLE
(SSLv3) 		RC4 FREAK Logjam プロトコル選択
Apple Safari
[注 37] 		1 Mac OS X v10.2, v10.3 非対応[146] 対応 対応 非対応 非対応 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 不可
2–5 Mac OS X v10.4, v10.5, Windows XP 非対応 対応 対応 非対応 非対応 非対応 v3.2以降 非対応 非対応 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 不可
3–5 Windows Vista, 7 非対応 対応 対応 非対応 非対応 非対応 v3.2以降 非対応 対応[75] 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 不可
4–6 Mac OS X v10.6, v10.7 非対応 対応 対応 非対応 非対応 非対応 対応 対応[48] 対応[49] 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 不可
6 OS X v10.8 非対応 対応 対応 非対応 非対応 非対応 対応 対応 対応[49] 対策済[注 38] 影響なし 対策済[注 39] 脆弱[注 39] 対策済[152] 脆弱 不可
7, 9 OS X v10.9 非対応 対応 対応 対応[153] 対応[153] 非対応 対応 対応 対応 対策済[148] 影響なし 対策済[注 39] 脆弱[注 39] 対策済[152] 脆弱 不可
8 9 OS X v10.10 非対応 対応 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済[注 39] 優先度最低[154][注 39] 対策済[152] 対策済[155] 不可
10
9-11 OS X v10.11 非対応 非対応 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 影響なし 優先度最低 対策済 対策済 不可
10-12 macOS 10.12 非対応 非対応 対応 対応 対応 不明 対応 対応 対応 対策済 影響なし 影響なし 不明 対策済 対策済 不可
11, 12 13 macOS 10.13 非対応 非対応 対応 対応 対応 不明 対応 対応 対応 対策済 影響なし 影響なし 不明 対策済 対策済 不可
12 13 macOS 10.14 非対応 非対応 対応 対応 対応 対応
(mac OS 10.14.4以降) 		対応 対応 対応 対策済 影響なし 影響なし 不明 対策済 対策済 不可
13 macOS 10.15 非対応 非対応 対応 対応 対応 対応 対応 対応 対応 対策済 影響なし 影響なし 不明 対策済 対策済 不可
Safari
(モバイル)
[注 40] 		3 iPhone OS 1, 2 非対応[159] 対応 対応 非対応 非対応 非対応 非対応 非対応 不明 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 不可
4, 5 iPhone OS 3, iOS 4 非対応 対応 対応 非対応 非対応 非対応 対応[160] 対応 iOS 4以降[75] 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 不可
5, 6 iOS 5, 6 非対応 対応 対応 対応[156] 対応[156] 非対応 対応 対応 対応 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 不可
7 iOS 7 非対応 対応 対応 対応 対応 非対応 対応 対応 対応[161] 対策済[162] 影響なし 脆弱 脆弱 脆弱 脆弱 不可
8 iOS 8 非対応 対応 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 対策済[注 39] 優先度最低[163][注 39] 対策済[164] 対策済[165] 不可
9 iOS 9 非対応 非対応 対応 対応 対応 非対応 対応 対応 対応 対策済 影響なし 影響なし 優先度最低 対策済 対策済 不可
10-11 iOS 10, 11 非対応 非対応 対応 対応 対応 不明 対応 対応 対応 対策済 影響なし 影響なし 非対応 対策済 対策済 不可
12 iOS 12 非対応 非対応 対応 対応 対応 対応
(iOS 12.2以降)[166] 		対応 対応 対応 対策済 影響なし 影響なし 非対応 対策済 対策済 不可
13 iOS 13 非対応 非対応 対応 対応 対応 対応 対応 対応 対応 対策済 影響なし 影響なし 非対応 対策済 対策済 不可
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない) 		SSL 3.0
(安全ではない) 		TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 EV証明書 SHA-2証明書 ECDSA証明書 BEAST CRIME POODLE
(SSLv3) 		RC4 FREAK Logjam プロトコル選択
ニンテンドーDSシリーズ
(携帯ゲーム機)
 ニンテンドーDSブラウザー[167] DS 対応 対応 対応 非対応 非対応 非対応 非対応 不明 不明 不明 不明 不明 不明 不明 不明 不可
ニンテンドーDSiブラウザー[168] DSi 非対応 対応 対応 非対応 非対応 非対応 非対応 対応 非対応 脆弱 影響なし 脆弱 脆弱 脆弱 脆弱 不可
ニンテンドー3DSシリーズ
(携帯ゲーム機)
 インターネットブラウザー[169] 3DS 非対応 非対応[170] 対応 対応[171] 対応[171] 非対応 対応 対応 非対応 対策済 影響なし 影響なし 優先度最低 対策済 対策済 不可
インターネットブラウザー New 3DS[172] 非対応 非対応 対応 対応 対応 非対応 対応 対応 非対応 対策済 影響なし 影響なし 優先度最低 対策済 対策済 不可
PSシリーズ
(携帯ゲーム機)
 [173] PSP 非対応 対応 非対応 非対応 非対応 非対応 非対応 対応 不明 不明 不明 不明 不明 不明 不明 不可
PS Vita 非対応 非対応 対応 非対応 非対応 非対応 対応 対応 対応 不明 影響なし 影響なし 優先度最低 対策済 脆弱 不可
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない) 		SSL 3.0
(安全ではない) 		TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 EV証明書 SHA-2証明書 ECDSA証明書 BEAST CRIME POODLE
(SSLv3) 		RC4 FREAK Logjam プロトコル選択
Wiiシリーズ
(据置機)
 インターネットチャンネル[174] Wii 対応 対応 対応 対応 非対応 非対応 非対応 対応 非対応 脆弱 影響なし 脆弱 脆弱 不明 不明 不可
インターネットブラウザー[175] Wii U 非対応 非対応 対応 対応 対応 非対応 対応 対応 不明 不明 影響なし 影響なし 優先度最低 対策済 対策済 不可
Nintendo Switchシリーズ
(据置機)
 名称不明 Nintendo Switch 非対応 非対応 非対応 対応 対応 非対応 対応 対応 対応 影響なし 影響なし 影響なし 非対応 対策済 対策済 不可
PSシリーズ
(据置機)
 [176] PS3 非対応 非対応[170] 対応[171] 非対応 非対応 非対応 不明 対応 非対応 不明 影響なし 影響なし 脆弱 対策済 対策済 不可
PS4 非対応 非対応 対応 対応[171] 対応[171] 非対応 対応 対応 対応 不明 影響なし 影響なし 優先度最低 対策済 脆弱 不可
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない) 		SSL 3.0
(安全ではない) 		TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 EV[注 3] SHA-2 ECDSA BEAST
[注 4] 		CRIME
[注 5] 		POODLE
(SSLv3)
[注 6] 		RC4
[注 7] 		FREAK Logjam プロトコル選択
[注 2]
SSLプロトコル TLSプロトコル 証明書のサポート 脆弱性への対応[注 1]
色および注釈 状況
ブラウザ プラットフォーム
ブラウザバージョン オペレーティングシステム 開発版
ブラウザバージョン オペレーティングシステム 現在の最新リリース
ブラウザバージョン オペレーティングシステム 過去のリリース：サポート継続
ブラウザバージョン オペレーティングシステム 過去のリリース：サポート継続（残り期間12か月未満）
ブラウザバージョン オペレーティングシステム 過去のリリース：開発終了
n/a オペレーティングシステム 混在 / 非特定
オペレーティングシステム (XX以降) そのブラウザの最新リリースがサポートするOSの最低バージョン
オペレーティングシステム そのブラウザによるサポートが完全に終了したOS
注


(一)^ ab既知の脆弱性に対する対応がされているか否か。暗号アルゴリズムや暗号強度は考慮しない︵#暗号化参照︶。

(二)^ abユーザあるいは管理者によって、使用するプロトコルを選択できるか否か。可能な場合、いくつかの攻撃を回避することができる︵SSL 3.0およびTLS 1.0におけるBEASTや、SSL 3.0におけるPOODLEなど︶。

(三)^ ab錠前アイコンやアドレスバーを緑色で表示するなど、EV SSLと通常のSSLを区別できるか否か。

(四)^ ab1/n-1 record splittingなど。

(五)^ abHTTPS/SPDYにおけるヘッダ圧縮の無効化。

(六)^ ab
●完全な対策としては、SSL 3.0そのものの無効化、"anti-POODLE record splitting"の実装。"anti-POODLE record splitting"はクライアント側のみの対応で有効でありSSL 3.0の仕様にも準拠しているが、サーバによっては互換性の問題が生じる可能性がある。
●部分的な対策としては、クライアント側でのSSL 3.0へのフォールバックの無効化、TLS_FALLBACK_SCSVの実装、CBCモードによるCipher Suiteの無効化など。TLS_FALLBACK_SCSVはSSL 3.0へのフォールバックの抑止の一つであるがクライアント、サーバ双方での対応が必要であり、サーバ側がこれに非対応かつSSL 3.0対応の場合には効果がない。SSL 3.0においてCBCモードによるCipher Suiteを無効化した場合には、RC4を用いたCipher Suiteしか利用できなくなるためRC4攻撃に対する脆弱性が増大する。
●手動でSSL 3.0を無効化した場合にはPOODLE攻撃を受けることはない。
(七)^ ab
●完全な対策としては、RC4を用いたCipher Suiteの無効化。
●古い環境との互換性を維持した部分的な対策としては、RC4を用いたCipher Suiteの優先度の低下。
(八)^ Google Chrome︵およびChromium︶はバージョン21でTLS 1.1に対応したもののいったん撤回され、バージョン22で再度有効となった。TLS 1.2についても、バージョン29で有効となったものが撤回され、バージョン30で再度有効となった[52][53][54]。

(九)^ TLSの実装はAndroid版、macOS版およびWindows版ではBoringSSL[55]、およびLinux版ではNSSによる。NSSからBoringSSLへの完全移行が進行中である。

(十)^ abcdefghijklmnopqrstuvwxyzaaabacadaeafagahaiajakalaman設定あるいはオプション︵ブラウザにより名称は異なる︶より設定可能 (プロトコルバージョンごとに有効/無効を指定)

(11)^ abcdefghijklmnopqrst起動オプションより設定可能 (最高および最低バージョンの指定による範囲指定)

(12)^ TLS_FALLBACK_SCSVを実装[63]。バージョン39よりSSL 3.0へのフォールバック無効化を追加[64]。

(13)^ TLS_FALLBACK_SCSVの実装、SSL 3.0へのフォールバック無効化に加え、バージョン40でSSL 3.0を既定で無効化[64]。

(14)^ abcchrome://flagsより設定可能 (最低バージョンの指定による範囲指定、最高バージョンは起動オプションより指定可能)[68]

(15)^ abcdefghiホストがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限り、RC4を用いたCipher Suiteがフォールバックとして利用される。

(16)^ abcdefghijklmnopqrstuvwxyzaaRC4を用いたCipher Suiteのすべてが既定で無効化される

(17)^ TLSの実装はNSSによる。Firefox 22以前では、同梱のNSSがTLS 1.1に対応していたもののブラウザとしてはTLS 1.0まで対応。Firefox 23でTLS 1.1に、Firefox 24でTLS 1.2に対応したが既定では無効。Firefox 27よりTLS 1.1およびTLS 1.2が既定で有効。

(18)^ abcdefghijklmnabout:configあるいはアドオン[85]より設定可能 (最高および最低バージョンの指定による範囲指定)

(19)^ バージョン34.0、ESR 31.3でSSL 3.0を既定で無効化[90]。バージョン34.0ではSSL 3.0へのフォールバック無効化を追加[92]。ESR 31.3およびバージョン35ではTLS_FALLBACK_SCSVを実装[90][93]。

(20)^ abcdIEのTLSへの対応はWindowsに同梱のSChannelによる。IE 11においてTLS 1.1および1.2が既定で有効[102][103]。

(21)^ abcWindows NT 3.1: IE 1–2, Windows NT 3.5: IE 1–3, Windows NT 3.51および4.0: IE 1–6

(22)^ abcdefgWindows XPおよび Server 2003以前のSChannelは3DESやRC4といった弱いアルゴリズムのみに対応[106]。これはIEだけではなく、Microsoft Officeなど、これらのOS上で動作する他のMicrosoft製品でも利用される。Server 2003のみ、KB 948963によってAESに対応する[107]。

(23)^ abcdeMS13-095あるいはMS14-049 (Server 2003およびXP 64ビット版)、SP3︵XP 32ビット版︶

(24)^ abcサーバがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限り、RC4を用いたCipher Suiteがフォールバックとして利用されるようレジストリから変更することも可能[114]。

(25)^ abcd﹁保護モード﹂においてSSL 3.0へのフォールバックを既定で無効化[116][117]。2015年4月にSSL 3.0そのものを無効化[118]。

(26)^ abレンダリングエンジンであるEdgeHTMLはInternet Explorer 11までのレンダリングエンジンであるTridentからフォークされた

(27)^ Windows 10 LTSB 2015 (LongTermSupportBranch) を除く[121]

(28)^ abcレジストリより設定可能 (サードパーティによるツールが必要)[123]

(29)^ Presto版では、Opera 10でTLS 1.2に対応︵既定では無効︶。

(30)^ ab2014年10月15日以降、SSL 3.0の既定での無効化をリモートで実施[135]。

(31)^ Opera 14以降におけるTLSへの対応は、対応するChromiumバックエンドを利用するChromeと同じとなる。Android版Opera 14はChromium 26︵レイアウトエンジンはWebKit︶[140]、Opera 15以降はChromium 28以降︵レイアウトエンジンはBlink︶をベースとしている[141]。

(32)^ TLS_FALLBACK_SCSVを実装[144]。

(33)^ BEASTおよびPOODLEへの対策を実装済み[135]

(34)^ TLS_FALLBACK_SCSVの実装に加え、"anti-POODLE record splitting"を実装[135]。

(35)^ TLS_FALLBACK_SCSV、"anti-POODLE record splitting"の実装に加え、SSL 3.0を既定で無効化[68]。

(36)^ abcopera://flagsより設定可能 (最低バージョンの指定による範囲指定、最高バージョンは起動オプションより指定可能)[68]

(37)^ SafariのTLSへの対応はOS同梱のライブラリによる[145]。

(38)^ 2013年9月にBEASTへの対処が実装がされたが、既定では無効であった[147][148]。2014年2月にアップデートされたOS X v10.8.5から既定で有効となった[149]。

(39)^ abcdefghPOODLEへの対応としてSSL 3.0においてCBCモードをすべて廃止した[150][151]ため、SSL 3.0では脆弱性が指摘されているRC4しか利用できず、RC4攻撃に対する脆弱性が増大している。

(40)^ モバイルSafariおよびTLS/SSLを必要とするサードパーティ製のすべてのソフトウェアはiOS同梱のUIWebViewライブラリを使用する。iOS 5以降でTLS 1.1および1.2が既定で有効[156][157][158]。

ライブラリ

[編集]
詳細は「en:Comparison of TLS implementations」を参照

TLS/SSLライブラリの多くはオープンソースソフトウェアである。

ライブラリにおけるTLS/SSLの対応状況
実装 SSL 2.0（安全ではない） SSL 3.0（安全ではない） TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Botan 非対応 非対応[177] 対応 対応 対応
cryptlib（英語版） 非対応 既定で有効 対応 対応 対応
GnuTLS 非対応[注 1] 既定で無効[178] 対応 対応 対応 対応(ドラフト版)[179]
Java Secure Socket Extension（英語版） 非対応[注 1] 既定で無効[180] 対応 対応 対応 対応
LibreSSL 非対応[181] 既定で無効[182] 対応 対応 対応
MatrixSSL（英語版） 非対応 コンパイル時点で既定で無効[183] 対応 対応 対応 対応(ドラフト版)
mbed TLS（英語版） 非対応 既定で無効[184] 対応 対応 対応
Network Security Services 既定で無効[注 2] 既定で無効[186] 対応 対応[187] 対応[188] 対応[189]
OpenSSL 既定で無効[190] 既定で有効 対応 対応[191] 対応[191] 対応[192]
RSA BSAFE（英語版）[193] 非対応 対応 対応 対応 対応 未対応
SChannel XP/2003[194] IE 7から既定で無効 既定で有効 IE 7から既定で有効 非対応 非対応 非対応
SChannel Vista/2008[195] 既定で無効 既定で有効 対応 非対応 非対応 非対応
SChannel 7/2008R2[196] 既定で無効 IE 11から既定で無効 対応 IE 11から既定で有効 IE 11から既定で有効 非対応
SChannel 8/1012[196] 既定で無効 既定で有効 対応 既定で無効 既定で無効 非対応
SChannel 8.1/2012R2, 10 v1507/v1511[196] 既定で無効 IE 11から既定で無効 対応 対応 対応 非対応
SChannel 10 v1607/2016[197] 非対応 既定で無効 対応 対応 対応 非対応
Secure Transport OS X v10.2-10.8 / iOS 1-4 対応 対応 対応 非対応 非対応
Secure Transport OS X v10.9-10.10 / iOS 5-8 非対応[注 3] 対応 対応 対応[注 3] 対応[注 3]
Secure Transport OS X v10.11 / iOS 9 非対応 非対応[注 3] 対応 対応 対応
SharkSSL 非対応 既定で無効 対応 対応 対応
wolfSSL 非対応 既定で無効[200] 対応 対応 対応 対応[201]
実装 SSL 2.0（安全ではない） SSL 3.0（安全ではない） TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
注
  1. ^ a b 後方互換性の確保のため、SSL 2.0に非対応あるいは既定で無効の場合にもSSL 2.0 client helloはサポートされる。
  2. ^ サーバ側でのSSL 2.0 client helloの受け取りのみサポートされる[185]
  3. ^ a b c d OS X v10.9以降でSSL 2.0非対応。OS X v10.11以降およびiOS 9以降でSSL 3.0非対応。OS X v10.9およびiOS 5以降以降でTLS 1.1、1.2に対応[198][199]

課題

[編集]

バーチャルホスト

[編集]

TLSは、TCP/IPネットワークでホスト名ベースのバーチャルホストを構成する際に問題となる。TCP/IPでは通信を開始する前にホスト名を解決し、実際にはIPアドレスとポート番号で接続先を識別している。このためTLSのネゴシエーションの時点では、バーチャルホストのうちどのホスト名を期待しているのか判断できず、ホスト名ごとに異なるサーバー証明書を使い分けることができない。

TLSの拡張機能を定義するRFC 6066では、ネゴシエーション時にホスト名を伝える手段としてServer Name Indication (SNI) を規定している。用例としては、HTTPの最新バージョンであるHTTP/2においてTLSを利用する際はSNIの利用が必須とされている。

一方、証明書を使い分けず、1つの証明書を複数のバーチャルホストで使い回す方式も広く利用されている。X.509証明書のフォーマットについて記述したRFC5280では、発行先ホスト名を保持するsubjectAltNameはひとつの証明書に複数のエントリを作成できると規定している。これを利用して、ホストに収容されたすべてのバーチャルホストに対応したsubjectAltNameを保持する証明書をクライアントに提示すれば良い。

また、発行先ホスト名にワイルドカードを使う方法も考えられる。HTTP over SSL/TLS (HTTPS) を定義するRFC 2818は、ワイルドカードの適用について記述している。バーチャルホストの対象が、ひとつのドメイン名の中のホストであれば、この方法で対応できる場合もある。

どの方法も実装によって対応状況にバラつきがあり、環境によっては使えない可能性がある。なおIPアドレスベースのバーチャルホストであれば、ネゴシエーションの時点で確実にどのバーチャルホストを期待しているか判断できるので、問題なく証明書を使い分けることができる。

TLS/SSLの既知の脆弱性

[編集]

TLS/SSLに対する攻撃のうち主なものを以下に挙げる。2015年2月に、TLS/SSLに対する既知の攻撃についての情報をまとめたRFC 7457がIETFから公開されている。

暗号の危殆化を利用したもの

[編集]

TLS 1.2ではすでに危殆化したRC4、MD5、SHA1が選択可能であり、この事が脆弱性の原因となっている。

MD5はすでに衝突が容易に見つかるレベルまで危殆化しているため、これを利用したSLOTH攻撃 (CVE-2015-7575) が知られている。

SHA1もFreestart Collision[202]が見つかっており安全ではない。

RC4

[編集]

RC4もTLSのすべてのバージョンにおいて利用を禁止するRFC 7465が公開された。MozillaおよびマイクロソフトではRC4を無効化することを推奨している[203][204][205][206]。

RC4そのものに対する攻撃法は多く報告されているが、TLS/SSLにおいてRC4を用いたCipher Suiteについては、その脆弱性に対処されており安全であると考えられていた。2011年には、ブロック暗号のCBCモードの取り扱いに関する脆弱性であったBEAST攻撃への対応策の一つとして、ストリーム暗号であるためその影響を受けないRC4に切り替えることが推奨されていた[207]。しかし、2013年にTLS/SSLでのRC4への効果的な攻撃が報告され、BEASTへの対応としてRC4を用いることは好ましくないとされた[208]。RC4に対する攻撃は、AlFardan、Bernstein、Paterson、Poettering、Schuldtによって報告された。新たに発見されたRC4の鍵テーブルにおける統計的な偏り[209]を利用し、平文の一部を回復可能であるというものである[210][211]。この攻撃では、13 × 220の暗号文を用いることで128ビットのRC4が解読可能であることが示され、2013年のUSENIXセキュリティシンポジウムにおいて﹁実現可能﹂と評された[212][213]。2013年現在では、NSAのような機関であればTLS/SSLを利用したとしてもRC4を解読可能であるとの疑惑がある[214]。

2015年現在ではクライアントのほとんどは既にBEASTへの対処が完了していることから、RC4はもはや最良の選択肢ではなくなっており、TLS 1.0以前においてもCBCモードを用いることがより良い選択肢となっている[215]。

ダウングレード攻撃

[編集]

FREAK および Logjam

[編集]
詳細は「FREAK」を参照

かつてアメリカ合衆国からの暗号の輸出規制が厳しかった時期に、規制を回避するために一時的に512ビットのRSA鍵を生成して、そちらで通信を行うというような手法が存在した[216]。この手法については、一時的な公開鍵を素因数分解することが可能であれば中間者攻撃が成立することが1998年時点で指摘されていたが[217]、コンピュータの性能向上、クラウドコンピューティングの普及により素因数分解が個人レベルですら現実的となったこと、さらに2015年には、OpenSSL、Safari、Androidなどでは輸出用でない暗号スイートでも512ビットの一時鍵を受け入れてしまう実装となっていたことが判明し、FREAK (Factoring RSA Export Keys)[218]として問題が再浮上している。

対策としては、すでに脆弱となっている輸出対応暗号の無効化、クライアント側では規格書通り、輸出暗号以外で一時的RSA鍵を使わないようにする[219]、ということが挙げられる。

2015年5月、Logjamと呼ばれる脆弱性が発見された。これも、FREAKと同様に輸出用の512ビットの一時鍵を受け入れてしまうものである[220]。FREAKとは異なり、LogjamはTLSプロトコル自体の脆弱性である。発見時点において、主要なブラウザのすべてがLogjamに対して脆弱である。

バージョンロールバック攻撃

[編集]

False Start[221]︵Google Chromeで有効化された[222]︶やSnap StartといったTLS/SSLを高速化する変法は、攻撃者が一定条件下において本来利用可能なTLS/SSLのバージョンよりも低いバージョンでTLS/SSL接続を行うよう仕向けること[223]や、クライアントからサーバへ送られる利用可能なCipher Suiteの一覧を改竄し、より低い暗号強度やより弱い暗号化アルゴリズム・鍵交換アルゴリズムを使用するよう仕向けること[224]が可能であると報告されている。さらに、特定の環境においては、攻撃者がオフラインで暗号化に用いられた鍵を回復し、暗号化されたデータにアクセスすることも可能であることがAssociation for Computing Machinery (ACM) のコンピュータセキュリティカンファレンスで報告された[225]。

Mac-then-Encrypt型の認証暗号に関するもの

[編集]

BEAST攻撃

[編集]

2011年9月23日、暗号研究者のThai DuongとJuliano Rizzoが、BEAST (Browser Exploit Against SSL/TLS)[226] と呼ばれるTLS 1.0におけるブロック暗号のCBCモードの取り扱いに関する脆弱性のコンセプトをJavaアプレットの同一生成元ポリシー違反によって実証した[227][228]。この脆弱性そのものは2002年にPhillip Rogawayによって発見されていた[229]が、2011年の発表までは実用的なエクスプロイトは報告されていなかった。

2006年に発表されたTLS 1.1においてBEASTへの脆弱性は修正されていたが、2011年の実証までTLS 1.1への対応はクライアント、サーバの双方でほとんど進んでいなかった。

Google ChromeおよびFirefoxはBEASTによる影響を直接的に受けることはないが[230][231]、MozillaはTLS/SSLのためのライブラリであるNetwork Security Services (NSS) に対して、BEASTおよびそれに類似した選択平文攻撃に対するTLS 1.0以前で有効な対応策を2011年に施した。NSSは、Mozilla FirefoxなどのMozillaのソフトウェアだけでなく、Google Chromeなど他のブラウザでも用いられているライブラリである。NSSでのTLS 1.1以降への対応は2012年までずれこみ、FirefoxでTLS 1.1以降を既定で利用可能となったのは2014年のバージョン27である。

マイクロソフトは2012年1月10日にSecurity Bulletin MS12-006を発表し、Windowsで用いられているライブラリであるSChannelに対して修正を加えた[232]。Windows 7以降では、TLS 1.1以降が利用可能である。

Apple製品では、macOSではv10.9においてTLS 1.1以降への対応およびTLS 1.0以前におけるBEAST脆弱性への対応がなされているが、v10.8以前では、TLS 1.1以降への対応、TLS 1.0以前におけるBEAST脆弱性への対応のいずれも行われていない。iOSでは、5以降ではTLS 1.1以降が利用可能であるが、TLS 1.0以前におけるBEAST脆弱性への対応は行われていない。iOS 7ではじめてTLS 1.0以前におけるBEAST脆弱性への対応が行われた。

パディング攻撃

[編集]

TLSの初期のバージョンはパディングオラクル攻撃に対して脆弱であることが2002年に報告された。

Lucky Thirteen

[編集]

2013年には、Lucky Thirteen攻撃（英語版）と呼ばれる新たなパディング攻撃が報告されている。2014年現在では、多くの実装においてLucky Thirteen攻撃に対して対応済みである。

POODLE攻撃

[編集]

2014年9月15日、Googleの研究者によって、SSL 3.0の設計に脆弱性が存在することが発表された[233] (CVE-2014-3566)。これは、SSL 3.0においてブロック暗号をCBCモードで使用した際にパディング攻撃が可能となるものであり、POODLE (Padding Oracle On Downgraded Legacy Encryption) と名付けられた。平均してわずか256回のリクエストで暗号文の1バイトの解読が可能となる[44][234]。CVE IDはCVE-2014-3566である。

この脆弱性はSSL 3.0の仕様のみに存在するものでありTLS 1.0以降に影響はないが、主要なすべてのブラウザではTLSでのハンドシェイクが失敗した場合にSSL 3.0での接続にダウングレードする。そのため、攻撃者はバージョンロールバック攻撃によってSSL 3.0での接続を行わせることでこの脆弱性を利用可能となる[44][234]。

POODLE攻撃への根本的な対処法は、少なくともクライアント、サーバのどちらかでSSL 3.0を無効化することである。しかし、古いクライアント、サーバなどではTLS 1.0以降に対応していないため、互換性を考慮してSSL 3.0を無効化できない場合がある。そこで、POODLEの発見者は、TLS_FALLBACK_SCSV[235]の実装を推奨している。この実装によりTLSからSSL 3.0へのフォールバックが抑止されるが[44][234]、これはクライアント側だけでなくサーバ側の対応も必要である。

Google ChromeブラウザやGoogleサービスのサーバは既にTLS_FALLBACK_SCSVに対応しており、加えて数か月以内にこれらクライアント、サーバからSSL 3.0のサポートを除去する予定である[234]。2014年11月リリースのバージョン39においてSSL 3.0へのフォールバックを、2015年1月リリースのバージョン40においてSSL 3.0そのものを既定で無効化している。

OperaもGoogle Chromeと同様にTLS_FALLBACK_SCSVを実装済みであるほか、バージョン25において"anti-POODLE record splitting"と呼ばれる異なる対策を実装した[236]。

Mozillaでは2014年12月リリースのMozilla Firefox34およびESR 31.3からSSL 3.0を無効化したほか、Firefox 35においてTLS_FALLBACK_SCSVをサポートした[237]。

マイクロソフトでは、グループポリシーからSSL 3.0を無効化する方法を公開しているほか[238]、10月29日にWindows Vista、Server 2003およびそれ以降のIEにおいてSSL 3.0を無効化する"Fix it"を公開し、数か月以内にIEおよびマイクロソフトのオンラインサービスにおいてSSL 3.0を既定で無効化する方針を表明した[239]。2015年2月のアップデートにおいて、IE 11の保護モードにおいてSSL 3.0へのフォールバックを既定で無効化した[240]。加えて、2015年4月にIE 11においてSSL 3.0自体を既定で無効化した[241]。

Safari︵OS X v10.8以降およびiOS 8.1以降︶では、POODLEへの対策としてSSL 3.0においてCBCモードのcipher suiteを無効化した[242][243]。これによりPOODLEの影響を受けることはなくなるが、SSL 3.0においてCBCモードを無効化したことで、脆弱性が指摘されているRC4しか利用できなくなるという問題が生じている。

サーバ側では、NSSが2014年10月3日にリリースされたバージョン3.17.1および10月27日にリリースされた3.16.2.3でTLS_FALLBACK_SCSVに対応したほか[244][245]、2015年4月までにSSL 3.0を既定で無効化する予定である[246]。OpenSSLは、10月15日リリースのバージョン1.0.1j、1.0.0、0.9.8zcでTLS_FALLBACK_SCSVに対応した[247]。LibreSSLでは、10月16日リリースのバージョン2.1.1でSSL 3.0を既定で無効化した[248]。

2014年12月8日に、SSL 3.0ではなくTLS 1.0から1.2に対して有効なPOODLE攻撃の変法が報告された。この変法はTLSの仕様においてサーバ側に要求されているパディングのチェックを正しく行わない実装において、SSL 3.0を無効にしていたとしてもPOODLE攻撃が可能となるというものである[249]。すなわち、SSL 3.0に対するものが仕様そのものの脆弱性であるのに対し、TLS 1.0以降に対するものは不適切な実装による脆弱性である。SSL Pulseでは、公開前の時点でHTTPS対応のサーバのうちおよそ10%がこの変法に対して脆弱であるとしている[250]。この変法のCVE IDはCVE-2014-8730である。この変法では、SSL 3.0へダウングレードさせる必要がなくTLS 1.2のままで攻撃が可能であるなど、オリジナルのSSL 3.0に対するPOODLE攻撃よりも実行が容易であるとされる[251]。

圧縮サイドチャネル攻撃

[編集]

TLS1.2では平文を圧縮した後に暗号化を施す。しかし圧縮後の平文のビット長さは圧縮前の平文に依存し、しかも暗号文のビット長は暗号化する文書＝圧縮後の平文のビット長に依存するので、暗号文長から平文の情報が攻撃者に漏れてしまう。この事実を利用した攻撃を圧縮サイドチャネル攻撃という。TLS1.2には以下の様な圧縮サイドチャネル攻撃が知られている。

CRIME攻撃

[編集]

2012年にBEAST攻撃の報告者によって、TLSにおいてデータ圧縮が有効な場合において、本来第三者に対して秘密であるべきCookieの内容が回復可能となるCRIME︵Compression Ratio Info-leak Made Easy, 英語版︶が報告された[252][253]。ウェブサイトでのユーザ認証に使われているCookieの内容を回復されることで、セッションハイジャックが可能となる。2012年9月にはMozilla FirefoxおよびGoogle ChromeにおいてCRIMEへの対応が実施された。また、マイクロソフトによればInternet ExplorerはCRIMEの影響を受けない。

CRIMEの報告者によって、CRIMEがTLS以外にもデータ圧縮を利用するSPDYやHTTPといったプロトコルにも広く適用可能であることが示されていたにもかかわらず、クライアント、サーバのいずれにおいてもTLSやSPDYに対する修正しか行われず、HTTPに対する修正は行われなかった。

BREACH攻撃

[編集]

2013年に、HTTPでのデータ圧縮をターゲットとしたBREACH︵Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext, 英語版︶と呼ばれるCRIME攻撃の変法が報告された。BREACH攻撃では、ログイントークン、メールアドレスなどの個人情報をわずか30秒で取得可能であり、不正なリンクを訪れさせたり、正当なウェブページに不正なコンテンツを挿入することも可能であった[254]。使用するアルゴリズム、Cipher Suiteを問わず、すべてのバージョンのTLS/SSLに対してBREACH攻撃は適用可能である[255]。TLSでのデータ圧縮やSPDYでのヘッダ圧縮を無効とすることで容易に回避可能であったCRIMEとは異なり、BREACHを回避するためにはHTTPでのデータ圧縮を無効にする必要があるが、通信速度の向上のためにほぼすべてのサーバがHTTPデータ圧縮を有効としている現状では、これを無効化することは現実的ではない[254]。

その他

[編集]

再ネゴシエーション脆弱性

[編集]

2009年11月4日、SSL 3.0以降の再ネゴシエーション機能を利用して、クライアントからのリクエストの先頭に中間者が任意のデータを挿入できるという脆弱性が報告された[256][257]。プロトコル自体の脆弱性であり、すべての実装が影響を受ける。

この脆弱性への簡単な対策は、サーバにおいて再ネゴシエーションを禁止することである。根本対応としては、TLS Extensionを使った安全な再ネゴシエーション手順がRFC 5746として提案されている。この脆弱性を利用した中間者攻撃では、サーバがRFC 5746に対応しない限りクライアントは再ネゴシエーションが発生したことを検出できないので、クライアント側のみで対応することは不可能である。

切り詰め攻撃

[編集]

TLSでの切り詰め攻撃では、ユーザがウェブサービスからログアウトすることを妨害し、意図せずログインしたままとすることが可能である。ユーザからログアウト要求が送信されたときに、攻撃者が偽のTCP FINメッセージ︵これ以上データを送信しない︶を平文で挿入する。このメッセージを受けたサーバでは、ユーザから送られたログアウト要求を受け取らないため、ユーザの意図とは異なりログイン状態が維持される[258]。

2013年の報告[259]では、この攻撃への対応として、GmailやHotmailなどのウェブサービスでは、ログアウトが正常に完了した旨のページを表示するようになった。これにより、ログアウトしたか否かをユーザが確認することが可能となり、攻撃者によってログイン状態のアカウントを悪用される危険性が軽減される。

この攻撃では目標のコンピュータにマルウェアなどを導入する必要はないが、攻撃者が目標とサーバの間の回線に割り込むことが可能であること[258]と、目標のコンピュータに物理的にアクセス可能であることが求められる。

実装上の脆弱性をついたもの

[編集]

ハートブリード

[編集]
詳細は「ハートブリード」を参照

ハートブリード︵英: Heartbleed︶は、2014年に発覚したOpenSSLライブラリのバージョン1.0.1から1.0.1fの間で発見された深刻なセキュリティ脆弱性である。この脆弱性を利用することで、TLS/SSLによって保護されているはずの情報を盗むことが可能である。

このバグでは、インターネット上の誰もが、脆弱性のあるOpenSSLを利用しているシステムのメモリにアクセスすることが可能となり、サービスプロバイダの認証やデータの暗号化に用いられている秘密鍵、ユーザのアカウントおよびパスワード、実際にやり取りされたデータなどを取得できる。これにより、メッセンジャーサービス、電子メールの盗聴、データの盗難、なりすましなどが可能となる。

ウェブサイトの統計

[編集]

Trustworthy Internet Movementは、TLS/SSLに対する攻撃に対して脆弱なウェブサイトの統計を発表している。2019年8月における統計は以下の通りである[42]。

TLS/SSLに対する攻撃に脆弱なウェブサイトの統計（括弧内は前月との差）
攻撃 セキュリティ
安全ではない 状況による 安全 その他
再ネゴシエーション脆弱性 0.3%
安全ではない再ネゴシエーションに対応 		0.1%
両方に対応 		98.4%
安全な再ネゴシエーションに対応 		1.1%
再ネゴシエーション非対応
RC4攻撃 1.2%
最新のブラウザで利用可能なRC4 Suiteをサポート 		12.1%
RC4 Suiteのいくつかをサポート 		86.7%
RC4によるCipher Suite非サポート 		N/A
CRIME攻撃 0.6%
脆弱 		N/A N/A N/A
ハートブリード <0.1%
脆弱 		N/A N/A N/A
CCS Injection Vulnerability 0.2%
脆弱かつ悪用可能 		1.2%
脆弱だが悪用不可能 		96.9%
脆弱ではない 		1.7%
不明
TLSへのPOODLE攻撃
SSL 3.0へのPOODLE攻撃は含まない 		0.3%
脆弱かつ悪用可能 		N/A 99.5%
脆弱ではない 		0.2%
不明
プロトコルダウングレード 11.3%
TLS_FALLBACK_SCSV非サポート 		N/A 71.6%
TLS_FALLBACK_SCSVサポート 		17.0%
不明

参考文献

[編集]
  • Eric Rescorla『マスタリングTCP/IP SSL/TLS編』齊藤孝道・鬼頭利之・古森貞監訳（第1版第1刷）、オーム社、2003年11月28日。ISBN 4-274-06542-1。 

脚注

[編集]


(一)^ プロトコル名を含めた歴史については、Eric Rescorla著,﹁マスタリングTCP/IP SSL/TLS編﹂,オーム社開発局︵2003年︶ISBN 4-274-06542-1 の2章6節が詳しい。

(二)^ ただし、メールサーバーへの接続においてはTLS接続用のTCPポートにはじめからTLSで接続するSMTP over SSLと、通常のTCPポートにSMTP接続後にSTARTTLSコマンドによってセキュアな接続に切り替えるSTARTTLSという異なる接続方式があり、名称を使い分けることがある。詳しくは#アプリケーション層プロトコルへの適用の項目を参照されたい。

(三)^ ab齋藤 孝道﹃マスタリングTCP/IP情報 セキュリティ編﹄︵第2版︶オーム社、2022年6月28日、178-179頁。 

(四)^ “SSL”. Dovecot Wiki. 2015年1月10日閲覧。 “SSL and TLS terms are often used in confusing ways”

(五)^  “Google Chrome、南京錠アイコンを2023年9月に廃止” (2023年5月4日). 2024年3月11日閲覧。

(六)^  “大多数の人は、ウェブブラウザの南京錠アイコンが何を意味するのか理解していない” (2023年11月23日). 2024年3月11日閲覧。

(七)^  “すべての﹁Chrome﹂をHTTPSファーストに、Googleが本腰を入れる” (2023年8月18日). 2024年3月11日閲覧。

(八)^ 高木 浩光 (2007年11月17日). “オレオレ証明書の区分 第三版”. 高木浩光＠自宅の日記. 2010年1月3日閲覧。

(九)^ “﹁安全なウェブサイトの作り方　改訂第3版﹂を公開”.  独立行政法人 情報処理推進機構 (2008年6月11日). 2010年1月3日閲覧。

(十)^ Ian Goldberg; David Wagner (1996年1月1日). “Randomness and the Netscape Browser” (英語).  Dr. Dobb's. 2010年1月3日閲覧。

(11)^ “OpenSSL パッケージの脆弱性とその影響について︵SSH鍵、SSL証明書等︶”.  Debian JP Project (2008年5月15日). 2010年1月3日閲覧。

(12)^ “Debian generated SSH-Keys working exploit”.  SecurityFocus (2008年5月15日). 2010年1月3日閲覧。

(13)^ “Debian GNU/Linux に含まれる OpenSSL/OpenSSH の脆弱性に関する注意喚起”.  JPCERT/CC (2008年5月19日). 2010年1月3日閲覧。

(14)^ abcdefghijklRFC5246日本語訳﹁ TLS ハンドシェイク関連プロトコル﹂、IPA。2016年8月11日閲覧

(15)^ abRFC5246日本語訳﹁ 8. 暗号技術的計算﹂、IPA。2016年8月11日閲覧

(16)^ abcRFC5246日本語訳﹁6. TLS レコードプロトコル﹂、IPA。2016年8月11日閲覧

(17)^ “IT管理者向け - TLS 1.2 への移行を推奨しています”.  マイクロソフト TechNet (2017年7月11日). 2018年5月12日閲覧。

(18)^ “TLS1.0 サポート停止におけるシステムメンテナンスのお知らせ”.  シマンテック (2016年2月19日). 2018年5月12日閲覧。

(19)^ “2018年6月1日以降、古いブラウザー、パソコン、スマートフォンなどでは、Yahoo! JAPANのウェブサービスが順次ご利用いただけなくなります。”.  Yahoo! JAPAN. 2018年5月23日閲覧。

(20)^ 大岩 寛 (2005年10月13日). “[Security] SSL 2.0 version rollback の件のFAQ”. おおいわのこめんと. 2010年1月3日閲覧。

(21)^ Eric Lawrence (2006年1月31日). “Internet Explorer 7 における HTTPS セキュリティの強化点”.  マイクロソフト. 2010年1月3日閲覧。

(22)^ “サイトが古くて安全でないバージョンの SSL プロトコルを使用しているため、安全な接続ができませんでした”. Firefox サポート (2009年7月6日). 2010年1月3日閲覧。

(23)^ “Opera 9 のサポートするウェブ標準ならびに仕様”.  Opera Software ASA.. 2010年1月3日閲覧。

(24)^ 勝村 幸博 (2006年6月2日). “﹁SSL 2.0だけに対応したWebサイトはわずか0.1％﹂---ネットクラフト”.  日経BP IT pro. 2010年1月3日閲覧。

(25)^ RFC 3268 によって後付けでAESが追加されたTLS 1.0とは異なり、TLS 1.1を定義する RFC 4346 A.5節ではRFC 3268が参照され、AESが当初から追加されている

(26)^ “Microsoft、﹁TLS 1.0﹂﹁TLS 1.1﹂対応を終了 ～2024年10月31日以降、利用不可”.  ITmedia. 2024年7月5日閲覧。

(27)^ draft-ietf-tls-tls13-18 "IETF The Transport Layer Security (TLS) Protocol Version 1.3"

(28)^ “IETFがTLS 1.3を承認、悪質なハッカーや盗聴者が仕事をしづらくなる仕掛けを盛り込む”.  TechCrunch Japan (2018年3月24日). 2018年5月12日閲覧。

(29)^ “IETFがTLS 1.3を承認--安全性や速度向上、課題も”.  ZDNet (2018年3月27日). 2018年5月12日閲覧。

(30)^ “IETF、﹁TLS 1.3﹂を正式リリース ～﹁Firefox﹂﹁Google Chrome﹂は最終草案に対応”. 窓の杜. (2018年8月20日). https://forest.watch.impress.co.jp/docs/news/1138657.html 2019年11月12日閲覧。 

(31)^ Sean Turner (2015年9月17日). “Consensus: remove DSA from TLS 1.3”. 2015年9月19日閲覧。

(32)^ abcdefgdraft-chudov-cryptopro-cptls-04 - GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)

(33)^ RFC 5288, RFC 5289

(34)^ RFC 6655, RFC 7251

(35)^ RFC 6367

(36)^ RFC 5932およびRFC 6367

(37)^ abRFC 6209

(38)^ RFC 4162

(39)^ “NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised)” (PDF) (2007年3月8日). 2014年7月3日閲覧。

(40)^ Qualys SSL Labs. “SSL/TLS Deployment Best Practices” (PDF). 2013年11月19日閲覧。

(41)^ RFC 7905

(42)^ abc2023年11月3日現在 “SSL Pulse: Survey of the SSL Implementation of the Most Popular Web Sites”. 2023年12月9日閲覧。

(43)^ ivanr. “RC4 in TLS is Broken: Now What?”.  Qualsys SSL Labs. 2018年9月10日閲覧。

(44)^ abcdBodo Möller, Thai Duong and Krzysztof Kotowicz. “This POODLE Bites: Exploiting The SSL 3.0 Fallback” (PDF). 2014年10月15日閲覧。

(45)^ “﹁Microsoft Edge﹂と﹁Internet Explorer 11﹂でTLS 1.0/1.1がデフォルト無効化へ” (2018年10月16日). 2021年1月1日閲覧。“﹁Google Chrome﹂﹁Firefox﹂﹁Safari﹂もTLS 1.0/1.1のサポートを廃止へ” (2018年10月16日). 2021年1月1日閲覧。

(46)^ “主要ブラウザーの TLS 1.0/1.1 無効化について︵続報︶” (2020年7月28日). 2021年1月1日閲覧。

(47)^ “緑色のバーの表示について”.  シマンテック. 2014年7月29日閲覧。

(48)^ abcdefghijklmno“SHA-256 Compatibility”. 2015年6月15日閲覧。

(49)^ abcdefghijklmnopqrstuvwxyzaaab“ECC Compatibility”. 2015年6月13日閲覧。

(50)^ “Tracking the FREAK Attack”. 2015年3月8日閲覧。

(51)^ “FREAK: Factoring RSA Export Keys”. 2015年3月8日閲覧。

(52)^ Google (2012年5月29日). “Dev Channel Update”. 2014年7月2日閲覧。

(53)^ Google (2012年8月21日). “Stable Channel Update”. 2014年7月2日閲覧。

(54)^ Chromium Project (2013年5月30日). “Chromium TLS 1.2 Implementation”. 2014年7月2日閲覧。

(55)^ “The Chromium Project: BoringSSL”. 2015年9月5日閲覧。

(56)^ “Chrome Stable Release”. Chrome Releases.  Google (2011年10月25日). 2015年2月1日閲覧。

(57)^ “SVN revision log on Chrome 10.0.648.127 release”. 2014年7月2日閲覧。

(58)^ ab“ImperialViolet - CRIME” (2012年9月22日). 2014年10月18日閲覧。

(59)^ ab“SSL/TLS Overview” (2008年8月6日). 2014年7月2日閲覧。

(60)^ ab“Chromium Issue 90392” (2008年8月6日). 2014年7月2日閲覧。

(61)^ ab“Issue 23503030 Merge 219882” (2013年9月3日). 2013年9月19日閲覧。

(62)^ ab“Issue 278370: Unable to submit client certificates over TLS 1.2 from Windows” (2013年8月23日). 2013年10月3日閲覧。

(63)^ Möller, Bodo (2014年10月14日). “This POODLE bites: exploiting the SSL 3.0 fallback”. Google Online Security blog.  Google (via Blogspot). 2014年10月29日閲覧。

(64)^ abc“An update on SSLv3 in Chrome.”. Security-dev.  Google (2014年10月31日). 2014年11月4日閲覧。

(65)^ “Stable Channel Update”. Mozilla Developer Network.  Google (2014年2月20日). 2014年11月14日閲覧。

(66)^ “Changelog for Chrome 33.0.1750.117”. Google.  Google. 2014年11月14日閲覧。

(67)^ “Issue 318442: Update to NSS 3.15.3 and NSPR 4.10.2”. 2014年11月14日閲覧。

(68)^ abcde“Issue 693963003: Add minimum TLS version control to about:flags and Finch gate it. - Code Review”. 2015年1月22日閲覧。

(69)^ abc“Issue 375342: Drop RC4 Support”. 2015年5月22日閲覧。

(70)^ ab“Issue 436391: Add info on end of life of SSLVersionFallbackMin & SSLVersionMin policy in documentation”. 2015年4月19日閲覧。

(71)^ “Issue 490240: Increase minimum DH size to 1024 bits (tracking bug)”. 2015年5月29日閲覧。

(72)^ abcdefghi“Intent to deprecate: RC4”. 2015年12月21日閲覧。

(73)^ abcdefghi“An update on SHA-1 certificates in Chrome” (2015年12月18日). 2015年12月21日閲覧。

(74)^ “SSLSocket | Android Developers”. 2015年3月11日閲覧。

(75)^ abcd“What browsers work with Universal SSL”. 2015年6月15日閲覧。

(76)^ abcd“SSLSocket | Android Developers”. 2015年12月17日閲覧。

(77)^ ab“Android 5.0 Behavior Changes | Android Developers”. 2015年3月11日閲覧。

(78)^ “Android 8.0 Behavior Changes” (2017年3月21日). 2017年12月1日時点のオリジナルよりアーカイブ。2020年3月29日閲覧。

(79)^ abcd“Security in Firefox 2” (2008年8月6日). 2014年7月2日閲覧。

(80)^ “TLS 暗号化通信に対する攻撃の Firefox への影響”. Mozilla Japan ブログ.  Mozilla Japan (2011年9月28日). 2015年2月1日閲覧。

(81)^ ab“Introduction to SSL”.  MDN. 2014年7月2日閲覧。

(82)^ ab“NSS 3.15.3 Release Notes”. Mozilla Developer Network.  Mozilla. 2014年7月13日閲覧。

(83)^ ab“MFSA 2013-103: Network Security Services (NSS) の様々な脆弱性”. Mozilla Japan.  Mozilla Japan. 2014年7月13日閲覧。

(84)^ “Bug 565047 – (RFC4346) Implement TLS 1.1 (RFC 4346)”. 2014年7月2日閲覧。

(85)^ SSL Version Control :: Add-ons for Firefox

(86)^ “Bug 480514 – Implement support for TLS 1.2 (RFC 5246)”. 2014年7月2日閲覧。

(87)^ “Bug 733647 – Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default”. 2014年7月2日閲覧。

(88)^ ab“Firefox 27.0 リリースノート” (2014年2月4日). 2014年7月2日閲覧。

(89)^ “Bug 861266 – Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default”. 2014年7月2日閲覧。

(90)^ abc“The POODLE Attack and the End of SSL 3.0”. Mozilla blog.  Mozilla (2014年10月14日). 2014年10月29日閲覧。

(91)^ “Firefox 34.0 リリースノート” (2014年12月1日). 2015年4月4日閲覧。

(92)^ “Bug 1083058 - A pref to control TLS version fallback”.  bugzilla.mozilla.org. 2014年11月6日閲覧。

(93)^ “Bug 1036737 - Add support for draft-ietf-tls-downgrade-scsv to Gecko/Firefox”.  bugzilla.mozilla.org. 2014年10月29日閲覧。

(94)^ abc“Bug 1166031 - Update to NSS 3.19.1”.  bugzilla.mozilla.org. 2015年5月29日閲覧。

(95)^ “Bug 1088915 - Stop offering RC4 in the first handshakes”.  bugzilla.mozilla.org. 2014年11月4日閲覧。

(96)^ “Firefox 39.0 リリースノート”.  Mozilla Japan (2015年6月30日). 2015年7月3日閲覧。

(97)^ “Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year”.  VentureBeat (2015年9月1日). 2015年9月5日閲覧。

(98)^ “Intent to ship: RC4 disabled by default in Firefox 44”. 2015年10月19日閲覧。

(99)^ “RC4 is now allowed only on whitelisted sites (Reverted)”. 2015年11月2日閲覧。

(100)^ “Firefox 44.0 リリースノート”.  Mozilla Japan (2016年1月26日). 2016年3月9日閲覧。

(101)^ “Bug 1250568 - Allow enabling TLS 1.3”. 2016年6月24日閲覧。

(102)^ Microsoft (2012年9月5日). “Secure Channel”. 2012年10月18日閲覧。

(103)^ Microsoft (2009年2月27日). “MS-TLSP Appendix A”. 2014年7月2日閲覧。

(104)^ abc“What browsers only support SSLv2?”. 2014年7月2日閲覧。

(105)^ abcde“SHA2 and Windows - Windows PKI blog - Site Home - TechNet Blogs” (2010年9月30日). 2014年7月29日閲覧。

(106)^ http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512(v=vs.85).aspx

(107)^ http://support.microsoft.com/kb/948963

(108)^ abcdefg“Schannel の脆弱性により、セキュリティ機能のバイパスが起こる (3046049)” (2015年3月11日). 2015年3月11日閲覧。

(109)^ abcdefg“Schannel の脆弱性により、情報漏えいが起こる (3061518)” (2015年5月12日). 2015年5月23日閲覧。

(110)^ abcdefg“HTTPS Security Improvements in Internet Explorer 7”. 2014年7月2日閲覧。

(111)^ http://support.microsoft.com/gp/msl-ie-dotnet-an

(112)^ abcd“Windows 7 adds support for TLSv1.1 and TLSv1.2 - IEInternals - Site Home - MSDN Blogs”. 2014年7月2日閲覧。

(113)^ abcThomlinson, Matt (2014年11月11日). “Hundreds of Millions of Microsoft Customers Now Benefit from Best-in-Class Encryption”.  Microsoft Security. 2014年11月14日閲覧。

(114)^ Microsoft security advisory: Update for disabling RC4

(115)^ abcdMicrosoft (2013年9月24日). “IE11 Changes”. 2014年7月2日閲覧。

(116)^ “February 2015 security updates for Internet Explorer” (2015年2月11日). 2015年2月11日閲覧。

(117)^ “Update turns on the setting to disable SSL 3.0 fallback for protected mode sites by default in Internet Explorer 11”. 2015年2月11日閲覧。

(118)^ “SSL 3.0 の脆弱性により、情報漏えいが起こる” (2015年4月14日). 2015年4月15日閲覧。

(119)^ ab“Release Notes: Important Issues in Windows 8.1 Preview”.  Microsoft (2013年6月24日). 2014年11月4日閲覧。

(120)^ ab“W8.1(IE11) vs RC4 | Qualys Community”. 2014年11月4日閲覧。

(121)^ [http://www.zdnet.com/article/some-windows-10-enterprise-users-wont-get-microsofts-edge-browser

(122)^ abJustinha (2017年3月21日). “TLS (Schannel SSP) changes in Windows 10 and Windows Server 2016”. 2017年3月30日時点のオリジナルよりアーカイブ。2020年3月29日閲覧。

(123)^ http://forum.xda-developers.com/windows-phone-8/development/poodle-ssl-vulnerability-secure-windows-t2906203

(124)^ ab“What TLS version is used in Windows Phone 8 for secure HTTP connections?”.  Microsoft. 2014年11月7日閲覧。

(125)^ https://www.ssllabs.com/ssltest/viewClient.html?name=IE%20Mobile&version=10&platform=Win%20Phone%208.0

(126)^ ab“Platform Security”.  Microsoft (2014年6月25日). 2014年11月7日閲覧。

(127)^ “Opera 2 series”. 2014年9月20日閲覧。

(128)^ “Opera 3 series”. 2014年9月20日閲覧。

(129)^ “Opera 4 series”. 2014年9月20日閲覧。

(130)^ ab“Changelog for Opera 5.x for Windows”. 2014年7月2日閲覧。

(131)^ “Changelog for Opera [8] Beta 2 for Windows”. 2014年7月2日閲覧。

(132)^ “Web Specifications Supported in Opera 9”. 2014年7月2日閲覧。

(133)^ ab“Opera: Opera 10 beta for Windows changelog”. 2014年7月2日閲覧。

(134)^ “About Opera 11.60 and new problems with some secure servers” (2011年12月11日). 2012年1月18日時点のオリジナルよりアーカイブ。2014年9月21日閲覧。

(135)^ abc“Security changes in Opera 25; the poodle attacks” (2014年10月15日). 2014年10月28日閲覧。

(136)^ abcd“Unjam the logjam” (2015年6月9日). 2015年6月11日閲覧。

(137)^ “Advisory: RC4 encryption protocol is vulnerable to certain brute force attacks” (2013年4月4日). 2014年11月14日閲覧。

(138)^ “On the Precariousness of RC4” (2013年3月20日). 2013年11月12日時点のオリジナルよりアーカイブ。2014年11月17日閲覧。

(139)^ abcde“Opera 12 and Opera Mail security update” (2016年2月16日). 2016年2月17日閲覧。

(140)^ “Dev.Opera — Opera 14 for Android Is Out!” (2013年5月21日). 2014年9月23日閲覧。

(141)^ “Dev.Opera — Introducing Opera 15 for Computers, and a Fast Release Cycle” (2013年7月2日). 2014年9月23日閲覧。

(142)^ abChrome 26–29と同じ

(143)^ abChrome 30以降と同じ

(144)^ abChrome 33以降と同じ

(145)^ Adrian, Dimcev. “Common browsers/libraries/servers and the associated cipher suites implemented”. TLS Cipher Suites Project. 2014年7月2日閲覧。

(146)^ “Apple Secures Mac OS X with Mavericks Release - eSecurity Planet” (2013年10月25日). 2014年7月2日閲覧。

(147)^ Ristic, Ivan. “Is BEAST Still a Threat?”. qualys.com. 2014年7月2日閲覧。

(148)^ abIvan Ristić (2013年10月31日). “Apple enabled BEAST mitigations in OS X 10.9 Mavericks”. 2014年7月2日閲覧。

(149)^ Ivan Ristić (2014年2月26日). “Apple finally releases patch for BEAST”. 2014年7月2日閲覧。

(150)^ http://support.apple.com/kb/HT6531

(151)^ http://support.apple.com/kb/HT6541

(152)^ abc“About Security Update 2015-002”. 2015年3月10日閲覧。

(153)^ ab“About the security content of OS X Mavericks v10.9”. 2014年7月2日閲覧。

(154)^ “User Agent Capabilities: Safari 8 / OS X 10.10”.  Qualsys SSL Labs. 2015年3月7日閲覧。

(155)^ “About the security content of OS X Yosemite v10.10.4 and Security Update 2015-005”. 2015年7月3日閲覧。

(156)^ abcApple (2011年10月14日). “Technical Note TN2287 – iOS 5 and TLS 1.2 Interoperability Issues”. 2014年7月2日閲覧。

(157)^ Liebowitz, Matt (2011年10月13日). “Apple issues huge software security patches”. NBCNews.com. 2014年7月2日閲覧。

(158)^ MWR Info Security (2012年4月16日). “Adventures with iOS UIWebviews”. 2014年7月2日閲覧。, "HTTPS (SSL/TLS)"セクション

(159)^ “Secure Transport Reference”. 2014年7月2日閲覧。 iOSにおいてkSSLProtocol2は"deprecated"とされている

(160)^ “iPhone 3.0: Mobile Safari Gets Enhanced Security Certificate Visualization | The iPhone Blog” (2009年3月31日). 2009年4月3日時点のオリジナルよりアーカイブ。2014年9月21日閲覧。

(161)^ https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=7&platform=iOS%207.1

(162)^ schurtertom (2013年10月11日). “SOAP Request fails randomly on one Server but works on an other on iOS7”. 2014年7月2日閲覧。

(163)^ “User Agent Capabilities: Safari 8 / iOS 8.1.2”.  Qualsys SSL Labs. 2015年3月7日閲覧。

(164)^ “About the security content of iOS 8.2”. 2015年3月10日閲覧。

(165)^ “About the security content of iOS 8.4”. 2015年7月3日閲覧。

(166)^ Pauly, Tommy. “TLS 1.3 in iOS”. 2020年3月29日閲覧。

(167)^ [1]

(168)^ [2]

(169)^ [3]

(170)^ ab初期バージョンは対応

(171)^ abcde初期バージョンは非対応

(172)^ [4]

(173)^ [5]

(174)^ [6]

(175)^ [7]

(176)^ [8]

(177)^ “Version 1.11.13, 2015-01-11 — Botan” (2015年1月11日). 2015年1月17日閲覧。

(178)^ “[gnutls-devel GnuTLS 3.4.0 released]” (2015年4月8日). 2015年4月16日閲覧。

(179)^ “Add TLS v1.3 as an option by SparkiDev · Pull Request #661 · wolfSSL/wolfssl” (英語). GitHub. 2020年3月30日閲覧。

(180)^ “Java™ SE Development Kit 8, Update 31 Release Notes”. 2015年1月22日閲覧。

(181)^ “OpenBSD 5.6 Released” (2014年11月1日). 2015年1月20日閲覧。

(182)^ “LibreSSL 2.3.0 Released” (2015年9月23日). 2015年9月24日閲覧。

(183)^ “MatrixSSL - News”. 2014年11月9日閲覧。

(184)^ “mbed TLS 2.0.0 released” (2015年7月10日). 2015年7月14日閲覧。

(185)^ “NSS 3.24 release notes”. Mozilla Developer Network.  Mozilla. 2016年6月19日閲覧。

(186)^ “NSS 3.19 release notes”. Mozilla Developer Network.  Mozilla. 2015年5月6日閲覧。

(187)^ “NSS 3.14 release notes”. Mozilla Developer Network.  Mozilla. 2014年7月2日閲覧。

(188)^ “NSS 3.15.1 release notes”. Mozilla Developer Network.  Mozilla. 2014年7月2日閲覧。

(189)^ Mavrogiannopoulos, Nikos (Mon Jul 16 08:51:21 CEST 2018). “[gnutls-devel gnutls 3.6.3]”. 2020年3月30日閲覧。

(190)^ “Changes between 0.9.8n and 1.0.0 [29 Mar 2010]”. 2016年2月11日閲覧。

(191)^ ab“Major changes between OpenSSL 1.0.0h and OpenSSL 1.0.1 [14 Mar 2012]” (2012年3月14日). 2015年1月20日閲覧。

(192)^ “NSS 3.39 release notes” (英語). MDN Web Docs. 2020年3月30日閲覧。

(193)^ “RSA BSAFE Technical Specification Comparison Tables” (PDF). 2015年1月22日閲覧。

(194)^ TLS cipher suites in Microsoft Windows XP and 2003

(195)^ SChannel Cipher Suites in Microsoft Windows Vista

(196)^ abcTLS Cipher Suites in SChannel for Windows 7, 2008R2, 8, 2012

(197)^ “Protocols in TLS/SSL (Schannel SSP)”. 2017年6月8日閲覧。

(198)^ “Technical Note TN2287: iOS 5 and TLS 1.2 Interoperability Issues”. iOS Developer Library.  Apple Inc.. 2014年7月2日閲覧。

(199)^ [9]

(200)^ “[wolfssl] wolfSSL 3.6.6 Released” (2015年8月20日). 2015年8月25日閲覧。

(201)^ “TLS 1.3 Protocol Support”. 2022年9月6日閲覧。

(202)^ Freestart collision for full SHA-1 Marc Stevens and Pierre Karpman and Thomas Peyrin EUROCRYPT 2016

(203)^ “Mozilla Security Server Side TLS Recommended Configurations”.  Mozilla. 2015年1月3日閲覧。

(204)^ “Security Advisory 2868725: Recommendation to disable RC4”.  マイクロソフト (2013年11月12日). 2013年12月13日閲覧。

(205)^ “マイクロソフト セキュリティ アドバイザリ (2868725)　RC4 を無効化するための更新プログラム”.  マイクロソフト (2013年11月13日). 2013年12月13日閲覧。

(206)^ draft-popov-tls-prohibiting-rc4-02

(207)^ security – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune – Server Fault

(208)^ ivanr. “RC4 in TLS is Broken: Now What?”.  Qualsys Security Labs. 2013年7月30日閲覧。

(209)^ Pouyan Sepehrdad, Serge Vaudenay, Martin Vuagnoux (2011). “Discovery and Exploitation of New Biases in RC4”. Lecture Notes in Computer Science 6544: 74–91. doi:10.1007/978-3-642-19574-7_5. http://link.springer.com/chapter/10.1007%2F978-3-642-19574-7_5. 

(210)^ Green, Matthew. “Attack of the week: RC4 is kind of broken in TLS”. Cryptography Engineering. 2014年6月24日閲覧。

(211)^ Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt. “On the Security of RC4 in TLS”.  Royal Holloway University of London. 2014年6月24日閲覧。

(212)^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (8 July 2013) (PDF). On the Security of RC4 in TLS and WPA. http://www.isg.rhul.ac.uk/tls/RC4biases.pdf 2014年6月24日閲覧。. 

(213)^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (15 August 2013). On the Security of RC4 in TLS (PDF). 22nd USENIX Security Symposium. p. 51. 2014年6月24日閲覧。Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical

(214)^ John Leyden (2013年9月6日). “That earth-shattering NSA crypto-cracking: Have spooks smashed RC4?”.  The Register. 2013年12月13日閲覧。

(215)^ Qualys SSL Labs. “SSL/TLS Deployment Best Practices” (PDF). 2014年6月24日閲覧。

(216)^ Eric Rescorla、齋藤孝道、古森貞、鬼頭利之︵訳︶、2003、﹃マスタリングTCP/IP SSL/TLS編﹄、オーム社 ISBN 978-4274065422 p. 128

(217)^ 前掲﹁マスタリングTCP/IP SSL/TLS編﹂、p. 191。

(218)^ 暗号化通信に脆弱性﹁FREAK﹂が判明 - 盗聴や改ざんのおそれ Security NEXT、2015年3月5日閲覧。

(219)^ Only allow ephemeral RSA keys in export ciphersuites. OpenSSLのGithubツリー、2014年10月24日︵2015年3月5日閲覧︶

(220)^ Dan Goodin (2015年5月20日). “HTTPS-crippling attack threatens tens of thousands of Web and mail servers”.  Ars Technica. 2015年5月22日閲覧。

(221)^ A. Langley; N. Modadugu, B. Moeller (2012年6月). “Transport Layer Security (TLS) False Start”. Internet Engineering Task Force.  IETF. 2014年6月24日閲覧。

(222)^ Wolfgang, Gruener. “False Start: Google Proposes Faster Web, Chrome Supports It Already”. 2010年10月7日時点のオリジナルよりアーカイブ。2014年6月24日閲覧。

(223)^ Brian, Smith. “Limited rollback attacks in False Start and Snap Start”. 2014年6月24日閲覧。

(224)^ Adrian, Dimcev. “False Start”. Random SSL/TLS 101. 2014年6月24日閲覧。

(225)^ Mavrogiannopoulos, Nikos and Vercautern, Frederik and Velchkov, Vesselin and Preneel, Bart (2012) (PDF). A cross-protocol attack on the TLS protocol. Proceedings of the 2012 ACM conference on Computer and communications security. pp. 62–72. ISBN 978-1-4503-1651-4. https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf 

(226)^ Thai Duong and Juliano Rizzo (2011年5月13日). “Here Come The ⊕ Ninjas”. 2014年6月24日閲覧。

(227)^ Dan Goodin (2011年9月19日). “Hackers break SSL encryption used by millions of sites”. 2014年6月24日閲覧。

(228)^ “Y Combinator comments on the issue” (2011年9月20日). 2014年6月24日閲覧。

(229)^ “Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures” (2004年5月20日). 2012年6月30日時点のオリジナルよりアーカイブ。2014年6月24日閲覧。

(230)^ “Chrome Stable Release”. Chrome Releases.  Google (2011年10月25日). 2015年2月1日閲覧。

(231)^ “TLS 暗号化通信に対する攻撃の Firefox への影響”. Mozilla Japan ブログ.  Mozilla Japan (2011年9月28日). 2015年2月1日閲覧。

(232)^ “Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)” (2012年1月10日). 2014年6月24日閲覧。

(233)^ “Google、SSL 3.0の脆弱性﹁POODLE﹂を公表、SSL 3.0は今後サポート廃止の意向 -INTERNET Watch” (2014年10月15日). 2014年10月16日閲覧。

(234)^ abcdBodo Möller (2014年10月14日). “This POODLE bites: exploiting the SSL 3.0 fallback”. 2014年10月15日閲覧。

(235)^ RFC 7507

(236)^ Molland, Håvard (2014年10月15日). “Security changes in Opera 25; the poodle attacks”.  Opera. 2014年10月18日閲覧。

(237)^ “The POODLE Attack and the End of SSL 3.0” (2014年10月14日). 2014年10月15日閲覧。

(238)^ “SSL 3.0 の脆弱性により、情報漏えいが起こる” (2014年10月15日). 2014年10月15日閲覧。

(239)^ “Security Advisory 3009008 revised”. Microsoft TechNet.  マイクロソフト (2014年10月29日). 2014年10月30日閲覧。

(240)^ Oot, Alec (2014年12月9日). “December 2014 Internet Explorer security updates & disabling SSL 3.0 fallback”.  マイクロソフト. 2015年2月12日閲覧。

(241)^ “SSL 3.0 の脆弱性により、情報漏えいが起こる”.  セキュリティ TechCenter (2015年4月15日). 2015年4月16日閲覧。

(242)^ http://support.apple.com/kb/HT6531

(243)^ http://support.apple.com/kb/HT6541

(244)^ “NSS 3.17.1 release notes”.  Mozilla (2014年10月3日). 2014年10月20日閲覧。

(245)^ “NSS 3.16.2.3 release notes”.  Mozilla (2014年10月27日). 2014年10月27日閲覧。

(246)^ “Disable SSL 3 by default in NSS in April 2015.”.  mozilla.dev.tech.crypto (2014年10月27日). 2014年10月27日閲覧。

(247)^ “OpenSSL Security Advisory [15 Oct 2014]”.  OpenSSL (2014年10月15日). 2014年10月20日閲覧。

(248)^ “LibreSSL 2.1.1 released.”.  LibreSSL (2014年10月16日). 2014年10月20日閲覧。

(249)^ Langley, Adam (2014年12月8日). “The POODLE bites again”. 2014年12月10日閲覧。

(250)^ Ristic, Ivan (2014年12月8日). “Poodle Bites TLS”. 201-12-10閲覧。

(251)^ Stosh, Brandon (2014年12月8日). “Nasty POODLE Variant Bypasses TLS Crypto Affecting Over 10 Percent of the Web”. 2014年12月10日閲覧。

(252)^ Dan Goodin (2012年9月13日). “Crack in Internet's foundation of trust allows HTTPS session hijacking”.  Ars Technica. 2014年6月24日閲覧。

(253)^ Dennis Fisher (2012年9月13日). “CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions”.  ThreatPost. 2014年6月24日閲覧。[リンク切れ]

(254)^ abGoodin, Dan (2013年8月1日). “Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages”. Ars Technica.  Condé Nast. 2014年6月24日閲覧。

(255)^ Leyden, John (2013年8月2日). “Step into the BREACH: New attack developed to read encrypted web data”. The Register. 2014年6月24日閲覧。

(256)^ Ray, Marsh; Steve Dispensa (2009年11月4日). “Renegotiating TLS” (PDF) (英語). 2010年2月13日閲覧。

(257)^ “JVNVU#120541 SSL および TLS プロトコルに脆弱性”. Japan Vulnerability Notes.  JPCERT/CC and IPA (2009年11月13日). 2010年2月13日閲覧。

(258)^ abJohn Leyden (2013年8月1日). “Gmail, Outlook.com and e-voting 'pwned' on stage in crypto-dodge hack”. The Register. 2014年6月24日閲覧。

(259)^ “BlackHat USA Briefings”. Black Hat 2013. 2014年6月24日閲覧。

関連項目

[編集]
ウィクショナリーにSSLの項目があります。

外部リンク

[編集]

標準化

[編集]
  • 2018年9月時点での最新版
    • RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
  • 過去の版
    • RFC 2246: "The TLS Protocol Version 1.0".
    • RFC 4346: "The Transport Layer Security (TLS) Protocol Version 1.1".
    • RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
    • RFC 8996: "Deprecating TLS 1.0 and TLS 1.1"
  • SSLは標準化されていない
    • Hickman, Kipp E.B. (1995年4月). “The SSL Protocol”. 2013年7月31日閲覧。 This Internet Draft defines the now completely broken SSL 2.0.
    • RFC 6101: "The Secure Sockets Layer (SSL) Protocol Version 3.0".
  • TLS 1.0の拡張
    • RFC 2595: "Using TLS with IMAP, POP3 and ACAP". Specifies an extension to the IMAP, POP3 and ACAP services that allow the server and client to use transport-layer security to provide private, authenticated communication over the Internet.
    • RFC 2712: "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". The 40-bit cipher suites defined in this memo appear only for the purpose of documenting the fact that those cipher suite codes have already been assigned.
    • RFC 2817: "Upgrading to TLS Within HTTP/1.1", explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443).
    • RFC 2818: "HTTP Over TLS", distinguishes secured traffic from insecure traffic by the use of a different 'server port'.
    • RFC 3207: "SMTP Service Extension for Secure SMTP over Transport Layer Security". Specifies an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet.
    • RFC 3268: "AES Ciphersuites for TLS". Adds Advanced Encryption Standard (AES) cipher suites to the previously existing symmetric ciphers.
    • RFC 3546: "Transport Layer Security (TLS) Extensions", adds a mechanism for negotiating protocol extensions during session initialisation and defines some extensions. Made obsolete by RFC 4366.
    • RFC 3749: "Transport Layer Security Protocol Compression Methods", specifies the framework for compression methods and the DEFLATE compression method.
    • RFC 3943: "Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)".
    • RFC 4132: "Addition of Camellia Cipher Suites to Transport Layer Security (TLS)".
    • RFC 4162: "Addition of SEED Cipher Suites to Transport Layer Security (TLS)".
    • RFC 4217: "Securing FTP with TLS".
    • RFC 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", adds three sets of new cipher suites for the TLS protocol to support authentication based on pre-shared keys.
  • TLS 1.1の拡張
    • RFC 4347: "Datagram Transport Layer Security" specifies a TLS variant that works over datagram protocols (such as UDP).
    • RFC 4366: "Transport Layer Security (TLS) Extensions" describes both a set of specific extensions and a generic extension mechanism.
    • RFC 4492: "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)".
    • RFC 4680: "TLS Handshake Message for Supplemental Data".
    • RFC 4681: "TLS User Mapping Extension".
    • RFC 4785: "Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)".
    • RFC 5054: "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". Defines the TLS-SRP ciphersuites.
    • RFC 5077: "Transport Layer Security (TLS) Session Resumption without Server-Side State".
    • RFC 5081: "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", obsoleted by RFC 6091.
  • TLS 1.2の拡張
    • RFC 5288: "AES Galois Counter Mode (GCM) Cipher Suites for TLS".
    • RFC 5469: "DES and IDEA Cipher Suites for Transport Layer Security (TLS)"
    • RFC 5289: "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)".
    • RFC 5487: "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode"
    • RFC 5489: "ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)"
    • RFC 5746: "Transport Layer Security (TLS) Renegotiation Indication Extension".
    • RFC 5878: "Transport Layer Security (TLS) Authorization Extensions".
    • RFC 5932: "Camellia Cipher Suites for TLS"
    • RFC 6042: "Transport Layer Security (TLS) Authorization Using KeyNote".
    • RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions", includes Server Name Indication and OCSP stapling.
    • RFC 6091: "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication".
    • RFC 6176: "Prohibiting Secure Sockets Layer (SSL) Version 2.0".
    • RFC 6209: "Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)".
    • RFC 6347: "Datagram Transport Layer Security Version 1.2".
    • RFC 6358: "Additional Master Secret Inputs for TLS"
    • RFC 6367: "Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)".
    • RFC 6460: "Suite B Profile for Transport Layer Security (TLS)".
    • RFC 6655: "AES-CCM Cipher Suites for Transport Layer Security (TLS)".
    • RFC 6961: "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension"
    • RFC 7027: "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)".
    • RFC 7250: "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"
    • RFC 7251: "AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS".
    • RFC 7301: "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension".
    • RFC 7366: "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)".
    • RFC 7465: "Prohibiting RC4 Cipher Suites".
    • RFC 7507: "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks".
    • RFC 7568: "Deprecating Secure Sockets Layer Version 3.0".
    • RFC 7627: "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension".
    • RFC 7685: "A Transport Layer Security (TLS) ClientHello Padding Extension".
    • RFC 7905: "ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)".
    • RFC 7918: "Transport Layer Security (TLS) False Start"
    • RFC 7919: "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)".
    • RFC 7924: "Transport Layer Security (TLS) Cached Information Extension"
    • RFC 7925: "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things"
    • RFC 8442: "ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2"
    • RFC 8422: "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier"
    • RFC 8701: "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility"
    • RFC 8492: "Secure Password Ciphersuites for Transport Layer Security (TLS)"
  • TLS 1.3の拡張
    • RFC 8449: "Record Size Limit Extension for TLS"
    • RFC 8672: "TLS Server Identity Pinning with Tickets"
    • RFC 8734: "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3"
    • RFC 8879: "TLS Certificate Compression"
    • RFC 8902: "TLS Authentication Using Intelligent Transport System (ITS) Certificates"
    • RFC 8998: "ShangMi (SM) Cipher Suites for TLS 1.3"
  • TLSを含むカプセル化
    • RFC 5216: "The EAP-TLS Authentication Protocol"
    • RFC 8472: "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation"
  • X.509 (PKIX)との関係性
    • RFC 6125: "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"
    • RFC 7633: "X.509v3 Transport Layer Security (TLS) Feature Extension"
  • その他
    • RFC 5705: "Keying Material Exporters for Transport Layer Security (TLS)"
    • RFC 7457: "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)"
    • RFC 7525: "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"
    • RFC 8447: "IANA Registry Updates for TLS and DTLS"
    • RFC 8448: "Example Handshake Traces for TLS 1.3"
    • RFC 8744: "Issues and Requirements for Server Name Identification (SNI) Encryption in TLS"

IANA

[編集]
7. アプリケーション層

6. プレゼンテーション層

5. セッション層

4. トランスポート層

3. ネットワーク層

2. データリンク層

1. 物理層

カテゴリ カテゴリ
プロトコル

技術

歴史

実装

公証

脆弱性

理論

暗号

プロトコル

実装

クロスサイト攻撃

インジェクション攻撃 (CWE-74)

スプーフィング攻撃

セッションハイジャック関連

DoS攻撃

サイドチャネル攻撃

不適切な入力確認 (CWE-20)

未分類

対策

関連項目

「https://ja.wikipedia.org/w/index.php?title=Transport_Layer_Security&oldid=100961114」から取得