Blog GlobalSign

04 mai 2017

Qu’est-ce que le HSTS et comment le met-on en œuvre ?

Imaginez, si vous le voulez bien, que vous êtes en train de dîner dans votre restaurant préféré ou que vous rentrez à votre hôtel après une journée de conférence, dans l’intention d’utiliser le wifi gratuit de votre chambre d’hôtel. Avez-vous remarqué que les mots de passe Wifi des hôtels et restaurants étaient toujours imprimés sur papier... mais jamais changés ?

Il se trouve qu’un pirate informatique a réservé une chambre dans le même hôtel. Il espionne toutes les connexions qui transitent sur le réseau sans fil non sécurisé.

Dans sa panoplie du parfait hacker, notre pirate utilise ce que l’on appelle un « renifleur de paquets » ou packet sniffer. Cet utilitaire réseau analyse le flux de données qui transite par le réseau visé et peut y injecter des tâches.

Notre hacker pourrait donc capturer votre trafic réseau HTTP vers n’importe quel site Web qui s’appuierait uniquement sur des redirections 301 pour basculer du HTTP en HTTPS. La méthode offre au hacker une fenêtre d'opportunité pour détourner le trafic chiffré en SSL et s’emparer de vos précieuses données pour, pire encore, afficher une fausse page de portail de connexion.

Mieux vaut donc privilégier le HSTS (HTTP Strict Transport Security) par rapport au HTTPS simple pour votre site. Car vous procurer uniquement un certificat SSL ne suffira jamais.

Qu’est-ce que le HSTS ?

Le HTTP Strict Transport Security (HSTS) est une instruction (« directive ») donnée par un serveur Web aux agents utilisateurs et navigateurs Web sur la manière dont ils doivent interagir avec lui — directive communiquée au travers d’un en-tête de réponse envoyé au tout début, puis renvoyé au navigateur.

C’est ainsi qu’est paramétré le champ qui définit la politique Strict-Transport-Security. La règle force les connexions HTTPS avec chiffrement, sans tenir compte des appels de scripts pour charger des ressources en HTTP dans ce domaine. Le HSTS n’est qu'une des composantes des paramètres de sécurité de votre serveur ou service d’hébergement Web.

Pourquoi implémenter le HSTS dans votre entreprise ?

Il ne vous viendrait pas à l’idée de fermer votre boutique ou votre maison le soir sans verrouiller les portes, n’est-ce pas ? Dans certains magasins, vous pouvez même avoir des détecteurs de métaux aux portes pour contrôler les vols et les pertes. Les données peuvent être aussi précieuses que des produits en magasin ou des bijoux ou du matériel high-tech chez vous ; elles doivent donc être conservées en sécurité et sous clé. Parfois, il ne suffit pas de sécuriser votre site Web à l’aide d’un cadenas ; certaines personnes trouveront quand même le moyen d'y accéder en http://. Le HSTS force les navigateurs et les applications à utiliser — si cela est possible — le HTTPS pour se connecter. Même lorsque l’internaute tape uniquement « www » ou « http:// ».

Le HTTPS est un facteur de référencement utilisé par Google. C’est l’un des critères de « qualité d’un site », avec d’autres facteurs comme la vitesse de chargement d’une page et l’adaptabilité de votre site au format mobile (conception responsive).

Mais il ne suffit pas de configurer des redirections 301 pour sécuriser entièrement votre nom de domaine en basculant du http:// au https://. Le manque de sécurité de la redirection HTTP laisse la porte ouverte à nos hackers.

$ curl --head http://www.facebook.com HTTP/1.1 301 Moved Permanently Location: https://www.facebook.com/

