Почему SSL handshake выдает исключение "Не удалось сгенерировать DH keypair"?
Когда я устанавливаю SSL-соединение с некоторыми IRC-серверами (но не с другими - предположительно, из-за предпочтительного метода шифрования сервера) Я получаю следующее исключение:
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 неправильно настроен, но я поискал и не нашел никаких других ссылок на людей, у которых возникли проблемы с SSL-портами esper, и к нему подключается 'openssl' (см. Ниже). Итак, мне интересно, является ли это ограничением поддержки SSL Java по умолчанию или что-то в этом роде. Есть предложения?
Вот что происходит, когда я подключаюсь к aperture.esper.net 6697 с помощью 'openssl' из командной строки:
~ $ 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/emailAddress=support@esper.net
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/emailAddress=support@esper.net
verify return:1
---
Certificate chain
0 s:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
i:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
---
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/emailAddress=support@esper.net
issuer=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net
---
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).
В отчете об ошибке, на который я ссылался, упоминается обходной путь с использованием JCE-реализации BouncyCastle. Надеюсь, у вас это должно сработать.
Обновить
Об этом сообщалось как об ошибке JDK-7044060 и недавно исправлено.
Обратите внимание, однако, что ограничение было увеличено только до 2048 бит. Для размеров > 2048 бит есть JDK-8072452 - Удалить максимальный простой размер ключей DH; исправление, похоже, для 9.
Ответ 2
Ответ "Java Cryptography Extension (JCE) Unlimited Strength Juridity Policy Files" у меня не сработал, но предложение JCE-провайдера BouncyCastle сработало.
Вот шаги, которые я предпринял, используя Java 1.6.0_65-b14-462 на Mac OSC 10.7.5
1) Загрузите эти банки:
2) переместите эти банки в $JAVA_HOME /lib / ext
3) отредактируйте $JAVA_HOME/lib/security/java.security следующим образом: security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
перезапустите приложение с помощью JRE и попробуйте
Ответ 3
Вот мое решение (java 1.6), также было бы интересно, почему я должен был это сделать:
Я заметил из javax.security.debug = ssl, что иногда используемый набор шифров является TLS_DHE_ ... а иногда это TLS_ECDHE_ .... Более позднее произошло бы, если бы я добавил BouncyCastle. Если был выбран параметр TLS_ECDHE_, большую часть времени это работало, но не ВСЕГДА, поэтому добавление даже поставщика BouncyCastle было ненадежным (завершалось с той же ошибкой через раз или около того). Я предполагаю, что где-то в реализации Sun SSL иногда выбирается DHE, иногда - ECDHE.
Итак, опубликованное здесь решение основано на полном удалении шифров TLS_DHE_. ПРИМЕЧАНИЕ: BouncyCastle НЕ требуется для решения.
Итак, создайте файл сертификации сервера с помощью:
echo |openssl s_client -connect example.org:443 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
Сохраните это, поскольку на него будут ссылаться позже, чем вот решение для SSL http get, исключая наборы шифров TLS_DHE_.
package org.example.security;
import java.io.BufferedInputStream;
import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.InetAddress;
import java.net.Socket;
import java.net.URL;
import java.net.UnknownHostException;
import java.security.KeyStore;
import java.security.cert.Certificate;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.util.ArrayList;
import java.util.List;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLParameters;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.TrustManagerFactory;
import org.apache.log4j.Logger;
public class SSLExcludeCipherConnectionHelper {
private Logger logger = Logger.getLogger(SSLExcludeCipherConnectionHelper.class);
private String[] exludedCipherSuites = {"_DHE_","_DH_"};
private String trustCert = null;
private TrustManagerFactory tmf;
public void setExludedCipherSuites(String[] exludedCipherSuites) {
this.exludedCipherSuites = exludedCipherSuites;
}
public SSLExcludeCipherConnectionHelper(String trustCert) {
super();
this.trustCert = trustCert;
//Security.addProvider(new BouncyCastleProvider());
try {
this.initTrustManager();
} catch (Exception ex) {
ex.printStackTrace();
}
}
private void initTrustManager() throws Exception {
CertificateFactory cf = CertificateFactory.getInstance("X.509");
InputStream caInput = new BufferedInputStream(new FileInputStream(trustCert));
Certificate ca = null;
try {
ca = cf.generateCertificate(caInput);
logger.debug("ca=" + ((X509Certificate) ca).getSubjectDN());
} finally {
caInput.close();
}
// Create a KeyStore containing our trusted CAs
KeyStore keyStore = KeyStore.getInstance("jks");
keyStore.load(null, null);
keyStore.setCertificateEntry("ca", ca);
// Create a TrustManager that trusts the CAs in our KeyStore
String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
tmf.init(keyStore);
}
public String get(URL url) throws Exception {
// Create an SSLContext that uses our TrustManager
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, tmf.getTrustManagers(), null);
SSLParameters params = context.getSupportedSSLParameters();
List<String> enabledCiphers = new ArrayList<String>();
for (String cipher : params.getCipherSuites()) {
boolean exclude = false;
if (exludedCipherSuites != null) {
for (int i=0; i<exludedCipherSuites.length && !exclude; i++) {
exclude = cipher.indexOf(exludedCipherSuites[i]) >= 0;
}
}
if (!exclude) {
enabledCiphers.add(cipher);
}
}
String[] cArray = new String[enabledCiphers.size()];
enabledCiphers.toArray(cArray);
// Tell the URLConnection to use a SocketFactory from our SSLContext
HttpsURLConnection urlConnection =
(HttpsURLConnection)url.openConnection();
SSLSocketFactory sf = context.getSocketFactory();
sf = new DOSSLSocketFactory(sf, cArray);
urlConnection.setSSLSocketFactory(sf);
BufferedReader in = new BufferedReader(new InputStreamReader(urlConnection.getInputStream()));
String inputLine;
StringBuffer buffer = new StringBuffer();
while ((inputLine = in.readLine()) != null)
buffer.append(inputLine);
in.close();
return buffer.toString();
}
private class DOSSLSocketFactory extends javax.net.ssl.SSLSocketFactory {
private SSLSocketFactory sf = null;
private String[] enabledCiphers = null;
private DOSSLSocketFactory(SSLSocketFactory sf, String[] enabledCiphers) {
super();
this.sf = sf;
this.enabledCiphers = enabledCiphers;
}
private Socket getSocketWithEnabledCiphers(Socket socket) {
if (enabledCiphers != null && socket != null && socket instanceof SSLSocket)
((SSLSocket)socket).setEnabledCipherSuites(enabledCiphers);
return socket;
}
@Override
public Socket createSocket(Socket s, String host, int port,
boolean autoClose) throws IOException {
return getSocketWithEnabledCiphers(sf.createSocket(s, host, port, autoClose));
}
@Override
public String[] getDefaultCipherSuites() {
return sf.getDefaultCipherSuites();
}
@Override
public String[] getSupportedCipherSuites() {
if (enabledCiphers == null)
return sf.getSupportedCipherSuites();
else
return enabledCiphers;
}
@Override
public Socket createSocket(String host, int port) throws IOException,
UnknownHostException {
return getSocketWithEnabledCiphers(sf.createSocket(host, port));
}
@Override
public Socket createSocket(InetAddress address, int port)
throws IOException {
return getSocketWithEnabledCiphers(sf.createSocket(address, port));
}
@Override
public Socket createSocket(String host, int port, InetAddress localAddress,
int localPort) throws IOException, UnknownHostException {
return getSocketWithEnabledCiphers(sf.createSocket(host, port, localAddress, localPort));
}
@Override
public Socket createSocket(InetAddress address, int port,
InetAddress localaddress, int localport) throws IOException {
return getSocketWithEnabledCiphers(sf.createSocket(address, port, localaddress, localport));
}
}
}
Наконец, вот как это используется (certFilePath, если путь к сертификату сохранен из openssl):
try {
URL url = new URL("https://www.example.org?q=somedata");
SSLExcludeCipherConnectionHelper sslExclHelper = new SSLExcludeCipherConnectionHelper(certFilePath);
logger.debug(
sslExclHelper.get(url)
);
} catch (Exception ex) {
ex.printStackTrace();
}
Ответ 4
Приведенный выше ответ правильный, но с точки зрения обходного пути у меня возникли проблемы с реализацией BouncyCastle, когда я установил ее в качестве предпочтительного поставщика:
java.lang.ArrayIndexOutOfBoundsException: 64
at com.sun.crypto.provider.TlsPrfGenerator.expand(DashoA13*..)
Это также обсуждается в одной теме форума, которую я нашел, в которой не упоминается решение.
http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems
Я нашел альтернативное решение, которое работает в моем случае, хотя я им совсем не доволен. Решение состоит в том, чтобы настроить его так, чтобы алгоритм Диффи-Хеллмана был недоступен вообще. Тогда, предположив, что сервер поддерживает альтернативный алгоритм, он будет выбирать во время обычного согласования. Очевидно, недостатком этого является то, что если кому-то каким-то образом удастся найти сервер, который поддерживает только Diffie-Hellman на уровне 1024 бит или меньше, то это фактически означает, что он не будет работать там, где работал раньше.
Вот код, который работает с SSLSocket (перед его подключением):
List<String> limited = new LinkedList<String>();
for(String suite : ((SSLSocket)s).getEnabledCipherSuites())
{
if(!suite.contains("_DHE_"))
{
limited.add(suite);
}
}
((SSLSocket)s).setEnabledCipherSuites(limited.toArray(
new String[limited.size()]));
Неприятно.