Как генерировать новые, 2048-разрядные параметры Diffie-Hellman с Java keytool?

Мы - неспециалисты, пробующие - неудачно до сих пор - для обновления нашего веб-сервера (JBoss-5.1.0. GA) настройки для соответствования стандартам Diffie-Hellman. После запущения теста на https://weakdh.org/sysadmin.html нам говорят, что мы должны "генерировать новые, 2048-разрядные параметры Diffie-Hellman". В прошлом мы генерировали ключи с Java keytool, но мы не могли найти любую информацию о генерации нового, 2048-разрядного параметра Diffie-Hellman с Java keytool. Кто-либо знает, как сделать это или мог указать на нас в правильном направлении?Спасибо!

9
задан 14 September 2015 в 16:51
3 ответа

С помощью keytool этого сделать нельзя. Во-первых, keytool вообще не поддерживает DH. Во-вторых, keytool сам по себе не генерирует параметры для любого алгоритма, только privatekey/keypair. В-третьих, когда keytool генерирует пару ключей, он также генерирует самоподписной сертификат (который иногда впоследствии заменяется "настоящим" CA-выпущенным сертификатом), и сгенерировать самоподписанный сертификат для РД невозможно, так как РД не подписывается. Вы могли бы написать очень простую (около 10 строк) Java-программу для генерации параметров DH. Но это, вероятно, не принесет Вам никакой пользы, потому что:

Java все равно не принимает DHE параметры здесь. JbossWS (Jboss webserver, позже Wildfly) является развилкой Tomcat, и обычно использует Java реализацию SSL/TLS, JSSE. Вверх по Java 7, JSSE использует свои собственные параметры DHE, которые являются 768-битными, что является недопустимо слабым (за исключением пакетов EXPORT, где JSSE подчиняется требованиям RFC для DH-512, которые полностью сломаны, но затем пакеты EXPORT по дизайну полностью сломаны в любом случае, и отключены по умолчанию в Java 7 вверх). Java 8 JSSE позволяет управлять размером параметров DHE, но не фактическим значением.

Вашими (некоторыми накладывающимися) опциями являются:

Использовать Java 8. JSSE в Java 8, но не ранее, по умолчанию DHE равна 1024 битам, что большинство авторитетов считают достаточно сильным, даже несмотря на слабость. org этого не делает, и позволяет указать больше, смотрите https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#customizing_dh_keys и для фона https://stackoverflow.com/questions/30352105/how-to-set-custom-dh-group-in-java-sslengine-to-prevent-logjam-attack . Обратите внимание, что если у вас есть клиенты Java до Java 8, то они будут отказывать , если сервер использует DHE более 1024 бит. Я не знаю других клиентов, у которых есть эта проблема, но проверьте свои перед тем, как зафиксировать это изменение.

Включите ECDHE. JSSE в Java 7 и более поздних версиях реализует ECDHE, которая не подвержена пре-вычислению, как DHE, (обычно) используя P-256, который более чем достаточно силен. (Хотя некоторые люди не доверяют любым кривым NIST ECC, потому что NIST в целом находится под влиянием NSA, хотя ни один открытый исходный код, о котором я знаю, не показал проблему конкретно в кривых ECC). Java 6 на самом деле имеет часть JSSE для ECDHE, но она включена только в том случае, если JVM имеет криптографический "провайдер" для ECC примитивов, чего Java 6 не имеет. bcprov-*-jdk15on из http://www.bouncycastle.org/ является JCE провайдером для ряда криптографических Java примитивов, включая ECC, поэтому, если вы добавите банку к вашей JRE/lib/ext и добавите org. bouncycastle.jce.provider.BouncyCastleProvider в список в JRE/lib/security/java.security (или сделайте подходящее Security.add/insertProvider() где-нибудь в начале вашего кода) Java 6 может сделать ECDHE. Конечно, стоит ли вам использовать Java 6 до сих пор, - вопрос сам по себе.

Несколько лет назад поддержка ECDHE в браузерах и других клиентах была сомнительной, но сегодня AFAIK все современные браузеры поддерживают ее и предпочитают ее DHE - то есть, приветствие браузера перечисляет ECDHE-пакеты перед DHE-пакетами, так что если сервер реализует оба, то он должен выбрать ECDHE. Небраузерные клиенты, возможно, нет; проверьте, чтобы быть уверенным.

Disable DHE. Вы можете настроить список шифров в атрибуте Connector на исключение DHE-шифров; в то же время вы можете исключить staticDH и staticECDH, которые бесполезны, и (одиночные) DES и (все) "EXPORT", если они присутствуют (Java 6). Это означает, что браузеры и клиенты, которые не делают ECHDE, будут застревать в plain-RSA и Forward Secrecy, но, по крайней мере, у них есть "текущая" секретность. Я не помню наверняка, но думаю, что конфигурация 5.1 Коннектора все еще была где-то вроде $server/deploy/jbossweb/server.xml .

Попробуйте нативный. Tomcat, с которого, как я уже говорил, JbossWS и начинался, имеет возможность реализовать HTTPS (SSL/TLS), используя "родной" язык, известный как "APR", который на самом деле является OpenSSL внутри, а не JSSE. Я имел смешанный успех в получении этой опции для работы на JbossWS, и не припомню около 5.1. Если ваш JbossWS имеет работающую TC-native опцию, и если он может справиться с настройкой DH параметров, то используйте openssl для генерации DH параметров и JbossWS-аналогов инструкций по их конфигурированию.