Le(s) hacker(s) peuvent toujours intercepter les cookies de sites, l’identifiant de session (généralement envoyé sous la forme d'un paramètre d’URL) ou forcer une redirection vers un faux site (phishing) présentant un aspect identique au vôtre. Aie?!

En revanche, l’installation d’un en-tête Strict-Transport-Security complique considérablement la tâche des Méchants pour subtiliser des informations ! Même votre planning de yoga sera à l’abri !

$ curl --head https://www.facebook.com HTTP/1.1 200 OK Strict-Transport-Security: max-age=15552000; preload

Le HSTS est-il vraiment répandu ?

La richissime entreprise Google a officiellement mis en place une politique de sécurité HSTS le 29 juillet 2016.

Les premières versions du projet HSTS remontent à 2009. La note de service du Directeur des systèmes d'information, Tony Scott date du 8 juin 2015, même si l’on note une intensification des démarches en faveur du HSTS dès le début 2015.

Facebook, Google, Gmail, Twitter et PayPal ne sont que quelques-uns des grands réseaux sociaux et portails de paiement à déployer une politique de sécurité HSTS aujourd’hui. Aux États-Unis, même le bureau du président a publié une note imposant l’obligation d'instaurer des connexions sécurisées entre les sites et services Web au niveau fédéral (Memorandum M-15-13- Policy to Require Secure Connections across Federal Websites and Web Services. Alors que les premières versions du projet HSTS remontent à 2009.

Mode d’emploi du HSTS pour votre site Web

Si votre structure de contenus utilise des sous-domaines, il vous faudra un certificat Wildcard pour pouvoir utiliser UNIQUEMENT du HTTPS. Si ce n’est pas le cas, vous serez en sécurité avec un certificat SSL de validation de domaine (DV), à validation d'organisation (OV) ou à validation étendue (EV). Vérifiez que vos certificats sont correctement installés et fonctionnent bien.

Les étapes initiales présentées ci-après permettent de tester vos applications Web, la connexion utilisateur et la gestion de session. Faites expirer le HSTS toutes les 5 minutes. Continuez à le tester pendant une semaine et un mois. Résolvez les problèmes qui pourraient survenir lors de votre déploiement. Modifiez le paramètre « max-age=xxx ». Une semaine = 604800 ; un mois = 2592000. Ajoutez le preload une fois les tests terminés.

Si vous trouvez que le HSTS fonctionne bien avec vos applications Web, modifiez « max-age » sur 63072000. Cela correspond à une durée de 2 ans — ce qu’exige le projet « Chromium » dans votre demande d’inscription sur la liste prédéfinie de sites dont la connexion doit se faire en HSTS !

Exigences permanentes du HSTS

  • Votre site Web doit avoir un certificat SSL valide. Vous pouvez vérifier la validité de votre certificat SSL avec le SSL Checker de GlobalSign.
  • Redirigez TOUS les liens HTTP vers HTTPS avec une redirection 301 (ou redirection permanente).
  • Votre certificat SSL doit couvrir tous les sous-domaines. Pensez à commander un certificat Wildcard.
  • Envoyez un en-tête HSTS sur le domaine de base pour les requêtes HTTPS.
  • La paramètre « Max-age » doit être défini sur au moins 10886400 secondes ou 18 semaines. Optez pour la valeur « deux ans », comme indiqué plus haut.
  • La directive « includeSubDomains » doit, le cas échéant, être spécifiée !
  • La directive « preload » doit être spécifiée.

Les exigences sont entrées en vigueur au 29 février 2016, et le restent au-delà de cette date. Tout manquement à ces exigences entraînerait votre radiation de la liste. Si, pour une raison ou une autre, vous devez supprimer votre domaine « HTTPS ONLY » de cette liste, suivez la procédure indiquée dans ce guide.

Installation de HSTS pour serveur Web Apache

Vous pouvez ajouter l’information suivante à votre fichier .htaccess  dans le document du dossier racine (ex : public_html ou httpdoc)

# Use HTTP Strict Transport Security to force client to use secure connections only Header always set Strict-Transport-Security "max-age=300; includeSubDomains; preload"

Installation de HSTS pour lighttpd

Ajoutez l’information suivante à votre fichier de configuration Lighttpd /etc/lighttpd/lighttpd.conf

server.modules += ( "mod_setenv" ) $HTTP["scheme"] == "https" { setenv.add-response-header = ("Strict-Transport-Security" => "max-age=300; includeSubDomains; preload") }

Installation HSTS pour NGINX

Cela va dans votre fichier site.conf. J’ai créé une modification avec des paramètres de sécurité supplémentaires.

add_header Strict-Transport-Security 'max-age=300; includeSubDomains; preload; always;'

Au cours de mes recherches pour les paramètres NGIX, j’ai découvert qu’un site du gouvernement américain donnait des informations erronées ; j’ai donc proposé les modifications de code nécessaires pour forcer le HSTS, quel que soit le retour du code de réponse HTTP.

Installation du HSTS pour serveurs IIS

protected void Application_BeginRequest(Object sender, EventArgs e) { switch (Request.Url.Scheme) { case "https": Response.AddHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains; preload"); break; case "http": var path = "https://" + Request.Url.Host + Request.Url.PathAndQuery; Response.Status = "301 Moved Permanently"; Response.AddHeader("Location", path); break; } }

Une fois mes recommandations installées, allez sur le formulaire de demande d’inscription sur la liste prédéfinie HSTS (HSTS Preloading Application Form) et faites inscrire votre site Web sur la liste de preload. L'ajout de votre domaine à cette liste n’est pas immédiat.

Qu’est-ce que le HSTS Preloading ?

Le HSTS Preloading est une fonction intégrée au navigateur qui définit une liste mondiale d'hôtes appliquant UNIQUEMENT le HTTPS sur leurs sites.

Compilée par le Projet Chromium, cette liste est utilisée par Chrome, Firefox et Safari. Sur les sites de la liste, l’application de la politique HSTS n’est pas subordonnée à l’émission des en-têtes de réponse HSTS. En fait, le navigateur sait déjà que le nom de domaine exige l’utilisation EXCLUSIVE du HTTPS et pousse le HSTS avant toute connexion ou communication.

Ainsi, les hackers ne peuvent intercepter et « saboter » les redirections HTTP. L’en-tête de réponse HSTS reste cependant nécessaire dans ce scénario et doit être conservé pour les navigateurs qui n’utilisent pas de listes HSTS préchargées.

Références

Le HTTP Strict Transport Security existe depuis près de huit ans maintenant. L’activation de la règle « HTTPS UNIQUEMENT » sur votre infrastructure Web permet de tenir les hackers à l'écart et de maintenir vos données sensibles en sécurité. Rapide à installer pour votre webmaster ou service d’hébergement Web, cette règle permet en prime de booster votre score SSL dans le SSL Checker de GlobalSign.

Références HSTS

  1. HTTP Strict Transport Security
  2. Google Starts Giving A Ranking Boost To Secure HTTPS/SSL Sites
  3. Google I/O 2014 - HTTPS Everywhere
  4. Bringing HSTS to www.google.com
  5. Strict Transport Security W3 List Archives
  6. Compliance Guide OMB - CIO
  7. Policy to Require Secure Connections across Federal Websites and Web Services

À propos de Denver

Président de StrikeHawk eCommerce, Inc., Denver est impliqué dans l'hébergement sécurisé depuis 2005. Cet évangéliste du logiciel open source participe à de nombreux projets open source sur le Web. Il a cofondé StrikHawk eCommerce, Inc., société spécialisée dans l’hébergement sécurisé d'applications Web e-commerce open source. Denver réside actuellement dans le sud des États-Unis d'Amérique.

StrikeHawk eCommerce, Inc. propose des services d’hébergement mutualisé, cloud et dédié avec une prise en charge complète d’applications de panier d'achats du type de PrestaShop, Woocommerce et WHMCS. Strikehawk est également revendeur agréé de produits et services GlobalSign.

Partager ce blog