Sécurité des serveurs web avec TLS, petite toilette d’automne 2016

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 :

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) :mozJe 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” c0 au cadenas “vert”c1.

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) 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.

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1Nb4aJWgAUAqMUCzeF2vTTDUNVNTM5ak42

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

4 thoughts on “Sécurité des serveurs web avec TLS, petite toilette d’automne 2016”

  1. Il faut peut-être préciser l’effet de la suppression des suites cryptographiques basées sur le chiffrement 3DES : toutes les versions d’IE qui fonctionnent sur Windows XP ne pourront plus se connecter à un tel serveur HTTPS. Car TLS_RSA_WITH_3DES_EDE_CBC_SHA était la dernière suite encore vaguement potable : https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8&platform=XP&key=20
    Maintenant comme l’indique l’ANSSI http://www.ssi.gouv.fr/uploads/2016/09/guide_tls_v1.1.pdf il est possible de mettre en place des contremesures au niveau serveur (en forçant une renégociation de clé après un certain volume de données échangées ou temps écoulé) pour rentre une attaque SWEET32 impraticable.
    Maintenant si un site est par ailleurs uniquement prévu pour IE 9 ou plus récent alors oui autant retirer 3DES, seul défaut les utilisateurs d’IE sur XP ne comprendront probablement jamais pourquoi le site n’est pas accessible si cela est fait sans prévenir ; après faut-il encore ménager les derniers utilisateurs d’un des OS les plus dangereux du net et que Microsoft a abandonné depuis 18 mois ?

    1. Frédéric, merci pour les précisions !

      Effectivement je pense quand même que pour un site Internet généraliste on peut abandonner l’IE d’origine de XP à son triste sort, et plus généralement suivre les choix de Google qui a fini par laisser tomber IE6.

      Mais après, les circonstances locales peuvent varier… sur un intranet isolé du monde, pourquoi pas.

  2. Toujours aussi user firendly le TLS ;)…de la daube en paquet de 10…avec des autorités de confiance qui magouillent !

Comments are closed.