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

74

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

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

  • Fornisci la connessione più sicura possibile, incluso, ove possibile, Perfect Forward Security ed evita punti deboli noti.
  • Fornire compatibilità con un'ampia gamma di client comunemente implementati, inclusi dispositivi mobili (ad esempio, Android, iOS, Windows Phone) e desktop (incluso Windows XP / IE6)
posta Rоry McCune 17.02.2014 - 10:39
fonte

4 risposte

49

L'impostazione più sicura non dipende solo dalle crittografie, ma anche dalla versione tls utilizzata. Per openssl, si preferisce tls 1.1 / 1.2. BEAST e CRIME sono attacchi al client e in genere sono mitigati dal lato client, ma esistono anche attenuazioni sul lato server:

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

Per una configurazione perfetta: SSL incide sempre sulle prestazioni a un livello elevato, RC4 e altre suite di cifratura veloci potrebbero essere ancora accettabili per i contenuti statici, esp. quando servito dal tuo cdn.

Una buona guida alla comprensione di OpenSSL è OpenSSL Cookbook con spiegazioni dettagliate anche su PFS , cipher-suite, tls-version ecc. pp. ci sono 2 blogposts che spiegano PFS e impostazione pratica:

suite di crittografia: suggerimenti per abilitare PFS anche su client precedenti:

# 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 di nginx / ssl vorrei indirizzarti a questo Guida a Nginx + SSL + SPDY .

    
risposta data 17.02.2014 - 20:34
fonte
27

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

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

  • Supporto Windows XP / IE 6 non è ottimale Ti suggerisco di lasciarlo se possibile. Richiede SSL 3.0, che lascia aperti client decenti agli attacchi di downgrade. Modifica: report anti-password deboli nei commenti sopra che IE 6 può supportare TLS 1.0. Non ho idea di quale percentuale di client IE 6 lo supporti o sia abilitato, però.

  • Supportando XP / IE 8 non è male. Supporta TLS 1.0, anche se la sua suite di cifratura migliore è DES-CBC3-SHA e non supporta la perfetta sicurezza in avanti o SNI. (Le sue seconde suite di cifratura sono RC4-SHA e RC4-MD5 . 3DES è molto lento, ma RC4 ha problemi di sicurezza. Se possibile, evitalo.

  • 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. Anche i parametri a 1024 bit sono sicuri, a meno che i tuoi avversari non includano decenni di supercomputer in futuro. Potresti aver bisogno di usarli invece. (Java 7 supporta ECDHE, ignorando l'intero problema delle dimensioni dei parametri DHE.)

L'elenco di suite di cifratura principale di Mozilla include RC4. Come sopra, raccomando l'elenco dalla sezione RC4 debolezze che utilizza 3DES.

Gli esempi di configurazione di Mozilla abilitano SSL 3.0. Come ho detto, vorrei scoraggiarlo.

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

    
risposta data 18.02.2014 - 03:47
fonte
22

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

Tuttavia, man mano che vengono scoperte nuove vulnerabilità e vengono aggiornati i browser, le risposte qui possono (diventeranno) obsolete. Ti suggerisco di fare affidamento sul Mozilla SSL Configuration Generator per verificare quale configurazione dovresti usare.

    
risposta data 02.02.2015 - 19:29
fonte
4

Il cifrario SSL "ottimale" che configuri sul tuo server web dipenderà dalle esigenze del cliente. In molti casi, questo sarebbe un fattore nella scelta del protocollo e delle suite di crittografia. Non sono sicuro che sia il tuo caso.

Potresti configurare la migliore sicurezza possibile - supporta solo il protocollo TLS 1.2, solo le crittografie con Perfect Forward Security (PFS) e solo AES 256. All'interno di PFS, puoi supportare solo la variante della curva ellittica ECDHE. Puoi scegliere i nuovi codici di crittografia GCM sicuri che forniscono la crittografia autenticata e forniscono prestazioni molto buone (con istruzioni AES-NI). Ma se il tuo cliente più importante utilizza IE8 su Windows 7 e non riesci a convincerli ad aggiornare il browser, non potranno utilizzare il tuo servizio e perderai un cliente.

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

Si noti che il punteggio può cambiare per un periodo di tempo in cui i browser e i server vengono riparati, emergono nuovi punti deboli, vengono scoperti nuovi exploit ecc. In precedenza, ssllabs ha assegnato una valutazione inferiore ai siti che non implementavano attenuazioni sul lato server per Attacco BEAST, ma hanno smesso di farlo come lo considerano mitigato dal lato client (tranne che per la Apple laggard), ma soprattutto perché la mitigazione comportava l'applicazione di RC4 (per i protocolli TLS 1.0 o precedenti) e risulta che RC4 è molto più debole di quanto si pensasse in precedenza.

Puoi visitare il sito ssl labs , inserire l'url e ottenere il punteggio.

Il rapporto sui laboratori SSL include una sezione sulla simulazione di Handshake in cui mostra un gruppo di client (browser, Java, openssl) e quali protocolli, pacchetti di crittografia, dimensioni delle chiavi saranno negoziati con il tuo server. Se la negoziazione non è possibile mostrerà "Protocollo o mismatch suite di cifratura" in rosso. Puoi cercare la simulazione di 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 dimostri di stringere la configurazione ssl del tuo server per supportare solo TLS 1.2, quindi questa riga leggerà

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

Tuttavia, mentre i tuoi clienti eseguono la migrazione / l'aggiornamento / l'upgrade, puoi stringere la sicurezza con l'obiettivo di TLS 1.2 solo, solo PFS e solo 256 bit

Un'altra informazione importante fornita dal rapporto è se le suite di crittografia si trovano nell'ordine preferito dal server o meno. Nel primo caso, l'ordine dei cifrari elencati nella configurazione del server sarà rispettato --- quindi metti prima i pacchetti di crittografia preferiti. Il primo cifrario nella lista che sia server che client possono utilizzare sarà scelto. Se si utilizza Apache, è possibile abilitarlo con la direttiva "SSLHonorCipherOrder on". Per nginx, la direttiva è "ssl_prefer_server_ciphers on;"

    
risposta data 07.03.2014 - 19:19
fonte

Leggi altre domande sui tag