Améliorer la sécurité SSL de votre site avec NGINX

Sécurité 30 avr. 2020

La page d'accueil de votre site est le premier contact entre votre entreprise et vos prospects. Elle se doit d'être irréprochable et agréable aux yeux de vos clients mais pas que ! Dans ce tutoriel, on vous montre comment renforcer la sécurité SSL de votre site avec NGINX. L'outil utilisé pour les tests est proposé gratuitement par Qualys sur la page de SSL Labs. Voici la note "A+" de notre site (début 2020) :

Résultat du test SSL Labs pour etineo.com

Pour ce tutoriel, il faudra éditer les fichiers de configuration de votre site NGINX ici /etc/nginx/sites-enabled/votresite.conf (Debian/Ubuntu). Pensez à faire une sauvegarde avant toute modification !

Toutes les modifications suivantes sont à réaliser au sein du bloc "server" pour chaque site web SSL hébergé sur votre serveur. Nous nous sommes concentrés sur les changements essentiels pour la sécurité de votre site.

La configuration de référence suivante est proposée (avant modification) :

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;

	server_name yoursite.com www.yoursite.com;
	root /var/www/yousite.com/;

	ssl_certificate /etc/letsencrypt/live/yoursite.com/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/yoursite.com/privkey.pem;
	include /etc/letsencrypt/options-ssl-nginx.conf;
	ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

	location /public/ {
		try_files $uri $uri/ =404;
	}

	location / {
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Host $http_host;
		proxy_set_header X-NginX-Proxy true;
		proxy_pass "http://127.0.0.1:3000";
	}
}
server {
	if ($host = www.yoursite.com) {
		return 301 https://$host$request_uri;
	}

	if ($host = yoursite.com) {
		return 301 https://$host$request_uri;
	}

	listen 80;
	server_name yoursite.com www.yoursite.com;
	return 404;
}

Nous vous conseillons de créer un fichier de configuration SSL global pour tous vos sites. Par exemple /etc/nginx/conf.d/ssl-params.conf. Il vous suffit ensuite d'ajouter la ligne suivante dans la configuration de votre site include /etc/nginx/conf.d/ssl-params.conf;

Si vous utilisez LetEncrypt pour vos certificats SSL, l'inclusion suivante est normalement présente dans la configuration de votre site include /etc/letsencrypt/options-ssl-nginx.conf;. Remplacez-la par celle indiquée ci-dessus.

Déclarer l'entrée DNS CAA

L'entrée DNS CAA (Certification Authority Authorization) permet de définir l'autorité de confiance en charge de signer les certificats de votre site web. En effet, plusieurs fois par le passé, des autorités de certification reconnues mondialement ont été volées par des pirates. Ces derniers pouvaient ainsi générer des certificats valides et tromper l'utilisateur néophyte de manière totalement transparente. Avec cette nouvelle RFC 6844 effective depuis 2017, vous pouvez indiquer les autorités de certifications autorisées à délivrer les certificats pour votre domaine (le navigateur web pourra ainsi contrôler qu'il n'y a pas anguille sous roche !).

Plus d'informations ici.

Voici la manipulation à réaliser chez OVH si vous utilisez LetEncrypt.

Dans la section "Web > Domaines > votresite.com".

Cliquez sur "Ajouter une entrée" et sélectionnez "CAA".

L'entrée DNS créée ressemblera à ceci yoursite.com. CAA 128 issue "letsencrypt.org".

Si l'opération est bien réalisée, votre test SSL Labs affichera l'information DNS CAA : Yes comme indiqué dans l'exemple ci-dessous.

Protocoles SSL

Tous les protocoles inférieurs à la version TLS 1.2 sont considérés comme non sécurisés. On va donc autoriser uniquement TLS 1.2 et TLS 1.3 (dernière version au moment de la rédaction de cet article).

Mettre à jour le fichier /etc/nginx/conf.d/ssl-params.conf et ajouter la ligne suivante :

ssl_protocols TLSv1.2 TLSv1.3;

Si votre version de NGINX est inférieure à la version 1.13.0, il faudra supprimer "TLSv1.3" qui ne sera pas supporté.

TLS 1.2 et TLS 1.3 uniquement (SSL Labs)

Les algorithmes de chiffrement / signature

Mettez à jour le fichier /etc/nginx/conf.d/ssl-params.conf et ajoutez la ligne suivante :

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;

Il s'agit ici des algorithmes recommandés par Mozilla (si vous ne souhaitez pas supporter des vieilleries comme IE6 ou Windows XP).
Plus d'informations ici.

Algorithmes supportés par etineo.com (SSL Labs)

OCSP Stapling

Pour ne pas faire trop long :

Les fichiers CRL (Certificate Revocation List) peuvent atteindre des tailles importantes et sont téléchargés entièrement par les clients (navigateur) avant d'autoriser la communication avec votre site.
Les répondeurs OCSP sont la nouvelle approche pour vérifier l'état de révocation d'un certificat en temps réel. La communication est limitée au numéro de série du certificat à controler. Le problème c'est que le répondeur OSCP peut ne pas fonctionner où mettre du temps à répondre...

La solution optimale est de permettre à votre serveur de donner aux clients une version mise en cache de son état de révocation. Cette dernière est proposée aux navigateurs (charge à eux de l'utiliser pour améliorer les performances et la sécurité).

Si votre serveur envoie l'ensemble de la chaîne de certification utilisée pour la signature de son certificat aux navigateurs, il vous suffit d'ajouter au fichier /etc/nginx/conf.d/ssl-params.conf les lignes suivantes :

ssl_stapling on;

ssl_stapling_verify on;

resolver 8.8.8.8 8.8.4.4 valid=300s;

resolver_timeout 5s;

Dans le cas contraire, il vous faudra référencer (en plus des lignes précédentes) la chaîne de confiance de votre autorité signataire avec la ligne suivante (récupérer "votresite.chain.pem" auprès de votre fournisseur de certificat):

ssl_trusted_certificate /etc/ssl/certs/votresite.chain.pem;

HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) permet à votre site d'annoncer au navigateur de vos clients que les communications doivent se faire uniquement en HTTPS (au lieu d'HTTP). Ceci permet d'éviter une tentative d'interception par "downgrade SSL" et donc à votre trafic d'être écouté par un tiers.

Mettez à jour le fichier /etc/nginx/conf.d/ssl-params.conf et ajoutez les lignes suivantes :

add_header Strict-Transport-Security "max-age=63072000" always;

add_header X-Frame-Options SAMEORIGIN;

add_header X-Content-Type-Options nosniff;