Transport Layer Security

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

TLSは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。
既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとしてSTARTTLSが広まっているため、この方式自体をSTARTTLSと呼ぶこともある。
前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、平文で接続を開始する実装と共存できなくなるため、既存のポート番号とは別にTLS対応用のポート番号が必要となる。実態としては、SSL/TLSの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。ただし、この方式はバーチャルホストを構成する際に問題となる可能性がある。詳細は#バーチャルホストの節を参照。
なお、ポート番号を分ける方式をSSL、同一ポート番号で切替える方式（STARTTLS方式）をTLSと呼んでいる実装もある。TLS/SSLという用語の区別がプロトコルのバージョンを指しているか、アプリケーション層プロトコルへの適用方式を指しているかは、文脈で判断する必要がある。

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

TLSを導入さえすればセキュリティが確保できるという認識は誤っている。TLS通信は、平文での通信に比べて（主に暗号化・復号時）余分な計算機能力を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、TLSが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。
特にWorld Wide Webでは、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信でSSL/TLSが使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに南京錠のアイコンを表示したり、アドレスバーの色を変化させたりして、利用者に情報を提供している。
また実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため、TLSを使用していても、システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある。このような場合もダイアログメッセージなどを使って利用者に警告すべきである。

乱数の品質

他の多くの近代暗号と同様に、TLSもまた、暗号としての強度は乱数の品質に依存している。桁数（ビット長）の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている。（これは、公開鍵暗号システムにも言える）もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、総当たり攻撃で解読される可能性が上昇する。通常は、これは実装の問題に起因している。
古い例では、Netscapeの初期の実装における乱数生成の脆弱性がある。プロセスIDや時刻から乱数を生成していることが判明し、これらの情報を取得できる場合には総当たり攻撃の所要時間が大幅に短くなるという問題があった。
2008年5月15日にはDebianが脆弱性に関する報告を発表した。OpenSSLライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536 (= 2¹⁶) 通りの予測可能な物が生成されてしまった事を明らかにした（なお、この問題は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の勧告等に従うべきである。

プロトコル概要

本説では2016年現在の最新版であるTLS 1.2の概要を説明する。
TLSには主なプロトコルとして暗号通信に必要な鍵 (master secret) を鍵共有してセッションを確立するTLSハンドシェイクプロトコルと、master secretを用いて暗号通信することで確立されたセッションにおけるコネクションをセキュアにするTLSレコードプロトコルがある。
その他に用いている暗号方式やハッシュ関数等のアルゴリズムを変更する Change Cipher Spec プロトコルと通信相手からの通信終了要求や何らかのエラーを通知する アラートプロトコルがある。

第一フェーズ

第一のフェーズではサーバ・クライアント間で通信に必要情報の合意を図る。このフェーズでは、まずクライアントからサーバにClientHelloが送信され、次にサーバからクライアントにServerHelloが送信される。
ClientHelloはTLSのバージョン、乱数、セッションID、通信に用いる暗号方式やハッシュアルゴリズムのリスト (cipher_suites)、通信内容の圧縮方法、および拡張領域の6つからなる。乱数は鍵共有におけるリプレイ攻撃を防ぐためのものである。
ServerHelloもClientHelloと同様の6つからなっている（名称は一部異なる）。ServerHelloの主な目的は、ClientHelloで提示された選択肢の中でサーバにとって好ましいものを選択する事で、例えばClientHelloで提示されたcipher_suitesの中から、サーバが通信に使いたいcipher_suiteを一組選ぶ。乱数はClientHelloとは独立して選ぶ。これもリプレイ攻撃を回避するためである。セッションIDは特に問題がなければClientHelloと同一のものを返す。

第二フェーズ

第二フェーズではサーバからクライアントに対して鍵共有に必要な情報を送る。具体的にはサーバはCertificate、ServerKeyExchange、CertificateRequest、ServerHelloDoneを（第一フェーズServerHelloに引き続き）クライアントに送信する。
Certificateは鍵共有で用いる公開鍵とその証明書で別途取り決めがない限りX.509v3のフォーマットに従う。なお鍵共有方式としてDH_anonを用いている場合にはcertificateは必要ない。
ServerKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、gˣ mod pという形のデータを送る。ここでxはサーバの秘密の乱数である。鍵共有プロトコルがDHE_DSS、DHE_RSA、DH_anonでは何らかのserver_key_exchangeを送るが、RSA、DH_DSS、DH_RSAでは何も送らない。
CertificateRequestはクライアントの公開鍵とその証明書を送ることを要求するためのもので、サーバが許容できる証明書の種別、ハッシュと署名方式、および認証局のリストからなっている。
そして最後にサーバ側からのメッセージ送信が終わった事を示すServerHelloDoneをクライアントに送る。

