Mise en œuvre de la confidentialité parfaite des clés SSL dans le serveur Web NGINX

Ce GUIDE décrit le processus de mise en œuvre de la confidentialité parfaite des clés avec le serveur Web NGINX sur les systèmes Debian et Ubuntu. Le processus peut facilement être adapté à d’autres systèmes GNU/Linux.

En bref, la confidentialité parfaite des clés garantit : “… que la compromission d’un message ne peut pas conduire à la compromission d’autres, et aussi qu’il n’y a pas de valeur secrète unique qui peut conduire à la compromission de plusieurs messages.” Pour plus d’informations, voir http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy.

Lorsque la vulnérabilité Heartbleed dans OpenSSL a été révélée au début de 2014, il est devenu de plus en plus clair que la PFS est indispensable pour tout système qui utilise SSL/TLS de manière sérieuse.

Si vous souhaitez comparer vos résultats aux miens, ma mise en œuvre de référence peut être testée à https://www.ssllabs.com/ssltest/analyze.html?d=indietorrent.org, et la chaîne de certificats SSL et les en-têtes NGINX qui sont envoyés peuvent être examinés à https://indietorrent.org.

Sans plus tarder, configurons NGINX pour mettre en œuvre la PFS.

Déplaçons-nous dans le répertoire de configuration de NGINX :

cd /etc/nginx/

Nous devons générer des paramètres Diffie-Hellman qui sont suffisamment forts. Certains soutiennent que 4096 bits est excessif et causera une charge indue sur le CPU du système, mais avec la puissance de calcul moderne, cela semble être un compromis valable. Pour plus d’informations, voir la section Références, ci-dessous.

openssl dhparam -out dh4096.pem 4096

Il est pratique d’avoir ce fichier de configuration, qui est spécifique à la tâche à accomplir, compartimenté dans un fichier d’inclusion ; cela rend plus simple la mise en œuvre de la PFS sur un grand nombre de systèmes.

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

Collez ce qui suit dans le fichier ci-dessus :

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;

Modifiez la configuration de NGINX pour inclure le fichier ci-dessus, en insérant la ligne suivante dans le fichier de configuration principal de NGINX (par défaut, /etc/nginx/nginx.conf), au bas de (et à l’intérieur de) le bloc http {} :

# Voir : https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
# Cela DOIT venir APRÈS les lignes qui incluent .../sites-enabled/*, sinon le support SSLv3 peut être réactivé accidentellement.
include perfect-forward-secrecy.conf;

Redémarrez NGINX pour rendre les modifications effectives :

service nginx restart

Si le test à https://www.ssllabs.com/ssltest/analyze.html affiche la reprise de session (mise en cache) Non (IDs attribués mais non acceptés) en rouge, et que le serveur implémente SNI, ajoutez ce qui suit au bloc http {} de niveau supérieur (c’est-à-dire, ajoutez à nginx.conf, juste en dessous de l’endroit où nous avons fait les ajouts précédents) :

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

Encore une fois, redémarrez NGINX pour rendre les modifications effectives :

service nginx restart

Le test ci-dessus ne devrait plus signaler ce problème (même si le problème ne réduit pas le score global du test).

Aller plus loin : Mise en œuvre de la sécurité stricte du transport HTTP (HSTS) avec une longue durée

C’est facile, et cela vaut vraiment la peine de le faire, à condition que :

1. Vous souhaitez forcer SSL pour toutes les ressources pour tout hôte pour lequel cet en-tête est défini (c’est-à-dire, chaque page du site Web en question).
2. Vous pouvez vous passer de la capacité d’accepter et d’ignorer les avertissements SSL pour toute ressource demandée depuis tout hôte pour lequel cet en-tête est défini, tel que “Incompatibilité de nom de domaine”, etc. La nature même de HSTS est que les conditions d’avertissement et d’erreur relatives au certificat SSL ne peuvent pas être contournées.

J’ai fouillé Internet à la recherche d’informations concernant la possibilité que la définition de cet en-tête puisse avoir des conséquences inattendues dans les navigateurs qui ne prennent pas en charge l’en-tête et je n’ai pas trouvé de réponse. Mais, j’ai pu apaiser mes inquiétudes en testant cette mise en œuvre dans Internet Explorer 6, par exemple, et les navigateurs dans lesquels HSTS n’est pas implémenté ignorent simplement l’en-tête. Parfait !

Ajoutez simplement les lignes suivantes au bas de /etc/nginx/perfect-forward-secrecy.conf et enregistrez les modifications :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# Cela empêchera certaines attaques de click-jacking, mais empêchera
# d'autres sites de mettre votre site en cadre, donc supprimez ou modifiez si nécessaire !
add_header X-Frame-Options SAMEORIGIN;

Un rechargement (au lieu d’un redémarrage) suffira pour forcer NGINX à prendre en compte ces modifications particulières :

service nginx reload

Il est possible de confirmer que HSTS fonctionne comme prévu en testant votre mise en œuvre à https://www.ssllabs.com/ssltest/analyze.html. Si HSTS est correctement implémenté, vous devriez voir une boîte verte juste en dessous de votre score, indiquant : “Ce serveur prend en charge la sécurité stricte du transport HTTP avec une longue durée. Note définie à A+.”

Félicitations !

Vous avez maintenant l’une des mises en œuvre SSL/TLS les plus sécurisées sur Internet.

Références :

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

Droits d’auteur © 2014 Ben Johnson