Implementazione di SSL Perfect Forward Secrecy nel server Web NGINX

Su questa pagina

Andare oltre: implementazione di HTTP Strict Transport Security (HSTS) a lunga durata
Congratulazioni!
Riferimenti:

Questo HOW-TO descrive il processo di implementazione di Perfect Forward Secrecy con il server Web NGINX su sistemi Debian e Ubuntu. Il processo può essere facilmente adattato ad altri sistemi GNU/Linux.

In breve, Perfect Forward Secrecy garantisce: \... che la compromissione di un messaggio non può portare alla compromissione di altri, e anche che non esiste un singolo valore segreto che può portare alla compromissione di più messaggi.\ Per maggiori informazioni, vedere http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy.

Quando la vulnerabilità Heartbleed in OpenSSL è stata rivelata all'inizio del 2014, è diventato sempre più chiaro che PFS è un must per qualsiasi sistema che utilizza SSL/TLS in modo serio.

Se desideri confrontare i tuoi risultati con i miei, la mia implementazione di riferimento può essere testata su https://indietorrent.org.

Senza ulteriori indugi, configuriamo NGINX per implementare PFS.

Passiamo alla directory di configurazione di NGINX:

cd /etc/nginx/

Dobbiamo generare parametri Diffie-Hellman sufficientemente forti. Alcuni sostengono che 4096 bit siano eccessivi e causeranno un carico eccessivo sulla CPU del sistema, ma con la moderna potenza di calcolo, questo sembra un compromesso utile. Per ulteriori informazioni, vedere la sezione Riferimenti, di seguito.

openssl dhparam -out dh4096.pem 4096

È utile avere questo file di configurazione, che è specifico per l'attività da svolgere, suddiviso in compartimenti in un file di inclusione; questo semplifica l'implementazione di PFS su un gran numero di sistemi.

vi /etc/nginx/perfect-forward-secrecy.conf

Incolla quanto segue nel file sopra:

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 !MEDIUM";
ssl_dhparam dh4096.pem;

Modifica la configurazione di NGINX per includere il file precedente, inserendo la seguente riga nel file di configurazione principale di NGINX (per impostazione predefinita, /etc/nginx/nginx.conf), nella parte inferiore (e all'interno) del http {} blocco:

# See: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
# This MUST come AFTER the lines that includes .../sites-enabled/*, otherwise SSLv3 support may be re-enabled accidentally.
include perfect-forward-secrecy.conf;

Riavvia NGINX per rendere effettive le modifiche:

service nginx restart

Se il test su https://www.ssllabs.com/ssltest/analyze.html visualizza Ripresa della sessione (memorizzazione nella cache) No (ID assegnati ma non accettati) in rosso e il server implementa SNI, aggiungere quanto segue al livello superiore Blocco http {} (cioè, aggiungi a nginx.conf, appena sotto dove abbiamo fatto le aggiunte precedenti):

# See: http://forum.nginx.org/read.php?2,152294,152401#msg-152401
ssl_session_cache shared:SSL:10m;

Ancora una volta, riavvia NGINX per rendere effettive le modifiche:

service nginx restart

Il test precedente non dovrebbe più segnalare questo problema (anche se il problema non riduce il punteggio complessivo del test).

Andare oltre: implementare HTTP Strict Transport Security (HSTS) con lunga durata

Questo è facile e vale la pena farlo, a condizione che:

Vuoi forzare SSL per tutte le risorse per qualsiasi host per il quale è impostata questa intestazione (ovvero, ogni pagina del sito web in questione).
Puoi vivere senza avere la possibilità di accettare e ignorare gli avvisi SSL per qualsiasi risorsa richiesta da qualsiasi host per cui è impostata questa intestazione, come \Domain Name Mismatch\, ecc. La vera natura di HSTS è che le condizioni di avviso e di errore relative al certificato SSL non possono essere ignorate.

Ho setacciato Internet per informazioni sull'eventualità che l'impostazione di questa intestazione possa avere conseguenze indesiderate nei browser che non supportano l'intestazione e sono venuto fuori breve. Ma sono stato in grado di placare le mie preoccupazioni testando questa implementazione in Internet Explorer 6, ad esempio, e i browser in cui HSTS non è implementato semplicemente ignorano l'intestazione. Perfetto!

Aggiungi semplicemente le seguenti righe in fondo a /etc/nginx/perfect-forward-secrecy.conf e salva le modifiche:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# This will prevent certain click-jacking attacks, but will prevent
# other sites from framing your site, so delete or modify as necessary!
add_header X-Frame-Options SAMEORIGIN;

Un ricaricamento (invece di un riavvio) sarà sufficiente per forzare NGINX a raccogliere queste particolari modifiche:

service nginx reload

È possibile confermare che HSTS funziona come previsto testando l'implementazione su https://www.ssllabs.com/ssltest/analyze.html. Se HSTS è implementato correttamente, dovresti vedere una casella verde appena sotto il tuo punteggio, che afferma: \Questo server supporta HTTP Strict Transport Security con lunga durata. Voto impostato su A+.\

Congratulazioni!

Ora disponi di una delle implementazioni SSL/TLS più sicure su Internet.

Riferimenti:

https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy