Sto configurando un server node.js:
https.createServer({
...
ciphers: 'ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH',
honorCipherOrder: true
}, app).listen(443);
Questo è in grado di ottenere un punteggio SSLLabs, che è buono. Ora, sembra che tutte le negoziazioni nella simulazione dell'handshake vengano eseguite utilizzando TLS_RSA_WITH_RC4_128_SHA .
RC4 è resiliente contro BEAST. Se siamo vulnerabili a BEST non possiamo ottenere un rating A.
Vorrei supportare PFS (inoltro segreto) se supportato dal client.
Sulla base della mia lettura, "devo generare un po 'di casualità" generando i parametri Diffie-Hellman e ottenerlo nei miei certificati in qualche modo, prima che il server implementi correttamente l'ECDHE per la segretezza futura. Ho letto da qualche parte che ECDHE richiede meno risorse della CPU rispetto a DHE, quindi questo è un vantaggio.
Bene, ho un sacco di domande. Ma chiederò il primo:
Perché devo generare "alcuni casualità " da aggiungere ai certificati, a che scopo serve e cosa fa effettivamente il comando? La pagina OpenSSL su dhparam non mi dice molto su cosa effettivamente fa.
Ho visto questa risposta e sto cercando una spiegazione più chiara (o almeno riferimenti alla lettura pertinente !).
Secondo OpenSSL Ciphers sembra che ECDHE sia una crittografia TLS 1.2. Su pagina PFS di Qualys si dice che ECDHE è supportato da tutti i principali browser moderni, eppure vedo iOS6 solo nei risultati del mio test SSLLabs che si collega tramite TLS1.2. Immagino di poter prendere la sezione "Simulazione handshake" con una grana di sale.
Un'altra domanda è: perché SSLLabs valuta con una A se lascio la voce HIGH nella lista di codici: questo avrebbe il server che supporta una connessione, ad es. TLS_RSA_WITH_AES_128_CBC_SHA (il report indica tanto), che è vulnerabile a BEAST! Forse perché non è mai stato testato con un "client" che non riporta alcun supporto per RC4.
Un'altra domanda: nella pagina Cipressi OpenSSL l'elenco delle suite di crittografia TLS 1.2 include:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDHE-RSA-AES128-SHA256
Questo indica che se ottengo il collegamento con ECDHE che è ora vulnerabile anche a BEAST, a causa dell'uso di CBC? Per esempio. Dovrei cambiarlo per fare come fa Google: ECDHE con RC4. Ma la pagina Ciphers non include nulla che assomigli ad ECDHE-RSA-RC4-SHA. Esiste tuttavia un ECDHE-ECDSA-RC4-SHA. Come è diverso? Modifica: questa risposta SO indica che ECDSA è qualcosa di separato da RSA. Mi piacerebbe replicare ciò che Google sta facendo con ECDHE_RSA + RC4 + SHA in quanto sembra la perfetta combinazione di prestazioni e sicurezza.
Altre note (per favore, dimmi se ho frainteso le cose, specialmente le dichiarazioni travestite da domande):
La resilienza BEAST è controllata attraverso la selezione del codice simmetrico (RC4 vs AES, ecc.). Le modalità di AES che non usano CBC non sono supportate da molti client? Quindi dovremmo semplicemente evitare AES del tutto ...? PFS può essere ottenuto tramite l'uso dello scambio di chiavi Diffie-Hellman, e solo le modalità che includono DHE o ECDHE soddisfano questo. Solo OpenSSL supporta la perfetta segretezza in avanti. RC4 è più veloce di AES. RC4 è migliore di AES (a causa di BEAST)?
Un'altra modifica: vediamo ... qui indica che BEAST non è qualcosa da essere < em> troppo realisticamente preoccupati, anche se influisce negativamente sulla valutazione di SSLLabs. Quella grande "A" sembra così buona ... Vediamo ... Probabilmente dovrei ancora inserire i cifrari RC4_128 all'inizio della catena di cifratura se non altro per il fatto che non sono stati mostrati come "infranti" e più veloce di AES in generale. Ad ogni modo, mi sono allontanato molto dall'argomento originale che è l'ECDHE. E come ottenere correttamente i parametri DH lavorando con Node / Express?