Java lang runtimeexception keypair generation error

Rutoken и КриптоПро JCP (ошибка java.lang.RuntimeException)

Форум Рутокен → Техническая поддержка пользователей → Rutoken и КриптоПро JCP (ошибка java.lang.RuntimeException)

Сообщений 7

#1 Тема от mariya 2015-06-17 17:21:00

• mariya
• Посетитель
• Неактивен

Rutoken и КриптоПро JCP (ошибка java.lang.RuntimeException)

Всем Доброго времени суток!
возникла проблема: в вэб-сервисе не подписываются запросы с помощью крипто jcp, возникает ошибка:
java.lang.RuntimeException: Не найден закрытый ключ
at isc.jcp.JcpFacade.createSignature(JcpFacade.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.intersys.gateway.JavaGateway.executeInstanceMethod(JavaGateway.java:891)
at com.intersys.gateway.JavaGateway.executeMethod(JavaGateway.java:836)
at com.intersys.gateway.JavaGateway.processMessage(JavaGateway.java:432)
at com.intersys.gateway.JavaGateway.run(JavaGateway.java:421)
at com.intersys.gateway.JavaGateway.run(JavaGateway.java:402)

После выполнения:
store = KeyStore.getInstance(«RutokenStore»);
store.load(null, «пароль»);
получаем:
store!=null

Затем:
aliases = store.aliases();
size = store.size();
получаем:
aliases не содержит элементов,
size = 0

Соответственно в хранилище RutokenStore не видится контейнер.

КриптоПро JCP 1.0 (1.0.54)
Java 1.7.0.17
драйвер рутокена 2.96.00.0530
модуль поддержки рутокена для криптопро jcp 2.06.00.0013

Источник

Could not generate DH keypair (Unlimited Strength Extension doesn’t work)

I’m trying to do simple https GET from a webserver having a selfsigned 2048 certificate, but it fails since stock java doesn’t support > 1024 bits encryption.
I’ve hit this with 1.6.0_07 and 1.6.0_43, and for both versions, I’ve tried downloading:
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html

and replacing the two jar files, but with no detectable change. Is there any (simple) way to verify that I actually did install the two files successfully?
is there something else I need to do?

Upgrading java is not an option in the short run..

The full exception..
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1554)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1537)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1463)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:64)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:147)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:154)
at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:278)
at org.apache.http.impl.AbstractHttpClientConnection.flush(AbstractHttpClientConnection.java:283)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.flush(ManagedClientConnectionImpl.java:175)
at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:260)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:717)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:522)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at tp7summerization.RancidParser.findTP7Aggregates(RancidParser.java:122)
at tp7summerization.RouterThread.run(RouterThread.java:42)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.DHCrypt. (DHCrypt.java:106)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:417)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:145)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
. 17 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. (DHCrypt.java:100)
. 25 more

Answers

Host systems are respectively:
1. OSX, where all 3 occurrences of the files < local_policy.jar, US_export_policy.jar >has been replaced. (plugin version, installed version & Xcode version)
2. FreeBSD, where both occurrences of the files has been replaced. (SUN version & Diablo version).

I also checked that the files have the same attributes/rights set as the original ones.
I hope the date of the two jars should be ignorable.

If you check the link in the original post — is it right for 1.6?

Seems like a dead end to me as it stands..

I must be jinxed somehow:

/usr/local/bin/java -jar /store0/JavaApplication4/JavaApplication4.jar
os.arch : i386
os.name : FreeBSD
os.version : 8.1-RELEASE
Java version : 1.6.0_07

java -jar «/Users/ssch/NetBeansProjects/JavaApplication4/dist/JavaApplication4.jar»
os.arch : x86_64
os.name : Mac OS X
os.version : 10.8.3
Java version : 1.6.0_43

I guess it’d make sense to suspect some other cause then just the amount of bits used in the certificate?
I’m really not that much of a scolar when it comes to certificates — and as mentioned, I think its a self-signed one.
its using: SHA-1 with RSA Encryption
and its issued by RapidSSL.com fwiw.

I’ve tried to expand a bit on your code and print out all the available providers, and the getInfo() of each of them:

Available provider: SUN version 1.6
SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores, JavaPolicy Policy; JavaLoginConfig Configuration)
Available provider: Apple version 1.0
Apple Provider (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC/MD5, HMAC/SHA1)
Available provider: SunRsaSign version 1.5
Sun RSA signature provider
Available provider: SunJSSE version 1.6
Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
Available provider: SunJCE version 1.6
SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)
Available provider: SunJGSS version 1.0
Sun (Kerberos v5, SPNEGO)
Available provider: SunSASL version 1.5
Sun SASL provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5)
Available provider: XMLDSig version 1.0
XMLDSig (DOM XMLSignatureFactory; DOM KeyInfoFactory)
Available provider: SunPCSC version 1.6
Sun PC/SC provider

I’m not sure I understand your response. Do you get an exception on either of the OS?

I note you are using Netbeans. It is very common for people to fail to configure the Netbeans ‘Platform’ correctly so that they pick up the Netbeans JDK rather than the one they desire. If in doubt, follow «Properties->Libraries->Manage Platforms» and add the desired JDK then configure «Properties->Libraries->Java Platform» .

No, there were no exceptions.

I now tried on a third machine (OSX also), running JDK7.
This is the entire screen-dump. Notice that only the local_policy.jar changes size — I’m not sure if it matters that I’m located in Denmark?
The NetBeans project is using the JDK listed below, at least that what the settings for the project says.

Is there really no chance that this is something other then the policies not being installed correct?

Also — I really appreciate all the help I’m getting in here — really awesome how fast responses are coming and how competent they are!! Excellent!

Источник

Error on Debian with Java 8: «Could not generate DH keypair» #2626

I’m trying to use ZAP on Debian with OpenJDK8 (package is openjdk-8-jre , Version 8u91-b14-1

bpo8+1 ). Accessing a website via HTTPS through ZAP with a browser configured properly (CA is installed and configured) leads to the following error (most of the time, see notes below):

These are my notes so far:

• It looks like ZAP is trying to create DH parameters larger than 2048 bit, this will be supported in Java 9, thread on stackoverflow, OpenJDK bugtracker
• Using burpsuite works, with the same version of Java
• It seems Fedora patched OpenJDK to allow larger primes: https://bugzilla.redhat.com/show_bug.cgi?id=1163501
• It looks like the size of the DH parameters is provided by the server: thread on stackoverflow
• Whether this error occurs depends on the Server: It works well with TLS servers with small DH groups, but due to the mitigation for the Logjam attack, everybody generated large, custom DH parameters.
• I’ve tried the latest released version (2.5.0) and the latest nightly version of ZAP, no difference.

Is there anything I can do to help you debug this problem further?

I’d really like to use ZAP, is it maybe possible to configure the SSLContext to only accept ciphers which do not use DH with a Java version that is unable to handle large DH parameters? How do other program work around this limitation?

The text was updated successfully, but these errors were encountered:

Источник

Почему рукопожатие SSL дает исключение «Не удалось создать пару ключей DH»?

Когда я делаю SSL-соединение с некоторыми серверами IRC (но не другими — предположительно из-за предпочтительного метода шифрования сервера), я получаю следующее исключение:

Примером сервера, демонстрирующего эту проблему, является aperture.esper.net:6697 (это IRC-сервер). Примером сервера, который не демонстрирует проблему, является kornbluth.freenode.net:6697. [Неудивительно, что все серверы в каждой сети имеют одинаковое поведение.]

Мой код (который, как указано, работает при подключении к некоторым серверам SSL):

Это тот последний startHandshake, который выдает исключение. И да, с «trustAllCerts» происходит некоторая магия; этот код заставляет систему SSL не проверять сертификаты. (Итак, не проблема с сертификатом.)

Очевидно, что одна из возможностей заключается в неправильной настройке esper-сервера, но я искал и не нашел никаких других ссылок на людей, имеющих проблемы с esper-портами SSL, и к ним подключается «openssl» (см. ниже). Поэтому мне интересно, является ли это ограничение поддержки SSL по умолчанию Java или что-то в этом роде. Любые предложения?

Вот что происходит, когда я подключаюсь к aperture.esper.net 6697, используя ‘openssl’ из командной строки:

Как уже отмечалось, после всего этого он успешно подключается, что больше, чем вы можете сказать для моего приложения Java.

Если это уместно, я использую OS X 10.6.8, версию Java 1.6.0_26.

ОТВЕТЫ

Ответ 1

Проблема заключается в основном размере. Максимально допустимый размер, который принимает Java, составляет 1024 бит. Это известная проблема (см. JDK-6521495).

UPDATE

Об этом сообщается как ошибка JDK-7044060 и исправлена ​​в последнее время.

