20181106追記
RFC7568として「Deprecating Secure Sockets Layer Version 3.0」標準化されています。
現在はTLS1.0, TLS1.1の廃止が検討されています
TLS WGでは「Deprecating Secure Sockets Layer Version 3.0(draft-ietf-tls-sslv3-diediedie-00
)」というI-DがWG Last Callになっています。
これは、SSLv3の使用を禁止するI-Dになります。
ざっと以下の様な事が書かれています。禁止されるという事実よりも、SSLv3で使用される暗号アルゴリズム・ハッシュアルゴリズムがすでに脆弱である話や、TLSでは脆弱性に対してSSLv3ではそもそも定義されていないextensionの仕組みを用いていて修正しているためそのまま適用できないという話が興味深かったです。
Introduction
SSL version 3はもはや安全ではありません。この文書はSSLv3が使われないことを要求します。
代替バージョンであるTLS 1.2はより安全で有用なプロトコルです。
SSLv3が1996年に公開されてからサポートしている暗号スキームと鍵交換の仕組みは長い間攻撃の対象となっています。
1999年にTLS1.0、2002年にTLS1.1、そして2006年にTLS1.2によって置き換えられたにも関わらず、これらの代替バージョンの可用性は例外なく当てはまるわけではありませんでした。
その結果、多くのTLS実装はSSLv3のネゴシエーションを許可しています。
SSLv3の前身のSSLv2はもはや安全でなく、SSLv3もそれに続くことになります。
Do Not Use SSL Version 3.0
SSLv3 は使用されてはいけません(MUST NOT)。どのバージョンのTLSからもSSLv3のネゴシエーションは許可されません(MUST NOT)。
どのバージョンのTLSもSSLv3よりも安全で、より高いバージョンの方が好ましいです。
具体的に、クライアントはClientHelloでClientHello.client_versionに{03,00}をセットし送信してはいけません(MUST NOT)。同様に、サーバもServerHelloでServerHello.server_versionに{03,00}をセットし送信してはいけません(MUST NOT)。
Helloメッセージにおいてprotocol versionに{03,00}がセットされていた場合、 "protocol_version"アラートメッセージを応答し、コネクションを閉じなければなりません。(MUST)
A Litany of Attacks
Record Layer
SSLv3のCBCモードで使用される非決定論的なパディングが自明に平文の回復を可能にします[POODLE]。より一般的に、SSLv3のCBCモードは欠陥のあるMAC-then-encrypt構成を使用しています。
それは、その後のTLSで置き換えられています。不幸ながら、この欠陥を修正するためのメカニズムはextention機能に依存しています。そのためTLS1.0で追加された機能は同じようにはSSLv3に適応できません。
このSSLv3にて定義されるストリーム暗号にも脆弱性があります。これらの定義は、現在ではRC4のみが広く使用されています。しかしながら、RC4はもはや使用するに値しません。
これによりSSLv3は、適切なレコード保護機構を持たないということです。
Key Exchange
SSLv3の鍵交換は、renegotiation [Ray09]やsession resumption [TRIPLE-HS]を行った際に中間者攻撃に対して脆弱です。
これらの欠陥はTLSでextensionsを用いることで修正されいます。
繰り返しになりますが、SSLv3はこれらの欠陥を正しく直すことは出来ません。
Limited Capabilities
SSLv3は最近のTLSバージョンに追加された多くの機能を使用できません。これらにはSSLv3ではサポートされていないClientHello extentionsによって有効化される機能も含まれています。
- AEADモード [RFC5246]
- ECDHやECDSA [RFC4492]
- Stateless session tickets [RFC5077]
- データグラムモードの操作、DTLS [RFC6347]
- ALPN [RFC7301]