Recherche de site Web

Implémentation de SSL Perfect Forward Secrecy dans le serveur Web NGINX

Ce HOW-TO décrit le processus d'implémentation de Perfect Forward Secrecy 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, Perfect Forward Secrecy garantit : "... que la compromission d'un message ne peut pas conduire à la compromission d'autres messages, et également qu'il n'existe pas une seule valeur secrète pouvant conduire à la compromission de plusieurs messages." Pour plus d'informations, consultez http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy.

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

Si vous souhaitez comparer vos résultats avec les miens, mon implémentation de référence peut être testée sur https://www.ssllabs.com/ssltest/analyze.html?d=indietorrent.org, ainsi que la chaîne de certificats SSL et les en-têtes NGINX envoyés. peut être consulté sur https://indietorrent.org.

Sans plus tarder, configurons NGINX pour implémenter PFS.

Passons au répertoire de configuration de NGINX :

cd /etc/nginx/

Nous devons générer des paramètres Diffie-Hellman suffisamment forts. Certains soutiennent que 4 096 bits est excessif et entraînera une charge excessive sur le processeur du système, mais avec la puissance de calcul moderne, cela semble être un compromis valable. Pour plus d’informations, consultez la section Références ci-dessous.

openssl dhparam -out dh4096.pem 4096

Il est pratique d'avoir ce fichier de configuration, spécifique à la tâche à accomplir, compartimenté dans un fichier d'inclusion ; cela simplifie la mise en œuvre de 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 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 (et dans) le Bloc http {} :

# 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;

Redémarrez NGINX pour que les modifications soient effectives :

service nginx restart

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

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

Encore une fois, redémarrez NGINX pour que les modifications soient 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 la note globale du test).

Pour aller plus loin : implémentation de la sécurité de transport HTTP Strict (HSTS) avec une longue durée

C’est une tâche facile et qui en vaut la peine, à condition que :

  1. Vous souhaitez forcer SSL pour toutes les ressources de 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 vivre sans avoir la possibilité d'accepter et d'ignorer les avertissements SSL pour toute ressource demandée à partir de tout hôte pour lequel cet en-tête est défini, tels que "Incompatibilité de nom de domaine", etc. La nature même de HSTS est que les conditions d'avertissement et d'erreur liées au certificat SSL ne peut pas être annulé.

J'ai parcouru Internet pour savoir si la définition de cet en-tête pourrait avoir des conséquences inattendues dans les navigateurs qui ne prennent pas en charge l'en-tête et j'ai échoué. Mais j'ai pu apaiser mes inquiétudes en testant cette implémentation 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";
# 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 rechargement (au lieu d'un redémarrage) suffira pour forcer NGINX à reprendre ces modifications particulières :

service nginx reload

Il est possible de confirmer que HSTS fonctionne comme prévu en testant votre implémentation sur https://www.ssllabs.com/ssltest/analyze.html. Si HSTS est correctement implémenté, vous devriez voir une case verte juste en dessous de votre score, indiquant : "Ce serveur prend en charge HTTP Strict Transport Security avec une longue durée. Note définie sur A+."

Toutes nos félicitations!

Vous disposez désormais de l’une des implémentations SSL/TLS les plus sécurisées sur Internet.

Les références:

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

Copyright © 2014 Ben Johnson

Articles connexes: