Transport Layer Security

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
TCP/IP群
アプリケーション層

BGP / DHCP / DNS / FTP / HTTP / IMAP / IRC / LDAP / MGCP / NNTP / NTP / POP / RIP / RPC / RTP / SIP / SMTP / SNMP / SSH / Telnet / TFTP / TLS/SSL / XMPP

カテゴリ
トランスポート層

TCP / UDP / DCCP / SCTP / RSVP

カテゴリ
ネットワーク層

IP (IPv4, IPv6) / ICMP / ICMPv6 / IGMP / IPsec

カテゴリ
リンク層

ARP/InARP / NDP / OSPF / トンネリング (L2TP) / PPP / MAC (イーサネット, IEEE 802.11, DSL, ISDN)

カテゴリ

Transport Layer Security(トランスポート・レイヤー・セキュリティー、TLS)は、セキュリティーを要求される通信のためのプロトコルである。また、当プロトコルを発表したIETFの作業部会の名前でもある。歴史的な理由により、当プロトコルは、しばしば(特に区別する場合を除いて)Secure Sockets Layer (SSL) とも呼ばれている。これは、TLSの元になったプロトコルがSSLだったこと[1]と、SSLという名称が広く普及していることによる。以下においては、特にことわりのないかぎり、作業部会ではなく、プロトコルのほうを指す。

TLSは、コネクション型のトランスポート層プロトコルの上位に位置し、通常はTCPがラップする形で利用される。特にHTTPでの利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存しない。

バージョン[編集]

SSL 1.0[編集]

ネットスケープコミュニケーションズ社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな脆弱性が発見され、破棄された。このため、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を無効にしない限りこの脆弱性の影響を受ける可能性を否定できない[2]。SSL 3.0以降に対応した実装が十分に普及したものとして、Internet Explorer 7Mozilla Firefox 2Opera 9などは、初期状態でSSL 2.0を無効にしている[3][4][5]。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっている[6]

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[編集]

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攻撃に対する耐性を上げるため、初期化ベクトルを明示的に指定することにし、さらにパディングの処理も改善された。また、予期せぬ回線クローズ後に、セッションを再開できるようになった。共通鍵暗号アルゴリズムとしてAESが選択肢に加わった[7]

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

TLS 1.2[編集]

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

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

提供する機能[編集]

SSLによるセキュアな通信

TLSは、認証暗号化改竄検出の機能を提供する。具体的なアルゴリズムはそれぞれ複数の選択肢が定義されており、TLS通信の開始時に行われるネゴシエーション時に、双方が許容するアルゴリズムの中から選択される。

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

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

認証[編集]

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

TLSの各バージョンで使用できる署名アルゴリズム
未対応 未対応、選択可能 選択可能、実装必須 実装必須)
アルゴリズム SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2
ECDSA 未対応 選択可能
RSA 選択可能 実装必須
DSA 未対応 選択可能 実装必須 選択可能

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

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

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

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

暗号化[編集]

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

