Transport Layer Securityのソースを表示

{{IPstack}}
<!-- Edit the stack image at: Template:IPstack -->
'''Transport Layer Security'''（トランスポート・レイヤー・セキュリティー、'''TLS'''）は、[[セキュア通信|セキュリティーを要求される通信]]のための[[通信プロトコル|プロトコル]]である。また、当プロトコルを発表した[[IETF]]の作業部会の名前でもある。歴史的な理由により、当プロトコルは、しばしば（特に区別する場合を除いて）'''Secure Sockets Layer''' ('''SSL''') とも呼ばれている。これは、TLSの元になったプロトコルがSSLだったこと<ref>プロトコル名を含めた歴史については、Eric Rescorla著,「マスタリングTCP/IP SSL/TLS編」,オーム社開発局(2003年) ISBN 4-274-06542-1 の2章6節が詳しい。</ref>と、SSLという名称が広く普及していることによる。以下においては、特にことわりのないかぎり、作業部会ではなく、プロトコルのほうを指す。

TLSは、コネクション型の[[OSI参照モデル#トランスポート層|トランスポート層]]プロトコルの上位に位置し、通常は[[Transmission Control Protocol|TCP]]がラップする形で利用される。特に[[Hypertext Transfer Protocol|HTTP]]での利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存しない。

== バージョン ==
=== SSL 1.0 ===
[[ネットスケープコミュニケーションズ]]社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな[[セキュリティホール#脆弱性|脆弱性]]が発見され、破棄された。このため、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=Microsoft Corporation
|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=http://itpro.nikkeibp.co.jp/article/NEWS/20060602/239846/
|title=「SSL 2.0だけに対応したWebサイトはわずか0.1％」---ネットクラフト
|publisher=[[日経BP]] IT pro
|accessdate=2010-01-03
}}</ref>。

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

=== SSL 3.0 ===
ネットスケープコミュニケーションズ社はSSL 2.0の問題を修正するとともに機能追加を行い、[[1995年]]にSSL 3.0を発表した。また、Netscape Navigator 2.0においてSSL 3.0を実装した。SSL 3.0の仕様書については、2011年に[[IETF]]から歴史的文書という扱いでRFC 6101として公開された。

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

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

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

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

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

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

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

==={{anchors|TLS 1.3}}TLS 1.3（草稿）===
2014年7月現在、TLS 1.3が新たなTLSのバージョンとして提案されている<ref>[http://tools.ietf.org/html/draft-ietf-tls-tls13-02 draft-ietf-tls-tls13-02]</ref><ref>[https://tlswg.github.io/tls13-spec/ draft-ietf-tls-tls13-latest]</ref>。TLS 1.2からの変更点としては、[[データ圧縮]]の非サポート、[[forward secrecy]]ではないcipher suiteおよび{{仮リンク|AEAD|en|AEAD block cipher modes of operation}}ではないcipher suite（[[暗号利用モード|CBCモード]]の[[ブロック暗号]]や[[RC4]]を用いたもの）の廃止が挙げられる。

ネゴシエーションにおけるバージョン番号は3.4となる予定。

== 提供する機能 ==
[[ファイル:SSLによるセキュアな通信.jpg|360px|thumb|SSLによるセキュアな通信]]
TLSは、[[認証]]・[[暗号|暗号化]]・[[改竄]]検出の機能を提供する。具体的なアルゴリズムはそれぞれ複数の選択肢が定義されており、TLS通信の開始時に行われるネゴシエーション時に、双方が許容するアルゴリズムの中から選択される。

選択肢によっては、攻撃への耐性の強度が大きく変化する場合もある（極端な例だが、双方が同意すれば「暗号化なし」を選択することもできる）。許容できない選択肢はあらかじめネゴシエーションの候補から外しておいたり、また望ましくないアルゴリズムが選択された場合はユーザーに警告したりといった対策が考えられる。一般に公開されている製品は、実際にこれらの対策が取られている。

なお、選択できるアルゴリズムはTLS/SSLのバージョンによって異なる。また、認証、暗号化、改竄検出の3つをひとまとめにして選択肢が定義されており、しかも全ての組み合わせが網羅されているわけではないので、同時に利用できない組み合わせも存在する。

=== 認証・鍵共有 ===
TLSは[[公開鍵証明書]]に基づく認証および鍵共有を提供する。使用する署名アルゴリズムの選択肢は以下のとおりである。

{| class="wikitable" style="text-align:center"
|+ TLSの各バージョンで使用できる署名アルゴリズム
! アルゴリズム !! SSL 2.0 !! SSL 3.0 !! TLS 1.0 !! TLS 1.1 !! TLS 1.2
|-
! {{partial|[[RSA暗号|RSA]]}}
| {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}}
|-
! {{partial|[[ディフィー・ヘルマン鍵共有|DH]]-[[RSA暗号|RSA]]}}
| rowspan="2" ! {{No|非対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
|-
! {{yes|[[ディフィー・ヘルマン鍵共有|DHE]]-[[RSA暗号|RSA]] ([[forward secrecy]])}}
|-
! {{partial|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDH]]-[[RSA暗号|RSA]]}}
| rowspan="2" ! {{No|非対応}}
| rowspan="2" ! {{No|非対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
|-
! {{yes|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDHE]]-[[RSA暗号|RSA]] ([[forward secrecy]])}}
|-
! {{partial|[[ディフィー・ヘルマン鍵共有|DH]]-[[Digital Signature Algorithm|DSS]]}}
| rowspan="2" ! {{No|非対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
|-
! {{yes|[[ディフィー・ヘルマン鍵共有|DHE]]-[[Digital Signature Algorithm|DSS]] ([[forward secrecy]])}}
|-
! {{partial|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDH]]-[[楕円曲線DSA|ECDSA]]}}
| rowspan="2" ! {{No|非対応}}
| rowspan="2" ! {{No|非対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
|-
! {{yes|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDHE]]-[[楕円曲線DSA|ECDSA]] ([[forward secrecy]])}}
|-
! {{no|[[ディフィー・ヘルマン鍵共有|DH]]-[[匿名|ANON]]（安全ではない）}}
| {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}}
|-
! {{no|[[楕円曲線ディフィー・ヘルマン鍵共有|ECDH]]-[[匿名|ANON]]（安全ではない）}}
| {{No|非対応}} || {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}}
|}

TLSの一般的な用途では、サーバだけが証明書を提示し、クライアントがその正当性を確認する。オプションでクライアント認証も可能であり、必要な場合にはサーバがクライアントに対して証明書の提示を求める。

なりすましを防ぐために、証明書には[[認証局]] (CA; Certification Authority) による[[電子署名]]が必要である。また、サーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。この確認を行わない場合、攻撃者はサーバAの管理者でなくても、自分が管理するサーバBの正当な証明書を取得して、その証明書を使ってサーバAを名乗ることができてしまう。