Обратите внимание, однако, что ограничение было увеличено до 2048 бит. Для размеров > 2048 бит существует JDK-8072452 — удалить максимальный основной размер ключей DH; исправление, по-видимому, относится к 9.

Ответ 2

«Ответы на политику криминализации расширения (JCE)» Неограниченная сила «.» Ответ не помог мне, но предложение провайдера BouncyCastle JCE сделало.

Вот шаги, которые я предпринял с использованием 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_, MOST OF the time it, но не ВСЕГДА, поэтому добавление даже провайдера BouncyCastle было ненадежным (сбой с той же ошибкой, каждый раз или около того). Я предполагаю, что где-то в реализации Sun SSL иногда он выбирает DHE, иногда он выбирает ECDHE.

Итак, решение, размещенное здесь, полностью зависит от полного удаления TLS_DHE_ шифров. ПРИМЕЧАНИЕ. BouncyCastle НЕ требуется для решения.

Итак, создайте файл сертификации сервера:

Сохраните это, как будет указано позже, чем это решение для SSL http get, за исключением наборов шифрования TLS_DHE_.

Наконец, вот как он используется (certFilePath, если путь сертификата сохранен от openssl):

Ответ 4

Ответ выше правильный, но с точки зрения обходного пути у меня были проблемы с реализацией BouncyCastle, когда я задал его как предпочтительный поставщик:

Это также обсуждается в одной теме форума, которую я нашел, которая не упоминает решение. http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems

Я нашел альтернативное решение, которое работает для моего случая, хотя я его совсем не доволен. Решение состоит в том, чтобы установить его таким образом, чтобы алгоритм Диффи-Хелмана не был доступен вообще. Затем, полагая, что сервер поддерживает альтернативный алгоритм, он будет выбирать при нормальных переговорах. Очевидно, что недостатком этого является то, что если кому-то удастся найти сервер, который поддерживает Diffie-Hellman только с 1024 бит или меньше, это на самом деле означает, что он не будет работать там, где он раньше работал.

Вот код, который работает с SSLSocket (перед его подключением):

Ответ 5

Вы можете полностью отключить DHE в своем jdk, отредактировать jre/lib/security/java.security и убедиться, что DHE отключен, например. как

Ответ 6

Динамическую установку поставщика можно установить:

1) Загрузите эти банки:

2) Скопируйте баннеры на WEB-INF/lib (или ваш путь к классам)

3) Динамически добавить поставщика:

Ответ 7

Это довольно старый пост, но если вы используете Apache HTTPD, вы можете ограничить размер DH. См. http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

Ответ 8

Если вы используете jdk1.7.0_04, перейдите на jdk1.7.0_21. Проблема была исправлена ​​в этом обновлении.

Ответ 9

Попробуйте загрузить «Файлы политики неограниченной юрисдикции Java Cryptography Extension (JCE)» с сайта загрузки Java и заменить файлы в своей JRE.

Это сработало для меня, и мне даже не нужно было использовать BouncyCastle — стандартный Sun JCE мог подключаться к серверу.

PS. Я получил ту же ошибку (ArrayIndexOutOfBoundsException: 64), когда пытался использовать BouncyCastle перед изменением файлов политики, поэтому, похоже, наша ситуация очень похожа.

Ответ 10

Если вы по-прежнему укушены этой проблемой и используете Apache httpd v> 2.4.7, попробуйте это: http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

скопировано с URL:

Начиная с версии 2.4.7, mod_ssl будет использовать параметры DH, которые включают простые числа длиной более 1024 бит. Однако в Java 7 и более ранних версиях поддержка простейших размеров DH ограничена максимум 1024 битами.

Если ваш клиент на основе Java прерывает работу с такими исключениями, как java.lang.RuntimeException: не удалось сгенерировать пару ключей DH и java.security.InvalidAlgorithmParameterException: основной размер должен быть кратным 64, и может варьироваться от 512 до 1024 (включительно), и httpd регистрирует внутреннюю ошибку оповещения tlsv1 (номер оповещения SSL 80) (для информации LogLevel или выше), вы можете либо переупорядочить список шифров mod_ssl с помощью SSLCipherSuite (возможно, в сочетании с SSLHonorCipherOrder), либо вы можете использовать пользовательские параметры DH с 1024-битным простым числом, который всегда будет иметь приоритет над любым из встроенных параметров DH.

Для генерации пользовательских параметров DH используйте

команда. В качестве альтернативы вы можете использовать следующие стандартные 1024-битные параметры DH из RFC 2409, раздел 6.2:

Добавьте пользовательские параметры, включая строки «BEGIN DH PARAMETERS» и «END DH PARAMETERS», в конец первого файла сертификата, который вы сконфигурировали с помощью директивы SSLCertificateFile.

Я использую Java 1.6 на стороне клиента, и это решило мою проблему. Я не опустил наборы шифров и т.п., но добавил специально созданный параметр DH в файл сертификата.

Ответ 11

Возможно, у вас неверные зависимости Maven. Вы должны найти эти библиотеки в иерархии зависимостей Maven:

Если у вас есть эти зависимости, это ошибка, и вы должны сделать это:

Исключите эти зависимости из артефакта, который включал неправильные зависимости, в моем случае это:

Ответ 12

У меня такая же проблема с сервером Yandex Maps, JDK 1.6 и Apache HttpClient 4.2.1. Ошибка была

с включенным отлаживанием -Djavax.net.debug=all появилось сообщение в журнале

Я исправил эту проблему, добавив библиотеку BouncyCastle bcprov-jdk16-1.46.jar и зарегистрировав поставщика в классе сервисов карты

Поставщик регистрируется при первом использовании MapService .

Ответ 13

Решена проблема, перейдя на JDK 8.

Ответ 14

Я использую coldfusion 8 на JDK 1.6.45 и имел проблемы с предоставлением мне только красных крестов вместо изображений, а также с cfhttp, неспособным подключиться к локальному веб-серверу с помощью ssl.

мой тест script для воспроизведения с coldfusion 8 был

это дало мне довольно общую ошибку: «Исключение I/O: равноуровень не аутентифицирован». Затем я попытался добавить сертификаты сервера, включая корневые и промежуточные сертификаты, в хранилище ключей java, а также хранилище ключей coldfusion, но ничего не помогло. то я отлаживал проблему с помощью

Тогда у меня возникла идея, что веб-сервер (apache в моем случае) имеет очень современные шифры для ssl и является довольно ограничительным (qualys оценивает a +) и использует сильные ключи diffmann hellmann с более чем 1024 бит. очевидно, coldfusion и java jdk 1.6.45 не могут справиться с этим. Следующий шаг в одизее состоял в том, чтобы подумать об установке альтернативного поставщика безопасности для java, и я решил заняться замком. см. также http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/

Затем я загрузил

из http://www.bouncycastle.org/latest_releases.html и установил его под C:jdk6_45jrelibext или где-либо ваш jdk, в оригинальной установке coldfusion 8 он будет находиться под C:JRun4jrelibext, но я использую новый jdk (1.6.45), расположенный снаружи каталог coldfusion. очень важно поставить bcprov-ext-jdk15on-156.jar в каталог ext (это стоило мне около двух часов и некоторых волос;-) затем я отредактировал файл C:jdk6_45jrelibsecurityjava.security(с помощью wordpad не с editor.exe!) и поместил одну строку для нового провайдера. впоследствии список выглядел как

(см. новый в позиции 1)

затем полностью перезапустите службу холодного охлаждения. вы можете

и наслаждайтесь чувством. и, конечно же,

какая ночь и какой день. Надеюсь, это поможет (частично или полностью) кому-то там. если у вас есть вопросы, просто напишите мне по info. (домен выше).

Ответ 15

Я столкнулся с ошибкой SSL на сервере CentOS, на котором запущен JDK 6.

Мой план состоял в том, чтобы установить более высокую версию JDK (JDK 7), чтобы сосуществовать с JDK 6, но оказалось, что просто установить новый JDK с rpm -i было недостаточно.

Установка JDK 7 будет успешной только с опцией обновления rpm -U , как показано ниже.

1. Загрузить JDK 7

2. Ошибка установки RPM

3. Обновление RPM успешно

4. Подтвердите новую версию

Ответ 16

Если сервер поддерживает шифр, который не включает DH, вы можете заставить клиента выбрать этот шифр и избежать ошибки DH. Например:

Имейте в виду, что указание точного шифрования подвержено поломке в конечном итоге.

Ответ 17

Мы получили ту же самую исключенную ошибку исключения, чтобы исправить это было легко после нескольких часов работы в Интернете.

Мы загрузили самую высокую версию jdk, которую мы могли найти на oracle.com, установили ее и указали на сервер приложений Jboss в каталог установленного нового jdk.

Перезапущенный Jboss, обработанный, проблема исправлена ​​.

Ответ 18

У меня есть эта ошибка с Bamboo 5.7 + Gradle project + Apache. Gradle попытался получить некоторые зависимости от одного из наших серверов через SSL.