TLS/SSLの各バージョンで使用できる暗号化アルゴリズム
暗号化 プロトコルバージョン
種類 アルゴリズム 暗号強度
(bit)
SSL 2.0 SSL 3.0
[注 1][注 2][注 3]
TLS 1.0
[注 1][注 3]
TLS 1.1
[注 1]
TLS 1.2
[注 1]
ブロック暗号
暗号利用モード
AES CBC[注 4] 128, 256 N/A N/A 実装による 安全 安全
AES GCM[注 5][注 6] N/A N/A N/A N/A 安全
AES CCM[注 7][注 6] N/A N/A N/A N/A 安全
CAMELLIA CBC[注 8][注 4] 128, 256 N/A N/A 実装による 安全 安全
CAMELLIA GCM[注 9][注 6] N/A N/A N/A N/A 安全
SEED CBC[注 10][注 4] 128 N/A N/A 実装による 安全 安全
ARIA英語版 CBC[注 11][注 4] 128, 256 N/A N/A 実装による 安全 安全
ARIA英語版 GCM[注 12][注 6] N/A N/A N/A N/A 安全
IDEA CBC[注 4][注 13] 128 安全ではない 実装による 実装による 安全 N/A
3DES EDE CBC[注 4] 112[注 14] 安全ではない 強度不足、実装による 強度不足、実装による 強度不足 強度不足
DES CBC[注 4][注 13] 56 安全ではない 安全ではない 安全ではない 安全ではない N/A
40[注 15] 安全ではない 安全ではない 安全ではない N/A N/A
RC2 CBC[注 4] 40[注 15] 安全ではない 安全ではない 安全ではない N/A N/A
ストリーム暗号 CHACHA20+POLY1305[注 16][注 6] 256 N/A N/A N/A N/A 安全
RC4[注 17] 128 安全ではない 安全ではない 安全ではない 安全ではない 安全ではない
40[注 15] 安全ではない 安全ではない 安全ではない N/A N/A
認証なし[注 18] アルゴリズムによる 40–256 N/A 安全ではない 安全ではない 安全ではない 安全ではない
暗号化なし NULL - N/A 安全ではない 安全ではない 安全ではない 安全ではない
  1. ^ a b c d 再ネゴシエーション脆弱性への対応のため、RFC 5746への対応が必要
  2. ^ RFC 5746への対応はSSL 3.0の仕様を逸脱するが、ほとんどの実装では対応したうえで仕様からの逸脱にも対処している
  3. ^ a b TLS 1.0以前ではBEAST攻撃に対して脆弱であり、クライアント側、サーバ側での対応が必要
  4. ^ a b c d e f g h CBCモードは、サイドチャネル攻撃への対処が不十分な実装ではLucky Thirteen攻撃に対して脆弱である
  5. ^ RFC 5288による追加
  6. ^ a b c d e GCM、CCMなどのAEAD(認証付き暗号モード)は、TLS 1.2のみで利用可能
  7. ^ RFC 6655による追加
  8. ^ RFC 5932およびRFC 6367による追加
  9. ^ RFC 6367による追加
  10. ^ RFC 4162による追加
  11. ^ RFC 6209による追加
  12. ^ RFC 6209による追加
  13. ^ a b IDEA、DESはTLS 1.2で廃止された
  14. ^ 3DESの暗号強度は112ビットであり[8]、2014年現在で最低限必要とされる128ビットに不足している[9]
  15. ^ a b c 40ビットのセキュリティ強度を持つCipher Suiteは、アメリカ合衆国による高強度暗号アルゴリズムの輸出規制 (en:Export of cryptography from the United States) を回避するために設計された。これらはTLS 1.1以降では利用が禁止されている。
  16. ^ draft-agl-tls-chacha20poly1305-04およびdraft-mavrogiannopoulos-chacha-tls-02による提唱
  17. ^ 脆弱性が指摘されている(RC4攻撃
  18. ^ ディフィー・ヘルマン鍵共有および楕円曲線ディフィー・ヘルマン鍵共有による匿名での鍵共有 (DH_anon、ECDH_anon) は中間者攻撃に対して脆弱である

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 4132RFC 5932RFC 6367)、SEED CBC(RFC 4162)およびARIA英語版 CBC(RFC 6209)が、認証付き暗号によるAES GCMRFC 5288)、AES CCMRFC 6655)、Camellia GCM(RFC 6367)およびおよびARIA英語版 GCM(RFC 6209)が追加されている。IDEA CBC、DES CBCはTLS1.2で廃止された(RFC 5469に解説がある)。

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

ストリーム暗号であるRC4は前述のBEAST攻撃を受けることはないが、RC4には仕様上の脆弱性が存在し(RC4攻撃)、2013年現在では、NSAのような機関であればTLS/SSLを利用したとしてもRC4を解読可能であるとの疑惑がある[10]MicrosoftではRC4を無効化することを推奨している[11][12][13]Googleによって、ストリーム暗号であるChaCha20と認証のためのPoly1305を組み合わせたChaCha20+Poly1305が提唱されている[14]

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

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

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

DHおよびECDHでの鍵共有では、サーバ証明書を利用せずに匿名での鍵共有を行う DH_anon、ECDH_anon と呼ばれる暗号スイートが存在する。また、鍵共有のみを行い暗号化は行わないこと (NULL) も可能である。前者は中間者攻撃に対して脆弱であり、後者は平文でのやりとりとなることから、これらは安全とはみなされていない。

改竄検出[編集]

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

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

TLS/SSLの各バージョンで使用できる改竄検出
未対応 未対応、選択可能 選択可能、実装必須 実装必須)
アルゴリズム SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2
HMAC-MD5 選択可能
HMAC-SHA1 未対応 選択可能 実装必須
HMAC-SHA256/384 未対応 選択可能
AEAD英語版 未対応 選択可能

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

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

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

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

実装[編集]

ウェブサイト[編集]

