Siamo non esperti che cercano - finora senza successo - di aggiornare le impostazioni del nostro server Web (JBoss-5.1.0.GA) per soddisfare gli standard Diffie-Hellman. Dopo aver eseguito un test su https://weakdh.org/sysadmin.html , ci viene detto che dobbiamo "generare nuovi parametri Diffie-Hellman a 2048 bit". In passato, abbiamo generato chiavi con keytool Java, ma non siamo riusciti a trovare alcuna informazione sulla generazione di un nuovo parametro Diffie-Hellman a 2048 bit con keytool Java. Qualcuno sa come fare questo o potrebbe indicarci la giusta direzione? Grazie!

Non puoi farlo con keytool. Innanzitutto, keytoolnon supporta affatto DH. Secondo, keytoolnon genera parametri da solo per nessun algoritmo, ma solo una chiave privata / coppia di chiavi. Terzo, quando keytoolgenera una coppia di chiavi genera anche un certificato autofirmato (che a volte viene successivamente sostituito da un certificato "reale" emesso dalla CA) ed è impossibile generare un certificato autofirmato per DH perché DH non firma. È possibile scrivere un programma Java molto semplice (circa 10 righe) per generare parametri DH. Ma probabilmente non ti farebbe nulla di buono perché:

Java non accetta comunque i parametri DHE qui. JbossWS (il webserver Jboss, in seguito Wildfly) è un fork di Tomcat e normalmente utilizza l'implementazione Java di SSL / TLS, JSSE. Fino a Java 7, JSSE utilizza i propri parametri DHE che sono 768 bit, inaccettabilmente deboli. (Ad eccezione delle suite EXPORT in cui JSSE obbedisce ai requisiti RFC per DH-512, che è totalmente rotto, ma le suite EXPORT sono comunque progettate completamente rotte e disabilitate di default in Java 7 e versioni successive. Java 8 JSSE consente di controlla la dimensione dei parametri DHE, ma non il valore effettivo.

Le opzioni (alcune sovrapposte) sono:

Usa Java 8. JSSE in Java 8, ma non in precedenza, per impostazione predefinita DHE su 1024 bit, che la maggior parte delle autorità considera abbastanza forte anche se deboledh.org non lo fa e ti consente di specificare altro, vedi https://docs.oracle.com /javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#customizing_dh_keys e per lo sfondo /programming/30352105/how-to-set-custom-dh-group-in-java -sslengine-to-prevent-logjam-attack . Si noti che se si dispone di client Java prima di Java 8, falliranno se il server utilizza DHE oltre 1024 bit. Non conosco altri clienti che hanno questo problema, ma testalo prima di impegnarti in questa modifica.

