Implementazione della Perfect Forward Secrecy in NGINX Web-Server

Questo HOW-TO descrive il processo di implementazione della 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, la Perfect Forward Secrecy garantisce: “… che il compromesso di un messaggio non possa portare al compromesso di altri, e anche che non ci sia un singolo valore segreto che possa portare al compromesso di più messaggi.” Per ulteriori 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 la PFS è un must per qualsiasi sistema che utilizzi SSL/TLS in modo serio.

Se desideri confrontare i tuoi risultati con i miei, la mia implementazione di riferimento può essere testata su https://www.ssllabs.com/ssltest/analyze.html?d=indietorrent.org, e la catena di certificati SSL e gli header NGINX che vengono inviati possono essere esaminati su https://indietorrent.org.

Senza ulteriori indugi, configuriamo NGINX per implementare la PFS.

Passiamo nella directory di configurazione di NGINX:

cd /etc/nginx/

Dobbiamo generare parametri Diffie-Hellman che siano sufficientemente forti. Alcuni sostengono che 4096 bit sia eccessivo e causerà un onere eccessivo sulla CPU del sistema, ma con la potenza di calcolo moderna, questo sembra un compromesso valido. Per ulteriori informazioni, vedere la sezione Riferimenti, qui sotto.

openssl dhparam -out dh4096.pem 4096

È utile avere questo file di configurazione, specifico per il compito in questione, compartimentato in un file di inclusione; questo rende più semplice implementare la 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 sopra, inserendo la seguente riga nel file di configurazione principale di NGINX (di default, /etc/nginx/nginx.conf), in fondo (e all’interno) del blocco http {}:

# Vedi: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
# Questo DEVE venire DOPO le righe che includono .../sites-enabled/*, altrimenti il supporto SSLv3 potrebbe essere riattivato accidentalmente.
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 mostra Session resumption (caching) No (IDs assigned but not accepted) in rosso, e il server implementa SNI, aggiungi quanto segue al blocco http {} di livello superiore (cioè, aggiungi a nginx.conf, appena sotto dove abbiamo fatto le aggiunte precedenti):

# Vedi: 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 sopra non dovrebbe più segnalare questo problema (anche se il problema non riduce il punteggio complessivo del test).

Andare oltre: Implementazione dell’HTTP Strict Transport Security (HSTS) con lunga durata

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

1. Vuoi forzare SSL per tutte le risorse per qualsiasi host per il quale questo header è impostato (cioè, ogni pagina sul sito web in questione).
2. Puoi vivere senza la possibilità di accettare e ignorare gli avvisi SSL per qualsiasi risorsa richiesta da qualsiasi host per il quale questo header è impostato, come “Mismatch del nome di dominio”, ecc. La natura stessa dell’HSTS è che le condizioni di avviso e errore relative al certificato SSL non possono essere sovrascritte.

Ho setacciato Internet per informazioni riguardo se impostare questo header potesse avere conseguenze indesiderate nei browser che non supportano l’header e sono rimasto deluso. Ma, sono riuscito a placare le mie preoccupazioni testando questa implementazione in Internet Explorer 6, ad esempio, e i browser in cui l’HSTS non è implementato semplicemente ignorano l’header. 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";
# Questo impedirà alcuni attacchi di click-jacking, ma impedirà
# ad altri siti di incorniciare il tuo sito, quindi elimina o modifica come necessario!
add_header X-Frame-Options SAMEORIGIN;

Un ricaricamento (anziché un riavvio) sarà sufficiente per costringere NGINX a prendere queste modifiche particolari:

service nginx reload

È possibile confermare che l’HSTS sta funzionando come previsto testando la tua implementazione su https://www.ssllabs.com/ssltest/analyze.html. Se l’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 hai 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

Copyright © 2014 Ben Johnson