Résumé pour gens très pressés : ce n’est pas si difficile que cela en a l’air.

Résumé pour gens pressés : même sans être un gourou de la cryptographie, il est possible de sécuriser son site au niveau approximatif de l’état de l’art (du moment — ce n’est jamais une tâche définitive) en s’appuyant sur des sites de recommandations réalisés par des spécialistes.

Après avoir passé quelques heures à peaufiner ma configuration, je pense utile de partager ce que j’ai appris pour dispenser autour de moi un peu de bonheur artificiel par l’entremise de la sécurité cryptographique.

L. Hirlimann (@lhirlimann) m’a récemment orienté sur un excellent site de la fondation Mozilla, observatory.mozilla.org,  qui permet de vérifier la configuration sécurité basique de votre site web, à commencer par l’aujourd’hui indispensable TLS, et mutualise également (par défaut, mais c’est débrayable) les résultats des non moins excellents :

• SSL Labs
• tls.imirhil.fr de @Aeris22
• securityheaders.io
• hstspreload.appspot.com

1. TLS, les algorithmes cryptographiques

Au-delà de ses origines mathématiques, la cryptographie est une affaire de paranoïaques qui n’ont pas tous exactement le même avis sur ce qui est casher ou pas à un instant donné.  Les audits rapides réalisés par les sites qui précèdent vous en convaincront rapidement.

Ainsi, après quelques premières modifications rapides sur ma configuration TLS, SSL Labs attribuait un A+ à ce site, alors que tls.imirhil.fr l’affublait d’un catastrophique F sous prétexte que l’algorithme DES n’était pas désactivé.

Bien entendu, cela évolue aussi au fil du temps, qui fait qu’un algorithme donné va passer en quelques petites décennies à peine du statut de “sûr” à celui de “passoire”, que ce soit par l’évolution des performances brutes ou par celles de la recherche en attaques cryptographiques.

Par ailleurs, vous aurez éventuellement également le plaisir de vous faire rappeler à l’ordre par ces analyses si votre implémentation TLS comporte des trous de sécurité connus. J’ai découvert qu’il est assez facile de se faire avoir, même avec un système d’exploitation que l’on pensait à jour.

Les “suites” cryptographiques recommandées varient au fil des sites spécialistes que l’on consulte.

Voici, pour ne pas vous faire languir, celle que j’ai concoctée pour satisfaire les sites cités (!) ci-dessus, et qui est certainement sujette à commentaires et critiques (attention, c’est supposé tenir sur une ligne sans retour) :

EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA
-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-S
HA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:
ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-
SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-
SHA256:AES256-SHA:AES128-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4

N’allez surtout pas croire que j’ai construit ni même analysé en détail ce qui précède : la liste provient à l’origine de https://www.digicert.com/ssl-support/ssl-enabling-perfect-forward-secrecy.htm dont l’objet est d’expliquer la configuration d’un serveur web pour éviter qu’un vol de clé privée permette le déchiffrement a posteriori des communications, une mesure à prendre suite aux révélations de l’affaire Snowden sur les capacités de la NSA, et suite également à l’affaire Lavabit.

J’ai simplement amendé la liste pour y ajouter !DES:!3DES: pour évacuer ce vieil algorithme des choix et passer chez tls.imirhil.fr d’un catastrophique F à un passable B.

Si comme moi vous utilisez Apache, cette liste est à placer dans la directive SSLCipherSuite.

Problème : l’incantation qui précède est difficile à comprendre, et donc à modifier, si on n’a pas lu la documentation. En particulier il ne suffit pas d’ajouter !DES pour se débarrasser également de 3DES. Ce n’est pas facile à découvrir rapidement en passant par les sites ci-dessus, qui pour éviter d’être surchargés ne permettent pas des accès trop fréquents (limite à 5 minutes au mieux).

J’ai donc découvert également l’excellente (tout le monde est excellent ici, vous l’aurez compris) commande :

openssl ciphers "la chaîne"

et son avatar plus bavard :

openssl ciphers -v "la chaîne"

qui permettent de tester la chaîne immédiatement en local pour voir ce qu’elle produit sans avoir à attendre la réponse d’un serveur situé à l’autre bout de la planète.

2. Sécurité “web” :  contenu et entêtes

Ce qui précède ne concerne que la partie TLS, c’est-à-dire la couche de chiffrement.

