Bonjour à tous,
Aujourd’hui je vous propose de déblayer un peu le sujet de la configuration HTTPS (HyperText Transfer Protocol Secure) au niveau d’un serveur web. Comme me le faisait remarquer xhark, l’auteur du blog http://blogmotion.fr, il y a beaucoup de publications sur le sujet, souvent tout n’est pas très clair, je vais donc faire le maximum pour l’être.
Autre problème, on rencontre des configurations obsolètes, ce qui sera peut être le cas de cet article dans 10 jours, 1 mois, 1 an. Vous l’aurez compris, dans le domaine les changements vont vites.
Je donne des conseils par rapport à mes observations et ne serait être tenu responsable en cas de problème sur vos serveurs pour quel problème que cela soit.
Avant toute chose, les applications telles que le serveur web et openSSL doivent être mis à jour, des failles sont décelées et corrigées régulièrement. Il vous faudra un certificat x509 (souvent appelé inexactement certificat SSL). Cet élément et la clé privée associée sont indispensables à la configuration de votre serveur. Pour plus d’informations je vous renvoie vers mes précédents articles :
L’objectif affiché est d’obtenir une configuration optimum qui fonctionnera avec un maximum de navigateurs, systèmes d’exploitations et un niveau de sécurité élevé. Mon but, obtenir une note « A » voir « A+ » sur le test de SSLLabs.
Personnellement j’utilise nginX comme serveur web car je le trouve léger et performant mais l’ensemble de ce que je vais vous indiquer se fait sur d’autres serveurs type Apache, lighttpd ou même IIS (dire « 2IS »). Le tout n’est pas de copier/coller une configuration mais de comprendre ce qu’elle apporte et de savoir si c’est pertinent dans le cadre de mon utilisation.
Temps de configuration : entre 10 et 20 minutes
-
Désactiver les protocoles SSLv2 et SSLv3
Ces protocoles (SSL : Secure Sockets Layer) sont maintenant obsolètes et vulnérables à de nombreuses failles, donc on désactive tout ça et laisse activer la relève, TLSv1, TLSv1.1 et TLSv1.2 (TLS : Transport Layer Security). Je vous donne les lignes de configuration au fur et à mesure.
Conséquence : Les Windows XP avec IE6 ne pourront pas se connecter car IE6 ne sait pas faire de TLSv1.
Sous nginX :
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Sous Apache :
SSLProtocol All -SSLv2 -SSLv3
-
Mise en place du Perfect Forward Secrecy (confidentialité persistante)
Lors de la connexion du client au serveur, ce dernier va renvoyer les suites ciphers (les algorithmes de chiffrement) avec lesquelles il sait travailler. On indique avec la première ligne de configuration qu’il y a un ordre, du plus fort au moins fort, à la fin ce que l’on ne veut pas utiliser est précédé d’un « ! ». Ensuite le client et le serveur se mettent d’accord sur l’algorithme et font divers échanges avant que la communication soit sécurisée.
Le Forward Secrecy est la capacité de rendre secret dans le temps la communication par un mécanisme d’échange de secret partagé Diffie-Hellman, même si la clé privée du serveur est compromise plus tard. Le Perfect Forward Secrecy est l’utilisation de l’échange Diffie-Hellman éphémère (EDH ou DHE dans les ciphers).
Conséquence : Ne fonctionne pas sous XP et IE6/IE8, Java 6/7
Sous nginX :
ssl_prefer_server_ciphers on;
ssl_ciphers « EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH »;
Sous Apache :
SSLHonorCipherOrder On
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
L’excellent site Cipherli.st référence pour de nombreuses applications le paramétrage à effectuer pour obtenir une configuration convenable. Par défaut il propose cette petite suite de ciphers mais une configuration plus large pour un fonctionnement avec un maximum d’environnements est disponible.
-
Générer de nouveaux paramètres Diffie-Hellman
Pas de chance, sur le papier l’échange de clé semblait optimum mais dans la réalité une attaque appelée « logjam » permettait de connaitre les paramètres que le serveur échangerait et donc la communication n’était plus sûr. La solution à ce problème est simple, générer de nouveaux paramètres avec la commande openSSL puis indiquer au serveur de prendre en compte ces derniers.
La longueur de clé recommandée aujourd’hui est de 2048 bit ou plus. Sachant qu’un certificat est valide plusieurs années en générale, il semble bon de partir directement sur « plus ». Les paramètres DH doivent être de la longueur de votre clé privée.
On se place dans le dossier qui contient les certificats du serveur et on exécute la commande suivante :
openssl dhparam -out dhparams.pem 4096
L’outil répond :
Generating DH parameters, 4096 bit long safe prime, generator 2
This is going to take a long time
A titre d’exemple, sur un Core 2 Duo 2,26 GHz, comptez plus de 35 minutes montre en main.
Sous nginX :
ssl_dhparam /path/to/dhparam.pem;
Sous Apache :
SSLDHParametersFile /path/to/dhparam.pem
-
Gestion des sessions SSL
Autre point intéressant, la façon dont est géré le pool de sessions SSL avec le serveur ou ses processus. La première instruction indique un cache des sessions partagées avec ses processus et 10 Mb ce qui selon la documentation nginX permet de gérer 10 x 4 000 sessions.
Le timeout est la période pendant laquelle le client peut réutiliser sa session sans faire une nouvelle négociation. Par défaut, selon la documentation toujours, le délai est de 5 minutes.
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
Concernant Apache il semble conseillé de désactiver :
SSLSessionTickets Off
-
Activer le HSTS
Le HSTS (HTTP Strict Transport Security) est une information ajoutée par le serveur dans les en-têtes renvoyées au client afin de lui indiquer qu’il sait faire du HTTPS. Une notion de durée (en secondes) est ajoutée (ici 2 ans) ce qui permet au client (le navigateur) de revenir directement en HTTPS la fois suivante, de même pour les sous-domaines.
Au passage on ajoute l’en-tête « X-Frame-Options » qui permet d’éviter les vols de cookie de session.
Sous nginX :
add_header Strict-Transport-Security « max-age=63072000; includeSubdomains; preload »;
add_header X-Frame-Options « DENY »;
Sous Apache :
Header always set Strict-Transport-Security « max-age=63072000; includeSubdomains; preload »
Header always set X-Frame-Options DENY
-
Conclusion
Nous sommes arrivés au bout (pour ceux qui ont résisté) de cette configuration. J’espère avoir été synthétique et clair.
Il ne me reste plus qu’à vous inviter à tester votre site sur SSLLabs afin de savoir si la note obtenue vous convient. N’hésitez pas à me laisser vos commentaires pour faire évoluer ce billet.
Un dernier site pour tester d’autres services comme l’IMAP (niveau SSL) ou autre : SSLDecoder
Stay tuned !
EDIT : MAJ des suites ciphers (16/08/2015)
Chargeur EU + le One