Решение:

Добавить в файл сертификата (для Apache — SSLCertificateFile param)

Попробуйте снова создать проект

Ответ 19

Я использовал для получения аналогичной ошибки доступ к svn.apache.org с java-клиентами SVN с использованием IBM JDK. В настоящее время пользователи svn.apache.org используют настройки шифрования клиентов.

После запуска только один раз с захватом пакетов /javax.net.debug = ALL, я смог занести в черный список только один шифр DHE, и все работает для меня (ECDHE обсуждается вместо этого).

Хорошее быстрое исправление, когда нелегко изменить клиента.

Ответ 20

Недавно у меня возникла та же проблема, и после обновления версии jdk с 1.6.0_45 до jdk1.7.0_191, которая разрешила проблему.

Ответ 21

Ошибка является ограничением Java. Настройте провайдера JCE:

Источник

Here is my solution (java 1.6), also would be interested why I had to do this:

I noticed from the javax.security.debug=ssl, that sometimes the used cipher suite is TLS_DHE_… and sometime it is TLS_ECDHE_…. The later would happen if I added BouncyCastle. If TLS_ECDHE_ was selected, MOST OF the time it worked, but not ALWAYS, so adding even BouncyCastle provider was unreliable (failed with same error, every other time or so). I guess somewhere in the Sun SSL implementation sometimes it choose DHE, sometimes it choose ECDHE.

So the solution posted here relies on removing TLS_DHE_ ciphers completely. NOTE: BouncyCastle is NOT required for the solution.

So create the server certification file by:

echo |openssl s_client -connect example.org:443 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Save this as it will be referenced later, than here is the solution for an SSL http get, excluding the TLS_DHE_ cipher suites.

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));
        }

    }
}

Finally here is how it is used (certFilePath if the path of the certificate saved from 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();
        }

Home
>
Java
>
Detail page

Posted by bel5f5
in Java
at May 19, 2017 — 9:12 AM
Tag:
SSL

Hi,

I’m trying to use ZAP on Debian with OpenJDK8 (package is openjdk-8-jre, Version 8u91-b14-1~bpo8+1). Accessing a website via HTTPS through ZAP with a browser configured properly (CA is installed and configured) leads to the following error (most of the time, see notes below):

ZAP Error [javax.net.ssl.SSLException]: java.lang.RuntimeException: Could not generate DH keypair

Stack Trace:
java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120)
at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:674)
at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:128)
 [wrapped] java.lang.RuntimeException: Could not generate DH keypair
at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:142)
at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:114)
at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:708)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:268)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
 [wrapped] javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1906)
at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1889)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1410)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at org.parosproxy.paros.network.SSLConnector.createSocket(Unknown Source)
at org.apache.commons.httpclient.HttpConnection.open(Unknown Source)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(Unknown Source)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(Unknown Source)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.parosproxy.paros.network.HttpSender.executeMethod(Unknown Source)
at org.parosproxy.paros.network.HttpSender.runMethod(Unknown Source)
at org.parosproxy.paros.network.HttpSender.send(Unknown Source)
at org.parosproxy.paros.network.HttpSender.sendAuthenticated(Unknown Source)
at org.parosproxy.paros.network.HttpSender.sendAndReceive(Unknown Source)
at org.parosproxy.paros.network.HttpSender.sendAndReceive(Unknown Source)
at org.parosproxy.paros.core.proxy.ProxyThread.processHttp(Unknown Source)
at org.parosproxy.paros.core.proxy.ProxyThread.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)

These are my notes so far:

• It looks like ZAP is trying to create DH parameters larger than 2048 bit, this will be supported in Java 9, thread on stackoverflow, OpenJDK bugtracker
• Using burpsuite works, with the same version of Java
• It seems Fedora patched OpenJDK to allow larger primes: https://bugzilla.redhat.com/show_bug.cgi?id=1163501
• It looks like the size of the DH parameters is provided by the server: thread on stackoverflow
• Whether this error occurs depends on the Server: It works well with TLS servers with small DH groups, but due to the mitigation for the Logjam attack, everybody generated large, custom DH parameters.
• I’ve tried the latest released version (2.5.0) and the latest nightly version of ZAP, no difference.

Is there anything I can do to help you debug this problem further?

I’d really like to use ZAP, is it maybe possible to configure the SSLContext to only accept ciphers which do not use DH with a Java version that is unable to handle large DH parameters? How do other program work around this limitation?