C’est ensuite que observatory.mozilla.org prend tout son sens, en complétant l’expertise cryptographique avec l’expertise web des auteurs de Firefox par le tableau suivant (exemple pour ce site au jour de la publication de ce billet) :Je ne vais pas entrer dans les détails ; chaque point correspond à des catégories particulières d’attaques plus ou moins pertinentes pour chaque site, et comme vous pouvez le voir je n’ai pas encore débloqué tous les trophées. On y trouve des recommandations sur :

• HSTS (Host Strict Transport Security), permettant au site de s’engager vis-à-vis du navigateur sur la disponibilité de https.
• Subresource Integrity, pour valider les contenus inclus (en particulier scripts) stockés sur des serveurs tiers ;
• X-Content-Type-Options, pour interdire au navigateur d’interpréter n’importe quoi (par exemple une supposée image téléchargée par un attaquant) comme un script ;
• X-Frame-Options, pour bloquer des attaques par détournement de clics (clickjacking) ;
• les redirections diverses afin d’amener l’utilisateur à un site https même dans le cas où il ne s’y est pas dirigé lui-même initialement ;
• etc

observatory.mozilla.org vous donne par les liens bleus (dont j’ai recopié certains ci-dessus) toutes les explications détaillées sur les possibilités et le sens de chaque option de configuration.

Sous Apache, cela se configure comme ci-dessous, à condition d’avoir chargé le module mod_headers.

Attention : les options pour mon site ne sont certainement pas exactement celles dont vous aurez besoin ; en particulier vous pouvez facilement vous tirer une petite balle dans le pied et vous retrouver avec Javascript désactivé sur certaines fonctions essentielles. Ce fut mon cas, ce qui m’a fait perdre temporairement l’éditeur Wysiwyg de WordPress, et le problème est encore potentiellement présent dans l’exemple qui suit.

Attention également aux sauts de ligne si vous recopiez.

  # HSTS 366 days
Header set Strict-Transport-Security "max-age=31622400"
# Prevent browsers from incorrectly detecting non-scripts as scripts
Header set X-Content-Type-Options: nosniff
# Block site from being framed
Header set X-Frame-Options "DENY"
# Do the same thing, but with Content Security Policy
# +Disable unsafe inline/eval, only allow loading of resources
# (images, fonts, scripts, etc.) over https (recommended)
Header set Content-Security-Policy "default-src https:; frame-ancestors 'none'"
# Block pages from loading when they detect reflected XSS attacks
Header set X-XSS-Protection "1; mode=block"

Ces recommandations permettent d’élucider le comportement souvent mystérieux des navigateurs en ce qui concerne le contenu sécurisé, dans le but de comprendre comment passer du cadenas https “avec avertissement” au cadenas “vert”.

Je n’ai pas encore tout à fait réussi en ce qui concerne la page https://signal.eu.org/osm/, malgré la mise en œuvre de Subresource Integrity.

3. Les cookies

Pour les cookies, c’est encore différent, cela dépend de l’environnement (framework) web que vous utilisez. Concernant WordPress je n’ai pas encore trouvé si/où cela se gérait, pour Django voici ce que j’ai configuré dans le fichiers settings.py :

LANGUAGE_COOKIE_AGE=1209600
CSRF_COOKIE_HTTPONLY=True
CSRF_COOKIE_SECURE=True
SESSION_COOKIE_AGE=1209600
SESSION_COOKIE_HTTPONLY=True
SESSION_COOKIE_SECURE=True

4. One more thing

Enfin, vous pouvez aussi pour tout cela vous faire assister par un autre site proposé par la fondation Mozilla, le générateur de configuration pour serveur web, qui vous conseillera sur la configuration de l’agrafage (stapling) OCSP et certains des points qui précèdent :

https://mozilla.github.io/server-side-tls/ssl-config-generator/

 

 

Nul doute qu’il y a des précisions ou corrections à apporter à ce qui précède, si vous le jugez utile n’hésitez pas ci-dessous.

Mise à jour : @_eric_quinton me signale gentiment sur twitter ce document de l’ANSSI :  Le nouveau (juillet 2016) “guide de recommandations de sécurité relatives à TLS”.  C’est très complet mais très technique, et cela mixe recommandations à destination des administrateurs de site comme à destination des développeurs de suites crypto, ce qui complique la lecture.