Web sunucusu (JBoss-5.1.0.GA) ayarlarımızı Diffie-Hellman standartlarını karşılayacak şekilde güncellemeye çalıştığımız uzman değiliz. Https://weakdh.org/sysadmin.html adresinde bir test yaptıktan sonra "yeni, 2048 bit Diffie-Hellman parametreleri oluşturmamız" gerektiği söyleniyor. Geçmişte, Java keytool ile anahtarlar oluşturduk, ancak Java keytool ile yeni bir 2048 bit Diffie-Hellman parametresi oluşturma hakkında herhangi bir bilgi bulamadık. Bunun nasıl yapılacağını bilen var mı yoksa bizi doğru yönde gösterebilir mi? Teşekkür ederim!

Bunu keytool ile yapamazsınız. İlk olarak, keytoolDH'yi hiç desteklemiyor. İkincisi, keytoolherhangi bir algoritma için tek başına parametre üretmez, sadece bir privatekey / keypair. Üçüncüsü, keytoolbir anahtar çifti oluşturduğunda, kendinden imzalı bir sertifika da oluşturur (bu bazen daha sonra "gerçek" CA tarafından verilen bir sertifika ile değiştirilir) ve DH için imzalamadığı için DH için kendinden imzalı bir sertifika oluşturmak imkansızdır. Sen olabilir DH parametrelerini oluşturmak için çok basit (yaklaşık 10 hat) Java programı yazmak. Ama muhtemelen sana hiç faydası olmaz çünkü:

Java zaten DHE parametrelerini burada kabul etmiyor. JbossWS (Jboss web sunucusu, daha sonra Wildfly) Tomcat'in bir çataldır ve normalde SSL / TLS, JSSE'nin Java uygulamasını kullanır. Java 7 ile, JSSE, kabul edilemeyecek kadar zayıf olan 768 bit olan kendi DHE parametrelerini kullanır. (JSSE'nin tamamen kırık olan DH-512 için RFC gereksinimine uyduğu EXPORT paketleri hariç, ancak EXPORT süitleri zaten tamamen kırılmış ve Java 7'de varsayılan olarak devre dışı bırakılmıştır.) Java 8 JSSE DHE parametrelerinin boyutunu kontrol eder , ancak gerçek değeri kontrol etmez.

(Bazı çakışan) seçenekleriniz:

Java 8'i kullanın. Java 8'de JSSE, ancak daha önce değil, DHE'yi varsayılan olarak 1024 bits olarak ayarlar; bu, çoğu otoruğun weakdh.org olmasa bile yeterince güçlü olduğunu düşünür ve daha fazlasını belirtmenize izin verir, bkz. Https://docs.oracle.com /javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#customizing_dh_keys ve arka plan için /programming/30352105/how-to-set-custom-dh-group-in-java -sslengine-önlemek-logjam-saldırı . Java 8'den önce herhangi bir Java istemciniz varsa, sunucu 1024 bitin üzerinde DHE kullanıyorsa bunların başarısız olacağını unutmayın. Bu sorunu yaşayan başka bir müşteri bilmiyorum, ancak bu değişikliği yapmadan önce kendi testinizi yapın.

ECDHE'yi etkinleştirin. Java 7 ve sonraki sürümlerinde JSSE, DHE gibi ön hesaplamaya tabi olmayan ECDHE'yi (normalde) yeterince güçlü olan P-256 kullanarak uygular. (Bazı insanlar güvenmiyorum rağmen herhangi genelde NIST NSA etkilenir çünkü benim bildiğim hiçbir açık kaynak özellikle ECC eğrileri bir sorun gösterse de NIST ECC eğrilerinin.) Java 6 fiilen ECDHE için JSSE parçası vardır ancak yalnızca JVM'nin ECC ilkelleri için Java 6'da olmayan bir kripto "sağlayıcısı" varsa etkinleştirilir. bcprov - * - dan jdk15on http://www.bouncycastle.org/ size kavanoz Apple Şifre eğer öyleyse, ECC dahil Java kripto ilkel bir dizi için bir JCE sağlayıcıdır JRE/lib/extve eklemek org.bouncycastle.jce.provider.BouncyCastleProviderlisteye JRE/lib/security/java.security(veya uygun yapmakSecurity.add/insertProvider()Java 6 ECDHE yapabilir. Elbette hala kullanımda olan herhangi bir Java 6'ya sahip olup olmamanız kendi başına bir sorudur.

Birkaç yıl önce, tarayıcılarda ve diğer istemcilerde ECDHE desteği iffy idi, ancak bugün AFAIK tüm güncel tarayıcılar bunu destekliyor ve DHE'ye tercih ediyor - yani, tarayıcı merhaba DHE paketlerinden önce ECDHE paketlerini listeliyor sunucu her ikisini de uygularsa, ECDHE'yi seçmesi gerektiğini unutmayın. Tarayıcı olmayan istemciler olmayabilir; emin olmak için test.

