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

Ви не можете цього зробити з keytool. По-перше, keytoolвзагалі не підтримує DH. По-друге, keytoolне генерує параметри самостійно для жодного алгоритму, лише приватну клавішу / ключ. По-третє, коли keytoolгенерується ключ, він також генерує самопідписаний cert (який іноді згодом замінюється "справжнім", виданим сертифікатом CA) і неможливо генерувати самопідписаний cert для DH, оскільки DH не підписується. Ви можете написати дуже просту (приблизно 10 рядків) програму Java для створення параметрів DH. Але це, мабуть, не принесе вам користі, оскільки:

Java все одно не приймає параметри DHE. JbossWS (веб-сервер Jboss, пізніше 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 та для фону /programming/30352105/how-to-set-custom-dh-group-in-java -slengine-to-предотвращать-атаку . Зауважте, що якщо у вас є 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. Клієнти, які не переглядають браузер, можливо, ні; тест, щоб бути певним.

Вимкнути DHE. Ви можете налаштувати список шифрів в атрибуті Connector, щоб виключити шифри DHE; в той час як ви перебуваєте на ньому, виключайте також staticDH та staticECDH, які є марними, та (одиночні) DES та (усі) "ЕКСПОРТ", якщо вони є (Java 6). Це означає, що браузери та клієнти, які не роблять ECHDE, будуть застрягати з простою RSA і без Forward Secrecy, але принаймні вони мають "поточну" таємницю. Я не пам'ятаю точно, але я думаю, що конфігурація 5.1 Connector все ще була десь схожа $server/deploy/jbossweb/server.xml.

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

Насправді ви можете вказати власні параметри 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 біт prime ( ffffff ffffffffffc90f ... 5381ffffffffffffffffff ) під час підключення до сервера 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 (768bit) будуть "e9e642 ... 7a3daf" з довгим генератором "30470ad..529252", як визначено в ParameterCache .

Я переживав цю ж проблему, але від Glassfish.

По-перше, я рекомендую (якщо можете) поставити якийсь зворотний проксі перед вашим сервером JBoss, оскільки він видалить зв’язок між захистом шифру / сертифікату та версією Java, яку ви працюєте.

Щоб отримати більш тривалий ключ Ephemeral DH, ніж 768 біт, вам потрібно запустити на Java 8. 1024 - це новий за замовчуванням, і ви можете перейти до 2048 року за допомогою jdk.tls.ephemeralDHKeySize(деталі: налаштування ключів DH ). З того, що я міг знайти, в Java не існує концепції відновлення ключових параметрів окремо.