要約

  • 一部のクライアントは失敗のたびに古いTLS版で接続し直した。経路上の攻撃者は新しい版の試行を妨げるだけで、クライアント自身にSSL 3.0を提示させられた。
  • POODLEによるWeb上の秘密回収には、SSL 3.0 CBCに加えて能動的な中間者、秘密を含む反復要求、レコード改変が必要だった。原論文の期待値は1バイト当たり256要求である。
  • TLS_FALLBACK_SCSVは暗号方式ではない。低い版のClientHelloが再試行だと示し、より高い版を使えるサーバーにローカルな拒否判断を与えた。

TLSには本来、版交渉がある。TLS 1.2を提示したクライアントに対し、TLS 1.0までしか扱えないサーバーは共通する最高版を応答できる。その合意はハンドシェイクで保護される。

別に作られたのが、古いサーバーやミドルボックスへの救済路だった。新しいClientHelloで失敗すると、最大版を下げて再接続する。だが、切断はサーバー能力の認証済み証明ではない。攻撃者が高い版の試行を落とせば、クライアントは自ら階段を下りる。

SSL 3.0に到達した後、CBCの弱点が効く。SSL 3.0のパディングにはMACで完全に検証できない任意バイトが含まれた。原報告のWeb攻撃では、ブラウザにcookie付きHTTPS要求を繰り返させ、対象バイトをブロック末尾に移し、暗号文ブロックを差し替える。サーバーが改変レコードを受理したかどうかがオラクルになる。

条件が合う確率は平均256回に1回で、期待作業量は1バイトにつき256個のSSL 3.0要求とされた。これは固定時間ではない。経路上の位置、要求形状への影響、CBCセッション、反復が必要であり、SSL 3.0対応というだけで秘密が読めるわけではない。

第一の対策はSSL 3.0を無効にすることだった。すぐに切れない互換性が残る間は、本当に古い相手と、攻撃者が作った失敗を区別する必要がある。

RFC 7507の{0x56,0x00}は、その区別だけを担う。cipher_suitesに置かれても選択可能な暗号ではない。クライアントが自分の最高版より低い版で再試行していることを示す。サーバーがそれより高い版を有効にしていれば、inappropriate_fallback(86)で終了する。

この警告は攻撃の証明ではない。通常のネットワーク障害も不適切な再試行を起こし得る。SCSVは正しい版交渉の代替でもなく、両端が対応しなければ保護は成立しない。

その後、OpenSSL 1.0.1j、1.0.0o、0.9.8zcが支援を実装し、RFC 7568はSSL 3.0を禁止した。RFC 8996はTLS 1.0と1.1を廃止し、TLS 1.3のServerHello.Randomセンチネルが役割を引き継いだためRFC 7507を廃止扱いにした。

移行用の制御は、役目を終えたら消せることまで含めて優れている。