Transport Layer Security
2006年にRFC 4346としてTLS 1.1が制定された。TLS 1.0からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。特にCBC攻撃に対する耐性を上げるため、初期化ベクトルを明示的に指定することにし、さらにパディングの処理も改善された。また、予期せぬ回線クローズ後に、セッションを再開できるようになった。共通鍵暗号アルゴリズムとしてAESが選択肢に加わった。
2021年3月、RFC 8996によりTLS 1.1を使用しないことが呼びかけられている。
ネゴシエーションにおけるバージョン番号は3.2となっている。
TLS/SSLに対する攻撃のうち主なものを以下に挙げる。2015年2月に、TLS/SSLに対する既知の攻撃についての情報をまとめたRFC 7457がIETFから公開されている。
TLSハンドシェイクプロトコルは4つのフェーズに大別できる。
2015年2月、TLSのすべてのバージョンにおいてRC4の利用を禁止する RFC 7465 が公開された。ストリーム暗号であるChaCha20と認証のためのPoly1305を組み合わせたChaCha20+Poly1305が RFC 7905 として標準化されている。
いくつかの国家標準に基づく暗号化アルゴリズムもTLSで利用可能であり、日本のCRYPTRECによる推奨暗号であるCamellia(CBCモード:RFC 4132、RFC 5932、RFC 6367、GCM:RFC 6367)、韓国の情報通信標準規格に採用されているSEED(CBCモード:RFC 4162)、ARIA(CBCモードおよびGCM:RFC 6209)が追加されている。また、独立国家共同体のGOST規格によって規定された暗号化アルゴリズムであるGOST 28147-89も提案されている。
SSLが設計された当時は、アメリカ合衆国によって高強度暗号アルゴリズムの輸出が規制されていた。そのため、全世界で共通して利用できるアルゴリズムとして、DES・RC2・RC4に関して暗号強度を40ビットに制限したものが導入されていた。これらはTLS 1.1以降では利用が禁止されている。
また、鍵共有のみを行い暗号化は行わないこと (NULL) も可能であるが、平文でのやりとりとなることから安全とはみなされていない。
2012年にBEAST攻撃の報告者によって、TLSにおいてデータ圧縮が有効な場合において、本来第三者に対して秘密であるべきCookieの内容が回復可能となるCRIME(Compression Ratio Info-leak Made Easy, 英語版)が報告された。ウェブサイトでのユーザ認証に使われているCookieの内容を回復されることで、セッションハイジャックが可能となる。2012年9月にはMozilla FirefoxおよびGoogle ChromeにおいてCRIMEへの対応が実施された。また、マイクロソフトによればInternet ExplorerはCRIMEの影響を受けない。
CRIMEの報告者によって、CRIMEがTLS以外にもデータ圧縮を利用するSPDYやHTTPといったプロトコルにも広く適用可能であることが示されていたにもかかわらず、クライアント、サーバのいずれにおいてもTLSやSPDYに対する修正しか行われず、HTTPに対する修正は行われなかった。
2014年9月15日、Googleの研究者によって、SSL 3.0の設計に脆弱性が存在することが発表された (CVE-2014-3566)。これは、SSL 3.0においてブロック暗号をCBCモードで使用した際にパディング攻撃が可能となるものであり、POODLE (Padding Oracle On Downgraded Legacy Encryption) と名付けられた。平均してわずか256回のリクエストで暗号文の1バイトの解読が可能となる。CVE IDはCVE-2014-3566である。
この脆弱性はSSL 3.0の仕様のみに存在するものでありTLS 1.0以降に影響はないが、主要なすべてのブラウザではTLSでのハンドシェイクが失敗した場合にSSL 3.0での接続にダウングレードする。そのため、攻撃者はバージョンロールバック攻撃によってSSL 3.0での接続を行わせることでこの脆弱性を利用可能となる。
POODLE攻撃への根本的な対処法は、少なくともクライアント、サーバのどちらかでSSL 3.0を無効化することである。しかし、古いクライアント、サーバなどではTLS 1.0以降に対応していないため、互換性を考慮してSSL 3.0を無効化できない場合がある。そこで、POODLEの発見者は、TLS_FALLBACK_SCSVの実装を推奨している。この実装によりTLSからSSL 3.0へのフォールバックが抑止されるが、これはクライアント側だけでなくサーバ側の対応も必要である。
Google ChromeブラウザやGoogleサービスのサーバは既にTLS_FALLBACK_SCSVに対応しており、加えて数か月以内にこれらクライアント、サーバからSSL 3.
1: IE 1–2, Windows NT 3.5: IE 1–3, Windows NT 3.51および4.0: IE 1–6
1 2 3 4 5 6 7 Windows XPおよび Server 2003以前のSChannelは3DESやRC4といった弱いアルゴリズムのみに対応。これはIEだけではなく、Microsoft Officeなど、これらのOS上で動作する他のMicrosoft製品でも利用される。Server 2003のみ、KB 948963によってAESに対応する。
1 2 3 4 5 MS13-095あるいはMS14-049 (Server 2003およびXP 64ビット版)、SP3(XP 32ビット版)
1 2 3 サーバがRC4以外のアルゴリズムを用いたCipher Suiteに対応していない場合に限り、RC4を用いたCipher Suiteがフォールバックとして利用されるようレジストリから変更することも可能。
1 2 3 4 「保護モード」においてSSL 3.0へのフォールバックを既定で無効化。2015年4月にSSL 3.0そのものを無効化。
1 2 レンダリングエンジンであるEdgeHTMLはInternet Explorer 11までのレンダリングエンジンであるTridentからフォークされた
↑ Windows 10 LTSB 2015 (LongTermSupportBranch) を除く
1 2 3 レジストリより設定可能 (サードパーティによるツールが必要)
↑ Presto版では、Opera 10でTLS 1.2に対応(既定では無効)。
1 2 2014年10月15日以降、SSL 3.0の既定での無効化をリモートで実施。
脆弱性のあるバージョンの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の勧告等に従うべきである。
TLSレコードプロトコルはアプリケーション層から受け取った通信内容を2バイト以下のブロックに分解 (fragmentation) し、各ブロックを圧縮 (compress) し、圧縮されたブロックを認証暗号で暗号化するレコード Payload 防護を施した上で、通信内容を通信相手に送信する。
認証暗号は、TLS 1.1まではMACをつけた後で共通鍵暗号化するMAC-then-Encrypt (MtE) のみが利用可能であった。TLS 1.2からは、AES-GCMのようなAEADに分類される認証暗号専用の暗号利用モードも利用可能になり、TLS 1.3ではAEADのみが利用可能となっている。
認証暗号にブロック暗号(AEAD以外)を選択した場合、TLS 1.1以降においてIVはTLSレコードプロトコルの送信者がランダムに選ぶ。ランダムなIVは、BEAST攻撃への対策として有効である。一方、認証暗号で用いる共通鍵はTLSハンドシェイクプロトコルで共有されたmaster secretを用いる。