Consigliati ssl_ciphers per sicurezza, compatibilità - Perfect Forward segretezza

In primo luogo, esaminiamo come funziona la negoziazione della suite di crittografia, molto brevemente. Ad esempio, possiamo utilizzare il documento TLS 1.2 RFC 5246 a partire dalla sezione 7.4.1.2 per vedere , nel breve modulo breve:

• ClientHello: il client comunica al server quali suite di crittografia supportate dal client
• Ora il server ne sceglie uno
  • Discuterò su come controllare quale sceglierà dopo
• ServerHello: il server comunica al client quale suite di crittografia ha scelto, o dà al client un messaggio di errore.

Ora, per quanto riguarda la selezione effettiva. Ho usato la documentazione del modulo nginx ssl , la articoloQualys 2013 sulla configurazione di Apache, Nginx e OpenSSL per il segreto diretto , e il articolo Hynek Hardening SSL Ciphers per riferimento. Gli ultimi due riguardano sia Apache che Nginx (poiché entrambi utilizzano OpenSSL come base).

Essenzialmente, devi dire a Nginx di usare l'ordine che selezioni, e devi selezionare un ordine. Per vedere quali sarebbero i risultati di tale ordine, puoi utilizzare la riga di comando di OpenSSL, ad es.

openssl ciphers -v 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED'

NOTA: è possibile rimuovere:! 3DES da quella stringa; Triple-DES a 3 tasti non è efficiente, ma è ancora sicuro in sé e per sé a più o meno 112 bit di sicurezza ed è molto, molto comune.

Utilizzare il comando precedente per determinare quali suite di cifratura saranno maggiormente preferite e meno preferite nella configurazione, e cambiarle fino a quando non si apprezzano i risultati. I riferimenti che ho dato hanno le loro stringhe; L'ho leggermente modificato per ottenere l'esempio sopra riportato (rimuovendo RC4 e SEED e inserendo ogni suite di crittografia TLS 1.2 su qualsiasi suite di crittografia SSLv3, ad esempio).

Quindi, per Nginx in particolare, dovresti modificare il tuo file di configurazione per includere qualcosa come:

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

Aggiungi SSLv3 a ssl_protocols se lo vuoi davvero.

I ssl_prefer_server_ciphers informeranno nginx di usare l'ordine che specifichiamo e ignoreranno l'ordine in cui il client presenta la loro lista di codici. Ora, se l'unica suite di crittografia condivisa tra ClientHello e l'elenco OpenSSL ciphers -v ... dà è il nostro cifrario meno preferito, è quello che userà nginx. Se nulla corrisponde, inviamo al client un avviso di errore.

Il comando ssl_ciphers è la carne della scelta, qui, come nginx informerà OpenSSL della nostra lista di suite di cifratura preferita. Per favore, usa il comando openssl ciphers -v per vedere i risultati che ottieni sulla tua piattaforma. Idealmente, ricontrollalo dopo aver cambiato le versioni di OpenSSL.

Inoltre, leggi l'articolo di Scott Helme su come configurare HSTS (HTTP Transport Transport Security) in nginx , che consentirà a un host di imporre l'utilizzo di HTTPS sul lato client. Assicurati di includere l'intestazione HSTS all'interno del blocco http con l'istruzione ssl listen.

Modificato per aggiungere: Almeno dopo questo (se non prima anche), vai a Qualys SSL Labs per vedere le informazioni di sicurezza HTTPS e per Test del server che è stato tenuto abbastanza bene aggiornato negli ultimi anni. Le raccomandazioni cambiano regolarmente, e talvolta anche spesso si invertono (RC4, ad esempio, che quasi induce al colpo di frusta). Puoi anche Testare il tuo browser !

Mozilla ha uno strumento online che ti aiuterà a scegliere la suite di crittografia corretta.

link

Ti consente di inserire la versione del server, la versione del software, ecc. e quindi scegliere tra un equilibrio di sicurezza e il supporto legacy.