Abilita ECDHE. JSSE in Java 7 e versioni successive implementa ECDHE, che non è soggetto a precomputazione come DHE, (normalmente) usando P-256, che è più che abbastanza forte. (Anche se alcune persone non si fidano di nessuna delle curve ECC del NIST perché il NIST in generale è influenzato dall'NSA, anche se nessun open source che conosco ha mostrato un problema specifico nelle curve ECC.) Java 6 ha effettivamente la parte JSSE per ECDHE ma è abilitato solo se JVM ha un "provider" crittografico per primitive ECC, che Java 6 non ha. bcprov - * - jdk15on da http://www.bouncycastle.org/ è un fornitore JCE per una gamma di primitive crittografiche Java incluso ECC, quindi se aggiungi il jar al tuo JRE/lib/exte aggiungi org.bouncycastle.jce.provider.BouncyCastleProviderall'elenco in JRE/lib/security/java.security(o fai un adattoSecurity.add/insertProvider()da qualche parte all'inizio del codice) Java 6 può eseguire ECDHE. Ovviamente se dovresti avere ancora Java 6 in uso è una domanda a sé stante.

Qualche anno fa, il supporto per ECDHE nei browser e altri client era incerto, ma oggi AFAIK tutti i browser aggiornati lo supportano e lo preferiscono a DHE, ovvero il ciao del browser elenca le suite ECDHE prima delle suite DHE, quindi che se il server implementa entrambi dovrebbe scegliere ECDHE. Forse i client non browser; prova per essere certi.

Disabilita DHE. È possibile configurare l'elenco di cifre nell'attributo Connector per escludere le cifre DHE; mentre ci sei, escludi anche staticDH e staticECDH che sono inutili, e (singolo) DES e (tutto) "EXPORT" se presente (Java 6). Ciò significa che i browser e i client che non eseguono ECHDE saranno bloccati con semplice RSA e senza segretezza diretta, ma almeno hanno un segreto "attuale". Non ricordo per certo, ma penso che la configurazione del connettore 5.1 fosse ancora da qualche parte $server/deploy/jbossweb/server.xml.

Prova nativo. Tomcat, che come ho detto da JbossWS è partito, ha un'opzione per implementare HTTPS (SSL / TLS) usando "native" aka "APR" che in realtà è OpenSSL all'interno piuttosto che JSSE. Ho avuto un successo misto nel far funzionare questa opzione su JbossWS e non ricordo di 5.1. Se il tuo JbossWS ha un'opzione nativa TC realizzabile e se è in grado di gestire la configurazione dei parametri DH, usa opensl per generare i parametri DH e le istruzioni native JbossWS per configurarli.

In realtà è possibile specificare parametri DHE personalizzati con recenti versioni di Java 8 . Questo è indipendente dall'applicazione (purché utilizzi l'implementazione TLS JSSE).

Devi prima specificare la dimensione della chiave DHE da usare ( -Djdk.tls.ephemeralDHKeySize=1024o -Djdk.tls.ephemeralDHKeySize=2048). Sul server verrà utilizzata una combinazione generatore / primo predefinita per DHE. Con Java 8 è possibile utilizzare solo 1024 o 2048, JDK 9 supporterà dimensioni maggiori .

Se si desidera fornire una combinazione diversa, è possibile specificarli in jre / lib / security / Java.security con la jdk.tls.server.defaultDHEParametersproprietà security (da 8u51). Prende un elenco di parametri (uno per ogni dimensione di chiave utilizzata) e deve contenere il primo e il generatore (in genere 2 o 5) come esadecimali.

Se hai usato openssl dhparam -out dhparam2048.pem 2048per generare una nuova coppia puoi usare openssl dhparam -noout -text -check -in dhparam2048.pemper leggere e stampare quel file in modalità testo. Dovrai copiare e incollare il testo nelle proprietà di sicurezza di Java (usando tr -d ':'per rimuovere :tra la rappresentazione esadecimale di openssl)

Ecco un esempio (solo 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.

E questo si traduce in

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

È necessario riavviare il server e verificare che utilizzi effettivamente questo numero primo (e non quelli predefiniti) poiché il processo non è diretto, quindi molte cose possono andare storte. L'impostazione predefinita è definita nella sorgente , per 2048 bit il numero primo proviene dalla bozza TLS FFDHE.

Ad esempio quando eseguo openssl s_client, posso vedere il primo a 1024 bit ( ffffff ffffffffffc90f ... 5381ffffffffffffffffff ) quando mi connetto a un server JSSE Java 8:

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

Invece di questo, è necessario visualizzare i parametri personalizzati quando installato.

I parametri predefiniti per Java 7 (768 bit) sarebbero "e9e642 ... 7a3daf" con un generatore "30470ad..529252" lungo come definito in ParameterCache .

Ho riscontrato questo stesso problema, ma da Glassfish.

In primo luogo, ti consiglio (se puoi) di mettere una sorta di proxy inverso davanti al tuo server JBoss in quanto rimuoverà il collegamento tra la sicurezza di cifratura / certificato e la versione di Java che stai eseguendo.

Per ottenere una lunghezza della chiave DH effimera maggiore di 768 bit è necessario essere in esecuzione su Java 8. 1024 è il nuovo valore predefinito e si può arrivare fino al 2048 usando i jdk.tls.ephemeralDHKeySize(dettagli: personalizzazione delle chiavi DH ). Da quello che ho potuto trovare, non esiste il concetto di rigenerare i parametri chiave separatamente in Java.