Checklist HTTPS
Depuis les révélations de Snowden, Heartbleed en 2014 et l’actualité en général… la cryptographie et en particulier les protocoles SSL/TLS connaissent à juste raison une généralisation quelque soit le site web, service, application, etc.
Dans cet article, je vais présenter une check-list des bonnes pratiques lorsque l’on administre un serveur web sécurisé.
Je ne détaillerai pas toutes les différentes techniques mises en oeuvre : d’innombrables sites ou blogs le font très bien. Je vais en revanche lister les point importants pour rendre le protocole TLS particulièrement robuste. Ceci avec des exemples de configuration pour le serveur HTTP NGINX.
1. Maintenir à jour la librairie TLS
On ne le répétera jamais assez : la librairie TLS (par exemple OpenSSL ou mieux, LibreSSL) doit absolument être maintenue à jour, en particulier après chaque correctif de sécurité.
Bien évidemment, cela s’applique également au serveur HTTP et tout le système d’exploitation en général.
2. Désactiver SSL
Aujourd’hui il est plus que recommandé de désactiver totalement SSL (jusqu’à la v3). En particulier pour bénéficier de la confidentialité persistante (PFS). Ainsi, votre serveur web ne devrait répondre qu’aux protocoles TLS (1.0 et supérieur).
Ceci aura pour effet de casser la compatibilité avec les navigateurs anciens. Notamment Internet Explorer 6 sous Windows XP qui ne supporte pas TLS par défaut (il peut être paramétré pour supporter TLS 1.0, avec quelques algorithmes de faible robustesse, qui doivent absolument être bannis de nos jours). Est-ce réellement un problème ?
NGINX : ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
3. Suites de chiffrement fortes
Votre serveur web doit être paramétré pour fonctionner avec des suites de chiffrement robustes. Il faut donc, dans la configuration du serveur web prohiber : RC4, MD5, DES, EXPORT (suites de chiffrement anciennes, autorisées à être exportées des USA).
De la même façon que la désactivation de SSL, ce point cassera la compatibilité avec les navigateurs anciens.
NGINX :
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
4. Générer ses propres paramètres DH
Avec l’utilisation de PFS et des certificats de 2048 bits, ceci permet de rendre plus robuste les échanges de clés Diffie Hellman, qui utiliseraient sinon les clés par défaut d’OpenSSL d’une taille de 1024 bits.
NGINX : ssl_dhparam /etc/ssl/certs/dhparam.pem;
5. OCSP Stapling
OCSP souffre de deux problèmes :
- C’est au client de valider le certificat du serveur en contactant l’Autorité de Certification (AC) lui-même à chaque connexion. Ceci est très coûteux en performance.
- Si l’AC ne répond pas : soit on accepte tout de même le certificat du serveur avec un gros risque en terme de sécurité, soit on refuse la connexion ce qui est très pénalisant pour l’utilisateur.
L’OCSP Stapling permet de rendre plus efficient la validation des certificats, puisqu’il délègue cette tâche au serveur lui-même, qui renvoie au client le certificat accompagné de sa validation signée par l’AC. Cette extension de TLS inclut un mécanisme de cache pour améliorer les performances et ne pas trop solliciter l’AC.
NGINX :
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/startssl_ca.pem;
resolver 127.0.0.1 valid=300s;
resolver_timeout 5s;
6. HTTP Strict Transport Security
Le mécanisme HSTS permet au serveur web d’inclure une en-tête HTTP signalant au navigateur que durant une période donnée (6 mois minimum recommandé), il ne doit communiquer avec le serveur que de façon sécurisée.
NGINX : add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
7. HTTP Public Key Pinning
L’extension HPKP permet au serveur web d’inclure une entête HTTP contenant un condensat du ou des certificats autorisés à établir la session TLS.
Le serveur web fournit donc une liste blanche de certificats autorisés à chiffrer une communication avec un site web.
Ceci permet d’être certain que le certificat que l’on utilise pour chiffrer la communication est bien celui autorisé par le propriétaire du site : et donc bloquer les attaques MiTM sur lesquelles reposent notamment les solutions de déchiffrement SSL du marché, très utilisées en entreprise ou par les Etats.
NGINX : add_header Public-Key-Pins 'pin-sha256="XXX_le_condensat_apparait_ici_XXX"; max-age=2592000; includeSubDomains';
Attention, ce mécanisme nécessite des précautions lors du renouvellement des certificats. Je vous conseille de bien étudier HPKP avant de le mettre en place.
8. Conclusion
Ces mécanismes de sécurité autour de TLS sont applicables sur d’autres serveurs web (Apache ou Lighttpd).
Pour mes configuration, je me suis fortement inspiré de cet article, plus complet et renvoyant vers beaucoup de liens très intéressants. Je vous en conseille la lecture.
Enfin, l’éditeur Qualys fournit un outil très pratique permettant de tester la robustesse d’un service HTTPS. Je vous conseille de l’utiliser pour valider votre configuration.
Voici mon résultat :