DHE'yi devre dışı bırakın. DHE şifrelerini hariç tutmak için Connector özniteliğindeki şifre listesini yapılandırabilirsiniz; buna rağmen, işe yaramaz olan staticDH ve staticECDH'yi ve varsa (tek) DES ve (tümü) "EXPORT" u (Java 6) hariç tutar. Bu, ECHDE yapmayan tarayıcıların ve istemcilerin düz RSA ile takıldıkları ve İletme Gizliliği bulunmayacakları anlamına gelir, ancak en azından "geçerli" gizlilikleri vardır. Emin hatırlamıyorum, ama sanırım 5.1 Bağlayıcı yapılandırması hala bir yerdeydi $server/deploy/jbossweb/server.xml.

Yerli deneyin. Dediğim gibi JbossWS'ın başladığı Tomcat, HTTPS'yi (SSL / TLS) JSSE yerine aslında OpenSSL olan "yerli" aka "APR" kullanarak bir seçeneğe sahip. JbossWS üzerinde çalışmak için bu seçeneği elde etmede karışık bir başarı elde ettim ve 5.1'i hatırlamıyorum. Eğer senin JbossWS çalışılabilir TC-yerli seçeneği vardır ve eğer bu DH parametrelerini yapılandırmak işleyebilir, daha sonra bunları yapılandırmak için DH parametrelerini ve JbossWS yerli talimatları oluşturmak için openssl kullanın.

Aslında , en son Java 8 sürümleriyle özel DHE Parametreleri belirtebilirsiniz . Bu uygulamadan bağımsızdır (JSSE TLS uygulamasını kullandığı sürece).

Kullanılacak ( -Djdk.tls.ephemeralDHKeySize=1024veya -Djdk.tls.ephemeralDHKeySize=2048) DHE tuşunun boyutunu belirtmeniz gerekir . Sunucuda, DHE için önceden tanımlanmış bir jeneratör / ana kombinasyon kullanılır. Java 8 ile yalnızca 1024 veya 2048 kullanılabilir, JDK 9 daha büyük boyutları destekleyecektir .

Farklı bir kombinasyon sağlamak istiyorsanız, bunları jdk.tls.server.defaultDHEParameterssecurity özelliği ile jre / lib / security / Java.security'de belirtebilirsiniz (8u51'den beri). Parametrelerin bir listesini alır (her kullanılan anahtar boyutu için bir tane) ve asal ve Jeneratörü (genellikle 2 veya 5) onaltılık olarak içermelidir.

Eğer kullanılırsa openssl dhparam -out dhparam2048.pem 2048yeni bir çift oluşturmak için kullanabileceğiniz openssl dhparam -noout -text -check -in dhparam2048.pemokuma ve metin modunda bu dosyayı yazdırmak için. Metni kopyalayıp Java güvenlik özelliklerine yapıştırmanız gerekir ( openssl onaltılık temsilini tr -d ':'kaldırmak için kullanarak :)

İşte bir örnek (sadece 1024 bis):

>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.

Bu da

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

Sunucuyu yeniden başlatmanız ve işlemin düz olmadığı için bu asal (varsayılanları değil) kullandığını doğrulamanız gerekir, böylece çok şey ters gidebilir. Varsayılan kaynak olarak tanımlanmıştır , 2048 bit için asal TLS FFDHE taslağından alınmıştır.

Örneğin, openssl s_client çalıştırırken, bir Java 8 JSSE Sunucusuna bağlanırken 1024bit prime ( ffffff ffffffffffc90f ... 5381ffffffffffffffff ) görebiliyorum:

>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 ...

Bunun yerine, yüklendiğinde özel Parametrelerinizi görmeniz gerekir.

Java 7 (768bit) için Varsayılan Parametreler , ParameterCache'de tanımlandığı gibi "30470ad..529252" uzun bir jeneratörle "e9e642 ... 7a3daf" olacaktır .

Aynı sorunu yaşıyorum, ama Glassfish'ten.

İlk olarak, (mümkünse) JBoss sunucunuzun önüne bir tür ters proxy koymanızı öneririm, çünkü şifre / sertifika güvenliği ile çalıştırdığınız Java sürümü arasındaki bağlantıyı kaldıracaktır.

768 bit'ten daha büyük Geçici DH anahtar uzunluğu elde etmek için Java 8'de çalıştırmanız gerekir. 1024 yeni varsayılan değerdir ve jdk.tls.ephemeralDHKeySize(ayrıntılar: DH anahtarlarını özelleştirme ) kullanarak 2048'e kadar gidebilirsiniz . Bulabildiğim kadarıyla, Java'da anahtar parametreleri ayrı ayrı yeniden oluşturma kavramı yoktur.