ウェブサイトにおけるTLS/SSLの対応状況
プロトコル ウェブサイトにおけるサポート[15] セキュリティ[15][16]
SSL 2.0 21.1% (−0.3%) 安全ではない
SSL 3.0 98.7% (−0.2%) 暗号アルゴリズム[注 1]および脆弱性への対処[注 2]による
TLS 1.0 99.3% (+0.1%) 暗号アルゴリズム[注 1]および脆弱性への対処[注 2]による
TLS 1.1 36.0% (+2.0%) 暗号アルゴリズム[注 1]および脆弱性への対処[注 2]による
TLS 1.2 38.5% (+1.5%) 暗号アルゴリズム[注 1]および脆弱性への対処[注 2]による
  1. ^ a b c d #暗号化を参照のこと
  2. ^ a b c d #ウェブブラウザおよび#既知の攻撃を参照のこと

ウェブブラウザ[編集]

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向け)
ウェブブラウザにおけるTLS/SSLの対応状況の変化
ウェブブラウザ バージョン プラットフォーム SSL 2.0(安全ではない) SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 脆弱性への対応[注 1]
Google Chrome
[注 2]
[注 3]
0–9 Android,
iOS,
Linux,
Mac OS X,
Windows
既定で無効 対応 対応 非対応 非対応 未対応、開発終了
10–21 非対応[24] 対応 対応 非対応 非対応 おそらく未対応、開発終了
22–29 非対応 対応 対応 対応[25] 非対応[25][26][27][28] おそらく未対応、開発終了
30–[注 4] 非対応 対応 対応 対応 対応[26][27][28] 対応済み
ブラウザ バージョン プラットフォーム SSL 2.0(安全ではない) SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 脆弱性への対応[注 1]
Mozilla Firefox
[注 3]
[注 5]
1, 1.5 Android,
Firefox OS,
Linux,
Mac OS X,
Windows
対応[29] 対応[29] 対応[29] 非対応 非対応 未対応、開発終了
2–7 既定で無効[29][30] 対応 対応 非対応 非対応 未対応、開発終了
8–22
ESR 10, 17
非対応[30] 対応 対応 非対応 非対応 おそらく未対応、開発終了
23 非対応 対応 対応 既定で無効[20] 非対応 おそらく未対応、開発終了
24–26 非対応 対応 対応 既定で無効 既定で無効[22] 不明、開発終了
ESR 24 対応済み(ESRの最新)
27–[注 4] 非対応 対応 対応 対応[31][32] 対応[33][32] 対応済み
ブラウザ バージョン プラットフォーム SSL 2.0(安全ではない) SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 脆弱性への対応[注 1]
Internet Explorer
[注 6]
2 Windows 3.1, 95, NT 3.1[注 7] 対応 非対応 非対応 非対応 非対応 未対応、開発終了
3 対応 対応[37] 非対応 非対応 非対応 未対応、開発終了
4-6 Windows 3.1, 95, 98, ME
Windows NT 3.x, 4
Windows 2000[注 7]
対応 対応 既定で無効[37] 非対応 非対応 おそらく未対応、開発終了
(Win 3.1, 95, 98, ME
Windows NT 3.x, 4, Windows 2000向けの最新)
6 Windows XP[注 7] 対応 対応 既定で無効 非対応 非対応 対応済み、開発終了
7, 8 既定で無効[38] 対応 対応[38] 非対応 非対応 対応済み、開発終了(Win XP向けの最新)
7–9 Windows Vista 既定で無効 対応 対応 非対応 非対応 対応済み(Win Vista向けの最新)
8–10 Windows 7 既定で無効 対応 対応 既定で無効[39] 既定で無効[39] 対応済み
10 Windows 8 既定で無効 対応 対応 既定で無効 既定で無効 対応済み(Win 8向けの最新)
11 Windows 7 既定で無効 対応 対応 対応[40] 対応[40] 対応済み[41](Win 7, 8.1向けの最新)
Windows 8.1
ブラウザ バージョン プラットフォーム SSL 2.0(安全ではない) SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 脆弱性への対応[注 1]
Opera
[注 8]
[注 9]
5–7 Android,
iOS,[要出典]
Linux,
Mac OS X,
Windows
対応[42] 対応[42] 対応[42] 非対応 非対応 未対応、開発終了
8 対応 対応 対応 既定で無効[43] 非対応 未対応、開発終了
9 既定で無効[44] 対応 対応 既定で無効 非対応 未対応、開発終了
10–12 非対応[45] 対応 対応 既定で無効 既定で無効[45] 11.60以降で対応済み(Linux向け、Presto版の最新)
14–16 非対応 対応 対応 対応[46] 非対応[46] 不明、開発終了
17–[注 4] 非対応 対応 対応 対応[47] 対応[47] 対応済み(Windows、OS X、Android向けの最新)
ブラウザ バージョン プラットフォーム SSL 2.0(安全ではない) SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 脆弱性への対応[注 1]
Safari
[注 10]
1–5 Mac OS X 10.0–10.6 非対応[49] 対応 対応 非対応 非対応 未対応、開発終了(OS X 10.0–10.6向けの最新)
Mac OS X 10.7
6 Mac OS X 10.7 非対応 対応 対応 非対応 非対応 未対応(OS X 10.7向けの最新)
Mac OS X 10.8 対応済み[注 11](OS X 10.8向けの最新)
7 Mac OS X 10.9 非対応 対応 対応 対応[53] 対応[53] 対応済み[51](OS X 10.9向けの最新)
3–5 iPhone (i)OS 1–4[注 12] 非対応[54] 対応 対応 非対応 非対応 未対応、開発終了(iPhone (i)OS 1–4)向けの最新
5, 6 iOS 5, 6[注 12] 非対応 対応 対応 対応[55] 対応[55] 未対応、開発終了(iOS 5, 6向けの最新)
7 iOS 7[注 12] 非対応 対応 対応 対応 対応 対応済み[58](iOS 7向けの最新)
3–5 Windows 非対応 対応 対応 非対応 非対応 未対応、開発終了(Windows向けの最新)
ブラウザ バージョン プラットフォーム SSL 2.0(安全ではない) SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 脆弱性への対応[注 1]
バージョン、プラットフォーム 状況
灰色 混在
赤色 過去のリリース:開発終了
黄色 過去のリリース:サポート継続
緑色 現在のリリース[注 4]
  1. ^ a b c d e f 既知の脆弱性(BEAST, CRIME, BREACH, Lucky Thirteen:#既知の攻撃を参照)に対する対応がされているか否か。暗号アルゴリズムや暗号強度は考慮しない(#暗号化参照)。
  2. ^ Google Chrome(およびChromium)はバージョン21でTLS 1.1に対応したもののいったん撤回され、バージョン22で再度有効となった。TLS 1.2についても、バージョン29で有効となったものが撤回され、バージョン30で再度有効となった[17][18][19]
  3. ^ a b TLSの実装はNSSによる。NSS 3.14でTLS 1.2に[20][21]、3.15.1でTLS 1.2に対応した[22][23]
  4. ^ a b c d "27-"などのバージョン表記は、TLSへの対応状況が変化した最初のバージョン番号を示している。閲覧時点での最新版のバージョン番号が反映されているとは限らない。
  5. ^ 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が既定で有効。
  6. ^ IEのTLSへの対応はWindowsに同梱のSChannelによる。IE 11においてTLS 1.1および1.2が既定で有効[34][35]
  7. ^ a b c Windows XP以前のSChannelは3DESやRC4といった弱いアルゴリズムのみに対応[36]。これはIEだけではなく、Microsoft Officeなど、これらのOS上で動作する他のMicrosoft製品でも利用される。
  8. ^ Presto版では、Opera 10でTLS 1.2に対応(既定では無効)。
  9. ^ Opera 14以降におけるTLSへの対応は、対応するChromiumバックエンドを利用するChromeと同じとなる。
  10. ^ SafariのTLSへの対応はOS同梱のライブラリによる[48]
  11. ^ 2013年9月にBEASTへの対処が実装がされたが、既定では無効であった[50][51]。2014年2月にアップデートされたOS X 10.8.5から既定で有効となった[52]
  12. ^ a b c モバイルSafariおよびTLS/SSLを必要とするサードパーティ製のすべてのソフトウェアはiOS同梱のUIWebViewライブラリを使用する。iOS 5以降でTLS 1.1および1.2が既定で有効[55][56][57]

ライブラリ[編集]

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

ライブラリにおけるTLS/SSLの対応状況
実装 SSL 2.0(安全ではない) SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2
Botan 非対応[注 1] 対応 対応 対応 対応
cryptlib 非対応 対応 対応 対応 対応
CyaSSL 非対応 対応 対応 対応 対応
GnuTLS 非対応[注 1] 対応 対応 対応 対応
MatrixSSL 非対応[注 1] 対応 対応 対応 対応
NSS 既定で無効[注 1] 対応 対応 対応[59] 対応[60]
OpenSSL 対応 対応 対応 対応[61] 対応[61]
LibreSSL 対応 対応 対応 対応[61] 対応[61]
PolarSSL 非対応 対応 対応 対応 対応
SChannel XP/2003[62] IE 7から既定で無効 対応 IE 7から既定で有効 非対応 非対応
SChannel Vista/2008[63] 既定で無効 対応 対応 非対応 非対応
SChannel 7/2008R2, 8/1012, 8.1/2012R2[64] 既定で無効 対応 対応 対応 対応
Secure Transport 非対応[注 2] 対応 対応 対応[注 2] 対応[注 2]
SharkSSL 非対応 対応 対応 対応 対応
JSSE 非対応[注 1] 対応 対応 対応 対応
実装 SSL 2.0(安全ではない) SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2
  1. ^ a b c d e 後方互換性の確保のため、SSL 2.0に非対応あるいは既定で無効の場合にもSSL 2.0 client helloはサポートされる。
  2. ^ a b c OS X 10.8以降でSSL 2.0非対応。iOS 5以降およびOS X 10.8以降でTLS 1.1、1.2に対応[65]

課題[編集]

バーチャルホスト[編集]

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が必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。

Mozilla Firefoxにおける南京錠アイコンの例

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

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

証明書の正当性[編集]

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

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

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

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

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

例として、利用者が意図する接続先であるサーバ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つの条件を満たす必要がある。

  1. 利用者は意図する接続先の正しいホスト名を知っている。
  2. 利用者は、現在システムに指示されている接続先が、自分の知っている正しいホスト名と一致していることを確認できる。

2は、情報処理推進機構(IPA)が公開している「安全なウェブサイトの作り方」[67]という文書の「フィッシング詐欺を助長しないための対策」に対応する。

乱数の品質[編集]

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

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

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

既知の攻撃[編集]

TLS/SSLに対する攻撃のうち主なものを以下に挙げる。

再ネゴシエーション脆弱性[編集]

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

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

バージョンロールバック攻撃[編集]

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

BEAST攻撃[編集]

2011年9月23日、暗号研究者のThai DuongとJuliano Rizzoが、BEAST (Browser Exploit Against SSL/TLS)[79]と呼ばれるTLS 1.0におけるブロック暗号CBCモードの取り扱いに関する脆弱性のコンセプトをJavaアプレット同一生成元ポリシー違反によって実証した[80][81]。この脆弱性そのものは2002年にPhillip Rogawayによって発見されていた[82]が、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に対して修正を加えた[83]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脆弱性への対応が行われた。

CRIME攻撃、BREACH攻撃[編集]

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

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

パディング攻撃[編集]

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

RC4攻撃[編集]

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

OS X 10.8以前、iOS 6以前およびWindows向けのSafariを除いて、クライアントのほとんどは既にBEASTへの対処が完了していることから、RC4はもはや最良の選択肢ではなくなっており、TLS 1.0以前においてもCBCモードを用いることがより良い選択肢となっている[9]

Microsoftは可能であればRC4を用いないことを推奨している[94][95]

切り詰め攻撃[編集]

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

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

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

ハートブリード[編集]

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

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

ウェブサイトの統計[編集]

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

TLS/SSLに対する攻撃に脆弱なウェブサイトの統計(括弧内は前月との差)
攻撃 セキュリティ
安全ではない 状況による 安全 その他
再ネゴシエーション脆弱性 N/A 4.8% (−0.2%)
安全ではない再ネゴシエーションに対応
1.3% (−0.1%)
両方に対応
87.1% (+0.5%)
安全な再ネゴシエーションに対応
6.8% (−0.2%)
再ネゴシエーション非対応
RC4攻撃 1.8% (±0.0%)
RC4によるCipher Suiteのみサポート
30.6% (−1.0%)
多くのブラウザで利用可能なRC4 Suiteをサポート
58.7% (+0.7%)
RC4 Suiteのいくつかをサポート
10.7% (+0.3%)
RC4によるCipher Suite非サポート
N/A
BEAST攻撃 N/A 74.1% (+0.6%)
脆弱
N/A N/A N/A
CRIME攻撃 N/A 10.0% (−1.0%)
脆弱
N/A N/A N/A
ハートブリード N/A 0.5% (−0.2%)
脆弱
N/A N/A N/A
CVE-2014-0224 N/A 8.9% (−)
脆弱
N/A N/A N/A

参考文献[編集]

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

脚注[編集]

  1. ^ プロトコル名を含めた歴史については、Eric Rescorla著,「マスタリングTCP/IP SSL/TLS編」,オーム社開発局(2003年) ISBN 4-274-06542-1 の2章6節が詳しい。
  2. ^ 大岩 寛 (2005年10月13日). “[Security] SSL 2.0 version rollback の件のFAQ”. おおいわのこめんと. 2010年1月3日閲覧。
  3. ^ Eric Lawrence (2006年1月31日). “Internet Explorer 7 における HTTPS セキュリティーの強化点”. Microsoft Corporation. 2010年1月3日閲覧。
  4. ^ サイトが古くて安全でないバージョンの SSL プロトコルを使用しているため、安全な接続ができませんでした”. Firefox サポート (2009年7月6日). 2010年1月3日閲覧。
  5. ^ Opera 9 のサポートするウェブ標準ならびに仕様”. Opera Software ASA.. 2010年1月3日閲覧。
  6. ^ 勝村 幸博 (2006年6月2日). “「SSL 2.0だけに対応したWebサイトはわずか0.1%」---ネットクラフト”. 日経BP IT pro. 2010年1月3日閲覧。
  7. ^ RFC 3268によって後付けでAESが追加されたTLS 1.0とは異なり、TLS 1.1を定義するRFC 4346 A.5節ではRFC3268が参照され、AESが当初から追加されている
  8. ^ NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised)” (2007年3月8日). 2014年7月3日閲覧。
  9. ^ a b Qualys SSL Labs. “SSL/TLS Deployment Best Practices”. 2013年11月19日閲覧。
  10. ^ John Leyden (2013年9月6日). “That earth-shattering NSA crypto-cracking: Have spooks smashed RC4?”. The Register. 2013年12月13日閲覧。
  11. ^ Security Advisory 2868725: Recommendation to disable RC4”. Microsoft (2013年11月12日). 2013年12月13日閲覧。
  12. ^ マイクロソフト セキュリティ アドバイザリ (2868725) RC4 を無効化するための更新プログラム”. Microsoft (2013年11月13日). 2013年12月13日閲覧。
  13. ^ draft-popov-tls-prohibiting-rc4-02
  14. ^ draft-agl-tls-chacha20poly1305-04
  15. ^ a b c 2014年7月3日現在 SSL Pulse: Survey of the SSL Implementation of the Most Popular Web Sites”. 2014年7月9日閲覧。
  16. ^ a b ivanr. “RC4 in TLS is Broken: Now What?”. Qualsys Security Labs. 2013年7月30日閲覧。
  17. ^ Google (2012年5月29日). “Dev Channel Update”. 2014年7月2日閲覧。
  18. ^ Google (2012年8月21日). “Stable Channel Update”. 2014年7月2日閲覧。
  19. ^ Chromium Project (2013年5月30日). “Chromium TLS 1.2 Implementation”. 2014年7月2日閲覧。
  20. ^ a b Bug 565047 – (RFC4346) Implement TLS 1.1 (RFC 4346)”. 2014年7月2日閲覧。
  21. ^ NSS 3.14 release notes”. 2014年7月2日閲覧。
  22. ^ a b Bug 480514 – Implement support for TLS 1.2 (RFC 5246)”. 2014年7月2日閲覧。
  23. ^ NSS 3.15.1 release notes”. 2014年7月2日閲覧。
  24. ^ SVN revision log on Chrome 10.0.648.127 release”. 2014年7月2日閲覧。
  25. ^ a b SSL/TLS Overview” (2008年8月6日). 2014年7月2日閲覧。
  26. ^ a b Chromium Issue 90392” (2008年8月6日). 2014年7月2日閲覧。
  27. ^ a b Issue 23503030 Merge 219882” (2013年9月3日). 2013年9月19日閲覧。
  28. ^ a b Issue 278370: Unable to submit client certificates over TLS 1.2 from Windows” (2013年8月23日). 2013年10月3日閲覧。
  29. ^ a b c d Security in Firefox 2” (2008年8月6日). 2014年7月2日閲覧。
  30. ^ a b Introduction to SSL”. MDN. accessdate=2014-07-02閲覧。
  31. ^ Bug 733647 – Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default”. 2014年7月2日閲覧。
  32. ^ a b Firefox Notes – Desktop” (2014年2月4日). 2014年7月2日閲覧。
  33. ^ Bug 861266 – Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default”. 2014年7月2日閲覧。
  34. ^ Microsoft (2012年9月5日). “Secure Channel”. 2012年10月18日閲覧。
  35. ^ Microsoft (2009年2月27日). “MS-TLSP Appendix A”. 2014年7月2日閲覧。
  36. ^ http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512(v=vs.85).aspx
  37. ^ a b What browsers only support SSLv2?”. 2014年7月2日閲覧。
  38. ^ a b HTTPS Security Improvements in Internet Explorer 7”. 2014年7月2日閲覧。
  39. ^ a b Windows 7 adds support for TLSv1.1 and TLSv1.2 - IEInternals - Site Home - MSDN Blogs”. 2014年7月2日閲覧。
  40. ^ a b Microsoft (2013年9月24日). “IE11 Changes”. 2014年7月2日閲覧。
  41. ^ Microsoft (2013年6月24日). “Release Notes: Important Issues in Windows 8.1 Preview”. 2013年10月29日閲覧。
  42. ^ a b c Changelog for Opera 5.x for Windows”. 2014年7月2日閲覧。
  43. ^ Changelog for Opera [8] Beta 2 for Windows”. 2014年7月2日閲覧。
  44. ^ Web Specifications Supported in Opera 9”. 2014年7月2日閲覧。
  45. ^ a b Opera: Opera 10 beta for Windows changelog”. 2014年7月2日閲覧。
  46. ^ a b Chrome 27–29と同じ
  47. ^ a b Chrome 30以降と同じ
  48. ^ Adrian, Dimcev. “Common browsers/libraries/servers and the associated cipher suites implemented”. TLS Cipher Suites Project. 2014年7月2日閲覧。
  49. ^ Apple Secures Mac OS X with Mavericks Release - eSecurity Planet” (2013年10月25日). 2014年7月2日閲覧。
  50. ^ Ristic, Ivan. “Is BEAST Still a Threat?”. qualys.com. 2014年7月2日閲覧。
  51. ^ a b Ivan Ristić (2013年10月31日). “Apple enabled BEAST mitigations in OS X 10.9 Mavericks”. 2014年7月2日閲覧。
  52. ^ Ivan Ristić (2014年2月26日). “Apple finally releases patch for BEAST”. 2014年7月2日閲覧。
  53. ^ a b About the security content of OS X Mavericks v10.9”. 2014年7月2日閲覧。
  54. ^ Secure Transport Reference”. 2014年7月2日閲覧。 iOSにおいてkSSLProtocol2は"deprecated"とされている
  55. ^ a b c Apple (2011年10月14日). “Technical Note TN2287 – iOS 5 and TLS 1.2 Interoperability Issues”. 2014年7月2日閲覧。
  56. ^ Liebowitz, Matt (2011年10月13日). “Apple issues huge software security patches”. NBCNews.com. 2014年7月2日閲覧。
  57. ^ MWR Info Security (2012年4月16日). “Adventures with iOS UIWebviews”. 2014年7月2日閲覧。, "HTTPS (SSL/TLS)"セクション
  58. ^ schurtertom (2013年10月11日). “SOAP Request fails randomly on one Server but works on an other on iOS7”. 2014年7月2日閲覧。
  59. ^ NSS 3.14 release notes”. Mozilla Developer Network. Mozilla. 2014年7月2日閲覧。
  60. ^ NSS 3.15.1 release notes”. Mozilla Developer Network. Mozilla. 2014年7月2日閲覧。
  61. ^ a b c d www.openssl.org/news/changelog.html
  62. ^ TLS cipher suites in Microsoft Windows XP and 2003
  63. ^ SChannel Cipher Suites in Microsoft Windows Vista
  64. ^ TLS Cipher Suites in SChannel for Windows 7, 2008R2, 8, 2012
  65. ^ Technical Note TN2287: iOS 5 and TLS 1.2 Interoperability Issues”. iOS Developer Library. Apple Inc.. 2014年7月2日閲覧。
  66. ^ 高木 浩光 (2007年11月17日). “オレオレ証明書の区分 第三版”. 高木浩光@自宅の日記. 2010年1月3日閲覧。
  67. ^ 「安全なウェブサイトの作り方 改訂第3版」を公開”. 独立行政法人 情報処理推進機構 (2008年6月11日). 2010年1月3日閲覧。
  68. ^ Ian Goldberg; David Wagner (1996年1月1日). “Randomness and the Netscape Browser” (英語). Dr. Dobb's. 2010年1月3日閲覧。
  69. ^ OpenSSL パッケージの脆弱性とその影響について (SSH鍵、SSL証明書等)”. Debian JP Project (2008年5月15日). 2010年1月3日閲覧。
  70. ^ Debian generated SSH-Keys working exploit”. SecurityFocus (2008年5月15日). 2010年1月3日閲覧。
  71. ^ Debian GNU/Linux に含まれる OpenSSL/OpenSSH の脆弱性に関する注意喚起”. JPCERT/CC (2008年5月19日). 2010年1月3日閲覧。
  72. ^ Ray, Marsh; Steve Dispensa (2009年11月4日). “Renegotiating TLS (PDF)” (英語). 2010年2月13日閲覧。
  73. ^ JVNVU#120541 SSL および TLS プロトコルに脆弱性”. Japan Vulnerability Notes. JPCERT/CC and IPA (2009年11月13日). 2010年2月13日閲覧。
  74. ^ A. Langley; N. Modadugu, B. Moeller (2012年6月). “Transport Layer Security (TLS) False Start”. Internet Engineering Task Force. IETF. 2014年6月24日閲覧。
  75. ^ Wolfgang, Gruener. “False Start: Google Proposes Faster Web, Chrome Supports It Already”. 2010年10月7日時点のオリジナルよりアーカイブ。2014年6月24日閲覧。
  76. ^ Brian, Smith. “Limited rollback attacks in False Start and Snap Start”. 2014年6月24日閲覧。
  77. ^ Adrian, Dimcev. “False Start”. Random SSL/TLS 101. 2014年6月24日閲覧。
  78. ^ Mavrogiannopoulos, Nikos and Vercautern, Frederik and Velchkov, Vesselin and Preneel, Bart (2012). 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. 
  79. ^ Thai Duong and Juliano Rizzo (2011年5月13日). “Here Come The ⊕ Ninjas”. 2014年6月24日閲覧。
  80. ^ Dan Goodin (2011年9月19日). “Hackers break SSL encryption used by millions of sites”. 2014年6月24日閲覧。
  81. ^ Y Combinator comments on the issue” (2011年9月20日). 2014年6月24日閲覧。
  82. ^ Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures” (2004年5月20日). 2012年6月30日時点のオリジナルよりアーカイブ。2014年6月24日閲覧。
  83. ^ Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)” (2012年1月10日). 2014年6月24日閲覧。
  84. ^ Dan Goodin (2012年9月13日). “Crack in Internet's foundation of trust allows HTTPS session hijacking”. Ars Technica. 2014年6月24日閲覧。
  85. ^ Dennis Fisher (2012年9月13日). “CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions”. ThreatPost. 2014年6月24日閲覧。[リンク切れ]
  86. ^ a b Goodin, Dan (2013年8月1日). “Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages”. Ars Technica. Condé Nast. 2014年6月24日閲覧。
  87. ^ Leyden, John (2013年8月2日). “Step into the BREACH: New attack developed to read encrypted web data”. The Register. 2014年6月24日閲覧。
  88. ^ security – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune – Server Fault
  89. ^ 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. 
  90. ^ Green, Matthew. “Attack of the week: RC4 is kind of broken in TLS”. Cryptography Engineering. 2014年6月24日閲覧。
  91. ^ 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日閲覧。
  92. ^ 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日閲覧。. 
  93. ^ 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. https://www.usenix.org/sites/default/files/conference/protected-files/alfardan_sec13_slides.pdf 2014年6月24日閲覧. "Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical" 
  94. ^ Security Advisory 2868725: Recommendation to disable RC4”. Microsoft (2013年11月12日). 2014年6月24日閲覧。
  95. ^ draft-popov-tls-prohibiting-rc4-02
  96. ^ a b John Leyden (2013年8月1日). “Gmail, Outlook.com and e-voting 'pwned' on stage in crypto-dodge hack”. The Register. 2014年6月24日閲覧。
  97. ^ BlackHat USA Briefings”. Black Hat 2013. 2014年6月24日閲覧。

関連項目[編集]

外部リンク[編集]

標準化[編集]

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は標準化されていない

  • 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の拡張

TLS 1.2の拡張

  • RFC 5288: "AES 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 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 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 7027: "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)".

TLSを含むカプセル化

日本の認証局ベンダー(50音順)[編集]