第三フェーズ

第三フェーズではクライアントからサーバに対して鍵共有に必要な情報を送る。具体的にはクライアントはCertificate、ClientKeyExchange、CertificateVerifyをサーバに送る。
Certificateは鍵共有で用いるクライアントの公開鍵とその証明書である。証明書はサーバから送られてきたCertificateRequestの条件を満たさねばならない。
ClientKeyExchangeは鍵共有プロトコルに依存して送るデータが異なるが、DH_anonであれば、gʸ mod pという形のデータを送る。ここでyはクライアントの秘密の乱数である。
ここまでのプロトコルにより、サーバとクライアントの間でpremaster secretが共有された事になる。DH_anonであればpremaster secretはgˣʸ mod pである。premaster secretを鍵にした擬似ランダム関数にServerHelloとClientHelloの乱数などを並べたものを入力した結果得られたものがmaster secretである。
CertificateVerifyはクライアントが署名能力を持っている事を証明するためにこれまでTLSハンドシェイクプロトコルで送受信された全メッセージに対し、共有されたmaster secret で署名したものである。

第四フェーズ

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

TLSレコードプロトコル

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を用いる。

SSL 1.0

ネットスケープコミュニケーションズ社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな脆弱性が発見され、破棄された。このため、2018年現在ではSSL 1.0を実装した製品はない。

SSL 2.0

ネットスケープコミュニケーションズ社はSSL 1.0の問題を修正して再設計し、1994年にSSL 2.0として発表した。また、同社のウェブブラウザであるNetscape Navigator 1.1においてSSL 2.0を実装した。
その後、SSL 2.0にもいくつかの脆弱性が発見され、SSL 3.0において修正された。SSL 2.0の脆弱性のひとつは、ネゴシエーションの情報を改竄すると、提示する選択肢のうち最弱のアルゴリズムを使わせることができ（ダウングレード攻撃）、改竄を受けたことを検出できないというものである。さらに悪いことに、この脆弱性を利用すると、双方がSSL 3.0をサポートしていてもSSL 2.0で接続させることさえ可能になる。
SSL 3.0ではSSL 2.0との互換性を提供するにあたり、乱数領域を使った細工を加えることで、このような攻撃を検出する仕組みを組み込んだ。しかしこの細工が無効にされているサーバ環境も存在し、クライアントから見るとSSL 2.0を無効にしない限りこの脆弱性の影響を受ける可能性を否定できない。SSL 3.0以降に対応した実装が十分に普及したものとして、Internet Explorer 7やMozilla Firefox 2、Opera 9などは、初期状態でSSL 2.0を無効にしている。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっている。
SSL 2.0にはチェーン証明書がなく、ルートCAから発行したSSLサーバ証明書しか使うことができない。
2011年3月、RFC 6176 によってSSL 2.0の使用は禁止された。

SSL 3.0

ネットスケープコミュニケーションズ社はSSL 2.0の問題を修正するとともに機能追加を行い、1995年にSSL 3.0を発表した。また、Netscape Navigator 2.0においてSSL 3.0を実装した。SSL 3.0の仕様書については、2011年にIETFから歴史的文書という扱いでRFC 6101として公開された。
2014年10月にSSL 3.0の仕様上の脆弱性（POODLE攻撃）が発見されたため、SSL 3.0への対応を打ち切り、TLS 1.0以降のみ対応への移行が望まれている。2015年6月、RFC 7568によってSSL 3.0の使用は禁止された。
SSLについては、使うべきではない。

TLS 1.0

IETFのTLSワーキンググループはRFC 2246としてTLS 1.0を公表した。TLS 1.0の標準化作業は1996年に開始され、年内に完了する予定だったが、いくつかの問題に阻まれ、公表は1999年まで遅延した。
TLS 1.0が提供する機能はSSL 3.0とあまり変わらないが、アルゴリズムやルートCAの自己署名証明書の取扱いなどの仕様の詳細が変更されたことに加え、これまであまり実装されていなかった選択肢のいくつかが必須と定められた。このため、TLS 1.0を実装した製品が普及するまでには、さらに数年を要した。
なおTLS 1.0はSSL 3.0より新しい規格であることを示すため、ネゴシエーションにおけるバージョン番号は3.1となっている。

