SSL 2.0を要求しないようにすべてのデバイスを構成し、提供されている場合は拒否する必要がありますか？
中間者攻撃を削減するために、クライアント側とサーバー側のSSL 2.0接続を拒否するのはいつ（またはそれが）業界で認められた慣行になるのでしょうか。
プロキシでこれを構成して、背後にある一連のホストを保護できますか？ （更新： この質問への回答はこちら または下にスクロール）
質問の最後の部分について：いいえ、プロキシはクライアントステーションの束をSSLv2の問題から通常保護できません。 SSL/TLS では、ほとんどの場合、次のようになります。
- クライアントは
ClientHelloメッセージを送信します。このメッセージには、受け入れる最大プロトコルバージョン番号が記載されています（したがって、TLS 1.0は「SSL 3.1」としてアナウンスされます）。 - サーバーは、実際に使用されるプロトコルバージョンを指定する
ServerHelloメッセージで応答します。 - クライアントとサーバーは他のいくつかのメッセージを交換しますが、その中には高額な暗号が含まれているため、「共有シークレット」が作成され、データを暗号化および復号化するためのキーとして使用されます。
- ハンドシェイクの最後に、実際のアプリケーションデータを送受信する直前に、ハッシュで計算されたデータを含む2つの
Finishedメッセージが送信されます（1つはクライアント、もう1つはサーバー）。以前に交換されたメッセージ。サーバー（またはクライアント）は、クライアント（またはサーバー）からFinishedメッセージを受信すると、予想されるハッシュを再計算します。不一致の場合、接続を閉じます。
次に、プロキシがあるとどうなるか見てみましょう。 HTTPプロキシは、HTTP要求と応答を処理することになっています。 SSLは要求/応答プロトコルではありません。双方向トンネルを期待して提供します。したがって、特別な何かがHTTPで設計されました（ RFC 2817 、セクション5で指定）：クライアントは、CONNECT注文をプロキシに送信し、後続のすべてのデータバイトを両方向に転送するように指示します。
したがって、HTTPプロキシが存在する場合でも、暗号化はクライアントとサーバー間で発生します。プロキシはハンドシェイクメッセージを参照しますが、（それが重要なポイントです）変更することはできません変更できませんこれは、Finishedメッセージのハッシュ計算を混乱させるためです：クライアントとサーバーはまったく同じハンドシェイクメッセージを表示しませんでした。それらは異なるハッシュを計算し、Finishedメッセージと不一致があります。特に、クライアントがSSLv2をサポートしていることを示すClientHelloを送信した場合（つまり、SSLv2形式を使用するClientHelloでありながら、「3.1までサポートします」と書き込んでいる場合）、プロキシはそれを変更できません。
注：SSLv2プロトコルでは、ハンドシェイクにFinishedメッセージがありません。そのため、双方向を傍受できる攻撃者（プロキシはその理想的な位置にあります）は、SSLv2形式のClientHelloをハイジャックして、「サポートされる最大バージョン」を3.1から2.0に変更できます。これにより、SSLv3をサポートするクライアントとサーバーの両方がSSLv3 +をサポートしている場合でも、SSLv2を使用するように強制できます。これは「バージョンロールバック攻撃」と呼ばれます。 TLS 1.0仕様 には、その攻撃をブロックする回避策が含まれています（セクションE.2）。
上記は「普通に」書いた。場合によっては、プロキシが /で実行できるファンキーなことがある。つまり、プロキシは真の man-in-the-middle-way で接続を「攻撃」します。これには、プロキシがその場で偽のサーバー証明書を組み込み、アドホックCAを埋め込む必要があります。対応するルート証明書がクライアントにインストールされている必要があります（つまり、ISPプロキシがそれを強制することはできません）。
このようなハイジャックプロキシが存在します。このトリックは、交換されたコンテンツにアグレッシブフィルタリングテクニックを適用するために使用されます（SSLセキュリティの基盤をわずかに壊すことに依存しているため、これもやや眉をひそめています）。ハイジャックプロキシは、理論的にはクライアントでSSLv2を実行し、目的のサーバーでSSLv3 +を実行して、実質的に「複数のクライアントをSSLv2から保護する」ことができます。
実際には、SSLv2を認識してSSLv3を認識しないソフトウェアは非常にまれです。 Webブラウザーの場合、これにより90年代半ばに戻ります。したがって、一般的に言えば、SSLv2をすべての構成から完全に禁止できます。
業界で認められている慣行について：
（from http://www.rapid7.com/vulndb/lookup/sslv2-and-up-enabled ）
「SSLv2は非推奨になり、推奨されなくなりました。SSLv2もSSLv3も、連邦情報システムで使用するための暗号化モジュールを管理するUS FIPS 140-2標準に適合していません。新しいTLSのみに注意してください。 （トランスポート層セキュリティ）プロトコルはFIPS 140-2要件を満たしています。さらに、ホスト上のSSLv2のみのサービスの存在はによって失敗と見なされますPCI（Payment Card Industry）データセキュリティ標準この脆弱性は、TLSまたはSSLv3もサポートされているかどうかに関係なく、リモートサーバーがSSLv2をサポートしている場合に報告されます。
下位互換性は、廃止することを要求すべきものの1つです。すべての企業のすべてのCISO/CSOは、SSL 2.0やWEPなどをサポートしている場合、製品ベンダーに火事で死ぬように指示する必要があります。
SSL 2.0にはセキュリティ上の欠点があります。私は間違いなくすべてのSSL 2.0接続を拒否することをお勧めします。引用： http://www.cs.berkeley.edu/~daw/papers/ssl3.0.ps （セクション2）
これを実現するのは私たち（セキュリティ専門家）の責任だと思います。たとえば、
IT監査を実施する場合、SSL v2が存在するときに監査委員会がREDを確認するようにする必要があります。
Web開発者と協力している場合、少なくともSSL v3、または理想的にはTLSを使用しない限り、ソフトウェアが受け入れられないことを明確にする必要があります。
プロジェクトを管理している場合、SSL v2を使用するソフトウェアを販売しようとするプロバイダーを失敗させる必要があります。
私たちは、SSL v2を使用すると害を及ぼすことをバイヤー/開発者/プロジェクトマネージャー/ CEOに教える必要がありますが、ビジネス言語で行う必要があります。 PCI DSSは、カードサービスプロバイダーに改善を強制できるため、この点で非常に役立ちます。他の組織を説得するための例としてうまく利用できると期待しています。
恐らく。これがUbuntuディストリビューションが2年前に始めたものであり、現在完成しつつあります。いくつかの問題を参照してください： https://wiki.ubuntu.com/MigrateOffSSL2 とメーリングリストで最近の議論を参照してください： https://lists.ubuntu.com/archives/ ubuntu-devel/2010-July/031010.html