SSLv2 ClientHelloサポートを有効にしても安全ですか？
POODLE攻撃を受けて、多くのWebサイトがSSLv3のサポートを中止しました。ただし、2015年5月の時点でまだ比較的一般的に使用されている一部のクライアントは、SSLv2 ClientHelloメッセージを使用してハンドシェイクを開始しています。たとえば、Mac OS X 10.10に同梱されているopenssl 0.9.8、およびJava 6は、少なくともMac OS Xではまだ一般的に使用されています。
Oracle 推奨 JSSEを使用してSSLを終了するサーバーは、SSLv2Hello疑似プロトコルを有効に維持します。これにより、SSLv2 ClientHelloハンドシェイクが可能になり、そのようなクライアントとの下位互換性が確保されます。 （表の行「JSSE APIを使用する開発者-サーバー」を参照してください）。
SSLv2 ClientHelloを使用するクライアントはプロトコルダウングレード攻撃に対して脆弱ですが、クライアントとサーバーの両方がTLS_FALLBACK_SCSVをサポートしていない限り、これは後のハンドシェイクバージョンを使用するクライアントにも当てはまります。また、サーバーがSSLv2およびSSLv3を無効にしている限り、ハンドシェイクはTLSv1より低いプロトコルでは完了できません。また、TLSv1.1以降をサポートするクライアントはおそらくSSLv2 ClientHelloを使用していないのではないかと思われるため、これは合理的な構成のようです。
SSLv2 ClientHelloサポートを有効にしておくことをお勧めできない、見逃した既知の攻撃ベクトルはありますか？
注： Java/JSSEは実際のSSLv2（helloのみ）を実装していないため、無効にする必要はありません。リンク先の記事にあるように、最近のアップデートではデフォルトでSSLv3が無効になっていますが、SSLv3を再度有効にすることができます。しないようにしてみてください。
攻撃： v2Helloからの直接的な攻撃はないと思いますが、機能上の制限があるかもしれません。主に拡張機能の使用を防止します。拡張機能の一部は現在重要または重要です。SNIは仮想ホストなどに必要になる場合があります。優先または使用可能な暗号を正しくネゴシエートするために、ECcurvesおよびおそらくsigalgsが必要になる場合があります。 （Renego_infoは、後続ハンドシェイクで必要ですが、チェックしていませんが、フォーマットをステップアップする必要があります;initialハンドシェイクemptyRI-SCSVで十分であり、とにかくほとんどの場合優先されるようです。）
Clients： OpenSSL 0.9.8commandlines_clientのデフォルトはv2helloですが、-no_ssl2以上の特定の-ssl3または-tls1修正します。 OpenSSLを使用するアプリは、特定のプロトコルを選択するか、（現在は誤った名前の）「v23」メソッドを使用して、明示的である可能性のある範囲をサポートする必要があります。ただし、1.0.0以降では、「v23」はSSLv2プロトコルを自動的に選択解除しますand暗号リストにSSLv2暗号が含まれておらず、デフォルトの暗号リストに含まれていない場合は、v2hello形式。アプリでJava6クライアントv2helloを無効にすることができます（そのようにハードコードされている場合、そのように構成可能である場合）、またはソースがあり、それを変更できる場合、または少なくともその関連部分が多数ある場合、Javaアプリケーションは、ほとんどがライブラリと接着剤です。