.
13
ответ дан 2 December 2019 в 22:23

У меня была та же проблема, но из Глассфиша.

Во-первых, я бы порекомендовал (если вы можете) поставить какой-нибудь обратный прокси перед вашим JBoss сервером, так как это удалит связь между шифром/сертификатом безопасности и версией Java, которую вы запускаете.

Для того, чтобы получить длину ключа Ephemeral DH больше 768 бит, вам нужно запустить на Java 8. 1024 - это новое значение по умолчанию, и вы можете перейти к 2048, используя jdk.tls.ephemeralDHKeySize (подробности: настройка DH ключей ). Из того, что я смог найти, в Java нет концепции регенерации параметров ключа по отдельности.

3
ответ дан 2 December 2019 в 22:23

На самом деле вы можете указать собственные параметры DHE в последних версиях Java 8 . Это не зависит от приложения (если оно использует реализацию JSSE TLS).

Сначала вам нужно указать размер используемого ключа DHE ( -Djdk.tls.ephemeralDHKeySize = 1024 или -Djdk.tls.ephemeralDHKeySize = 2048 ). На сервере будет использоваться предопределенная комбинация генератор / первичный преобразователь для DHE. В Java 8 можно использовать только 1024 или 2048, JDK 9 будет поддерживать большие размеры .

Если вы хотите предоставить другую комбинацию, вы можете указать их в jre / lib / security / Java.security с помощью свойство безопасности jdk.tls.server.defaultDHEParameters (начиная с версии 8u51). Он принимает список параметров (по одному для каждого используемого размера ключа), и он должен содержать простое число и генератор (обычно 2 или 5) в шестнадцатеричном формате.

Если вы использовали openssl dhparam -out dhparam2048.pem 2048 для создания новой пары вы можете использовать openssl dhparam -noout -text -check -in dhparam2048.pem для чтения и печати этого файла в текстовом режиме. Вам нужно будет скопировать и вставить текст в свойства безопасности Java (используя tr -d ':' , чтобы удалить : между шестнадцатеричным представлением openssl)

Вот образец (только 1024 бис):

>openssl dhparam -in p -check -text -noout | tr -d ':'
PKCS#3 DH Parameters: (1024 bit)
    prime:
       00f7a63b59edcc43a43df12077f0e9
        14129c20a73cef95f919896e608ebc
        8722776c948765bbbf61542e118329
        6c6ea74ecbded3a93aff77a062aba4
        fcf04fc01030e65077f5a802605058
        65b836368dd5ea389d77691fac0f2c
        f7a161c51c8e97ddecb3cf7f872b0c
        cfaf54373d5203edcabc575e871bb1
        107ec2f30c78ebf403
    generator: 2 (0x2)
DH parameters appear to be ok.

И это приводит к

jdk.tls.server.defaultDHEParameters= \
    { \
        00f7a63b59edcc43a43df12077f0e9 \
        14129c20a73cef95f919896e608ebc \
        8722776c948765bbbf61542e118329 \
        6c6ea74ecbded3a93aff77a062aba4 \
        fcf04fc01030e65077f5a802605058 \
        65b836368dd5ea389d77691fac0f2c \
        f7a161c51c8e97ddecb3cf7f872b0c \
        cfaf54373d5203edcabc575e871bb1 \
        107ec2f30c78ebf403, 2 }

. Вам следует перезапустить Сервер и убедиться, что он действительно использует это простое число (а не стандартные), так как процесс не прямолинейный, поэтому многое может пойти неправильно. Значение по умолчанию определено в исходном коде , для 2048-битного начального числа используется черновик TLS FFDHE.

Например, при запуске openssl s_client я вижу 1024-битное простое число ( ffffff ffffffffffc90f ... 5381ffffffffffffffff ) при подключении к серверу Java 8 JSSE:

>openssl s_client -msg -cipher DHE-RSA-AES128-SHA256 -connect localhost:1234
...
<<< TLS 1.2 Handshake [length 018f], ServerKeyExchange
0c 00 01 8b 00 80 ff ff ff ff ff ff ff ff c9 0f
da a2 21 68 c2 34 c4 c6 62 8b 80 dc 1c d1 29 02
4e 08 8a 67 cc 74 02 0b be a6 3b 13 9b 22 51 4a
08 79 8e 34 04 dd ef 95 19 b3 cd 3a 43 1b 30 2b
0a 6d f2 5f 14 37 4f e1 35 6d 6d 51 c2 45 e4 85
b5 76 62 5e 7e c6 f4 4c 42 e9 a6 37 ed 6b 0b ff
5c b6 f4 06 b7 ed ee 38 6b fb 5a 89 9f a5 ae 9f
24 11 7c 4b 1f e6 49 28 66 51 ec e6 53 81 ff ff
ff ff ff ff ff ff 00 01 02 ...

Вместо этого вы должны видеть свои собственные параметры при установке.

Параметры по умолчанию для Java 7 (768 бит) будут «e9e642 ... 7a3daf» с длинным генератором «30470ad..529252» , как определено в ParameterCache .

3
ответ дан 2 December 2019 в 22:23

Теги

Похожие вопросы