証明書に関する問題については「[[#証明書の正当性]]」の節を参照。

なお証明書には有効期限が設定されている。暗号理論およびコンピュータの計算能力は日々進歩しており、現在安全とみなされる技術であっても長年にわたって安全性を保てる保証はない。また現代暗号は[[計算量的安全性|解読に莫大な計算量が必要となる設計]]ではあるが、裏を返せばそれだけの計算量をこなせば解読できてしまうと言える。このため、一定期間ごとに証明書を再発行し、鍵を変更するとともに必要に応じて使用するアルゴリズムも更新している。

共通鍵は、クライアントとサーバの双方から提供される[[乱数列|乱数]]に基づいて決定される。双方で生成した乱数を組み合わせて使用するため、リプレイ攻撃では同一の共通鍵を得ることはできない。共通鍵は4つセットで生成し、クライアントから送信するデータの暗号化用とサーバから送信するデータの暗号化用にひとつずつ割り当てる（残り2つは後述するハッシュ値の生成に使われる）。

鍵の盗聴を防ぐ仕組みとして、サーバ証明書がRSA暗号を用いて署名されている場合は、クライアントから送る鍵情報の一部をサーバの公開鍵で暗号化することができる。サーバの秘密鍵を知らない部外者は、この情報を復号できない。あるいは鍵共有を公開鍵のみに頼らず、[[ディフィー・ヘルマン鍵共有]] (DH)、[[楕円曲線ディフィー・ヘルマン鍵共有]] (ECDH) のような鍵共有アルゴリズムを用いることも可能である。さらに、共有アルゴリズムで共有される鍵を一時的な (ephemeral) ものとすることで、将来万が一サーバの秘密鍵が判明したとしてもそれだけではセッションキーを割り出せない、[[Forward secrecy]]<!--定訳がないので記事名も英語のままです-->を実現することもできる (DHE、ECDHE)。

DHおよびECDHでの鍵共有では、サーバ証明書を利用せずに匿名での鍵共有を行う DH_anon、ECDH_anon と呼ばれる暗号スイートが存在するが、[[中間者攻撃]]に対して脆弱であることから安全とはみなされていない。

=== 暗号化 ===
[[共通鍵暗号]]に基づく暗号化を提供する。以下のアルゴリズムが選択肢として定義されている。

{| class="wikitable" style="text-align:center"
|+ TLS/SSLの各バージョンで使用できる暗号化アルゴリズム
! colspan="3"|暗号化 !! colspan="5" | プロトコルバージョン
|-
! 種類 !! アルゴリズム !! 暗号強度<br/>(bit) !! SSL 2.0 !! SSL 3.0<br/><ref group="注" name="RFC 5746">[[#再ネゴシエーション脆弱性|再ネゴシエーション脆弱性]]への対応のため、RFC 5746への対応が必要</ref><ref group="注">RFC 5746への対応はSSL 3.0の仕様を逸脱するが、ほとんどの実装では対応したうえで仕様からの逸脱にも対処している</ref><ref group="注" name="BEAST">TLS 1.0以前では[[#BEAST攻撃|BEAST攻撃]]に対して脆弱であり、クライアント側、サーバ側での対応が必要</ref> || TLS 1.0<br/><ref group="注" name="RFC 5746"/><ref group="注" name="BEAST"/> !! TLS 1.1<br/><ref group="注" name="RFC 5746"/> !! TLS 1.2<br/><ref group="注" name="RFC 5746"/>
|-
! rowspan="13"|[[ブロック暗号]]<br/>（[[暗号利用モード]]）
! [[Advanced Encryption Standard|AES]] [[暗号利用モード|CBC]]<ref group="注" name="Lucky13"/>
! rowspan="3"| 128, 256
| {{n/a}} ||{{n/a}} || {{partial|実装による}} || {{yes|安全}} || {{yes|安全}} 
|-
! [[Advanced Encryption Standard|AES]] [[Galois/Counter Mode|GCM]]<ref group="注">RFC 5288による追加</ref><ref group="注" name="AEAD">GCM、CCMなどのAEAD（認証付き暗号モード）は、TLS 1.2のみで利用可能</ref>
| {{n/a}} ||{{n/a}} ||{{n/a}} ||{{n/a}} || {{yes|安全}}
|-
! [[Advanced Encryption Standard|AES]] [[Counter with CBC-MAC|CCM]]<ref group="注">RFC 6655による追加</ref><ref group="注" name="AEAD"/>
| {{n/a}} ||{{n/a}} ||{{n/a}} ||{{n/a}} || {{yes|安全}}
|-
! [[Camellia|CAMELLIA]] [[暗号利用モード|CBC]]<ref group="注">RFC 5932およびRFC 6367による追加</ref><ref group="注" name="Lucky13"/>
! rowspan="2"| 128, 256
| {{n/a}} ||{{n/a}} || {{partial|実装による}} || {{yes|安全}} || {{yes|安全}} 
|-
! [[Camellia|CAMELLIA]] [[Galois/Counter Mode|GCM]]<ref group="注">RFC 6367による追加</ref><ref group="注" name="AEAD"/>
| {{n/a}} ||{{n/a}} ||{{n/a}} ||{{n/a}} || {{yes|安全}}
|-
! [[SEED (暗号)|SEED]] [[暗号利用モード|CBC]]<ref group="注">RFC 4162による追加</ref><ref group="注" name="Lucky13"/>
! 128
| {{n/a}} ||{{n/a}} || {{partial|実装による}} || {{yes|安全}} || {{yes|安全}} 
|-
! {{仮リンク|ARIA (暗号)|label=ARIA|en|ARIA (cipher)}} [[暗号利用モード|CBC]]<ref group="注">RFC 6209による追加</ref><ref group="注" name="Lucky13"/>
! rowspan="2"| 128, 256
| {{n/a}} ||{{n/a}} || {{partial|実装による}} || {{yes|安全}} || {{yes|安全}} 
|-
! {{仮リンク|ARIA (暗号)|label=ARIA|en|ARIA (cipher)}} [[Galois/Counter Mode|GCM]]<ref group="注">RFC 6209による追加</ref><ref group="注" name="AEAD"/>
| {{n/a}} ||{{n/a}} ||{{n/a}} ||{{n/a}} || {{yes|安全}}
|-
! [[International Data Encryption Algorithm|IDEA]] [[暗号利用モード|CBC]]<ref group="注" name="Lucky13"/><ref group="注" name="removal by TLS1.2">IDEA、DESはTLS 1.2で廃止された</ref>
! 128
| {{no|安全ではない}} || {{partial|実装による}} || {{partial|実装による}} || {{yes|安全}} || {{n/a}} 
|-
! [[トリプルDES|3DES EDE]] [[暗号利用モード|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)''|date=2007-03-08|accessdate=2014-07-03}}</ref>、2014年現在で最低限必要とされる128ビットに不足している<ref name="best-practices">{{cite web|url=https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf|title=SSL/TLS Deployment Best Practices|author=Qualys SSL Labs|accessdate=19 November 2013}}</ref>}}
| {{no|安全ではない}} || {{partial|強度不足、実装による}} || {{partial|強度不足、実装による}} || {{partial|強度不足}} || {{partial|強度不足}} 
|-
! rowspan="2"| [[Data Encryption Standard|DES]] [[暗号利用モード|CBC]]<ref group="注" name="Lucky13"/><ref group="注" name="removal by TLS1.2"/>
! 56
| {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{n/a}}
|-
! 40<ref group="注" name="EXPORT">40ビットのセキュリティ強度を持つCipher Suiteは、[[アメリカ合衆国]]による[[アメリカ合衆国からの暗号の輸出規制|高強度暗号アルゴリズムの輸出規制]]を回避するために設計された。これらはTLS 1.1以降では利用が禁止されている。</ref>
| {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{n/a}} || {{n/a}}
|-
! [[RC2]] [[暗号利用モード|CBC]]<ref group="注" name="Lucky13"/>
! 40<ref group="注" name="EXPORT"/>
| {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{n/a}} || {{n/a}}
|-
! rowspan="3"|[[ストリーム暗号]]
! [[ChaCha20|CHACHA20]]+[[Poly1305|POLY1305]]<ref group="注">[https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 draft-agl-tls-chacha20poly1305-04]および[http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02 draft-mavrogiannopoulos-chacha-tls-02]による提唱</ref><ref group="注" name="AEAD"/>
! 256
| {{n/a}} ||{{n/a}} ||{{n/a}} ||{{n/a}} || {{yes|安全}}
|-
! rowspan="2"| [[RC4]]<ref group="注" name="RC4">脆弱性が指摘されている（[[#RC4攻撃|RC4攻撃]]）</ref>
! 128
| {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}}
|-
! 40<ref group="注" name="EXPORT"/>
| {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{n/a}} || {{n/a}}
|-
! 暗号化なし
! NULL
! -
| {{n/a}} || {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} || {{no|安全ではない}} 
|}
{{reflist|group="注"}}

[[Advanced Encryption Standard|AES]] CBCはTLS 1.0を定義するRFC 2246には含まれていないが、RFC 3268で追加された。TLS 1.1を定義するRFC 4346からはRFC 3268が参照されており、さらにTLS 1.2では定義であるRFC 5246にAES CBCに関する記述が取り込まれた。また、個別のRFCによって[[Camellia]] CBC（RFC 4132、RFC 5932、RFC 6367）、[[SEED (暗号)|SEED]] CBC（RFC 4162）および{{仮リンク|ARIA (暗号)|label=ARIA|en|ARIA (cipher)}} CBC（RFC 6209）が、[[認証付き暗号]]による[[Advanced Encryption Standard|AES]] [[Galois/Counter Mode|GCM]]（RFC 5288）、[[Advanced Encryption Standard|AES]] [[Counter with CBC-MAC|CCM]]（RFC 6655）、[[Camellia]] GCM（RFC 6367）およびおよび{{仮リンク|ARIA (暗号)|label=ARIA|en|ARIA (cipher)}} GCM（RFC 6209）が追加されている。[[International Data Encryption Algorithm|IDEA]] CBC、[[Data Encryption Standard|DES]] CBCはTLS1.2で廃止された（RFC 5469に解説がある）。

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

[[ストリーム暗号]]である[[RC4]]は前述のBEAST攻撃を受けることはないが、RC4には仕様上の脆弱性が存在し（[[#RC4攻撃|RC4攻撃]]）、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?|author=John Leyden|date=2013-09-06|publisher=The Register|accessdate=2013-12-13}}</ref>。[[Microsoft]]ではRC4を無効化することを推奨している<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|date=2013-11-12|publisher=Microsoft|accessdate=2013-12-13}}</ref><ref>{{cite web|url=http://technet.microsoft.com/ja-jp/security/advisory/2868725|title=マイクロソフト セキュリティ アドバイザリ (2868725)　RC4 を無効化するための更新プログラム|date=2013-11-13|publisher=Microsoft|accessdate=2013-12-13}}</ref><ref>[http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 draft-popov-tls-prohibiting-rc4-02]</ref>。[[Google]]によって、ストリーム暗号である[[ChaCha20]]と認証のための[[Poly1305]]を組み合わせたChaCha20+Poly1305が提唱されている<ref name="ChaCha20">[https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 draft-agl-tls-chacha20poly1305-04]</ref>。

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

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

=== 改竄検出 ===
TLSでデータレコードを送信する際には、レコードのシーケンス番号、共通鍵、そしてデータから[[メッセージ認証コード]] (MAC) を算出し、それをレコードに付加して送信する。ハッシュ関数に基づくMACである[[HMAC]]（[[MD5]]、[[SHA-1]]あるいは[[SHA-2|SHA-256/384]]との組み合わせ）あるいは{{仮リンク|AEAD|en|AEAD block cipher modes of operation}}（[[Galois/Counter Mode|GCM]]や[[Counter with CBC-MAC|CCM]]などの[[認証付き暗号]]の場合）が用いられる。共有秘密鍵を知らない攻撃者は、データを改竄してもそれに対応するMACを生成できない。したがって受信者は、手元で送信者と同様にMACの計算を行ない、同一の値が得られるかを確認することで改竄の有無を検出できる。一部のレコードを重複して送りつける[[反射攻撃|リプレイ攻撃]]は、シーケンス番号が異なるため、やはりMACで検出できる。また、（アプリケーション層プロトコルによる代替手段がない限り）通信の終了を知らせるレコードを送り合うことになっているため、これが送られないうちに接続が切断された場合は、強制切断攻撃を受けたと判断することができる。

TLS/SSLの各バージョンで使用できる改竄検出の選択肢は以下のとおりである：

{| class="wikitable" style="text-align:center"
|+ TLS/SSLの各バージョンで使用できる改竄検出
! アルゴリズム !! SSL 2.0 !! SSL 3.0 !! TLS 1.0 !! TLS 1.1 !! TLS 1.2
|-
! [[HMAC]]-[[MD5]]
| {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}}
|-
! [[HMAC]]-[[SHA-1|SHA1]]
| {{No|非対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}} || {{Yes|対応}}
|-
! [[HMAC]]-[[SHA-2|SHA256/384]]
| {{No|非対応}} || {{No|非対応}} || {{No|非対応}} || {{No|非対応}} || {{Yes|対応}}
|-
! {{仮リンク|AEAD|en|AEAD block cipher modes of operation}}
| {{No|非対応}} || {{No|非対応}} || {{No|非対応}} || {{No|非対応}} || {{Yes|対応}}
|}

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

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

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

== 実装 ==
=== ウェブサイト ===
{|class="wikitable sortable" style="text-align: center;"
|+ウェブサイトにおけるTLS/SSLの対応状況
|-
!プロトコル
!ウェブサイトにおけるサポート<ref name="trustworthy_ssl_pulse">2014年8月3日現在 {{cite web|url=https://www.trustworthyinternet.org/ssl-pulse/|accessdate=2014-08-15|title=SSL Pulse: Survey of the SSL Implementation of the Most Popular Web Sites}}</ref>
!セキュリティ<ref name="trustworthy_ssl_pulse"/><ref name="community.qualys">{{cite web|url=https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what|accessdate=2013-07-30|publisher=Qualsys Security Labs|author=ivanr|title=RC4 in TLS is Broken: Now What?}}</ref>
|-
|SSL 2.0
|20.5% (−0.6%)
|{{No|安全ではない}}
|-
|SSL 3.0
|98.5% (−0.2%)
|{{Partial|暗号アルゴリズム<ref group="注" name="ciphers">[[#暗号化]]を参照のこと</ref>および脆弱性への対処<ref group="注" name="mitigations">[[#ウェブブラウザ]]および[[#既知の攻撃]]を参照のこと</ref>による}}
|-
|TLS 1.0
|99.3% (±0.0%)
|{{Partial|暗号アルゴリズム<ref group="注" name="ciphers"/>および脆弱性への対処<ref group="注" name="mitigations"/>による}}
|-
|TLS 1.1
|38.4% (+2.4%)
|{{Partial|暗号アルゴリズム<ref group="注" name="ciphers"/>および脆弱性への対処<ref group="注" name="mitigations"/>による}}
|-
|TLS 1.2
|40.8% (+2.3%)
|{{Partial|暗号アルゴリズム<ref group="注" name="ciphers"/>および脆弱性への対処<ref group="注" name="mitigations"/>による}}
|}
;注
{{reflist|group="注"}}

=== ウェブブラウザ ===
2014年7月現在、主要なウェブブラウザの最新版ではSSL 3.0、TLS 1.0、1.1、1.2のすべてが既定で有効であり、既知の脆弱性への対応も済んでいる。しかし、過去のバージョンのOS向けなど、最新ではないがサポートが継続しているウェブブラウザのいくつかのバージョンではそうではない。
* TLS 1.1、1.2に対応しているが既定で無効：[[Mozilla Firefox]] ESR 24（延長サポート版）、[[Internet Explorer]] 8–10（Windows 7向け）、IE 10（Windows 8向け）、Opera 12（[[Presto]]版）
* TLS 1.1、1.2に未対応：Internet Explorer 7–9（Windows Vista向け）、[[Safari]] 6（OS X 10.7、10.8向け）
* 既知の脆弱性に未対応：Safari 6（OS X 10.7向け）

{{clear}}
{|class="wikitable sortable" style="text-align: center; font-size: smaller;"
|+'''ウェブブラウザにおけるTLS/SSLの対応状況の変化'''
! ウェブブラウザ
! バージョン
! プラットフォーム
! SSL 2.0（安全ではない）
! SSL 3.0
! TLS 1.0
! TLS 1.1
! TLS 1.2
! [[Extended Validation 証明書|EV証明書]]<ref name=EVSSLbrowser>{{cite web|url=https://knowledge.verisign.co.jp/support/ssl-certificates-support/index?vproductcat=V_C_S&vdomain=VERISIGN.JP&page=content&id=SO23172&actp=search&viewlocale=ja_JP&searchid=1395731352735&locale=ja_JP&redirected=true|title=緑色のバーの表示について|publisher=[[シマンテック]]|accessdate=2014-07-29}}</ref>
! [[SHA-2]]証明書<ref name="SHA-2">{{cite web|title=SHA-256 Compatibility|accessdate=2014-07-29|url=https://www.globalsign.com/sha-256-compatibility/}}</ref>
! 脆弱性への対応{{refn | group="注" | name="note-sec" |既知の脆弱性（BEAST, CRIME, BREACH, Lucky Thirteen：[[#既知の攻撃]]を参照）に対する対応がされているか否か。暗号アルゴリズムや暗号強度は考慮しない（[[#暗号化]]参照）。}}
|-
! rowspan="4" | [[Google Chrome]]<br />{{refn |group="注" |name="note-a" |[[Google Chrome]]（および[[Chromium]]）はバージョン21でTLS 1.1に対応したもののいったん撤回され、バージョン22で再度有効となった。TLS 1.2についても、バージョン29で有効となったものが撤回され、バージョン30で再度有効となった<ref>{{cite web |author=Google |url=http://googlechromereleases.blogspot.nl/2012/05/dev-channel-update_29.html |title=Dev Channel Update |date=2012-05-29|accessdate=2014-07-02}}</ref><ref>{{cite web |author=Google |url=http://googlechromereleases.blogspot.co.uk/2012/08/stable-channel-update_21.html |title=Stable Channel Update |date=2012-08-21 |accessdate=2014-07-02}}</ref><ref>{{cite web |author=Chromium Project |url=http://src.chromium.org/viewvc/chrome?revision=203090&view=revision |title=Chromium TLS 1.2 Implementation |date=2013-05-30|accessdate=2014-07-02}}</ref>。}}<br /> <ref group="注" name="note-b">TLSの実装はAndroid版のみ[[OpenSSL]]、それ以外のプラットフォームでは[[Network Security Services|NSS]]による。</ref>
| style="background:salmon;" | 0–9
| rowspan="4" | Android,<br /> iOS,<br /> Linux,<br /> Mac OS X,<br />Windows
| {{Yes|既定で無効}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{partial|バージョン1より対応}}
| {{No|非対応}}
| {{No|未対応、開発終了}}
|-
| style="background:salmon;" | 10–21
| {{Yes|非対応}}<ref>{{cite web|url=http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=72316:67679&mode=html|title=SVN revision log on Chrome 10.0.648.127 release|accessdate=2014-07-02}}</ref>
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{Yes|対応}}
| {{No|非対応}}
| {{No|おそらく未対応、開発終了}}
|-
| style="background:salmon;" | 22–29
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}<ref name="SSL/TLS Overview">{{cite web |url=https://sites.google.com/site/tlsssloverview/ssl-v-tls/tls-versions-and-browser-compatability |title=SSL/TLS Overview|date=2008-08-06 |accessdate=2014-07-02 }}</ref>
| {{No|非対応}}<ref name="SSL/TLS Overview" /><ref name="Chromium Issue 90392">{{cite web |url=https://code.google.com/p/chromium/issues/detail?id=90392 |title=Chromium Issue 90392 |date=2008-08-06 |accessdate=2014-07-02}}</ref><ref name="Issue 23503030 Merge 219882">{{cite web |url=https://codereview.chromium.org/23503030/ |title=Issue 23503030 Merge 219882 |date=2013-09-03 |accessdate=2013-09-19}}</ref><ref name="Issue 278370">{{cite web |url=http://code.google.com/p/chromium/issues/detail?id=278370 |title=Issue 278370: Unable to submit client certificates over TLS 1.2 from Windows |date=2013-08-23 |accessdate=2013-10-03}}</ref>
| {{Yes|対応}}
| {{partial|バージョン26より対応}}
| {{No|おそらく未対応、開発終了}}
|-
| style="background:#a0e75a;" | 30–<ref group="注" name="note-j" />
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}<ref name="Chromium Issue 90392"/><ref name="Issue 23503030 Merge 219882"/><ref name="Issue 278370"/>
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応済み}}
|-
|-class="sortbottom"
! ブラウザ
! バージョン
! プラットフォーム
! SSL 2.0（安全ではない）
! SSL 3.0
! TLS 1.0
! TLS 1.1
! TLS 1.2
! EV証明書
! SHA-2証明書
! 脆弱性への対応
|-
! rowspan="7" | [[Mozilla Firefox]]<br /><ref group="注" name="note-c">TLSの実装は[[Network Security Services|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が既定で有効。</ref>
| style="background:salmon;" | 1, 1.5
| rowspan="7" | Android,<br /> Firefox OS,<br /> Linux,<br /> Mac OS X,<br />Windows
| {{No|対応}}<ref name="SecurityinFirefox">{{cite web |url=https://developer.mozilla.org/en-US/Firefox/Releases/2/Security_changes |title=Security in Firefox 2|date=2008-08-06 |accessdate=2014-07-02}}</ref>
| {{Yes|対応}}<ref name="SecurityinFirefox"/>
| {{Yes|対応}}<ref name="SecurityinFirefox"/>
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{partial|バージョン1.5より対応}}
| {{No|未対応、開発終了}}
|-
| style="background:salmon;" | 2–7
| {{Yes|既定で無効}}<ref name="SecurityinFirefox"/><ref name="FxSSL2">{{cite web|url=https://developer.mozilla.org/en-US/docs/Introduction_to_SSL|title=Introduction to SSL | publisher=MDN|accessdate=accessdate=2014-07-02}}</ref>
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{partial|バージョン3より対応}}
| {{Yes|対応}}
| {{No|未対応、開発終了}}
|-
| style="background:salmon;" | 8–22<br />{{nowrap|ESR 10, 17}}
| {{Yes|非対応}}<ref name="FxSSL2"/>
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|おそらく未対応、開発終了}}
|-
| style="background:salmon;" | 23
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Partial|既定で無効}}<ref name="Bug565047">{{cite web |url=https://bugzilla.mozilla.org/show_bug.cgi?id=565047 |title=Bug 565047 – (RFC4346) Implement TLS 1.1 (RFC 4346) |accessdate=2014-07-02}}</ref>
| {{No|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|おそらく未対応、開発終了}}
|-
| style="background:salmon;" | 24–26
| rowspan="2" ! {{Yes|非対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Partial|既定で無効}}
| rowspan="2" ! {{Partial|既定で無効}}<ref name="Bug480514">{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=480514 |title=Bug 480514 – Implement support for TLS 1.2 (RFC 5246) |accessdate=2014-07-02}}</ref>
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
| {{partial|不明、開発終了}}
|-
| style="background:khaki;" | ESR 24
| {{Yes|対応済み}}
|-
| style="background:#a0e75a;" | 27–<ref group="注" name="note-j" /><br/>ESR 31–
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}<ref name="Bug733647">{{cite web |url=https://bugzilla.mozilla.org/show_bug.cgi?id=733647 |title=Bug 733647 – Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default |accessdate=2014-07-02}}</ref><ref name="Fx27">{{cite web |url=http://www.mozilla.org/en-US/firefox/27.0/releasenotes/ |title=Firefox Notes – Desktop |date=2014-02-04 |accessdate=2014-07-02}}</ref>
|{{Yes|対応}}<ref name="Bug861266">{{cite web|url=https://bugzilla.mozilla.org/show_bug.cgi?id=861266 |title=Bug 861266 – Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default |accessdate=2014-07-02}}</ref><ref name="Fx27"/>
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応済み}}
|-
|-class="sortbottom"
! ブラウザ
! バージョン
! プラットフォーム
! SSL 2.0（安全ではない）
! SSL 3.0
! TLS 1.0
! TLS 1.1
! TLS 1.2
! EV証明書
! SHA-2証明書
! 脆弱性への対応
|-
! rowspan="12" | [[Internet Explorer]]<br />{{refn |group="注" |name="note-d" |IEのTLSへの対応はWindowsに同梱の[[SChannel]]による。IE 11においてTLS 1.1および1.2が既定で有効<ref>{{cite web |author=Microsoft |url=http://msdn.microsoft.com/en-us/library/windows/desktop/aa380123(v=vs.85).aspx |title=Secure Channel |date=2012-09-05 |accessdate=2012-10-18}}</ref><ref>{{cite web |author=Microsoft |url=http://msdn.microsoft.com/en-us/library/dd208005%28PROT.13%29.aspx |title=MS-TLSP Appendix A |date=2009-02-27 |accessdate=2014-07-02}}</ref>。}}
| style="background:salmon;" | 2
| style="background:salmon;" ! rowspan="2" | Windows 3.1, 95, NT 3.1{{refn |group="注" |name="note-k" |Windows XPおよび Server 2003以前のSChannelは3DESやRC4といった弱いアルゴリズムのみに対応<ref>http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512(v=vs.85).aspx</ref>。これはIEだけではなく、Microsoft Officeなど、これらのOS上で動作する他のMicrosoft製品でも利用される。Server 2003のみ、KB 948963によってAESに対応する<ref>http://support.microsoft.com/kb/948963</ref>。}}
| {{No|対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|未対応、開発終了}}
|-
| style="background:salmon;" | 3
| {{No|対応}}
| {{Yes|対応}}<ref name="IESSL3TLS1">{{cite web|title=What browsers only support SSLv2?|url=http://stackoverflow.com/questions/881563/what-browsers-only-support-sslv2|accessdate=2014-07-02}}</ref>
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|未対応、開発終了}}
|-
| style="background:salmon;" | 4-6
| style="background:salmon;" | Windows 3.1, 95, 98, ME<br />Windows NT 3.x, 4<br />Windows 2000<ref group="注" name="note-k"/>
| {{No|対応}}
| {{Yes|対応}}
| {{Partial|既定で無効}}<ref name="IESSL3TLS1"/>
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|おそらく未対応、開発終了<br />（Win 3.1, 95, 98, ME<br />Windows NT 3.x, 4, Windows 2000向けの最新）}}
|-
| style="background:salmon;" | 6
| style="background:salmon;" ! rowspan="2" | Windows XP<ref group="注" name="note-k"/>
| {{No|対応}}
| {{Yes|対応}}
| {{Partial|既定で無効}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{partial|SP3より対応<ref name=WinXP2003SHA2>{{cite web|url=http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx|title=SHA2 and Windows - Windows PKI blog - Site Home - TechNet Blogs|date=2010-09-30|accessdate=2014-07-29}}</ref>}}
| {{partial|対応済み、開発終了}}
|-
| style="background:salmon;" | 7, 8
| {{Yes|既定で無効}}<ref name="IE7HTTPS">{{cite web |url=http://msdn.microsoft.com/en-US/library/bb250503%28v=vs.85%29.aspx |title=HTTPS Security Improvements in Internet Explorer 7 |accessdate=2014-07-02}}</ref>
| {{Yes|対応}}
| {{Yes|対応}}<ref name="IE7HTTPS"/>
| {{No|非対応}}
| {{No|非対応}}
| {{Yes|対応}}
| {{partial|SP3より対応<ref name=WinXP2003SHA2/>}}
| {{partial|対応済み、開発終了（Win XP向けの最新）}}
|-
| style="background:salmon;" | 6
| style="background:salmon;" ! rowspan="2" | Windows Server 2003<ref group="注" name="note-k"/>
| {{No|対応}}
| {{Yes|対応}}
| {{Partial|既定で無効}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{partial|KB 938397、968730で対応<ref name=WinXP2003SHA2/>}}
| {{partial|対応済み、開発終了}}
|-
| style="background:salmon;" | 7, 8
| {{Yes|既定で無効}}<ref name="IE7HTTPS"/>
| {{Yes|対応}}
| {{Yes|対応}}<ref name="IE7HTTPS"/>
| {{No|非対応}}
| {{No|非対応}}
| {{Yes|対応}}
| {{partial|KB 938397、968730で対応<ref name=WinXP2003SHA2/>}}
| {{partial|対応済み、開発終了（Win Server 2003向けの最新）}}
|-
| style="background:khaki;" | 7–9
| style="background:khaki;" | Windows Vista / 2008
| {{Yes|既定で無効}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応済み（Win Vista / 2008向けの最新）}}
|-
| style="background:khaki;" | 8–10
| style="background:khaki;" | Windows 7 / 2008R2
| {{Yes|既定で無効}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Partial|既定で無効}}<ref name="Win7TLS1.1">{{cite web |url=http://blogs.msdn.com/b/ieinternals/archive/2009/06/19/windows-7-support-for-tls-and-ciphers.aspx |title=Windows 7 adds support for TLSv1.1 and TLSv1.2 - IEInternals - Site Home - MSDN Blogs |accessdate=2014-07-02}}</ref>
| {{Partial|既定で無効}}<ref name="Win7TLS1.1"/>
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応済み}}
|-
| style="background:khaki;" | 10
| style="background:khaki;" | Windows 8 / 2012
| {{Yes|既定で無効}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Partial|既定で無効}}
| {{Partial|既定で無効}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応済み（Win 8 / 2012向けの最新）}}
|-
| rowspan="2" ! style="background:#a0e75a;" | 11
| style="background:khaki;"| Windows 7 / 2008R2
| rowspan="2" ! {{Yes|既定で無効}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}<ref name="IE11_TLS_1.1_1.2">{{cite web |author=Microsoft |url=http://blogs.msdn.com/b/ieinternals/archive/2013/09/24/internet-explorer-11-changelist-change-log.aspx |title=IE11 Changes |date=2013-09-24 |accessdate=2014-07-02}}</ref>
| rowspan="2" ! {{Yes|対応}}<ref name="IE11_TLS_1.1_1.2"/>
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応}}
| rowspan="2" ! {{Yes|対応済み<ref>{{cite web |author=Microsoft |url=http://technet.microsoft.com/en-us/library/dn303404.aspx |title=Release Notes: Important Issues in Windows 8.1 Preview |date=2013-06-24 |accessdate=2013-10-29}}</ref>（Win 7 / 2008R2, 8.1 / 2012R2向けの最新）}}
|-
| style="background:#a0e75a;" | Windows 8.1 / 2012R2
|-
|-class="sortbottom"
! ブラウザ
! バージョン
! プラットフォーム
! SSL 2.0（安全ではない）
! SSL 3.0
! TLS 1.0
! TLS 1.1
! TLS 1.2
! EV証明書
! SHA-2証明書
! 脆弱性への対応
|-
! rowspan="6" | [[Opera]]<br />{{refn |group="注" |name="note-e" |[[Presto]]版では、Opera 10でTLS 1.2に対応（既定では無効）。}}<br /> {{refn |group="注" |name="note-f" |Opera 14以降におけるTLSへの対応は、対応するChromiumバックエンドを利用するChromeと同じとなる。}}
| style="background:salmon;" | 5–7
| rowspan="6" | Android,<br /> iOS,{{citation needed|date=September 2013}}<br /> Linux,<br /> Mac OS X,<br /> Windows
| {{No|対応}}<ref name="Opera5">{{cite web|url=http://www.opera.com/docs/changelogs/windows/500-512/|title=Changelog for Opera 5.x for Windows|accessdate=2014-07-02}}</ref>
| {{Yes|対応}}<ref name="Opera5"/>
| {{Yes|対応}}<ref name="Opera5"/>
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|未対応、開発終了}}
|-
| style="background:salmon;" | 8
| {{No|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Partial|既定で無効}}<ref>{{cite web|url=http://www.opera.com/docs/changelogs/windows/800b2/|title=Changelog for Opera <nowiki>[8]</nowiki> Beta 2 for Windows|accessdate=2014-07-02}}</ref>
| {{No|非対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{No|未対応、開発終了}}
|-
| style="background:salmon;" | 9
| {{Yes|既定で無効}}<ref>{{cite web|url=http://www.opera.com/docs/specs/opera9/|title=Web Specifications Supported in Opera 9|accessdate=2014-07-02}}</ref>
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|非対応}}
| {{partial|バージョン9.5より対応}}
| {{Yes|対応}}
| {{No|未対応、開発終了}}
|-
| style="background:khaki;" | 10–12
| {{Yes|非対応}}<ref name="Opera10b">{{cite web|url=http://www.opera.com/docs/changelogs/windows/1000b1/|title=Opera: Opera 10 beta for Windows changelog|accessdate=2014-07-02}}</ref>
| {{Yes|対応}}
| {{Yes|対応}}
| {{Partial|既定で無効}}
| {{Partial|既定で無効}}<ref name="Opera10b"/>
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|11.60以降で対応済み（Linux向け、[[Presto]]版の最新）}}
|-
| style="background:salmon;" | 14–16
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}<ref name="opera16">Chrome 27–29と同じ</ref>
| {{No|非対応}}<ref name="opera16"/>
| {{Yes|対応}}
| {{Yes|対応}}
| {{partial|不明、開発終了}}
|-
| style="background:#a0e75a;" | 17–<ref group="注" name="note-j" />
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}<ref name="opera17">Chrome 30以降と同じ</ref>
| {{Yes|対応}}<ref name="opera17"/>
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応済み（Windows、OS X、Android向けの最新)}}
|-
|-class="sortbottom"
! ブラウザ
! バージョン
! プラットフォーム
! SSL 2.0（安全ではない）
! SSL 3.0
! TLS 1.0
! TLS 1.1
! TLS 1.2
! EV証明書
! SHA-2証明書
! 脆弱性への対応
|-
! rowspan="9" | [[Safari]]<br />{{refn |group="注" |name="note-g" |SafariのTLSへの対応はOS同梱のライブラリによる<ref>{{cite web|last=Adrian|first=Dimcev|title=Common browsers/libraries/servers and the associated cipher suites implemented|url=http://www.carbonwind.net/TLS_Cipher_Suites_Project/tls_ssl_cipher_suites_annex_a1_main.docx|work=TLS Cipher Suites Project|accessdate=2014-07-02}}</ref>。}}
| rowspan="2" ! style="background:salmon;" | 1–5
| style="background:salmon;" | Mac OS X 10.0–10.6
| rowspan="2" ! {{Yes|非対応}}<ref name=SafariSSL2>{{cite web|title=Apple Secures Mac OS X with Mavericks Release - eSecurity Planet|url=http://www.esecurityplanet.com/mac-os-security/apple-secures-mac-os-x-with-mavericks-release.html|date=2013-10-25|accessdate=2014-07-02}}</ref>
| rowspan="2" !  {{Yes|対応}}
| rowspan="2" !  {{Yes|対応}}
| rowspan="2" !  {{No|非対応}}
| rowspan="2" !  {{No|非対応}}
| rowspan="2" !  {{partial|バージョン3.2より対応}}
| rowspan="2" !  {{partial|OS X 10.5より対応}}
| rowspan="2" !  {{No|未対応、開発終了（OS X 10.0–10.6向けの最新）}}
|-
| style="background:khaki;"  | Mac OS X 10.7
|-
| rowspan="2" ! style="background:khaki;" | 6
| style="background:khaki;" | Mac OS X 10.7
| rowspan="2" ! {{Yes|非対応}}
| rowspan="2" !  {{Yes|対応}}
| rowspan="2" !  {{Yes|対応}}
| rowspan="2" !  {{No|非対応}}
| rowspan="2" !  {{No|非対応}}
| rowspan="2" !  {{Yes|対応}}
| rowspan="2" !  {{Yes|対応}}
| {{No|未対応（OS X 10.7向けの最新）}}
|-
| style="background:khaki;" | Mac OS X 10.8
| {{Yes|対応済み{{refn |group="注" |name="note-i" |2013年9月にBEASTへの対処が実装がされたが、既定では無効であった<ref name="BEAST-Still">{{cite web|last= Ristic|first=Ivan|title=Is BEAST Still a Threat?|url=https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat|work=qualys.com|accessdate=2014-07-02}}</ref><ref name="beast-mitigations-mavericks">{{cite web |author=Ivan Ristić |url=http://blog.ivanristic.com/2013/10/apple-enabled-beast-mitigations-in-mavericks.html |title=Apple enabled BEAST mitigations in OS X 10.9 Mavericks |date=2013-10-31 |accessdate=2014-07-02}}</ref>。2014年2月にアップデートされたOS X 10.8.5から既定で有効となった<ref name="beast-mitigations-10.8">{{cite web |author=Ivan Ristić |url=https://community.qualys.com/thread/12496 |title=Apple finally releases patch for BEAST |date=2014-02-26 |accessdate=2014-07-02}}</ref>。}}（OS X 10.8向けの最新）}}
|-
| style="background:#a0e75a;" | 7
| style="background:#a0e75a;" | Mac OS X 10.9
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}<ref name="MavericksTLS1.2">{{cite web|title=About the security content of OS X Mavericks v10.9|url=http://support.apple.com/kb/HT6011|accessdate=2014-07-02}}</ref>
| {{Yes|対応}}<ref name="MavericksTLS1.2"/>
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応済み<ref name="beast-mitigations-mavericks"/>（OS X 10.9向けの最新）}}
|-
| style="background:salmon;" | 3–5
| style="background:salmon;" | iPhone (i)OS 1–4<ref group="注" name="note-h" />
| {{Yes|非対応}}<ref>{{cite web|title=Secure Transport Reference|url=https://developer.apple.com/library/mac/documentation/security/Reference/secureTransportRef/Reference/reference.html#//apple_ref/c/tdef/SSLProtocol|accessdate=2014-07-02}} iOSにおいて<code>kSSLProtocol2</code>は"deprecated"とされている</ref>
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{partial|バージョン3.2より対応}}
| {{partial|OS 3より対応}}
| {{No|未対応、開発終了（iPhone (i)OS 1–4）向けの最新}}
|-
| style="background:salmon;" | 5, 6
| style="background:salmon;" | iOS 5, 6{{refn |group="注" |name="note-h" |モバイルSafariおよびTLS/SSLを必要とするサードパーティ製のすべてのソフトウェアはiOS同梱のUIWebViewライブラリを使用する。iOS 5以降でTLS 1.1および1.2が既定で有効<ref name="iOS5TLS1.2">{{cite web|author=Apple|title=Technical Note TN2287 – iOS 5 and TLS 1.2 Interoperability Issues|date=2011-10-14|accessdate=2014-07-02|url=https://developer.apple.com/library/ios/#technotes/tn2287/_index.html}}</ref><ref>{{cite web|last=Liebowitz|first=Matt|title=Apple issues huge software security patches|date=2011-10-13|accessdate=2014-07-02|work=NBCNews.com|url=http://www.msnbc.msn.com/id/44896639/ns/technology_and_science-security/t/apple-issues-huge-software-security-patches/}}</ref><ref>{{cite web|author=MWR Info Security|title=Adventures with iOS UIWebviews|date=2012-04-16|accessdate=2014-07-02|url=http://labs.mwrinfosecurity.com/blog/2012/04/16/adventures-with-ios-uiwebviews/}}, "HTTPS (SSL/TLS)"セクション</ref>。}}
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}<ref name="iOS5TLS1.2"/>
| {{Yes|対応}}<ref name="iOS5TLS1.2"/>
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|未対応、開発終了（iOS 5, 6向けの最新）}}
|-
| style="background:#a0e75a;" | 7
| style="background:#a0e75a;" | iOS 7<ref group="注" name="note-h" />
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応済み<ref name="beast-mitigations-ios7">{{cite web|author=schurtertom|title=SOAP Request fails randomly on one Server but works on an other on iOS7|url=http://stackoverflow.com/questions/19221568/soap-request-fails-randomly-on-one-server-but-works-on-an-other-on-ios7|date=2013-10-11|accessdate=2014-07-02}}</ref>（iOS 7向けの最新）}}
|-
| style="background:salmon;" | 3–5
| Windows
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|非対応}}
| {{No|非対応}}
| {{partial|バージョン3.2より対応}}
| {{No|非対応}}
| {{No|未対応、開発終了（Windows向けの最新）}}
|-
|-class="sortbottom"
! ブラウザ
! バージョン
! プラットフォーム
! SSL 2.0（安全ではない）
! SSL 3.0
! TLS 1.0
! TLS 1.1
! TLS 1.2
! [[Extended Validation 証明書|EV証明書]]<ref name=EVSSLbrowser/>
! [[SHA-2]]証明書<ref name="SHA-2"/>
! 脆弱性への対応{{refn | group="注" | name="note-sec"}}
|}
{|class="wikitable" style="text-align: center; font-size: smaller;"
|-
! バージョン、プラットフォーム
! 状況
|-
| 灰色
| 混在
|-
| style="background:salmon;" | 赤色
| 過去のリリース：開発終了
|-
| style="background:khaki;" | 黄色
| 過去のリリース：サポート継続
|-
| style="background:#a0e75a;" | 緑色
| 現在のリリース{{refn |group="注" |name="note-j" |"27-"などのバージョン表記は、TLSへの対応状況が変化した最初のバージョン番号を示している。閲覧時点での最新版のバージョン番号が反映されているとは限らない。}}

|}
;注
{{reflist |group="注"}}

=== ライブラリ ===
{{main|:en:Comparison of TLS implementations}}
TLS/SSLライブラリの多くは[[オープンソースソフトウェア]]である。

{| class="wikitable sortable" style="text-align: center; font-size: smaller;"
|+ ライブラリにおけるTLS/SSLの対応状況
|-
! 実装
! SSL 2.0（安全ではない）
! SSL 3.0
! TLS 1.0
! TLS 1.1
! TLS 1.2
|-
| [[Botan]]
| {{Yes|非対応}}<ref group="注" name="a">後方互換性の確保のため、SSL 2.0に非対応あるいは既定で無効の場合にもSSL 2.0 client helloはサポートされる。</ref>
| {{Yes|対応}}<!--{{Yes|既定で無効}}<ref name="Botan 1.11.6"/>-->
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
|-
| [[cryptlib]]
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
|-
| [[CyaSSL]]
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
|-
| [[GnuTLS]]
| {{Yes|非対応}}<ref group="注" name="a" />
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
|-
| [[MatrixSSL]]
| {{Yes|非対応}}<ref group="注" name="a" />
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
|-
| [[Network Security Services|NSS]]
| {{Yes|既定で無効}}<ref group="注" name="a" />
| {{Yes|対応}}
| {{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>
|-
| [[OpenSSL]]
| {{No|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}<ref name=openssl_changelog>[http://www.openssl.org/news/changelog.html www.openssl.org/news/changelog.html]</ref>
| {{Yes|対応}}<ref name=openssl_changelog />
|-
| [[LibreSSL]]
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}<ref name=openssl_changelog />
| {{Yes|対応}}<ref name=openssl_changelog />
|-
| [[PolarSSL]]
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
|-
| [[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から既定で無効}}
| {{Yes|対応}}
| {{partial|IE 7から既定で有効}}
| {{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|既定で無効}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{No|非対応}}
| {{No|非対応}}
|-
| [[SChannel|SChannel 7/2008R2, 8/1012, 8.1/2012R2]]<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|既定で無効}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
|-
| Secure Transport
| {{yes|非対応}}{{refn|group="注"|name="b"|OS X 10.8以降でSSL 2.0非対応。iOS 5以降およびOS X 10.8以降で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>}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}<ref group="注" name="b" />
| {{Yes|対応}}<ref group="注" name="b" />
|-
| SharkSSL
| {{Yes|非対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
|-
| [[JSSE]]
| {{Yes|非対応}}<ref group="注" name="a" />
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
| {{Yes|対応}}
|-
|-class="sortbottom"
! 実装
! SSL 2.0（安全ではない）
! SSL 3.0
! TLS 1.0
! TLS 1.1
! TLS 1.2
|}
;注
{{reflist |group="注"}}

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

TLS（SSL）の拡張機能を定義するRFC 4366では、ネゴシエーション時にホスト名を伝える手段として[[Server Name Indication]](SNI)を提供している。TLS 1.2を定義するRFC 5246では、サーバ証明書を選択する際にこの情報を使うよう言及している。

逆に、証明書を使い分けず、1種類の証明書を使い回す方法も考えられる。[[X.509]]証明書のフォーマットについて記述したRFC 5280によれば、発行先ホスト名を保持するsubjectAltNameはひとつの証明書に複数のエントリを作成できる。しかし認証局が実際にそのような証明書を発行するかどうかは、別の問題である。認証局はすべてのホスト名に対して証明書の申請者が正当な管理者であることを確認しなければならないため、証明書発行の負荷は大きくなる。

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

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

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

[[ファイル:Firefox-SSL-padlock.png|frame|right|Mozilla Firefoxにおける南京錠アイコンの例]]
特に[[World Wide Web]]では、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信でSSL/TLSが使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに[[南京錠]]の[[アイコン]]を表示したり、[[アドレスバー]]の色を変化させたりして、利用者に情報を提供している。

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

=== 証明書の正当性 ===
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=http://www.ipa.go.jp/security/vuln/websecurity.html
|title=「安全なウェブサイトの作り方　改訂第3版」を公開
|publisher=独立行政法人 [[情報処理推進機構]]
|accessdate=2010-01-03
}}</ref>という文書の「[[フィッシング (詐欺)|フィッシング]]詐欺を助長しないための対策」に対応する。

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

古い例では、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/SSLに対する攻撃のうち主なものを以下に挙げる。

==== 再ネゴシエーション脆弱性 ====
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を使った安全な再ネゴシエーション手順がRFC 5746として提案されている。この脆弱性を利用した中間者攻撃では、サーバがRFC 5746に対応しない限りクライアントは再ネゴシエーションが発生したことを検出できないので、クライアント側のみで対応することは不可能である。

==== バージョンロールバック攻撃 ====
'''False Start'''<ref>{{cite web|title=Transport Layer Security (TLS) False Start|url=https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00|work=Internet Engineering Task Force|publisher=IETF|accessdate=2014-06-24|author=A. Langley|coauthors=N. Modadugu, B. Moeller|month=6|year=2012}}</ref>（[[Google Chrome]]で有効化された<ref>{{cite web|last=Wolfgang|first=Gruener|title=False Start: Google Proposes Faster Web, Chrome Supports It Already|url=http://www.conceivablytech.com/3299/products/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 }}</ref>）やSnap StartといったTLS/SSLを高速化する変法は、攻撃者が一定条件下において本来利用可能なTLS/SSLのバージョンよりも低いバージョンでTLS/SSL接続を行うよう仕向けること<ref>{{cite web|last=Brian|first=Smith|title=Limited rollback attacks in False Start and Snap Start|url=http://www.ietf.org/mail-archive/web/tls/current/msg06933.html|accessdate=2014-06-24}}</ref>や、クライアントからサーバへ送られる利用可能なCipher Suiteの一覧を改竄し、より低い暗号強度やより弱い暗号化アルゴリズム・鍵交換アルゴリズムを使用するよう仕向けること<ref>{{cite web|last=Adrian|first=Dimcev|title=False Start|url=http://www.carbonwind.net/blog/post/Random-SSLTLS-101-False-Start.aspx|work=Random SSL/TLS 101|accessdate=2014-06-24}}</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|year=2012|isbn=978-1-4503-1651-4|url=https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf|pages=62–72}}</ref>

==== 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|date=2011-05-13|accessdate=2014-06-24|author=Thai Duong and Juliano Rizzo}}</ref>と呼ばれるTLS 1.0における[[ブロック暗号]]の[[暗号利用モード|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|date=2011-09-19|accessdate=2014-06-24|author=Dan Goodin}}</ref><ref name=combinator>{{cite web|url=http://news.ycombinator.com/item?id=3015498|title=Y Combinator comments on the issue|date=2011-09-20|accessdate=2014-06-24}}</ref>。この脆弱性そのものは2002年にPhillip Rogawayによって発見されていた<ref>{{cite web|url=http://www.openssl.org/~bodo/tls-cbc.txt|archiveurl=https://web.archive.org/web/20120630143111/http://www.openssl.org/~bodo/tls-cbc.txt|archivedate=2012-06-30|title=Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures|date=2004-05-20|accessdate=2014-06-24}}</ref>が、2011年の発表までは実用的な[[エクスプロイト]]は報告されていなかった。

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

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である。

Microsoftは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)|date=2012-01-10|accessdate=2014-06-24}}</ref>。[[Windows 7]]以降では、TLS 1.1以降が利用可能である。

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

==== {{anchors|CRIME攻撃|BREACH攻撃}}CRIME攻撃、BREACH攻撃 ====
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|publisher=Ars Technica|author=Dan Goodin|date=2012-09-13|accessdate=2014-06-24}}</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|publisher=ThreatPost|date=September 13, 2012|author=Dennis Fisher|accessdate=2014-06-24}}{{dead link|date=2014年5月}}</ref>。ウェブサイトでのユーザ認証に使われているCookieの内容を回復されることで、[[セッションハイジャック]]が可能となる。
2012年9月にはMozilla FirefoxおよびGoogle ChromeにおいてCRIMEへの対応が実施された。また、MicrosoftによればInternet ExplorerはCRIMEの影響を受けない。

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

==== パディング攻撃 ====
TLSの初期のバージョンはパディングオラクル攻撃に対して脆弱であることが2002年に報告された。2013年には、'''Lucky Thirteen'''攻撃（[[:en:Lucky Thirteen attack|英語版]]）と呼ばれる新たなパディング攻撃が報告されている。2014年現在では、多くの実装においてLucky Thirteen攻撃に対して対応済みである。

==== RC4攻撃 ====
[[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.qualys">{{cite web|url=https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what|accessdate=2013-07-30|publisher=Qualsys Security Labs|author=ivanr|title=RC4 in TLS is Broken: Now What?}}</ref>。RC4に対する攻撃は、AlFardan、Bernstein、Paterson、Poettering、Schuldtによって報告された。新たに発見されたRC4の鍵テーブルにおける統計的な偏り<ref>{{cite journal |url=http://link.springer.com/chapter/10.1007%2F978-3-642-19574-7_5 |title=Discovery and Exploitation of New Biases in RC4 |author=Pouyan Sepehrdad, Serge Vaudenay, Martin Vuagnoux |journal=Lecture Notes in Computer Science |year=2011 |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 |work=Cryptography Engineering |accessdate=2014-06-24 |author=Green, Matthew}}</ref><ref>{{cite web |title=On the Security of RC4 in TLS |url=http://www.isg.rhul.ac.uk/tls/ |publisher=Royal Holloway University of London |accessdate=2014-06-24 |author=Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt}}</ref>。この攻撃では、13 × 2<sup>20</sup>の暗号文を用いることで128ビットのRC4が解読可能であることが示され、2013年の[[USENIX]]セキュリティシンポジウムにおいて「実現可能」と評された<ref>{{cite journal |first=Nadhem J. |last=AlFardan |first2=Daniel J. |last2=Bernstein |first3=Kenneth G. |last3=Paterson |first4=Bertram |last4=Poettering |first5=Jacob C. N. |last5=Schuldt |date= 8 July 2013 |title=On the Security of RC4 in TLS and WPA |format=PDF |accessdate=2014-06-24 |url=http://www.isg.rhul.ac.uk/tls/RC4biases.pdf}}</ref><ref>{{cite conference |url=https://www.usenix.org/sites/default/files/conference/protected-files/alfardan_sec13_slides.pdf |title=On the Security of RC4 in TLS |first=Nadhem J. |last=AlFardan |first2=Daniel J. |last2=Bernstein |first3=Kenneth G. |last3=Paterson |first4=Bertram |last4=Poettering |first5=Jacob C. N. |last5=Schuldt |date=15 August 2013 |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 |page=51}}</ref>。

OS X 10.8以前、iOS 6以前およびWindows向けの[[Safari]]を除いて、クライアントのほとんどは既にBEASTへの対処が完了していることから、RC4はもはや最良の選択肢ではなくなっており、TLS 1.0以前においてもCBCモードを用いることがより良い選択肢となっている<ref name="best-practices">{{cite web|url=https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf|title=SSL/TLS Deployment Best Practices|author=Qualys SSL Labs|accessdate=2014-06-24}}</ref>。

Microsoftは可能であればRC4を用いないことを推奨している<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|date=2013-11-12|publisher=Microsoft|accessdate=2014-06-24}}</ref><ref>[http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 draft-popov-tls-prohibiting-rc4-02]</ref>

==== 切り詰め攻撃 ====
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/>と、目標のコンピュータに物理的にアクセス可能であることが求められる。

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

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

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

{|class="wikitable" style="text-align: center;"
|+'''TLS/SSLに対する攻撃に脆弱なウェブサイトの統計（括弧内は前月との差）'''
|-
!rowspan="2" |攻撃
!colspan="5" |セキュリティ
|-
!colspan="2"|安全ではない
!状況による
!安全
!その他
|-
|[[#再ネゴシエーション脆弱性|再ネゴシエーション脆弱性]]
|{{N/A}}
|{{No|4.6% (−0.2%)<br /><small>安全ではない再ネゴシエーションに対応</small>}}
|{{Partial|1.4% (+0.1%)<br /><small>両方に対応</small>}}
|{{Yes|88.0% (+0.9%)<br /><small>安全な再ネゴシエーションに対応</small>}}
|6.0% (−0.8%)<br /><small>再ネゴシエーション非対応</small>
|-
|[[#RC4攻撃|RC4攻撃]]
|{{No|1.7% (−0.1%)<br /><small>RC4によるCipher Suiteのみサポート</small>}}
|{{No|29.6% (−1.0%)<br /><small>多くのブラウザで利用可能なRC4 Suiteをサポート</small>}}
|{{Partial|58.5% (−0.2%)<br /><small>RC4 Suiteのいくつかをサポート</small>}}
|{{Yes|11.8% (+1.1%)<br /><small>RC4によるCipher Suite非サポート</small>}}
|{{N/A}}
|-
|[[#BEAST攻撃|BEAST攻撃]]
|{{N/A}}
|{{No|75.0% (+0.9%)<br /><small>脆弱</small>}}
|{{N/A}}
|{{N/A}}
|{{N/A}}
|-
|[[#CRIME攻撃|CRIME攻撃]]
|{{N/A}}
|{{No|9.5% (−0.5%)<br /><small>脆弱</small>}}
|{{N/A}}
|{{N/A}}
|{{N/A}}
|-
|[[#ハートブリード|ハートブリード]]
|{{N/A}}
|{{No|0.5% (±0.0%)<br /><small>脆弱</small>}}
|{{N/A}}
|{{N/A}}
|{{N/A}}
|-
|[[OpenSSL#CVE-2014-0224|CVE-2014-0224]]
|{{N/A}}
|{{No|7.0% (−1.9%)<br /><small>脆弱かつ悪用可能</small>}}
|{{Partial|22.6% (−2.6%)<br /><small>脆弱だが悪用不可能</small>}}
|{{Yes|69.7% (+13.0%)<br /><small>脆弱ではない</small>}}
|0.7% (−8.5%)<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}}

== 関連項目 ==
* [[HTTPS]]
* [[Datagram Transport Layer Security]]
* [[FTPS]]
* [[Secure Shell|SSH]]
* [[GnuTLS]]
* [[Network Security Services]]
* [[OpenSSL]]
* [[フィッシング (詐欺)|フィッシング]]
* [[Extended Validation 証明書]] (EV SSL)
* [[共用SSL]]
* [[認証局]]
* [[SSLオフロード]]
* [[ヌルターミネーション攻撃]]

== 外部リンク ==
=== 標準化 ===
2014年6月時点での最新版
* RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".

過去の版
* RFC 2246: "The TLS Protocol Version 1.0".
* RFC 4346: "The Transport Layer Security (TLS) Protocol Version 1.1".

SSLは標準化されていない
* {{cite web|last=Hickman |first=Kipp E.B.|title=The SSL Protocol |url=http://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.
* 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 [[HTTP/1.1 Upgrade header|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|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 (暗号)|SEED]] Cipher Suites to Transport Layer Security (TLS)".
* RFC 4217: "Securing [[FTPS|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 protocol|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|Galois Counter Mode]] (GCM) Cipher Suites for TLS".
* RFC 5289: "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)".
* 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 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions", includes [[Server Name Indication]] and [[Online Certificate Status Protocol|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 (暗号)|ARIA]] Cipher Suites to Transport Layer Security (TLS)".
* RFC 6347: "Datagram Transport Layer Security Version 1.2".
* 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-[[Counter with CBC-MAC|CCM]] Cipher Suites for Transport Layer Security (TLS)"
* RFC 7027: "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)".

TLSを含むカプセル化
* RFC 5216: "The [[Extensible Authentication Protocol|EAP]]-TLS Authentication Protocol"

=== 日本の認証局ベンダー(50音順) ===
<!-- シェア順だと時間経過とともに変わるが、50音順なら時間経過にともなう維持管理は不要。 -->
* [http://crosstrust.co.jp/ クロストラスト]
* [http://jp.comodo.com/ コモドジャパン]
* [http://www.cybertrust.ne.jp/ サイバートラストジャパン]
* [http://jp.globalsign.com/ GMOグローバルサイン]
* [http://www.secomtrust.net/ セコムトラストシステムズ]
* [http://www.geotrust.co.jp/ 日本ジオトラスト]
* [http://www.verisign.co.jp/ 日本ベリサイン]

{{OSI}}
{{DEFAULTSORT:とらんすほおと れいや せきゆりてい}}

[[Category:アプリケーション層プロトコル]]
[[Category:コンピュータ・ネットワーク・セキュリティ]]
[[Category:セキュア通信]]
[[Category:電子商取引]]
[[Category:RFC|5246]]