TLS 1.1

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

TLS 1.2

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

TLS 1.3

新たなTLSのバージョンとしてTLS 1.3が提案されてきたが、IETFは2018年3月23日に、ドラフト28を標準規格として承認した。
TLS 1.2からの変更点としては、データ圧縮の非サポート、forward secrecyではないcipher suite（RSAのみを用いたもの）および認証付き暗号ではないcipher suite（CBCモードのブロック暗号やRC4を用いたもの）の廃止が挙げられる。なお名称をTLS 2.0やTLS 4等に変更することが検討されたが、最終的にTLS 1.3に落ち着いた。

バーチャルホスト

TLSは、TCP/IPネットワークでホスト名ベースのバーチャルホストを構成する際に問題となる。TCP/IPでは通信を開始する前にホスト名を解決し、実際にはIPアドレスとポート番号で接続先を識別している。このためTLSのネゴシエーションの時点では、バーチャルホストのうちどのホスト名を期待しているのか判断できず、ホスト名ごとに異なるサーバー証明書を使い分けることができない。
TLSの拡張機能を定義するRFC 6066では、ネゴシエーション時にホスト名を伝える手段としてServer Name Indication (SNI) を規定している。用例としては、HTTPの最新バージョンであるHTTP/2においてTLSを利用する際はSNIの利用が必須とされている。
一方、証明書を使い分けず、1つの証明書を複数のバーチャルホストで使い回す方式も広く利用されている。X.509証明書のフォーマットについて記述したRFC5280では、発行先ホスト名を保持するsubjectAltNameはひとつの証明書に複数のエントリを作成できると規定している。これを利用して、ホストに収容されたすべてのバーチャルホストに対応したsubjectAltNameを保持する証明書をクライアントに提示すれば良い。
また、発行先ホスト名にワイルドカードを使う方法も考えられる。HTTP over SSL/TLS (HTTPS) を定義するRFC 2818は、ワイルドカードの適用について記述している。バーチャルホストの対象が、ひとつのドメイン名の中のホストであれば、この方法で対応できる場合もある。
どの方法も実装によって対応状況にバラつきがあり、環境によっては使えない可能性がある。なおIPアドレスベースのバーチャルホストであれば、ネゴシエーションの時点で確実にどのバーチャルホストを期待しているか判断できるので、問題なく証明書を使い分けることができる。

TLS/SSLの既知の脆弱性

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

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

TLS 1.2ではすでに危殆化したRC4、MD5、SHA1が選択可能であり、この事が脆弱性の原因となっている。
MD5はすでに衝突が容易に見つかるレベルまで危殆化しているため、これを利用したSLOTH攻撃 (CVE-2015-7575) が知られている。
SHA1もFreestart Collisionが見つかっており安全ではない。

RC4

RC4もTLSのすべてのバージョンにおいて利用を禁止するRFC 7465が公開された。MozillaおよびマイクロソフトではRC4を無効化することを推奨している。
RC4そのものに対する攻撃法は多く報告されているが、TLS/SSLにおいてRC4を用いたCipher Suiteについては、その脆弱性に対処されており安全であると考えられていた。2011年には、ブロック暗号のCBCモードの取り扱いに関する脆弱性であったBEAST攻撃への対応策の一つとして、ストリーム暗号であるためその影響を受けないRC4に切り替えることが推奨されていた。しかし、2013年にTLS/SSLでのRC4への効果的な攻撃が報告され、BEASTへの対応としてRC4を用いることは好ましくないとされた。RC4に対する攻撃は、AlFardan、Bernstein、Paterson、Poettering、Schuldtによって報告された。新たに発見されたRC4の鍵テーブルにおける統計的な偏りを利用し、平文の一部を回復可能であるというものである。この攻撃では、13 × 2²⁰の暗号文を用いることで128ビットのRC4が解読可能であることが示され、2013年のUSENIXセキュリティシンポジウムにおいて「実現可能」と評された。2013年現在では、NSAのような機関であればTLS/SSLを利用したとしてもRC4を解読可能であるとの疑惑がある。
2015年現在ではクライアントのほとんどは既にBEASTへの対処が完了していることから、RC4はもはや最良の選択肢ではなくなっており、TLS 1.0以前においてもCBCモードを用いることがより良い選択肢となっている。

FREAK および Logjam

