it-swarm.dev

Configurazione della suite di crittografia SSL del server Web "ottimale"

Negli ultimi due anni ci sono stati alcuni cambiamenti in quella che sarebbe considerata una configurazione ottimale della suite di cifratura SSL (ad esempio gli attacchi BEAST e CRIME, i punti deboli in RC4)

La mia domanda è: quale sarebbe attualmente considerato un insieme ottimale di suite di crittografia SSL da abilitare con i seguenti obiettivi.

  • Fornire la connessione più sicura possibile, incluso ove possibile Perfect Forward Security ed evitando punti deboli noti.
  • Fornire la compatibilità con una vasta gamma di client comunemente distribuiti, inclusi dispositivi mobili (ad esempio Android, iOS, Windows Phone) e sistemi operativi desktop (incluso Windows XP/IE6)
74
Rory McCune

La configurazione più sicura non dipende solo dalle cifre, ma anche dalla versione tls utilizzata. Per openssl è preferibile tls 1.1/1.2. BEAST e CRIME sono attacchi al client e di solito sono mitigati dal lato client, ma ci sono anche mitigazioni dal lato server:

  • CRIMINE: basta disabilitare la compressione ssl; questo è tutto
  • BEAST/Lucky13: basta usare TLS 1.1, nessun SSLv3 e nessun RC4, vedi BEAST è ancora una minaccia? (Ivan Ristic)
  • BREACH: funziona solo, se sono soddisfatte alcune condizioni, vedere breachattack.com ; una mitigazione semplice e sempre funzionante sarebbe quella di smantellare la compressione http (gzip)

Per una configurazione perfetta: SSL incide sempre sulle prestazioni ad alto livello, RC4 e altre suite di cifratura rapida potrebbero essere ancora accettabili per il contenuto statico, esp. quando viene servito dal tuo cdn.

Una buona guida per comprendere OpenSSL è OpenSSL Cookbook con spiegazioni dettagliate anche su PFS , cipher-suites, tls-version ecc. Pp ci sono 2 blogposts che spiegano PFS e la configurazione pratica:

cipher-suite-suggerimenti per abilitare PFS anche su client più vecchi:

# Apache
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

# nginx

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

Per un manuale dettagliato nginx/ssl vorrei indirizzarvi a questo Guida a Nginx + SSL + SPDY .

Nell'anno da quando è stata scritta questa risposta, la guida di Mozilla è stata aggiornata regolarmente. Tutte le mie prenotazioni di seguito sono state prese in considerazione e consiglio vivamente di cuore la guida.


