SSL ハンドシェイクで「DH キーペアを生成できませんでした」という例外が発生するのはなぜですか? 質問する

SSL ハンドシェイクで「DH キーペアを生成できませんでした」という例外が発生するのはなぜですか? 質問する

一部の IRC サーバーと SSL 接続すると (他のサーバーとは接続しません - おそらくサーバーの優先暗号化方式による)、次の例外が発生します。

Caused by: java.lang.RuntimeException: Could not generate DH keypair
    at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:106)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:556)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:183)
    at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
    at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
    ... 3 more

最終原因:

Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)
    at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
    at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
    at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:100)
    ... 10 more

この問題が発生するサーバーの例としては、aperture.esper.net:6697 (IRC サーバー) があります。問題が発生しないサーバーの例としては、kornbluth.freenode.net:6697 があります。[当然ですが、各ネットワーク上のすべてのサーバーは、それぞれ同じ動作を共有します。]

私のコード(一部の SSL サーバーに接続するときに機能することに注意してください)は次のとおりです。

    SSLContext sslContext = SSLContext.getInstance("SSL");
    sslContext.init(null, trustAllCerts, new SecureRandom());
    s = (SSLSocket)sslContext.getSocketFactory().createSocket();
    s.connect(new InetSocketAddress(host, port), timeout);
    s.setSoTimeout(0);
    ((SSLSocket)s).startHandshake();

例外をスローするのは、最後の startHandshake です。そして、確かに 'trustAllCerts' では魔法が働いています。このコードは SSL システムに証明書を検証させないように強制します。(つまり、証明書の問題ではありません。)

明らかに、esper のサーバーが誤って設定されている可能性が 1 つありますが、検索しても、esper の SSL ポートで問題が発生しているという他の参考資料は見つかりませんでした。また、'openssl' はそれに接続します (下記参照)。したがって、これは Java のデフォルトの SSL サポートの制限か何かなのではないかと考えています。何か提案はありますか?

コマンドラインから「openssl」を使用して、aperture.esper.net 6697 に接続すると、次のようになります。

~ $ openssl s_client -connect aperture.esper.net:6697
CONNECTED(00000003)
depth=0 /C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
verify return:1
---
Certificate chain
 0 s:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
   i:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
[There was a certificate here, but I deleted it to save space]
-----END CERTIFICATE-----
subject=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
issuer=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
---
No client certificate CA names sent
---
SSL handshake has read 2178 bytes and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 51F1D40A1B044700365D3BD1C61ABC745FB0C347A334E1410946DCB5EFE37AFD
    Session-ID-ctx: 
    Master-Key: DF8194F6A60B073E049C87284856B5561476315145B55E35811028C4D97F77696F676DB019BB6E271E9965F289A99083
    Key-Arg   : None
    Start Time: 1311801833
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---

前述のとおり、その後、接続は成功しました。これは、私の Java アプリでは言えないことです。

関連があるかどうかはわかりませんが、私は OS X 10.6.8、Java バージョン 1.6.0_26 を使用しています。

ベストアンサー1

問題は素数のサイズです。Javaが受け入れる最大許容サイズは1024ビットです。これは既知の問題です(JDK-6521495)。

私がリンクしたバグレポートには、回避策BouncyCastle の JCE 実装を使用します。これでうまくいくはずです。

アップデート

これはバグとして報告されましたJDK-7044060そして最近修正されました。

ただし、制限は2048ビットまでしか引き上げられていないことに注意してください。2048ビットを超えるサイズの場合は、JDK-8072452 - DH キーの最大素数サイズを削除; 修正は 9 に対して行われるようです。

おすすめ記事