OpenSSL naturalmente preferirà i nuovi MAC per le suite di crittografia altrimenti equivalenti . Ad esempio, il lungo output openssl ciphers -v per la stringa di codice inizia con:

ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH        Au=RSA    Enc=AESGCM(256)    Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AESGCM(256)    Mac=AEAD
ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA384
ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA384
ECDHE-RSA-AES256-SHA           SSLv3    Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA1
ECDHE-ECDSA-AES256-SHA         SSLv3    Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA1

Ovviamente, TLS utilizzerà solo suite di crittografia supportate reciprocamente dal server e dal client e né Chrome né Firefox supportano le suite di crittografia HMAC-SHA256. Poiché HMAC-SHA1 (e persino HMAC-MD5) sono ancora considerati sicuri, credo che i loro sviluppatori (e quelli di NSS, la libreria TLS che entrambi utilizzano) siano scettici sullo spreco dello sforzo di sviluppo e della stretta di mano TLS aggiungendo nuovo, non necessario e indietro suite di crittografia non compatibili.

Guarda, ad esempio, suite di crittografia supportate di Chrome 33 in ordine di preferenza :

1. ChaCha20-Poly1305 ,
2. AES-128-GCM,
3. AES-256-CBC con HMAC-SHA1,
4. RC4 (ugh) e AES-128-CBC con HMAC-SHA1, ...

OpenSSL non supporta ChaCha20-Poly1305. Se il tuo non supporta AES-GCM (???) e utilizza un certificato RSA, ECDHE-RSA-AES256-SHA è naturalmente la suite di crittografia che Chrome utilizzerà. (Firefox 29 userebbe ECDHE-RSA-AES128-SHA .)

(Le suite di crittografia "SHA-256" che hai visto essere utilizzate su altri siti web sono presumibilmente ChaCha20-Poly1305 o AES-128-GCM, che sono AEAD che non utilizzano HMAC, ma i cui pacchetti di crittografia utilizzano SHA-256 in PRF .)

per la migliore compatibilità la suite di crittografia cloudflare non è la migliore; ho trovato il seguente migliore:

# suggestion from sslabs / including PFS, good compatibility
#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;


# suggestion my mozilla-server-team - good compatibility, pfs
#ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;

quando controlli ogni impostazione con ssllabs troverai per queste 2 suite la seguente dichiarazione:

• Inoltra segretezza Sì (con la maggior parte dei browser) ROBUST

mentre sul cipher_suite suggerito dice:

• Inoltra segretezza Sì (con i browser moderni)

informazioni aggiuntive: Guida a Nginx + SSL + SPDY

La raccomandazione di Comodo è:

ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

Fonte: link

link è un altro sito che offre:

The above ciphers are Copy Pastable in your nginx, Lighttpd or Apache config. These provide Strong SSL Security for all modern browsers, plus you get an A+ on the SSL Labs Test.

Questo materiale non è aggiornato per tutto il tempo, ma per quello che vale, nel maggio 2018 ecco i suoi consigli per nginx:

ssl_protocols TLSv1.3;# Requires nginx >= 1.13.0 else use TLSv1.2
ssl_prefer_server_ciphers on; 
ssl_dhparam /etc/nginx/dhparam.pem; # openssl dhparam -out /etc/nginx/dhparam.pem 4096
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_timeout  10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7

La scelta della funzione di hash (SHA-1 vs SHA-256) non dipende realmente dalla suite di crittografia , ma dalla versione del protocollo . Fondamentalmente, ottieni SHA-256 se usi TLS 1.2 , SHA-1 se usi una versione precedente.

(Sì, ho saputo che questa è una descrizione semplificata di una situazione leggermente più complessa, ma qui funziona.)

Normalmente, client e server utilizzeranno la versione di protocollo più alta supportata da entrambi, quindi dovresti già ottenere TLS-1.2 (quindi SHA-256) ogni volta che è possibile. Si noti che ciò richiede che sia il codice del server (OpenSSL) sia il codice del client siano recenti. Puoi modificare esplicitamente tale meccanismo con ssl_protocols .