かつてアメリカ合衆国からの暗号の輸出規制が厳しかった時期に、規制を回避するために一時的に512ビットのRSA鍵を生成して、そちらで通信を行うというような手法が存在した。この手法については、一時的な公開鍵を素因数分解することが可能であれば中間者攻撃が成立することが1998年時点で指摘されていたが、コンピュータの性能向上、クラウドコンピューティングの普及により素因数分解が個人レベルですら現実的となったこと、さらに2015年には、OpenSSL、Safari、Androidなどでは輸出用でない暗号スイートでも512ビットの一時鍵を受け入れてしまう実装となっていたことが判明し、FREAK (Factoring RSA Export Keys)として問題が再浮上している。
対策としては、すでに脆弱となっている輸出対応暗号の無効化、クライアント側では規格書通り、輸出暗号以外で一時的RSA鍵を使わないようにする、ということが挙げられる。
2015年5月、Logjamと呼ばれる脆弱性が発見された。これも、FREAKと同様に輸出用の512ビットの一時鍵を受け入れてしまうものである。FREAKとは異なり、LogjamはTLSプロトコル自体の脆弱性である。発見時点において、主要なブラウザのすべてがLogjamに対して脆弱である。

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

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

BEAST攻撃

2011年9月23日、暗号研究者のThai DuongとJuliano Rizzoが、BEAST (Browser Exploit Against SSL/TLS) と呼ばれるTLS 1.0におけるブロック暗号のCBCモードの取り扱いに関する脆弱性のコンセプトをJavaアプレットの同一生成元ポリシー違反によって実証した。この脆弱性そのものは2002年にPhillip Rogawayによって発見されていたが、2011年の発表までは実用的なエクスプロイトは報告されていなかった。
2006年に発表されたTLS 1.1においてBEASTへの脆弱性は修正されていたが、2011年の実証までTLS 1.1への対応はクライアント、サーバの双方でほとんど進んでいなかった。
Google ChromeおよびFirefoxはBEASTによる影響を直接的に受けることはないが、MozillaはTLS/SSLのためのライブラリであるNetwork Security Services (NSS) に対して、BEASTおよびそれに類似した選択平文攻撃に対するTLS 1.0以前で有効な対応策を2011年に施した。NSSは、Mozilla FirefoxなどのMozillaのソフトウェアだけでなく、Google Chromeなど他のブラウザでも用いられているライブラリである。NSSでのTLS 1.1以降への対応は2012年までずれこみ、FirefoxでTLS 1.1以降を既定で利用可能となったのは2014年のバージョン27である。
マイクロソフトは2012年1月10日にSecurity Bulletin MS12-006を発表し、Windowsで用いられているライブラリであるSChannelに対して修正を加えた。Windows 7以降では、TLS 1.1以降が利用可能である。
アップル製品では、macOSではv10.9においてTLS 1.1以降への対応およびTLS 1.0以前におけるBEAST脆弱性への対応がなされているが、v10.8以前では、TLS 1.1以降への対応、TLS 1.0以前におけるBEAST脆弱性への対応のいずれも行われていない。iOSでは、5以降ではTLS 1.1以降が利用可能であるが、TLS 1.0以前におけるBEAST脆弱性への対応は行われていない。iOS 7ではじめてTLS 1.0以前におけるBEAST脆弱性への対応が行われた。

パディング攻撃

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

Lucky Thirteen

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

POODLE攻撃

