web-dev-qa-db-ja.com

クライアントのHelloメッセージは、setEnabledCipherSuites（）メソッドで指定されたリストにない暗号スイートを示唆しています

私のコードでは、有効な暗号スイートのリストを指定するためにJSSE6 APIを使用しています。私は168ビット以上の暗号化暗号スイートのみを許可することを目指しました、以下は私のコードの一部です：

/** List of 168 bits encryption or higher cipher suites */
private static final String[] ENABLED_CIPHER_SUITES_168 = {
    "TLS_RSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_DHE_DSS_WITH_AES_256_CBC_SHA",
    "SSL_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA",
    "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
    "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA",
    "TLS_EMPTY_RENEGOTIATION_INFO_SCSV",
    "TLS_KRB5_WITH_3DES_EDE_CBC_SHA",
    "TLS_KRB5_WITH_3DES_EDE_CBC_MD5",
    "SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA",
    "NETSCAPE_RSA_FIPS_WITH_3DES_EDE_CBC_SHA",
    "SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA",
    };
// return a list of cipher suites which match both array
String[] list = matchStringArrays(ENABLED_CIPHER_SUITES_168, ((SSLSocket)socket).getSupportedCipherSuites());
// Set a list of enabled cipher suites
((SSLSocket)socket).setEnabledCipherSuites(list);

しかし、SSLスキャナーツールを使用してアプリをテストすると、私のサーバーでは96ビットの暗号化スイートが許可されていると言われますか？

次に、Wiresharkを使用してSSLハンドシェイクプロセスのパケットをキャプチャします。ClientHelloメッセージに、有効な暗号スイートのリストにない暗号スイートがあることがわかりました。暗号スイートは

ssl2_des_192_ede3_cbc_with_md5

この暗号スイートはクライアントのhelloメッセージにどのように表示されますか？

encryptiontlsjavawireshark
4
ducnh

SunJSSEプロバイダー はSSLv2をサポートしていません。ただし、doesは、SSLv2形式でのSSL/TLSハンドシェイクの最初のClientHelloメッセージの送信をサポートしています。

SSLv2形式でClientHelloメッセージを送信するクライアントは、クライアントが実際にSSLv2を使用する準備ができている場合に役立ちます。ただし、SunJSSEはSSLv2をサポートしていないため、弱い理由でClientHelloをSSLv2形式で送信します。これは、SSLv3を知っているが、SSLv2でClientHelloを期待する古いバグのあるレガシーサーバーをサポートするためです。フォーマットし、「通常の」SSLv3-format ClientHello（このようなサーバーはが存在するため SSLクライアントはすぐにClientHelloをSSLv2形式で送信する習慣がついたので、SSLv3 ClientHelloの受信は実際にはテストされていませんでした）。

これは、SunJSSEが何をするかについていくつかの光を放ちます。SSLv2を送信しますClientHello実際にはSSLv2を実行せず、そのメッセージ形式を予期する古いサーバーに接続して、SSLv3の使用を続行できるようにするだけです。 SSLv2 ClientHelloには、暗号スイートのリストに、SSLv2暗号スイートのコードも含まれます-クライアントが行うコードではありませんSSLv2を認識しないため、実際にサポートされます。したがって、これらの暗号スイートは無害です。クライアントはそれらを使用する意図がなく、実際にそれらの使用方法を知りません。 ClientHelloメッセージをより「SSLv2風」にするためだけに含まれています。クライアントは、サーバーがSSLv3 ServerHelloで応答することを強く期待します。SSLv2暗号スイートは無視されます。

その「SSLv2 ClientHello形式」のサポートを無効にすることは、次の理由により、依然として良い考えです。

  • Sun/OracleのJDKはSSLにSunJSSEを使用していますが、別のJava実装には完全なSSLv2サポートが含まれている可能性があり（IBMの実装はそれを行うと言われています）、誤って完全なバージョンを使用したくない場合SSLv2。いくつかの点で弱いため。

  • SSLv2を完全に無効にする strong Push があります。サーバーはSSLv2 ClientHelloメッセージ形式のサポートを中止する場合があります。 SSLv2を必要とする古いバグのあるサーバーである可能性がありますClientHello;しかし、SSLv2をサポートしていない新しいバグのないサーバーもありますClientHello;後者は時間の経過とともにますます普及します。

  • サポートされている場合でも、その形式にはSSL拡張機能を含めることはできません。 サーバー名表示 、SSLv2 ClientHello形式の使用には制限がある場合があります。

最近では、SSLv3を無効にしてTLS 1.0以上を強制することについても多くの議論が行われているため、SSLv2にしがみつくと、時代遅れに見えます。

2
Tom Leek