Ti consiglio di leggere Mozilla's Server Side TLS guida. È completo e sono particolarmente attenti alla compatibilità con i vecchi client, a volte a scapito della sicurezza. (Dopo tutto, IE 6 utenti meritano di essere in grado di scaricare Firefox.) Vorrei sottolineare diverse cose:

  • Supportare Windows XP/IE 6 non è ottimale. Ti suggerisco di lasciarlo cadere se possibile. Richiede SSL 3.0, che lascia i clienti decenti aperti agli attacchi di downgrade. Modifica: nei report precedenti i report anti-debole password indicano che IE 6 può supportare TLS 1.0. I non ho idea di quale percentuale di IE 6 client lo supportano o lo hanno abilitato, però.

  • Supportare XP/IE 8 non è male. Supporta TLS 1.0, sebbene la sua migliore suite di cifratura sia DES-CBC3-SHA e non supporta il perfetto segreto in avanti o SNI. (Le sue seconde migliori suite di cifratura sono RC4-SHA e RC4-MD5. 3DES è molto lento, ma RC4 ha problemi di sicurezza. Evitalo se possibile.)

  • I parametri Diffie-Hellman a 2048 bit sono i migliori dal punto di vista della sicurezza, ma Java 6 supporta solo i parametri a 1024 bit. I parametri comuni a 1024 bit potrebbero non essere stati rotto da NSA , ma DH a 1024 bit è per il momento più o meno sicuro per ora. Potrebbe essere necessario utilizzarlo. (Java 7 supporta ECDHE, aggirando l'intero problema di DHE dimensione del parametro.)

L'elenco della suite di crittografia principale di Mozilla include RC4. Come sopra, raccomando la lista dalla sezione punti deboli RC4 che usa invece 3DES.

Gli esempi di configurazione di Mozilla abilitano SSL 3.0. Come ho detto, lo scoraggerei.

Gli esempi di configurazione di Mozilla raccomandano principalmente parametri DH a 2048 bit, ma danno anche 1024 come opzione.

28
Matt Nordhoff

Naturalmente, il primo passo è mantenere aggiornato OpenSSL (o la libreria che usi).

Ma quando vengono scoperte nuove vulnerabilità e vengono aggiornati i browser, le risposte qui possono (diventeranno) obsolete. Suggerirei di fare affidamento su Mozilla SSL Configuration Generator per verificare quale configurazione dovresti usare.

enter image description here

22
Gaia

La crittografia SSL "ottimale" che si configura sul server Web dipende dalle esigenze del cliente. In molti casi, ciò costituirebbe un fattore nella scelta del protocollo e delle suite di crittografia. Non sono sicuro se questo è il tuo caso.

È possibile configurare la migliore sicurezza possibile - supportare solo il protocollo TLS 1.2, solo cifre con Perfect Forward Security (PFS) e solo AES 256. All'interno di PFS, è possibile supportare solo la variante della curva ellittica ECDHE. È possibile scegliere le nuove crittografie GCM sicure che forniscono crittografia autenticata e prestazioni molto buone (con istruzione AES-NI). Ma se il tuo cliente più importante utilizza IE8 su Windows 7 e non riesci a convincerlo ad aggiornare il browser, non sarà in grado di utilizzare il tuo servizio e perderai un cliente.

ssllabs.com fornisce un servizio web per scansionare il tuo sito e dare valutazioni come A +, A, B ecc. La valutazione si basa su punteggi numerici (max 100) ricevuti per 4 parametri --- Certificato, Supporto protocollo, Scambio chiavi e forza cifratura . Danno voti più alti se Perfect Forward Secrecy (PFS), Strict Transport Security (HSTS), per citarne alcuni, sono supportati.

Tieni presente che il punteggio può cambiare in un periodo di tempo man mano che i browser e i server vengono patchati, emergono nuovi punti deboli, vengono scoperti nuovi exploit, ecc. In precedenza, ssllabs ha assegnato un punteggio inferiore a siti che non implementavano mitigazioni sul lato server per l'attacco BEAST, ma hanno smesso di farlo se lo considerano mitigato sul lato client (tranne per la ritardata Apple), ma soprattutto perché la mitigazione ha comportato l'applicazione di RC4 (per i protocolli TLS 1.0 o precedenti) e gira che RC4 è molto più debole di quanto si pensasse in precedenza.

Puoi andare sul sito ssl labs , inserire l'URL e ottenere il punteggio.

Il rapporto sui laboratori SSL include una sezione sulla simulazione della stretta di mano in cui mostra un gruppo di client (browser, Java, openssl) e quali protocolli, suite di crittografia, dimensioni delle chiavi verranno negoziati con il tuo server. Se la negoziazione non è possibile, verrà visualizzato in rosso "Mancata corrispondenza del protocollo o della suite di crittografia". Puoi cercare la simulazione Handshake per la configurazione utilizzata dai tuoi clienti importanti. Ad esempio, potresti vedere la voce

IE 8-10/Win7, TLS 1.0, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, FS 256

Ma supponiamo che tu restringa la configurazione ssl del tuo server per supportare solo TLS 1.2, quindi questa riga verrà letta

IE 8-10/Win7, Protocol or cipher suite mismatch, Fail

Ma, man mano che i tuoi clienti migrano/aggiornano/aggiornano, puoi rafforzare la sicurezza con l'obiettivo solo di TLS 1.2, solo PFS e solo 256 bit

Un'altra importante informazione fornita dal report è se le suite di cifratura sono nell'ordine preferito dal server oppure no. Nel primo caso, l'ordine delle cifre elencate nella configurazione del server sarà rispettato --- quindi si mettono al primo posto le suite di crittografia preferite. Verrà scelta la prima cifra nell'elenco che possono essere utilizzati sia dal server che dal client. Se usi Apache, puoi abilitarlo con la direttiva "SSLHonorCipherOrder on". Per nginx, la direttiva è "ssl_prefer_server_ciphers on;"

4
Babu Srinivasan