2014年9月15日、Googleの研究者によって、SSL 3.0の設計に脆弱性が存在することが発表された (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.0のサポートを除去する予定である。2014年11月リリースのバージョン39においてSSL 3.0へのフォールバックを、2015年1月リリースのバージョン40においてSSL 3.0そのものを既定で無効化している。
OperaもGoogle Chromeと同様にTLS_FALLBACK_SCSVを実装済みであるほか、バージョン25において"anti-POODLE record splitting"と呼ばれる異なる対策を実装した。
Mozillaでは2014年12月リリースのMozilla Firefox 34およびESR 31.3からSSL 3.0を無効化したほか、Firefox 35においてTLS_FALLBACK_SCSVをサポートした。
マイクロソフトでは、グループポリシーからSSL 3.0を無効化する方法を公開しているほか、10月29日にWindows Vista、Server 2003およびそれ以降のIEにおいてSSL 3.0を無効化する"Fix it"を公開し、数か月以内にIEおよびマイクロソフトのオンラインサービスにおいてSSL 3.0を既定で無効化する方針を表明した。2015年2月のアップデートにおいて、IE 11の保護モードにおいてSSL 3.0へのフォールバックを既定で無効化した。加えて、2015年4月にIE 11においてSSL 3.0自体を既定で無効化した。
Safari（OS X v10.8以降およびiOS 8.1以降）では、POODLEへの対策としてSSL 3.0においてCBCモードのcipher suiteを無効化した。これによりPOODLEの影響を受けることはなくなるが、SSL 3.0においてCBCモードを無効化したことで、脆弱性が指摘されているRC4しか利用できなくなるという問題が生じている。
サーバ側では、NSSが2014年10月3日にリリースされたバージョン3.17.1および10月27日にリリースされた3.16.2.3でTLS_FALLBACK_SCSVに対応したほか、2015年4月までにSSL 3.0を既定で無効化する予定である。OpenSSLは、10月15日リリースのバージョン1.0.1j、1.0.0、0.9.8zcでTLS_FALLBACK_SCSVに対応した。LibreSSLでは、10月16日リリースのバージョン2.1.1でSSL 3.0を既定で無効化した。
2014年12月8日に、SSL 3.0ではなくTLS 1.0から1.2に対して有効なPOODLE攻撃の変法が報告された。この変法はTLSの仕様においてサーバ側に要求されているパディングのチェックを正しく行わない実装において、SSL 3.0を無効にしていたとしてもPOODLE攻撃が可能となるというものである。すなわち、SSL 3.0に対するものが仕様そのものの脆弱性であるのに対し、TLS 1.0以降に対するものは不適切な実装による脆弱性である。SSL Pulseでは、公開前の時点でHTTPS対応のサーバのうちおよそ10%がこの変法に対して脆弱であるとしている。この変法のCVE IDはCVE-2014-8730である。この変法では、SSL 3.0へダウングレードさせる必要がなくTLS 1.2のままで攻撃が可能であるなど、オリジナルのSSL 3.0に対するPOODLE攻撃よりも実行が容易であるとされる。

圧縮サイドチャネル攻撃

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

CRIME攻撃

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に対する修正は行われなかった。

BREACH攻撃

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

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

2009年11月4日、SSL 3.0以降の再ネゴシエーション機能を利用して、クライアントからのリクエストの先頭に中間者が任意のデータを挿入できるという脆弱性が報告された。プロトコル自体の脆弱性であり、すべての実装が影響を受ける。
この脆弱性への簡単な対策は、サーバにおいて再ネゴシエーションを禁止することである。根本対応としては、TLS Extensionを使った安全な再ネゴシエーション手順がRFC 5746として提案されている。この脆弱性を利用した中間者攻撃では、サーバがRFC 5746に対応しない限りクライアントは再ネゴシエーションが発生したことを検出できないので、クライアント側のみで対応することは不可能である。

切り詰め攻撃

TLSでの切り詰め攻撃では、ユーザがウェブサービスからログアウトすることを妨害し、意図せずログインしたままとすることが可能である。ユーザからログアウト要求が送信されたときに、攻撃者が偽のTCP FINメッセージ（これ以上データを送信しない）を平文で挿入する。このメッセージを受けたサーバでは、ユーザから送られたログアウト要求を受け取らないため、ユーザの意図とは異なりログイン状態が維持される。
2013年の報告では、この攻撃への対応として、GmailやHotmailなどのウェブサービスでは、ログアウトが正常に完了した旨のページを表示するようになった。これにより、ログアウトしたか否かをユーザが確認することが可能となり、攻撃者によってログイン状態のアカウントを悪用される危険性が軽減される。
この攻撃では目標のコンピュータにマルウェアなどを導入する必要はないが、攻撃者が目標とサーバの間の回線に割り込むことが可能であることと、目標のコンピュータに物理的にアクセス可能であることが求められる。

ハートブリード

ハートブリード（英: Heartbleed）は、2014年に発覚したOpenSSLライブラリのバージョン1.0.1から1.0.1fの間で発見された深刻なセキュリティ脆弱性である。この脆弱性を利用することで、TLS/SSLによって保護されているはずの情報を盗むことが可能である。
このバグでは、インターネット上の誰もが、脆弱性のあるOpenSSLを利用しているシステムのメモリにアクセスすることが可能となり、サービスプロバイダの認証やデータの暗号化に用いられている秘密鍵、ユーザのアカウントおよびパスワード、実際にやり取りされたデータなどを取得できる。これにより、メッセンジャーサービス、電子メールの盗聴、データの盗難、なりすましなどが可能となる。