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 / SPB / トンネリング (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として公開された。

2014年10月にSSL 3.0の仕様上の脆弱性 (POODLE攻撃) が発見されたため、SSL 3.0への対応を打ち切り、TLS 1.0以降のみ対応への移行が望まれている。

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といった認証付き暗号を用いたAEAD英語版によるcipher suiteが利用可能となった。また、AESに関する記述がRFC 5246自体に含まれるようになった。

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

TLS 1.3(草稿)[編集]

2014年10月現在、TLS 1.3が新たなTLSのバージョンとして提案されている[8][9]。TLS 1.2からの変更点としては、データ圧縮の非サポート、forward secrecyではないcipher suiteおよびAEAD英語版ではないcipher suite(CBCモードブロック暗号RC4を用いたもの)の廃止が挙げられる。

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

提供する機能[編集]

SSLによるセキュアな通信

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

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

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

認証・鍵共有[編集]

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

TLSの各バージョンで使用できる署名アルゴリズム
アルゴリズム SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 状況
RSA 対応 対応 対応 対応 対応 TLS 1.2向けにRFCで定義済み
DH-RSA 非対応 対応 対応 対応 対応
DHE-RSA (forward secrecy)
ECDH-RSA 非対応 非対応 対応 対応 対応
ECDHE-RSA (forward secrecy)
DH-DSS 非対応 対応 対応 対応 対応
DHE-DSS (forward secrecy)
ECDH-ECDSA 非対応 非対応 対応 対応 対応
ECDHE-ECDSA (forward secrecy)
DH-ANON(安全ではない) 非対応 対応 対応 対応 対応
ECDH-ANON(安全ではない) 非対応 非対応 対応 対応 対応
GOST R 34.10-94 / 34.10-2001[10] 非対応 非対応 対応 対応 対応 RFC草稿で提案中

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

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

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

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

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

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

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

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

暗号化[編集]

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

TLS/SSLの各バージョンで使用できる暗号化アルゴリズム
暗号化 プロトコルバージョン 状況
種類 アルゴリズム 暗号強度 (bit) SSL 2.0 SSL 3.0
[注 1][注 2][注 3][注 4]
TLS 1.0
[注 1][注 3]
TLS 1.1
[注 1]
TLS 1.2
[注 1]
ブロック暗号
暗号利用モード
AES GCM[11][注 5] 256, 128 N/A N/A N/A N/A 安全 TLS 1.2向けにRFCで定義済み
AES CCM[12][注 5] N/A N/A N/A N/A 安全
AES CBC[注 6] N/A N/A 実装による 安全 安全
Camellia GCM[13][注 5] 256, 128 N/A N/A N/A N/A 安全
Camellia CBC[14][注 6] N/A N/A 実装による 安全 安全
ARIA GCM[15][注 5] 256, 128 N/A N/A N/A N/A 安全
ARIA CBC[15][注 6] N/A N/A 実装による 安全 安全
SEED CBC[16][注 6] 128 N/A N/A 実装による 安全 安全
3DES EDE CBC[注 6] 112[注 7] 安全ではない 安全ではない 強度不足、実装による 強度不足 強度不足
GOST 28147-89英語版 CNT[10] 256 N/A N/A 安全 安全 安全 RFC草稿で提案中
IDEA CBC[注 6][注 8] 128 安全ではない 安全ではない 実装による 安全 N/A TLS 1.2で廃止
DES CBC[注 6][注 8] 056 安全ではない 安全ではない 安全ではない 安全ではない N/A
040[注 9] 安全ではない 安全ではない 安全ではない N/A N/A TLS 1.1以降で利用禁止
RC2 CBC[注 6] 040[注 9] 安全ではない 安全ではない 安全ではない N/A N/A
ストリーム暗号 RC4[注 10] 128 安全ではない 安全ではない 安全ではない 安全ではない 安全ではない TLS 1.2向けにRFCで定義済み
040[注 9] 安全ではない 安全ではない 安全ではない N/A N/A TLS 1.1以降で利用禁止
ChaCha20+Poly1305[19][注 5] 256 N/A N/A N/A N/A 安全 RFC草稿で提案中
ChaCha20[20] 256 N/A N/A 安全 安全 安全
暗号化なし Null[注 11] - N/A 安全ではない 安全ではない 安全ではない 安全ではない TLS 1.2向けにRFCで定義済み
  1. ^ a b c d 再ネゴシエーション脆弱性への対応のため、RFC 5746への対応が必要
  2. ^ RFC 5746への対応はSSL 3.0の仕様を逸脱するが、ほとんどの実装では対応したうえで仕様からの逸脱にも対処している
  3. ^ a b SSL 3.0およびTLS 1.0はBEAST攻撃に対して脆弱であり、クライアント側、サーバ側での対応が必要。#ウェブブラウザ節を参照
  4. ^ SSL 3.0はPOODLE攻撃に対して脆弱であり、クライアント側、サーバ側での対応が必要。#ウェブブラウザ節を参照
  5. ^ a b c d e GCM、CCMなどのAEAD(認証付き暗号モード)は、TLS 1.2のみで利用可能
  6. ^ a b c d e f g h CBCモードは、サイドチャネル攻撃への対処が不十分な実装ではLucky Thirteen攻撃に対して脆弱である
  7. ^ 3DESの鍵長は168ビットであるが実質的な暗号強度は112ビットであり[17]、2014年現在で最低限必要とされる128ビットに不足している[18]
  8. ^ a b IDEA、DESはTLS 1.2で廃止された
  9. ^ a b c 40ビットのセキュリティ強度を持つCipher Suiteは、アメリカ合衆国による高強度暗号アルゴリズムの輸出規制を回避するために設計された。これらはTLS 1.1以降では利用が禁止されている。
  10. ^ 脆弱性が指摘されている(RC4攻撃
  11. ^ 認証のみで暗号化は行われない。

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

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

ストリーム暗号であるRC4は前述のBEAST攻撃を受けることはないが、RC4には仕様上の脆弱性が存在する(RC4攻撃)。Googleなどによって、ストリーム暗号であるChaCha20単独および認証のためのPoly1305を組み合わせたChaCha20+Poly1305が提案されている[21]

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

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

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

改竄検出[編集]

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

暗号化にGCMCCMなどの認証付き暗号を利用する場合はMACとしてAEAD英語版が利用される。その他の場合はハッシュ関数に基づくMACであるHMACSHA-256/384SHA-1MD5との組み合わせ)が利用される。

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

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

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

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

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

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

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

実装[編集]

ウェブサイト[編集]

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

ウェブブラウザ[編集]

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

  • TLS 1.1、1.2に対応しているが既定で無効:Internet Explorer(8–10:Windows 7 / Server 2008 R2向け、10:Windows 8 / Server 2012向け、Mobile 10:Windows Phone 8向け)
  • TLS 1.1、1.2に未対応:Internet Explorer(6-8:Windows Server 2003向け、7–9:Windows Vista / Server 2008向け)、Safari 6(OS X 10.8向け)

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

  • POODLE攻撃への対応:Google ChromeおよびOperaがTLS_FALLBACK_SCSVを実装済みでSSL 3.0へのフォールバックを抑止することが可能となっているが、これはクライアント側だけでなくサーバ側での対応も必要である。Operaでは"anti-POODLE record splitting"と呼ばれる異なる対策も実装済みであり、こちらはクライアント側のみの対応で有効である。SSL 3.0を既定で無効にしない限りすべてのブラウザがPOODLEに対して脆弱である。Safariでは、OS X 10.8以降およびiOS 8ではSSL 3.0においてCBCモードを使用しないことでPOODLEへの対応としているが、これによりRC4攻撃に対して脆弱となっている。Firefoxでは、バージョン34およびESR 31.3においてSSL 3.0そのものを無効化し、バージョン35においてTLS_FALLBACK_SCSVを実装予定である。Google Chromeでは、バージョン40においてSSL 3.0を無効化する予定である。Safari(OS X 10.8およびiOS 8.1以降)では、POODLEへの対策としてSSL 3.0においてCBCモードのcipher suiteを無効化した。これによりPOODLEの影響を受けることはなくなるが、SSL 3.0においてCBCモードを無効化したことで、脆弱性が指摘されているRC4しか利用できなくなるという問題が生じている。
  • RC4攻撃への対応:Google Chrome、Mozilla Firefox、Opera、Windows 7 / Server 2008 R2およびWindows 8 / Server 2012向けのInternet Explorerでは、RC4の優先度を最低としている。Windows 8.1 / Server 2012 R2向けのInternet Explorer 11およびWindows Phone 8.1向けのInternet Explorer Mobile 11では、サーバが他のアルゴリズムに非対応の場合のフォールバックを除きRC4を無効としている(Windows 7 / Server 2008 R2およびWindows 8 / Server 2012向けのInternet Explorerでもレジストリからフォールバックを除きRC4を無効化することが可能)。Firefoxはバージョン36においてフォールバックを除きRC4を無効とする予定である。
ウェブブラウザにおけるTLS/SSLの対応状況の変化 [編集]
ウェブブラウザ バージョン プラットフォーム TLS/SSLプロトコル EV証明書[25] SHA-2証明書[26] 脆弱性への対応[注 1] プロトコル選択[注 2]
SSL 2.0
(安全ではない)
SSL 3.0
(安全ではない)
TLS 1.0 TLS 1.1 TLS 1.2 BEAST
[注 3]
CRIME
[注 4]
POODLE
[注 5]
RC4
[注 6]
Google Chrome
(Chrome for Android)
[注 7]
[注 8]
1–9 Windows
OS X
Linux
Android
iOS
Chrome OS
既定で無効 既定で有効 対応 非対応 非対応 対応 非対応 影響なし 脆弱
(HTTPS圧縮)
脆弱 脆弱 [注 9]
10–20 非対応[30] 既定で有効 対応 非対応 非対応 対応 非対応 影響なし 脆弱
(HTTPS/SPDY圧縮)
脆弱 脆弱 [注 9]
21 非対応 既定で有効 対応 非対応 非対応 対応 非対応 影響なし 対策済[31] 脆弱 脆弱 [注 9]
22–25 非対応 既定で有効 対応 対応[32] 非対応[32][33][34][35] 対応 非対応 影響なし 対策済 脆弱 脆弱 一時的[注 10]
26–29 非対応 既定で有効 対応 対応 非対応 対応 対応 影響なし 対策済 脆弱 脆弱 一時的[注 10]
30–32 非対応 既定で有効 対応 対応 対応[33][34][35] 対応 対応 影響なし 対策済 脆弱 脆弱 一時的[注 10]
33–38 非対応 既定で有効 対応 対応 対応[33][34][35] 対応 対応 影響なし 対策済 部分的に対策済[注 11] 優先度最低[38][39][40] 一時的[注 10]
39
40 非対応 既定で無効[37] 対応 対応 対応 対応 対応 影響なし 対策済 対策済[注 12] 優先度最低 一時的[注 10]
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない)
SSL 3.0
(安全ではない)
TLS 1.0 TLS 1.1 TLS 1.2 EV証明書 SHA-2証明書 BEAST CRIME POODLE RC4 プロトコル選択
Mozilla Firefox
(Firefox for Mobile)
[注 13]
1.0 Windows
OS X
Linux
Android
Firefox OS
既定で有効[41] 既定で有効[41] 対応[41] 非対応 非対応 非対応 非対応 影響なし 影響なし 脆弱 脆弱 [注 9]
1.5 既定で有効 既定で有効 対応 非対応 非対応 非対応 対応 影響なし 影響なし 脆弱 脆弱 [注 9]
2 既定で無効[41][42] 既定で有効 対応 非対応 非対応 非対応 対応 影響なし 影響なし 脆弱 脆弱 [注 9]
3–7 既定で無効 既定で有効 対応 非対応 非対応 対応 対応 影響なし 影響なし 脆弱 脆弱 [注 9]
8–10
ESR 10
非対応[42] 既定で有効 対応 非対応 非対応 対応 対応 影響なし 影響なし 脆弱 脆弱 [注 9]
11–14 非対応 既定で有効 対応 非対応 非対応 対応 対応 影響なし 脆弱
(SPDY圧縮)[31]
脆弱 脆弱 [注 9]
15–22 非対応 既定で有効 対応 非対応 非対応 対応 対応 影響なし 対策済 脆弱 脆弱 [注 9]
ESR 17 ESR 17.0.11より優先度最低[43][44]
23 非対応 既定で有効 対応 既定で無効[45] 非対応 対応 対応 影響なし 対策済 脆弱 脆弱 [注 14]
24–26
ESR 24
非対応 既定で有効 対応 既定で無効 既定で無効[47] 対応 対応 影響なし 対策済 脆弱 v25.0.1, ESR 24.1.1より優先度最低[43][44] [注 14]
27–33.1
ESR 31.0–31.2
非対応 既定で有効 対応 対応[48][49] 対応[50][49] 対応 対応 影響なし 対策済 脆弱 優先度最低 [注 14]
ESR 31.3 非対応 既定で無効[51][52] 対応 対応 対応 対応 対応 影響なし 対策済 対策済[注 15] 優先度最低 [注 14]
34
35
36 非対応 既定で無効 対応 対応 対応 対応 対応 影響なし 対策済 対策済 フォールバックを除き無効[注 16][55] [注 14]
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない)
SSL 3.0
(安全ではない)
TLS 1.0 TLS 1.1 TLS 1.2 EV証明書 SHA-2証明書 BEAST CRIME POODLE RC4 プロトコル選択
Internet Explorer
[注 17]
1 Windows 3.1, 95,
Windows NT 3.1 (v2まで), 3.5 (v3まで), 3.51, 4[注 18]
System 7, Mac OS
非対応 非対応 非対応 非対応 非対応 TLS/SSL非対応
2 対応 非対応 非対応 非対応 非対応 非対応 非対応 SSLv3/TLSv1非対応 影響なし SSLv3非対応 脆弱 不明
3 対応 対応[58] 非対応 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 不明
4, 5, 6 Windows 3.1, 95, 98, ME
Windows NT 3.51, 4
2000[注 18]
Mac OS, OS X, Solaris
HP-UX (v6を除く)
既定で有効 既定で有効 既定で無効[58] 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 [注 9]
6 Windows XP[注 18] 既定で有効 既定で有効 既定で無効 非対応 非対応 非対応 対応
SP3より[59]
対策済 影響なし 脆弱 脆弱 [注 9]
7, 8 既定で無効[60] 既定で有効 対応[60] 非対応 非対応 対応 対応
SP3より[59]
対策済 影響なし 脆弱 脆弱 [注 9]
6 Windows Server 2003[注 18] 既定で有効 既定で有効 既定で無効 非対応 非対応 非対応 hotfixで対応[注 19][59] 対策済 影響なし 脆弱 脆弱 [注 9]
7, 8 既定で無効[60] 既定で有効 対応[60] 非対応 非対応 対応 hotfixで対応[注 19][59] 対策済 影響なし 脆弱 脆弱 [注 9]
7, 8, 9 Windows Vista / Server 2008 既定で無効 既定で有効 対応 非対応 非対応 対応 対応 対策済 影響なし 脆弱 脆弱 [注 9]
8, 9, 10 Windows 7 / Server 2008 R2 既定で無効 既定で有効 対応 既定で無効[63] 既定で無効[63] 対応 対応 対策済 影響なし 脆弱 優先度最低[64][注 20] [注 9]
10 Windows 8 / Server 2012
11 Windows 7 / Server 2008 R2 既定で無効 既定で有効 対応 対応[66] 対応[66] 対応 対応 対策済 影響なし 脆弱 優先度最低[64][注 20] [注 9]
Windows 8.1 / Server 2012 R2 フォールバックを除き無効[注 16][67][68] [注 9]
Internet Explorer Mobile
[注 17]
7, 9 Windows Phone 7, 7.5, 7.8 既定で無効
[要出典]
既定で有効 対応 非対応
[要出典]
非対応
[要出典]
対応
[要出典]
対応 不明 影響なし 脆弱 脆弱 [注 21]
10 Windows Phone 8 既定で無効
[要出典]
既定で有効 対応 既定で無効[70] 既定で無効[70] 対応
[要出典]
対応 対策済 影響なし 脆弱 脆弱 [注 21]
11 Windows Phone 8.1 既定で無効
[要出典]
既定で有効 対応 対応[71] 対応[71] 対応
[要出典]
対応 対策済 影響なし 脆弱 フォールバックを除き無効[注 16][67][68] [注 21]
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない)
SSL 3.0
(安全ではない)
TLS 1.0 TLS 1.1 TLS 1.2 EV証明書 SHA-2証明書 BEAST CRIME POODLE RC4 プロトコル選択
Opera
(Opera Mobile)
(Presto以前)
[注 22]
1, 2 Windows
OS X
Linux
Android
Symbian S60
Windows Mobile
非対応[72] 非対応 非対応 非対応 非対応 TLS/SSL非対応
3 対応[73] 非対応 非対応 非対応 非対応 非対応 非対応 SSLv3/TLSv1非対応 影響なし SSLv3非対応 脆弱 不明
4 対応 対応[74] 非対応 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 不明
5–7 既定で有効 既定で有効 対応[75] 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 [注 9]
8 既定で有効 既定で有効 対応 既定で無効[76] 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 [注 9]
9 既定で無効[77] 既定で有効 対応 対応 非対応 v9.5より対応 対応 脆弱 影響なし 脆弱 脆弱 [注 9]
10 非対応[78] 既定で有効 対応 既定で無効 既定で無効[78] 対応 対応 脆弱 影響なし 脆弱 脆弱 [注 9]
11 非対応 既定で有効 対応 既定で無効 既定で無効 対応 対応 v11.60より対策済[79] 影響なし 脆弱 脆弱 [注 9]
12 非対応 既定で無効[注 23] 対応 既定で無効 既定で無効 対応 対応 対策済 影響なし 対策済[注 23] v12.15より部分的に対策済[81][82] [注 9]
Opera
(Opera Mobile)
(WebKit/Blink)
[注 24]
14–16 Windows
OS X
Linux
Android
非対応 既定で有効 対応 対応[85] 非対応[85] 対応 対応 影響なし 対策済 脆弱 脆弱 一時的[注 10]
17–19 非対応 既定で有効 対応 対応[86] 対応[86] 対応 対応 影響なし 対策済 脆弱 脆弱 一時的[注 10]
20–24 非対応 既定で有効 対応 対応 対応 対応 対応 影響なし 対策済 部分的に対策済[注 25] 優先度最低[87] 一時的[注 10]
25 非対応 既定で有効[注 26] 対応 対応 対応 対応 対応 影響なし 対策済 対策済[注 27] 優先度最低 一時的[注 10]
26
27 非対応 既定で無効[88] 対応 対応 対応 対応 対応 影響なし 対策済 対策済[注 28] 優先度最低 一時的[注 10]
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない)
SSL 3.0
(安全ではない)
TLS 1.0 TLS 1.1 TLS 1.2 EV証明書 SHA-2証明書 BEAST CRIME POODLE RC4 プロトコル選択
Safari
[注 29]
1 Mac OS X 10.2, 10.3 非対応[90] 対応 対応 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 不可
2–4 Mac OS X 10.4 非対応 対応 対応 非対応 非対応 v3.2より対応 非対応 脆弱 影響なし 脆弱 脆弱 不可
3–6 Mac OS X 10.5, 10.6, 10.7 非対応 対応 対応 非対応 非対応 v3.2より対応 対応 脆弱 影響なし 脆弱 脆弱 不可
6 OS X 10.8 非対応 対応 対応 非対応 非対応 対応 対応 対策済[注 30] 影響なし 対策済[注 31] 脆弱[注 31] 不可
7 OS X 10.9 非対応 対応 対応 対応[96] 対応[96] 対応 対応 対策済[92] 影響なし 対策済[注 31] 脆弱[注 31] 不可
8 OS X 10.10 非対応 対応 対応 対応 対応 対応 対応 対策済 影響なし 対策済[注 31] 脆弱[注 31] 不可
3–5 Windows 非対応 対応 対応 非対応 非対応 v3.2より対応 非対応 脆弱 影響なし 脆弱 脆弱 不可
Safari
(モバイル)
[注 32]
3 iPhone OS 1, 2 非対応[100] 対応 対応 非対応 非対応 非対応 非対応 脆弱 影響なし 脆弱 脆弱 不可
4, 5 iPhone OS 3, iOS 4 非対応 対応 対応 非対応 非対応 対応[101] 対応 脆弱 影響なし 脆弱 脆弱 不可
5, 6 iOS 5, 6 非対応 対応 対応 対応[97] 対応[97] 対応 対応 脆弱 影響なし 脆弱 脆弱 不可
7 iOS 7 非対応 対応 対応 対応 対応 対応 対応 対策済[102] 影響なし 脆弱 脆弱 不可
8 iOS 8 非対応 対応 対応 対応 対応 対応 対応 対策済 影響なし 対策済[注 31] 脆弱[注 31] 不可
ブラウザ バージョン プラットフォーム SSL 2.0
(安全ではない)
SSL 3.0
(安全ではない)
TLS 1.0 TLS 1.1 TLS 1.2 EV証明書[25] SHA-2証明書[26] BEAST
[注 3]
CRIME
[注 4]
POODLE
[注 5]
RC4
[注 6]
プロトコル選択
[注 2]
TLS/SSLプロトコル 脆弱性への対応[注 1]
バージョン、プラットフォーム 状況
開発版
現在の最新リリース
過去のリリース:サポート継続
過去のリリース:開発終了
オペレーティングシステム そのブラウザによるサポートが完全に終了したOS
混在
  1. ^ a b 既知の脆弱性に対する対応がされているか否か。暗号アルゴリズムや暗号強度は考慮しない(#暗号化参照)。
  2. ^ a b ユーザあるいは管理者によって、使用するプロトコルを選択できるか否か。可能な場合、いくつかの攻撃を回避することができる(SSL 3.0およびTLS 1.0におけるBEASTや、SSL 3.0におけるPOODLEなど)。
  3. ^ a b 1/n-1 record splittingなど。
  4. ^ a b HTTPS/SPDYにおけるヘッダ圧縮の無効化。
  5. ^ a b
    • 完全な対策としては、SSL 3.0そのものの無効化、"anti-POODLE record splitting"の実装。"anti-POODLE record splitting"はクライアント側のみの対応で有効でありSSL 3.0の仕様にも準拠しているが、サーバによっては互換性の問題が生じる可能性がある。
    • 部分的な対策としては、クライアント側でのSSL 3.0へのフォールバックの無効化、TLS_FALLBACK_SCSVの実装、CBCモードによるCipher Suiteの無効化など。TLS_FALLBACK_SCSVはSSL 3.0へのフォールバックの抑止の一つであるがクライアント、サーバ双方での対応が必要であり、サーバ側がこれに非対応かつSSL 3.0対応の場合には効果がない。SSL 3.0においてCBCモードによるCipher Suiteを無効化した場合には、RC4を用いたCipher Suiteしか利用できなくなるためRC4攻撃に対する脆弱性が増大する。
    • 手動でSSL 3.0を無効化した場合にはPOODLE攻撃を受けることはない。
  6. ^ a b
    • 完全な対策としては、RC4を用いたCipher Suiteの無効化。
    • 古い環境との互換性を維持した部分的な対策としては、RC4を用いたCipher Suiteの優先度の低下。
  7. ^ Google Chrome(およびChromium)はバージョン21でTLS 1.1に対応したもののいったん撤回され、バージョン22で再度有効となった。TLS 1.2についても、バージョン29で有効となったものが撤回され、バージョン30で再度有効となった[27][28][29]
  8. ^ TLSの実装はAndroid版のみOpenSSL、それ以外のプラットフォームではNSSによる。
  9. ^ a b c d e f g h i j k l m n o p q r s t u v w x y 設定あるいはオプションより設定可能(ブラウザにより名称は異なる)
  10. ^ a b c d e f g h i j 起動オプションより設定可能
  11. ^ TLS_FALLBACK_SCSVを実装[36]。バージョン39よりSSL 3.0へのフォールバック無効化を追加[37]
  12. ^ TLS_FALLBACK_SCSVの実装、SSL 3.0へのフォールバック無効化に加え、バージョン40でSSL 3.0を既定で無効化[37]
  13. ^ TLSの実装はNSSによる。Firefox 22以前では、同梱のNSSがTLS 1.1に対応していたもののブラウザとしてはTLS 1.0まで対応。Firefox 23でTLS 1.1に、Firefox 24でTLS 1.2に対応したが既定では無効。Firefox 27よりTLS 1.1およびTLS 1.2が既定で有効。
  14. ^ a b c d e about:configあるいはアドオン[46]より設定可能
  15. ^ バージョン34.0、ESR 31.3でSSL 3.0を既定で無効化[51][52]。バージョン34.0ではSSL 3.0へのフォールバック無効化を追加[53]。ESR 31.3およびバージョン35ではTLS_FALLBACK_SCSVを実装[51][54]
  16. ^ a b c サーバがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限り、RC4を用いたCipher Suiteがフォールバックとして利用される。
  17. ^ a b IEのTLSへの対応はWindowsに同梱のSChannelによる。IE 11においてTLS 1.1および1.2が既定で有効[56][57]
  18. ^ a b c d Windows XPおよび Server 2003以前のSChannelは3DESやRC4といった弱いアルゴリズムのみに対応[61]。これはIEだけではなく、Microsoft Officeなど、これらのOS上で動作する他のMicrosoft製品でも利用される。Server 2003のみ、KB 948963によってAESに対応する[62]
  19. ^ a b KB 938397および968730
  20. ^ a b サーバがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限り、RC4を用いたCipher Suiteがフォールバックとして利用されるようレジストリから変更することも可能[65]
  21. ^ a b c レジストリより設定可能[69]
  22. ^ Presto版では、Opera 10でTLS 1.2に対応(既定では無効)。
  23. ^ a b 2014年10月15日以降、SSL 3.0の既定での無効化をリモートで実施[80]
  24. ^ Opera 14以降におけるTLSへの対応は、対応するChromiumバックエンドを利用するChromeと同じとなる。Android版Opera 14はChromium 26(レイアウトエンジンはWebKit[83]、Opera 15以降はChromium 28以降(レイアウトエンジンはBlink)をベースとしている[84]
  25. ^ TLS_FALLBACK_SCSVを実装[87]
  26. ^ BEASTおよびPOODLEへの対策を実装済みであり[80]、SSL 3.0が既定で有効であってもこれらの攻撃を受けることはない。
  27. ^ TLS_FALLBACK_SCSVの実装に加え、"anti-POODLE record splitting"を実装[80]
  28. ^ TLS_FALLBACK_SCSV、"anti-POODLE record splitting"の実装に加え、SSL 3.0を既定で無効化[88]
  29. ^ SafariのTLSへの対応はOS同梱のライブラリによる[89]
  30. ^ 2013年9月にBEASTへの対処が実装がされたが、既定では無効であった[91][92]。2014年2月にアップデートされたOS X 10.8.5から既定で有効となった[93]
  31. ^ a b c d e f g h POODLEへの対応としてSSL 3.0においてCBCモードをすべて廃止した[94][95]ため、SSL 3.0では脆弱性が指摘されているRC4しか利用できず、RC4攻撃に対する脆弱性が増大している。
  32. ^ モバイルSafariおよびTLS/SSLを必要とするサードパーティ製のすべてのソフトウェアはiOS同梱のUIWebViewライブラリを使用する。iOS 5以降でTLS 1.1および1.2が既定で有効[97][98][99]

ライブラリ[編集]

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

ライブラリにおけるTLS/SSLの対応状況
実装 SSL 2.0(安全ではない) SSL 3.0(安全ではない) TLS 1.0 TLS 1.1 TLS 1.2
Botan 非対応[注 1] 既定で無効[103] 対応 対応 対応
cryptlib 非対応 既定で有効 対応 対応 対応
CyaSSL 非対応 既定で有効 対応 対応 対応
GnuTLS 非対応[注 1] 既定で有効 対応 対応 対応
MatrixSSL 非対応[注 1] コンパイル時点で既定で無効[104] 対応 対応 対応
NSS 既定で無効[注 1] 既定で有効 対応 対応[105] 対応[106]
OpenSSL 既定で有効 既定で有効 対応 対応[107] 対応[107]
LibreSSL 非対応 既定で無効[108] 対応 対応[107] 対応[107]
PolarSSL 非対応 既定で有効 対応 対応 対応
SChannel XP/2003[109] IE 7から既定で無効 既定で有効 IE 7から既定で有効 非対応 非対応
SChannel Vista/2008[110] 既定で無効 既定で有効 対応 非対応 非対応
SChannel 7/2008R2[111] 既定で無効 既定で有効 対応 IE 11から既定で有効 IE 11から既定で有効
SChannel 8/1012[111] 既定で無効 既定で有効 対応 既定で無効 既定で無効
SChannel 8.1/2012R2, 10 Technical Preview[111] 既定で無効 既定で有効 対応 対応 対応
Secure Transport OS X 10.2-10.7 / iOS 1-4 対応 対応 対応 非対応 非対応
Secure Transport OS X 10.8-10.10 / iOS 5-8 非対応[注 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に対応[112]

課題[編集]

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

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用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。

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

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

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

乱数の品質[編集]

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

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

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

既知の攻撃[編集]

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

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

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

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

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

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

BEAST攻撃[編集]

2011年9月23日、暗号研究者のThai DuongとJuliano Rizzoが、BEAST (Browser Exploit Against SSL/TLS)[126]と呼ばれるTLS 1.0におけるブロック暗号CBCモードの取り扱いに関する脆弱性のコンセプトをJavaアプレット同一生成元ポリシー違反によって実証した[127][128]。この脆弱性そのものは2002年にPhillip Rogawayによって発見されていた[129]が、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に対して修正を加えた[130]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の内容が回復可能となるCRIMECompression Ratio Info-leak Made Easy, 英語版)が報告された[131][132]。ウェブサイトでのユーザ認証に使われているCookieの内容を回復されることで、セッションハイジャックが可能となる。 2012年9月にはMozilla FirefoxおよびGoogle ChromeにおいてCRIMEへの対応が実施された。また、MicrosoftによればInternet ExplorerはCRIMEの影響を受けない。

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

パディング攻撃[編集]

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

TLSでこれまで用いられてきたMAC-then-Encrypt (MtE) に加え、拡張としてEncrypt-then-MAC (EtM) を定義するRFC 7366が2014年に勧告された(MtE、EtMについては認証付き暗号#認証付き暗号の手法を参照のこと)。

POODLE攻撃[編集]

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

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

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

Google ChromeブラウザやGoogleサービスのサーバは既にTLS_FALLBACK_SCSVに対応しており、加えて数か月以内にこれらクライアント、サーバからSSL 3.0のサポートを除去する予定である[136]OperaもGoogle Chromeと同様にTLS_FALLBACK_SCSVを実装済みであるほか、バージョン25において"anti-POODLE record splitting"と呼ばれる異なる対策を実装した[138]。Mozillaでは2014年12月リリースのMozilla Firefox 34およびESR 31.3からSSL 3.0を無効化したほか、Firefox 35においてTLS_FALLBACK_SCSVをサポートする予定である[139]。Microsoftでは、グループポリシーからSSL 3.0を無効化する方法を公開しているほか[140]、10月29日にWindows Vista、Server 2003およびそれ以降のIEにおいてSSL 3.0を無効化する"Fix it"を公開し、数か月以内にIEおよびマイクロソフトのオンラインサービスにおいてSSL 3.0を既定で無効化する方針を表明した[141]Safari(OS X 10.8およびiOS 8.1以降)では、POODLEへの対策としてSSL 3.0においてCBCモードのcipher suiteを無効化した[142][143]。これによりPOODLEの影響を受けることはなくなるが、SSL 3.0においてCBCモードを無効化したことで、脆弱性が指摘されているRC4しか利用できなくなるという問題が生じている。

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

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

RC4攻撃[編集]

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

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

MicrosoftではRC4を無効化することを推奨している[159][160][161]

切り詰め攻撃[編集]

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

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

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

ハートブリード[編集]

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

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

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

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

TLS/SSLに対する攻撃に脆弱なウェブサイトの統計(括弧内は前月との差)
攻撃 セキュリティ
安全ではない 状況による 安全 その他
再ネゴシエーション脆弱性 N/A 3.7% (−0.2%)
安全ではない再ネゴシエーションに対応
1.2% (±0.0%)
両方に対応
90.0% (+0.5%)
安全な再ネゴシエーションに対応
5.1% (−0.3%)
再ネゴシエーション非対応
RC4攻撃 1.3% (−0.1%)
RC4によるCipher Suiteのみサポート
26.6% (−0.7%)
多くのブラウザで利用可能なRC4 Suiteをサポート
53.2% (−0.7%)
RC4 Suiteのいくつかをサポート
20.2% (+1.4%)
RC4によるCipher Suite非サポート
N/A
BEAST攻撃
多くのブラウザではクライアント側で対応済み
N/A 77.4% (+0.6%)
脆弱
N/A N/A N/A
CRIME攻撃 N/A 7.2% (−0.4%)
脆弱
N/A N/A N/A
ハートブリード N/A 0.3% (−0.1%)
脆弱
N/A N/A N/A
CCS Injection Vulnerability N/A 3.3% (−0.4%)
脆弱かつ悪用可能
15.5% (−1.1%)
脆弱だが悪用不可能
80.1% (+1.3%)
脆弱ではない
1.0% (+0.1%)
未知
TLSへのPOODLE攻撃
SSL 3.0へのPOODLE攻撃は含まない
N/A 10.1%
脆弱かつ悪用可能
N/A 88.4%
脆弱ではない
1.6%
未知

参考文献[編集]

  • 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. ^ draft-ietf-tls-tls13-03
  9. ^ draft-ietf-tls-tls13-latest
  10. ^ a b c d e f g draft-chudov-cryptopro-cptls-04 - GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)
  11. ^ RFC 5288
  12. ^ RFC 6655
  13. ^ RFC 6367
  14. ^ RFC 5932およびRFC 6367
  15. ^ a b RFC 6209
  16. ^ RFC 4162
  17. ^ NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised)” (2007年3月8日). 2014年7月3日閲覧。
  18. ^ a b Qualys SSL Labs. “SSL/TLS Deployment Best Practices”. 2013年11月19日閲覧。
  19. ^ draft-agl-tls-chacha20poly1305-04およびdraft-mavrogiannopoulos-chacha-tls-03
  20. ^ draft-mavrogiannopoulos-chacha-tls-03
  21. ^ draft-agl-tls-chacha20poly1305-04およびdraft-mavrogiannopoulos-chacha-tls-03
  22. ^ a b c 2014年12月7日現在 SSL Pulse: Survey of the SSL Implementation of the Most Popular Web Sites”. 2014年12月13日閲覧。
  23. ^ a b ivanr. “RC4 in TLS is Broken: Now What?”. Qualsys Security Labs. 2013年7月30日閲覧。
  24. ^ a b c d Bodo Möller, Thai Duong and Krzysztof Kotowicz. “This POODLE Bites: Exploiting The SSL 3.0 Fallback”. 2014年10月15日閲覧。
  25. ^ a b 緑色のバーの表示について”. シマンテック. 2014年7月29日閲覧。
  26. ^ a b SHA-256 Compatibility”. 2014年7月29日閲覧。
  27. ^ Google (2012年5月29日). “Dev Channel Update”. 2014年7月2日閲覧。
  28. ^ Google (2012年8月21日). “Stable Channel Update”. 2014年7月2日閲覧。
  29. ^ Chromium Project (2013年5月30日). “Chromium TLS 1.2 Implementation”. 2014年7月2日閲覧。
  30. ^ SVN revision log on Chrome 10.0.648.127 release”. 2014年7月2日閲覧。
  31. ^ a b ImperialViolet - CRIME” (2012年9月22日). 2014年10月18日閲覧。
  32. ^ a b SSL/TLS Overview” (2008年8月6日). 2014年7月2日閲覧。
  33. ^ a b c Chromium Issue 90392” (2008年8月6日). 2014年7月2日閲覧。
  34. ^ a b c Issue 23503030 Merge 219882” (2013年9月3日). 2013年9月19日閲覧。
  35. ^ a b c Issue 278370: Unable to submit client certificates over TLS 1.2 from Windows” (2013年8月23日). 2013年10月3日閲覧。
  36. ^ Möller, Bodo (2014年10月14日). “This POODLE bites: exploiting the SSL 3.0 fallback”. Google Online Security blog. Google (via Blogspot). 2014年10月29日閲覧。
  37. ^ a b c An update on SSLv3 in Chrome.”. Security-dev. Google (2014年10月31日). 2014年11月4日閲覧。
  38. ^ Stable Channel Update”. Mozilla Developer Network. Google (2014年2月20日). 2014年11月14日閲覧。
  39. ^ Changelog for Chrome 33.0.1750.117”. Google. Google. 2014年11月14日閲覧。
  40. ^ Issue 318442: Update to NSS 3.15.3 and NSPR 4.10.2”. 2014年11月14日閲覧。
  41. ^ a b c d Security in Firefox 2” (2008年8月6日). 2014年7月2日閲覧。
  42. ^ a b Introduction to SSL”. MDN. 2014年7月2日閲覧。
  43. ^ a b NSS 3.15.3 Release Notes”. Mozilla Developer Network. Mozilla. 2014年7月13日閲覧。
  44. ^ a b MFSA 2013-103: Network Security Services (NSS) の様々な脆弱性”. Mozilla Japan. Mozilla Japan. 2014年7月13日閲覧。
  45. ^ Bug 565047 – (RFC4346) Implement TLS 1.1 (RFC 4346)”. 2014年7月2日閲覧。
  46. ^ SSL Version Control :: Add-ons for Firefox
  47. ^ Bug 480514 – Implement support for TLS 1.2 (RFC 5246)”. 2014年7月2日閲覧。
  48. ^ Bug 733647 – Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default”. 2014年7月2日閲覧。
  49. ^ a b Firefox Notes – Desktop” (2014年2月4日). 2014年7月2日閲覧。
  50. ^ Bug 861266 – Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default”. 2014年7月2日閲覧。
  51. ^ a b c The POODLE Attack and the End of SSL 3.0”. Mozilla blog. Mozilla (2014年10月14日). 2014年10月29日閲覧。
  52. ^ a b Bug 1076983 - (POODLE) Padding oracle attack on SSL 3.0”. bugzilla.mozilla.org. 2014年10月29日閲覧。
  53. ^ Bug 1083058 - A pref to control TLS version fallback”. bugzilla.mozilla.org. 2014年11月6日閲覧。
  54. ^ Bug 1036737 - Add support for draft-ietf-tls-downgrade-scsv to Gecko/Firefox”. bugzilla.mozilla.org. 2014年10月29日閲覧。
  55. ^ Bug 1088915 - Stop offering RC4 in the first handshakes”. bugzilla.mozilla.org. 2014年11月4日閲覧。
  56. ^ Microsoft (2012年9月5日). “Secure Channel”. 2012年10月18日閲覧。
  57. ^ Microsoft (2009年2月27日). “MS-TLSP Appendix A”. 2014年7月2日閲覧。
  58. ^ a b What browsers only support SSLv2?”. 2014年7月2日閲覧。
  59. ^ a b c d SHA2 and Windows - Windows PKI blog - Site Home - TechNet Blogs” (2010年9月30日). 2014年7月29日閲覧。
  60. ^ a b c d HTTPS Security Improvements in Internet Explorer 7”. 2014年7月2日閲覧。
  61. ^ http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512(v=vs.85).aspx
  62. ^ http://support.microsoft.com/kb/948963
  63. ^ a b Windows 7 adds support for TLSv1.1 and TLSv1.2 - IEInternals - Site Home - MSDN Blogs”. 2014年7月2日閲覧。
  64. ^ a b Thomlinson, Matt (2014年11月11日). “Hundreds of Millions of Microsoft Customers Now Benefit from Best-in-Class Encryption”. Microsoft Security. 2014年11月14日閲覧。
  65. ^ Microsoft security advisory: Update for disabling RC4
  66. ^ a b Microsoft (2013年9月24日). “IE11 Changes”. 2014年7月2日閲覧。
  67. ^ a b Release Notes: Important Issues in Windows 8.1 Preview”. Microsoft (2013年6月24日). 2014年11月4日閲覧。
  68. ^ a b W8.1(IE11) vs RC4 | Qualys Community”. 2014年11月4日閲覧。
  69. ^ http://forum.xda-developers.com/windows-phone-8/development/poodle-ssl-vulnerability-secure-windows-t2906203
  70. ^ a b What TLS version is used in Windows Phone 8 for secure HTTP connections?”. Microsoft. 2014年11月7日閲覧。
  71. ^ a b Platform Security”. Microsoft (2014年6月25日). 2014年11月7日閲覧。
  72. ^ Opera 2 series”. 2014年9月20日閲覧。
  73. ^ Opera 3 series”. 2014年9月20日閲覧。
  74. ^ Opera 4 series”. 2014年9月20日閲覧。
  75. ^ Changelog for Opera 5.x for Windows”. 2014年7月2日閲覧。
  76. ^ Changelog for Opera [8] Beta 2 for Windows”. 2014年7月2日閲覧。
  77. ^ Web Specifications Supported in Opera 9”. 2014年7月2日閲覧。
  78. ^ a b Opera: Opera 10 beta for Windows changelog”. 2014年7月2日閲覧。
  79. ^ About Opera 11.60 and new problems with some secure servers” (2011年12月11日). 2012年1月18日時点のオリジナルよりアーカイブ。2014年9月21日閲覧。
  80. ^ a b c Security changes in Opera 25; the poodle attacks” (2014年10月15日). 2014年10月28日閲覧。
  81. ^ Advisory: RC4 encryption protocol is vulnerable to certain brute force attacks” (2013年4月4日). 2014年11月14日閲覧。
  82. ^ On the Precariousness of RC4” (2013年3月20日). 2013年11月12日時点のオリジナルよりアーカイブ。2014年11月17日閲覧。
  83. ^ Dev.Opera — Opera 14 for Android Is Out!” (2013年5月21日). 2014年9月23日閲覧。
  84. ^ Dev.Opera — Introducing Opera 15 for Computers, and a Fast Release Cycle” (2013年7月2日). 2014年9月23日閲覧。
  85. ^ a b Chrome 26–29と同じ
  86. ^ a b Chrome 30以降と同じ
  87. ^ a b Chrome 33以降と同じ
  88. ^ a b Chrome 40以降と同じ
  89. ^ Adrian, Dimcev. “Common browsers/libraries/servers and the associated cipher suites implemented”. TLS Cipher Suites Project. 2014年7月2日閲覧。
  90. ^ Apple Secures Mac OS X with Mavericks Release - eSecurity Planet” (2013年10月25日). 2014年7月2日閲覧。
  91. ^ Ristic, Ivan. “Is BEAST Still a Threat?”. qualys.com. 2014年7月2日閲覧。
  92. ^ a b Ivan Ristić (2013年10月31日). “Apple enabled BEAST mitigations in OS X 10.9 Mavericks”. 2014年7月2日閲覧。
  93. ^ Ivan Ristić (2014年2月26日). “Apple finally releases patch for BEAST”. 2014年7月2日閲覧。
  94. ^ http://support.apple.com/kb/HT6531
  95. ^ http://support.apple.com/kb/HT6541
  96. ^ a b About the security content of OS X Mavericks v10.9”. 2014年7月2日閲覧。
  97. ^ a b c Apple (2011年10月14日). “Technical Note TN2287 – iOS 5 and TLS 1.2 Interoperability Issues”. 2014年7月2日閲覧。
  98. ^ Liebowitz, Matt (2011年10月13日). “Apple issues huge software security patches”. NBCNews.com. 2014年7月2日閲覧。
  99. ^ MWR Info Security (2012年4月16日). “Adventures with iOS UIWebviews”. 2014年7月2日閲覧。, "HTTPS (SSL/TLS)"セクション
  100. ^ Secure Transport Reference”. 2014年7月2日閲覧。 iOSにおいてkSSLProtocol2は"deprecated"とされている
  101. ^ iPhone 3.0: Mobile Safari Gets Enhanced Security Certificate Visualization | The iPhone Blog” (2009年3月31日). 2009年4月3日時点のオリジナルよりアーカイブ。2014年9月21日閲覧。
  102. ^ schurtertom (2013年10月11日). “SOAP Request fails randomly on one Server but works on an other on iOS7”. 2014年7月2日閲覧。
  103. ^ Version 1.11.6, 2013-12-29 — Botan” (2013年12月29日). 2014年12月14日閲覧。
  104. ^ MatrixSSL - News”. 2014年11月9日閲覧。
  105. ^ NSS 3.14 release notes”. Mozilla Developer Network. Mozilla. 2014年7月2日閲覧。
  106. ^ NSS 3.15.1 release notes”. Mozilla Developer Network. Mozilla. 2014年7月2日閲覧。
  107. ^ a b c d www.openssl.org/news/changelog.html
  108. ^ LibreSSL 2.1.1 released” (2014年10月16日). 2014年10月18日閲覧。
  109. ^ TLS cipher suites in Microsoft Windows XP and 2003
  110. ^ SChannel Cipher Suites in Microsoft Windows Vista
  111. ^ a b c TLS Cipher Suites in SChannel for Windows 7, 2008R2, 8, 2012
  112. ^ Technical Note TN2287: iOS 5 and TLS 1.2 Interoperability Issues”. iOS Developer Library. Apple Inc.. 2014年7月2日閲覧。
  113. ^ 高木 浩光 (2007年11月17日). “オレオレ証明書の区分 第三版”. 高木浩光@自宅の日記. 2010年1月3日閲覧。
  114. ^ 「安全なウェブサイトの作り方 改訂第3版」を公開”. 独立行政法人 情報処理推進機構 (2008年6月11日). 2010年1月3日閲覧。
  115. ^ Ian Goldberg; David Wagner (1996年1月1日). “Randomness and the Netscape Browser” (英語). Dr. Dobb's. 2010年1月3日閲覧。
  116. ^ OpenSSL パッケージの脆弱性とその影響について (SSH鍵、SSL証明書等)”. Debian JP Project (2008年5月15日). 2010年1月3日閲覧。
  117. ^ Debian generated SSH-Keys working exploit”. SecurityFocus (2008年5月15日). 2010年1月3日閲覧。
  118. ^ Debian GNU/Linux に含まれる OpenSSL/OpenSSH の脆弱性に関する注意喚起”. JPCERT/CC (2008年5月19日). 2010年1月3日閲覧。
  119. ^ Ray, Marsh; Steve Dispensa (2009年11月4日). “Renegotiating TLS (PDF)” (英語). 2010年2月13日閲覧。
  120. ^ JVNVU#120541 SSL および TLS プロトコルに脆弱性”. Japan Vulnerability Notes. JPCERT/CC and IPA (2009年11月13日). 2010年2月13日閲覧。
  121. ^ A. Langley; N. Modadugu, B. Moeller (2012年6月). “Transport Layer Security (TLS) False Start”. Internet Engineering Task Force. IETF. 2014年6月24日閲覧。
  122. ^ Wolfgang, Gruener. “False Start: Google Proposes Faster Web, Chrome Supports It Already”. 2010年10月7日時点のオリジナルよりアーカイブ。2014年6月24日閲覧。
  123. ^ Brian, Smith. “Limited rollback attacks in False Start and Snap Start”. 2014年6月24日閲覧。
  124. ^ Adrian, Dimcev. “False Start”. Random SSL/TLS 101. 2014年6月24日閲覧。
  125. ^ 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. 
  126. ^ Thai Duong and Juliano Rizzo (2011年5月13日). “Here Come The ⊕ Ninjas”. 2014年6月24日閲覧。
  127. ^ Dan Goodin (2011年9月19日). “Hackers break SSL encryption used by millions of sites”. 2014年6月24日閲覧。
  128. ^ Y Combinator comments on the issue” (2011年9月20日). 2014年6月24日閲覧。
  129. ^ Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures” (2004年5月20日). 2012年6月30日時点のオリジナルよりアーカイブ。2014年6月24日閲覧。
  130. ^ Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)” (2012年1月10日). 2014年6月24日閲覧。
  131. ^ Dan Goodin (2012年9月13日). “Crack in Internet's foundation of trust allows HTTPS session hijacking”. Ars Technica. 2014年6月24日閲覧。
  132. ^ Dennis Fisher (2012年9月13日). “CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions”. ThreatPost. 2014年6月24日閲覧。[リンク切れ]
  133. ^ 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日閲覧。
  134. ^ Leyden, John (2013年8月2日). “Step into the BREACH: New attack developed to read encrypted web data”. The Register. 2014年6月24日閲覧。
  135. ^ Google、SSL 3.0の脆弱性「POODLE」を公表、SSL 3.0は今後サポート廃止の意向 -INTERNET Watch” (2014年10月15日). 2014年10月16日閲覧。
  136. ^ a b c d Bodo Möller (2014年10月14日). “This POODLE bites: exploiting the SSL 3.0 fallback”. 2014年10月15日閲覧。
  137. ^ Bodo Moeller and Adam Langley (2014年7月4日). “draft-ietf-tls-downgrade-scsv-00 - TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks”. 2014年10月15日閲覧。
  138. ^ Molland, Håvard (2014年10月15日). “Security changes in Opera 25; the poodle attacks”. Opera. 2014年10月18日閲覧。
  139. ^ The POODLE Attack and the End of SSL 3.0” (2014年10月14日). 2014年10月15日閲覧。
  140. ^ SSL 3.0 の脆弱性により、情報漏えいが起こる” (2014年10月15日). 2014年10月15日閲覧。
  141. ^ Security Advisory 3009008 revised”. Microsoft TechNet. Microsoft (2014年10月29日). 2014年10月30日閲覧。
  142. ^ http://support.apple.com/kb/HT6531
  143. ^ http://support.apple.com/kb/HT6541
  144. ^ NSS 3.17.1 release notes”. Mozilla (2014年10月3日). 2014年10月20日閲覧。
  145. ^ NSS 3.16.2.3 release notes”. Mozilla (2014年10月27日). 2014年10月27日閲覧。
  146. ^ Disable SSL 3 by default in NSS in April 2015.”. mozilla.dev.tech.crypto (2014年10月27日). 2014年10月27日閲覧。
  147. ^ OpenSSL Security Advisory [15 Oct 2014]”. OpenSSL (2014年10月15日). 2014年10月20日閲覧。
  148. ^ LibreSSL 2.1.1 released.”. LibreSSL (2014年10月16日). 2014年10月20日閲覧。
  149. ^ Langley, Adam (2014年12月8日). “The POODLE bites again”. 2014年12月10日閲覧。
  150. ^ Ristic, Ivan (2014年12月8日). “Poodle Bites TLS”. 201-12-10閲覧。
  151. ^ Stosh, Brandon (2014年12月8日). “Nasty POODLE Variant Bypasses TLS Crypto Affecting Over 10 Percent of the Web”. 2014年12月10日閲覧。
  152. ^ security – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune – Server Fault
  153. ^ 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. 
  154. ^ Green, Matthew. “Attack of the week: RC4 is kind of broken in TLS”. Cryptography Engineering. 2014年6月24日閲覧。
  155. ^ 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日閲覧。
  156. ^ 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日閲覧。. 
  157. ^ 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" 
  158. ^ John Leyden (2013年9月6日). “That earth-shattering NSA crypto-cracking: Have spooks smashed RC4?”. The Register. 2013年12月13日閲覧。
  159. ^ Security Advisory 2868725: Recommendation to disable RC4”. Microsoft (2013年11月12日). 2013年12月13日閲覧。
  160. ^ マイクロソフト セキュリティ アドバイザリ (2868725) RC4 を無効化するための更新プログラム”. Microsoft (2013年11月13日). 2013年12月13日閲覧。
  161. ^ draft-popov-tls-prohibiting-rc4-02
  162. ^ 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日閲覧。
  163. ^ 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)".
  • RFC 7366: "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)".

TLSを含むカプセル化

日本の認証局ベンダー[編集]