プードルはSSLv3で修正できますか、それともTLS圧縮の方法になりますか？
TLS_FALLBACK_SCSVは、SSLv3を有効にしたままにするサーバーの修正になるのでしょうか？ SSLv3を無効にする以外に、どのようなアクションが行われている場合、その脆弱性に対処していますか？
SSLv3プロトコルに欠陥があります。これは修正できません。一般に、攻撃者はこれを悪用して、より高いプロトコルを使用する接続を強制的に失敗させ、SSLv3を使用してサーバーに接続するように被害者を強制します。 TLS_FALLBACK_SCSVは、より高いプロトコルがすでに試行されている場合、ブラウザ/サーバーがSSLv3に完全にフォールバックするのを停止しようとします。
ご覧のように、TLS_FALLBACK_SCSVは実際にはプロトコルの問題を修正しませんが、代わりに攻撃者が被害者にプロトコルのダウングレードを強制することを困難にすることで、攻撃対象を減らしようとします。
TLS_FALLBACK_SCSVは、ブラウザーまたはサーバーのいずれかがSSLv3より高いものをサポートしていない場合は効果がありません（これはまれですが、私は許可しますが、不可能ではありません）。
一部のレコード分割に関する問題の緩和について、いくつかの議論がありました。つまり、Poodleを効率的にするのは、パディングが最大ブロック全体を使用する可能性があることです（3DESまたはRC2では8バイト、AESでは16バイト）。これが発生すると、ブロックの最後のバイトのみが受信者によってチェックされます。これが、攻撃者による変更が確率1/256で通過する理由です。したがって、そのパディング状況が発生しないように調整できる場合は、攻撃者の成功確率を下げることができます。
アイデアは、レコードが暗号化され、ランダムパディングが多すぎて無視されないバイトが少なすぎる最終ブロックにつながる場合、splitデータを2つのレコードに分割します。その個々の長さにより、無視されるパディングバイトが十分に少ない最後のブロックが生成されます。
この「修正」について説明します there （特にコメント13を参照）。攻撃者の成功は1/256から1/281474976710656に低下します。ただし、これは説明したとおり、プードルにのみ適用されます。そして、レコード分割は、標準的な観点からは「合法的」ではありますが、古く、バグが多く、レガシーな実装を破壊する可能性があることが知られています。
TLS_FALLBACK_SCSVはSSL 3.0を修正しません。プロトコルダウングレード攻撃を修正します。これにより、クライアントとサーバーの両方がTLS 1.0+を知っている場合に、SSL 3.0の使用を強制されなくなります。ただし、クライアントまたはサーバーがSSL 3.0しか認識していない場合、通信はSSL 3.0を使用するため、プードル攻撃が適用される可能性があります。これは避けられないことです。サーバーがSSL 3.0しか認識していない場合は、プードルの脆弱性のあるプロトコルを使用するか、まったく通信しないかのどちらかを選択します。
多くの人々が後者を好むだろうと述べています。 TLS_FALLBACK_SCSVまたはいくつかのレコード分割のいずれかでSSL 3.0を許容するのではなく、単に停止させます。ある時点で発生する必要があります。脆弱性によって引き起こされる一般的な懸念は、その良い機会かもしれません。