23 septembre 2022

Qu'est-ce que HSTS, HTTP Strict Transport Security ?

HTTP Strict Transport Security est un mécanisme de politique de sécurité Web qui permet aux sites Web de se déclarer accessibles uniquement via des connexions sécurisées.

HSTS

HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité Web qui permet aux sites Web de se déclarer accessibles uniquement via des connexions sécurisées. Cela permet de protéger les sites Web et les utilisateurs contre les déclassements de protocole et les attaques de piratage de cookies.

HTTP Strict Transport Security (HSTS) a une histoire fascinante qui remonte à 2008. Tout a commencé avec un document de recherche intitulé "HTTPS forcé : protection des sites Web hautement sécurisés contre les attaques réseau», écrit par Collin Jackson et Adam Barth. Ce travail révolutionnaire a jeté les bases de ce qui allait devenir HSTS, décrivant l'idée fondamentale de forcer les connexions de sites Web à utiliser HTTPS pour améliorer la sécurité.

Protection-HTTPS-forcée-des-sites-Web-de-haute-sécurité-contre-les-attaques-de-réseau

Puis, le 18 septembre 2009, une évolution significative a eu lieu lorsque PayPal, avec Jackson et Barth, a publié une version révisée du schéma de protocole contenu dans le document original. Ce document mis à jour, qui est disponible en ligne, a été un pas en avant dans la définition de ce qui allait devenir le HSTS.

La prochaine phase cruciale de l'histoire du HSTS s'est produite le 18 dĂ©cembre 2009, lorsque la derniĂšre « version communautaire » de la spĂ©cification alors nommĂ©e « STS ​​» a Ă©tĂ© publiĂ©e. Cette version a incorporĂ© des modifications basĂ©es sur les commentaires reçus de la communautĂ© de la sĂ©curitĂ© Internet, affinant davantage les directives d'utilisation du HSTS.

Enfin, la spécification formelle du HSTS (RFC 6797) a été publiée le 19 novembre 2012, aprÚs avoir été approuvée le 2 octobre 2012 par l'Internet Engineering Steering Group (IESG), un organe composé du président de l'Internet Engineering Task Force ( IETF) et par les différents directeurs de zone. Cette approbation a marqué l'officialisation du HSTS comme norme de sécurité pour les connexions aux sites Web, confirmant son rÎle clé dans la protection des utilisateurs contre diverses attaques de réseau.

Pourquoi le HSTS a-t-il Ă©tĂ© introduit ?

Le protocole HTTP (Hypertext Transfer Protocol) est un protocole de communication largement utilisé pour la transmission d'informations sur Internet. Ce protocole s'appuie sur différents systÚmes de transport, dont le plus courant est le Transmission Control Protocol (TCP). TCP est le pilier fondamental du systÚme de transport et assure la livraison fiable des données entre les systÚmes interconnectés.

Cependant, TCP prĂ©sente un dĂ©faut important : il n'offre aucune protection de l'intĂ©gritĂ© des donnĂ©es, de la confidentialitĂ© des informations ou de l'identification sĂ©curisĂ©e de l'hĂŽte. En d'autres termes, les informations transmises via TCP sont vulnĂ©rables Ă  l'interception non autorisĂ©e, Ă  la modification des donnĂ©es et Ă  la fausse identification.

Ce manque de sécurité a motivé la création de protocoles supplémentaires pour améliorer la sécurité des données lors de leur transmission. Secure Sockets Layer (SSL) et son successeur, Transport Layer Security (TLS), sont nés avec cet objectif. Ces protocoles fournissent une couche de cryptage qui agit comme un bouclier entre les protocoles d'application et TCP. L'utilisation combinée de HTTP et de SSL/TLS donne naissance à ce que nous appelons communément HTTPS, ou HTTP sécurisé.

Les agents utilisateurs, comme les navigateurs Web, utilisent diverses politiques de sécurité locales pour décider comment interagir avec un hÎte. Cette décision est basée sur un certain nombre de facteurs, notamment la négociation entre le serveur et l'agent utilisateur, les préférences de l'utilisateur et la méthode de communication utilisée (HTTP ou HTTPS).

Cependant, dans certaines circonstances, les utilisateurs peuvent choisir de continuer Ă  interagir avec un site Web mĂȘme s'ils ne sont pas en mesure d'Ă©tablir une connexion sĂ©curisĂ©e. Cela peut se produire lorsque la chaĂźne de confiance d'un certificat TLS n'est pas validĂ©e, lorsque le certificat a expirĂ© ou lorsque le nom de domaine de l'hĂŽte TLS s'affiche de maniĂšre incorrecte dans le certificat. Cette pratique est connue sous le nom d'"insĂ©curitĂ© du clic".

Bien que cette possibilité puisse sembler pratique pour l'utilisateur, elle introduit des risques de sécurité potentiels. Les utilisateurs qui décident de continuer à utiliser un site Web sans connexion HTTPS sécurisée deviennent vulnérables à divers types de cyberattaques. Parmi celles-ci, les plus importantes sont les attaques de l'homme du milieu (MITM), dans lesquelles un attaquant intercepte et altÚre potentiellement la communication entre deux parties, les attaques de rétrogradation, qui forcent une connexion à utiliser un protocole moins sécurisé, et le détournement de session, dans lequel un attaquant prend le contrÎle de la session d'un utilisateur.

Suppression SSL

HTTP Strict Transport Security (HSTS) est un mĂ©canisme de sĂ©curitĂ© qui permet aux sites Web d'indiquer qu'ils ne sont accessibles que via une connexion sĂ©curisĂ©e. Cela signifie qu'un site Web peut empĂȘcher les utilisateurs de s'y connecter via des connexions non sĂ©curisĂ©es, telles que celles basĂ©es sur le protocole HTTP. Cette mesure protĂšge efficacement les utilisateurs d'une vulnĂ©rabilitĂ© de sĂ©curitĂ© bien connue appelĂ©e SSL-stripping.

Le SSL stripping est un type d'attaque par downgrade, une forme particuliÚrement insidieuse d'attaque cryptographique sur un systÚme informatique ou, comme dans ce cas, un protocole de communication. L'attaque de rétrogradation force le systÚme ou le protocole à abandonner sa connexion cryptée (HTTPS) et à adopter à la place une ancienne connexion non cryptée (HTTP), qui est généralement maintenue en place pour une compatibilité descendante avec les systÚmes plus anciens.

Le dĂ©capage SSL a Ă©tĂ© prĂ©sentĂ© pour la premiĂšre fois par Moxie Marlinspike dans son discours Ă  la confĂ©rence BlackHat 2009, intitulĂ© "Nouveaux trucs pour vaincre SSL en pratique". Cette attaque est mise en Ɠuvre dans le cadre d'une attaque de l'homme du milieu, oĂč le trafic Web est interceptĂ© et dĂ©tournĂ© de la version HTTPS sĂ©curisĂ©e du site Web vers une version HTTP non chiffrĂ©e.

Un facteur majeur qui permet à ce type d'attaque de continuer à réussir est que de nombreux sites Web n'utilisent pas de certificats TLS/SSL. Par conséquent, il est impossible de déterminer (sans connaissance préalable) si l'absence de HTTPS d'un site Web est due à une attaque SSL stripping ou parce que le site ne possÚde pas de certificat TLS.

Un aspect particuliĂšrement alarmant de cette attaque est qu'il n'y a pas de signaux ou d'avertissements qui peuvent avertir l'utilisateur pendant le processus de rĂ©trogradation. Cela rend l'attaque difficile Ă  dĂ©tecter, mĂȘme pour l'utilisateur le plus attentif et le plus conscient de la sĂ©curitĂ©.

La création par Marlinspike d'un outil pour automatiser entiÚrement ce type d'attaque fait du SSL stripping un risque sérieux pour la cybersécurité. La menace posée par ces attaques souligne l'importance de prendre des mesures de sécurité appropriées, telles que l'utilisation du HSTS, pour garantir l'intégrité et la sécurité des communications en ligne.

DĂ©tournement de session - DĂ©tournement de session

Le piratage de session, Ă©galement appelĂ© piratage de session ou piratage de cookies, est un type de vulnĂ©rabilitĂ© de sĂ©curitĂ© qui peut ĂȘtre exploitĂ©e par l'insĂ©curitĂ© des clics, un comportement qui permet aux utilisateurs de continuer Ă  interagir avec un site Web malgrĂ© l'absence de connexion HTTPS sĂ©curisĂ©e.

Dans une attaque de détournement de session, un attaquant exploite une session valide entre un ordinateur et un serveur pour obtenir un accÚs non autorisé à des informations ou à des services. Ce type d'attaque est particuliÚrement pertinent pour les développeurs Web, car les cookies, de petits fichiers texte enregistrés sur l'appareil de l'utilisateur, sont utilisés pour maintenir l'état de la session sur de nombreux sites Web.

Si un site Web ne marque pas ses cookies comme sĂ©curisĂ©s, en demandant aux agents utilisateurs, tels que les navigateurs Web, d'envoyer des cookies uniquement via une connexion HTTPS, ils peuvent facilement ĂȘtre interceptĂ©s et volĂ©s par un attaquant. En effet, des cookies non sĂ©curisĂ©s sont envoyĂ©s Ă  l'hĂ©bergeur quelle que soit la sĂ©curitĂ© du canal de transport utilisĂ©, ce qui les rend vulnĂ©rables aux attaques de l'homme du milieu. Ces attaques se produisent lorsqu'un attaquant parvient Ă  intercepter et potentiellement Ă  manipuler la communication entre deux parties sans que l'une ou l'autre des parties en soit consciente.

Une fois qu'un attaquant a eu accÚs aux cookies, il peut se faire passer pour l'utilisateur d'origine sur un site Web légitime, en utilisant les informations d'identification de session enregistrées dans le cookie pour accéder aux ressources protégées du site comme s'il était l'utilisateur légitime. Ce type d'attaque peut avoir de graves conséquences, notamment l'accÚs non autorisé à vos informations personnelles, financiÚres ou sensibles.

Il est important de noter qu'afin d'empĂȘcher le dĂ©tournement de session, il est essentiel que les sites Web utilisent des connexions HTTPS sĂ©curisĂ©es et marquent leurs cookies comme sĂ©curisĂ©s afin qu'ils ne soient envoyĂ©s que sur des connexions cryptĂ©es. En outre, les utilisateurs doivent ĂȘtre conscients des risques associĂ©s aux clics non sĂ©curisĂ©s et doivent Ă©viter d'accepter des connexions non sĂ©curisĂ©es dans la mesure du possible.

Comment fonctionne le HSTS ?

HTTP Strict Transport Security (HSTS) est un protocole de sécurité qui permet aux serveurs Web de déclarer que toutes les interactions entre un navigateur Web ou d'autres programmes utilisateur doivent se produire via des connexions HTTPS, qui offrent un cryptage sécurisé, au lieu de connexions HTTP non sécurisées.

Un serveur peut implĂ©menter une stratĂ©gie HSTS en fournissant un en-tĂȘte de rĂ©ponse spĂ©cifique via une connexion HTTPS. Cet en-tĂȘte, appelĂ© Strict-Transport-Security, spĂ©cifie une pĂ©riode de temps pendant laquelle l'interprĂ©teur, tel qu'un navigateur Web, doit accĂ©der au service exclusivement via des requĂȘtes HTTPS. Il est important de noter que les en-tĂȘtes HSTS envoyĂ©s via des rĂ©ponses HTTP non sĂ©curisĂ©es sont ignorĂ©s pour Ă©viter la possibilitĂ© d'une manipulation malveillante.

Le fonctionnement de HSTS est relativement simple. La premiĂšre fois qu'un utilisateur accĂšde Ă  un site via HTTPS et que le site renvoie l'en-tĂȘte Strict-Transport-Security, le navigateur enregistre ces informations. Ensuite, les futures tentatives de chargement du site via HTTP seront automatiquement redirigĂ©es vers HTTPS, assurant ainsi une connexion sĂ©curisĂ©e.

Une fois que le temps spĂ©cifiĂ© par l'en-tĂȘte Strict-Transport-Security s'est Ă©coulĂ©, la prochaine tentative de chargement du site via HTTP se dĂ©roulera comme d'habitude, au lieu d'ĂȘtre automatiquement redirigĂ© vers HTTPS. Cependant, chaque fois que l'en-tĂȘte Strict-Transport-Security est fourni Ă  l'agent utilisateur, il met Ă  jour la pĂ©riode de validitĂ© de ce site. Par consĂ©quent, les sites peuvent continuer Ă  envoyer ces en-tĂȘtes pour empĂȘcher l'expiration de la politique HSTS.

S'il est nĂ©cessaire de dĂ©sactiver HSTS, les serveurs Web peuvent dĂ©finir la valeur d'Ăąge maximale sur zĂ©ro sur une connexion HTTPS. Cela fera immĂ©diatement expirer l'en-tĂȘte HSTS, permettant ainsi l'accĂšs via des requĂȘtes HTTP.

Un exemple du fonctionnement de HSTS serait un serveur envoyant un en-tĂȘte demandant que toutes les demandes futures pour l'annĂ©e prochaine utilisent uniquement HTTPS. Cela peut ĂȘtre accompli via l'en-tĂȘte Strict-Transport-Security : max-age=31536000.

Lorsqu'une application Web envoie une politique HSTS aux agents utilisateurs, les agents utilisateurs conformes remplacent automatiquement toutes les connexions non sĂ©curisĂ©es par des connexions sĂ©curisĂ©es. Par exemple, un lien comme http://example.com/ serait transformĂ© en https://example.com avant d'atteindre le serveur. De plus, si une connexion sĂ©curisĂ©e ne peut pas ĂȘtre Ă©tablie, par exemple parce que le serveur ne dispose pas d'un certificat valide, l'agent utilisateur interrompra la connexion et ne permettra pas Ă  l'utilisateur d'accĂ©der au site Web.

L'aspect le plus important du HSTS est qu'il empĂȘche les clics non sĂ©curisĂ©s en ne permettant pas Ă  l'utilisateur d'utiliser la connexion non sĂ©curisĂ©e. Il s'agit de protĂ©ger les utilisateurs contre divers types de cyberattaques, telles que les attaques de l'homme du milieu, les attaques de rĂ©trogradation et les dĂ©tournements de session.

Quel est un exemple de situation impliquant le HSTS ?

Prenons un exemple pratique qui illustre l'importance et l'efficacité de HTTP Strict Transport Security (HSTS). Imaginons qu'un membre de votre équipe décide d'utiliser un point d'accÚs Wi-Fi gratuit dans un café pour surfer sur le Web. Au cours de sa session de navigation, il décide de se connecter au systÚme de paie de votre organisation pour vérifier ses détails salariaux.

Barre Wi-Fi

Malheureusement, le point d'accĂšs Wi-Fi auquel vous vous ĂȘtes connectĂ© n'est pas sĂ©curisĂ©. Il est gĂ©rĂ© par un pirate informatique qui a configurĂ© son ordinateur portable pour intercepter les requĂȘtes HTTP en transit. Lorsque votre employĂ© essaie d'accĂ©der Ă  votre systĂšme de paie, le pirate intercepte la requĂȘte HTTP d'origine et redirige votre employĂ© vers un faux site Web, une copie parfaite de votre systĂšme de paie. Cela conduit Ă  l'exposition des informations personnellement identifiables (PII) de vos employĂ©s, ce qui crĂ©e un problĂšme important de confidentialitĂ© et de sĂ©curitĂ©.

Cependant, si votre systÚme de paie utilise HSTS et que votre employé a déjà visité le site en utilisant une connexion HTTPS, son navigateur se souviendra d'utiliser uniquement les connexions HTTPS pour ce site à l'avenir. Cela signifie que peu importe à quel point le pirate essaie de rediriger le trafic de votre employé vers un faux site Web via une connexion HTTP non sécurisée, le navigateur de l'employé insistera pour utiliser uniquement HTTPS.

De cette maniÚre, l'utilisation du HSTS protÚge efficacement vos employés et votre systÚme de paie contre les attaques potentielles de l'homme du milieu. Démontrant à quel point il est crucial pour les organisations de s'assurer que leurs sites Web implémentent correctement le protocole HSTS, afin de maintenir la sécurité et la confidentialité de leurs utilisateurs et de leurs données.

Quelles sont les limites du HSTS ?

HTTP Strict Transport Security (HSTS) est un outil puissant pour sécuriser les connexions Web, mais il présente également certaines limitations fondamentales.

La premiĂšre est qu'un utilisateur incapable d'Ă©tablir une connexion HTTPS sĂ©curisĂ©e ne pourra pas accĂ©der au site Web qui implĂ©mente HSTS. Cela peut crĂ©er des problĂšmes d'accessibilitĂ© dans des circonstances oĂč les connexions HTTPS sont problĂ©matiques ou indisponibles.

De plus, la communication de la politique HSTS se fait via un en-tĂȘte de rĂ©ponse HTTP, ce qui signifie que l'utilisateur doit d'abord visiter le site Web pour dĂ©couvrir qu'il utilise HSTS. Cela implique que la premiĂšre demande au site Web, si elle est effectuĂ©e via un protocole non sĂ©curisĂ© tel que HTTP, reste vulnĂ©rable aux attaques actives. Il en va de mĂȘme pour la premiĂšre rĂ©clamation aprĂšs l'expiration de la pĂ©riode spĂ©cifiĂ©e dans la directive HSTS "max-age". Cette pĂ©riode est gĂ©nĂ©ralement dĂ©finie sur plusieurs jours ou mois, en fonction des besoins spĂ©cifiques du site et du comportement des utilisateurs.

Pour attĂ©nuer ce problĂšme, de nombreux navigateurs prennent en charge les stratĂ©gies HSTS de "prĂ©chargement". Cela signifie qu'ils maintiennent une liste de sites Web connus pour utiliser HSTS et utilisent automatiquement une connexion HTTPS pour la premiĂšre requĂȘte vers ces sites. Cependant, cette approche ne s'applique pas Ă  l'ensemble du Web. Il y a eu des discussions sur l'utilisation des enregistrements DNS et DNSSEC pour dĂ©clarer et garantir l'utilisation du HSTS, qui peut offrir une solution plus gĂ©nĂ©rale.

Une autre limite du HSTS est son inefficacité contre certains types d'attaques. Il ne protÚge pas, par exemple, contre les attaques par typosquattage, les attaques basées sur le DNS ou les attaques de l'homme du milieu utilisant de faux domaines qui ne sont pas inclus dans la liste de prélecture HSTS du navigateur.

Enfin, HSTS dépendant du protocole TLS, sa sécurité est liée à la robustesse de TLS. S'il existe des vulnérabilités dans TLS, HSTS sera indirectement affecté.

Pour une discussion plus détaillée et technique de ces aspects et d'autres aspects du HSTS, veuillez consulter la demande de commentaires (RFC) 6797.

Précharges HSTS

Le "préchargement" HSTS est une méthode utilisée pour améliorer la sécurité du site Web et surmonter l'une des principales limites du HSTS - le fait que l'utilisateur doit avoir déjà visité le site avant que la politique HSTS ne soit respectée. Le préchargement HSTS résout ce problÚme en incluant le site Web dans une liste prédéfinie de sites utilisant HSTS, distribuée avec le navigateur. Ainsi, lorsqu'un utilisateur visite le site pour la premiÚre fois, le navigateur sait déjà qu'il doit utiliser HTTPS, évitant ainsi le problÚme du « premier contact ».

hstspreload.org est un service qui permet aux propriĂ©taires de sites Web de demander l'inclusion de leur site dans la liste de prĂ©chargement HSTS distribuĂ©e avec les principaux navigateurs. Pour ĂȘtre inclus dans cette liste, un site Web doit rĂ©pondre Ă  un certain nombre de critĂšres spĂ©cifiĂ©s, y compris l'envoi d'un en-tĂȘte HSTS appropriĂ© avec une valeur "max-age" d'au moins 31536000 secondes (environ un an), et l'inclusion des "includeSubDomains" et directive "prĂ©chargement".

Pour configurer un serveur Web NGINX afin qu'il envoie les en-tĂȘtes corrects et rĂ©ponde Ă  ces critĂšres, vous devez ajouter la configuration suivante dans le bloc « serveur Â» de votre fichier de configuration NGINX :

server { # ... autres configurations de serveur ... add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; # ... autres configurations de serveur ... }

Une fois cette configuration implémentée, il est possible de demander l'inclusion du site (dans notre exemple, example.it) dans la liste de préchargement HSTS via hstspreload.org. Entrez simplement le domaine de votre site dans le champ de saisie fourni et suivez les instructions fournies. Le site sera ensuite vérifié pour s'assurer qu'il répond à tous les critÚres nécessaires, et si tout va bien, il sera ajouté à la liste.

Le processus de préchargement HSTS ne se produit pas en temps réel, mais plutÎt en conjonction avec chaque nouvelle version de Google Chrome. En effet, la liste par défaut des sites utilisant HSTS est incluse dans chaque version du navigateur Google Chrome. Une fois qu'un site Web a demandé et satisfait aux exigences d'inclusion via hstspreload.org, le site est ajouté à la liste et ce changement est inclus dans la prochaine version de Google Chrome.

hstspreload.org

Cependant, il est important de noter qu'il peut y avoir une période d'attente importante avant que l'inclusion ne prenne effet. Google publie de nouvelles versions de Chrome toutes les six semaines environ, mais il peut y avoir un délai supplémentaire avant que la modification ne soit intégrée au navigateur. En effet, il peut y avoir de nombreuses demandes d'inclusion en attente et le processus d'examen et d'ajout à la liste prend du temps.

Dans l'ensemble, il faut s'attendre à ce qu'il faille au moins deux à trois mois pour qu'un site soit inclus dans la liste par défaut de Chrome aprÚs la demande initiale. Cependant, une fois inclus dans la liste, tous les visiteurs du site Web utilisant une version mise à jour de Chrome bénéficieront de la politique HSTS dÚs leur premier contact avec le site.

Préchargement HSTS et amélioration des performances et des valeurs TTFB.

Le prĂ©chargement HSTS (HTTP Strict Transport Security) amĂ©liore non seulement la sĂ©curitĂ© globale du site Web, mais peut Ă©galement contribuer Ă  amĂ©liorer les performances globales du site et Ă  rĂ©duire le dĂ©lai avant le premier octet (TTFB). TTFB est une mĂ©trique qui mesure le temps qui s'Ă©coule entre le moment oĂč un client (par exemple, un navigateur Web) envoie une requĂȘte HTTP jusqu'Ă  ce qu'il reçoive le premier octet de la rĂ©ponse du serveur Web. La rĂ©duction du TTFB peut grandement amĂ©liorer la vitesse globale de chargement d'une page Web et l'expĂ©rience utilisateur.

Avec HSTS activé et configuré pour le préchargement, le navigateur de l'utilisateur sait à l'avance qu'il ne doit communiquer avec le site Web que via une connexion HTTPS sécurisée, éliminant ainsi le besoin d'une redirection HTTP vers HTTPS. Cette redirection peut introduire des latences supplémentaires qui augmentent le TTFB.

Sans HSTS, le navigateur de l'utilisateur peut initialement tenter d'établir une connexion HTTP non sécurisée, que le serveur redirige ensuite vers une connexion HTTPS. Cette redirection prend du temps et ralentit le chargement de la page.

Avec le prĂ©chargement HSTS, cette redirection est Ă©vitĂ©e, ce qui peut entraĂźner une rĂ©duction du TTFB, rendant le site Web plus rapide et plus rĂ©actif. Il s'agit d'un avantage particuliĂšrement important pour les sites Web hautes performances, oĂč mĂȘme des amĂ©liorations mineures du TTFB peuvent avoir un impact considĂ©rable sur l'expĂ©rience utilisateur et la vitesse globale du site.

Quelles sont les meilleures pratiques pour dĂ©ployer le HSTS ?

Les meilleures pratiques de dĂ©ploiement HTTP Strict Transport Security (HSTS) sont conçues pour optimiser la sĂ©curitĂ© de votre site et garantir que tous les visiteurs de votre site bĂ©nĂ©ficient de la protection offerte par HSTS. Ici, nous allons nous concentrer sur la façon de dĂ©ployer avec succĂšs HSTS si votre site est liĂ© Ă  HTTPS et que vous avez l'intention de prĂ©charger HSTS. Les Ă©tapes suivantes dĂ©crivent le processus :

  1. Assurez-vous de fournir un certificat valide : Un certificat SSL/TLS valide est essentiel pour Ă©tablir une connexion HTTPS sĂ©curisĂ©e. Cela implique que le certificat doit ĂȘtre dĂ©livrĂ© par une autoritĂ© de certification (CA) reconnue et que le nom de votre site doit correspondre au nom spĂ©cifiĂ© dans le certificat.
  2. Rediriger de HTTP vers HTTPS sur le mĂȘme hĂŽte, si vous Ă©coutez sur le port 80 : cette Ă©tape est essentielle pour garantir la sĂ©curitĂ© de toutes les connexions Ă  votre site. Toutes les requĂȘtes HTTP doivent ĂȘtre redirigĂ©es vers HTTPS sur le mĂȘme hĂŽte.
  3. Servir tous les sous-domaines via HTTPS : Assurez-vous que tous les sous-domaines de votre site utilisent HTTPS pour garantir des connexions sĂ©curisĂ©es sur l'ensemble de votre domaine.
  4. Prend en charge HTTPS pour le sous-domaine www si un enregistrement DNS existe pour ce sous-domaine : si votre site possĂšde un enregistrement DNS pour un sous-domaine www, il doit prendre en charge HTTPS.
  5. NĂ©cessite un en-tĂȘte HSTS dans le domaine de base pour les requĂȘtes HTTPS : l'en-tĂȘte doit spĂ©cifier un Ăąge maximal d'au moins 31536000 secondes (1 an), doit inclure la directive includeSubDomains et la directive preload.
  6. Si vous diffusez une redirection supplĂ©mentaire Ă  partir de votre site HTTPS, cette redirection doit toujours avoir l'en-tĂȘte HSTS.

Pour atteindre un niveau de sécurité optimal, il est recommandé de suivre ces étapes :

  • Commencez par examiner tous les sous-domaines et sous-domaines imbriquĂ©s de votre site pour vous assurer qu'ils fonctionnent sur HTTPS.
  • Ensuite, activez HSTS pour toutes les rĂ©ponses HTTPS et augmentez progressivement l'Ăąge maximum. Au cours de chaque Ă©tape, surveillez de prĂšs les mĂ©triques de votre site, rĂ©solvez les problĂšmes qui surviennent et attendez l'Ăąge maximum de l'Ă©tape avant de continuer. Vous pouvez suivre cette progression pour l'Ăąge maximum de l'en-tĂȘte : 5 minutes, 1 semaine, 1 mois.
  • Une fois que vous ĂȘtes sĂ»r qu'il n'y a pas de problĂšme, augmentez l'Ăąge maximum Ă  2 ans et soumettez votre site Ă  la liste de prĂ©lecture HSTS avec la directive de prĂ©lecture.

Enfin, vous pouvez soumettre votre site Web pour inclusion dans la liste de prĂ©chargement HSTS via hstspreload.org. Ce site est gĂ©rĂ© par l'Ă©quipe du projet Chromium et permet aux sites Web d'ĂȘtre inclus dans la liste de prĂ©chargement HSTS distribuĂ©e avec Chrome et d'autres navigateurs basĂ©s sur Chromium.

Quels navigateurs prennent en charge HSTS ?

HSTS (HTTP Strict Transport Security) bénéficie d'un large soutien parmi les principaux navigateurs, confirmant son rÎle vital dans l'augmentation de la sécurité des connexions Internet.

Chromium et Google Chrome ont Ă©tĂ© parmi les premiers navigateurs Ă  prendre en charge HSTS, Ă  partir de la version 4.0.211.0. Cela a marquĂ© une avancĂ©e majeure dans la mise en Ɠuvre de mesures de sĂ©curitĂ© avancĂ©es pour protĂ©ger les internautes contre les attaques potentielles.

Firefox a commencé à prendre en charge HSTS à partir de la version 4. Mais avec l'introduction de Firefox 17, Mozilla est allé encore plus loin en intégrant une liste de sites Web prenant en charge HSTS, améliorant encore la sécurité des utilisateurs.

Opera, à partir de la version 12, a commencé à prendre en charge HSTS, reconnaissant l'importance de fournir une connexion sécurisée à ses utilisateurs.

Safari a commencé à prendre en charge HSTS à partir d'OS X Mavericks, version 10.9. Cela a fourni une couche de protection supplémentaire aux utilisateurs de Safari, les aidant à naviguer sur Internet de maniÚre plus sécurisée.

Internet Explorer 11 sur Windows 8.1 et Windows 7 a commencé à prendre en charge HSTS lors de l'installation de la mise à jour KB 3058515. Cela a permis à ses utilisateurs de bénéficier des protections offertes par HSTS.

Microsoft Edge et Internet Explorer 11 sur Windows 10 prennent en charge HSTS, renforçant encore la sécurité de ces navigateurs.

Enfin, le navigateur BlackBerry 10 et WebView prennent Ă©galement en charge HSTS, Ă  partir de BlackBerry OS 10.3.3. Cela confirme l'importance du HSTS non seulement pour les ordinateurs de bureau, mais Ă©galement pour les appareils mobiles.

Conclusions

En bref, HTTP Strict Transport Security (HSTS) est un mĂ©canisme de sĂ©curitĂ© important qui aide Ă  protĂ©ger les sites Web et leurs utilisateurs contre divers types d'attaques, y compris les attaques de type "man-in-the-middle". Cela fonctionne en forçant les navigateurs Ă  utiliser des connexions HTTPS sĂ©curisĂ©es avec des sites Web qui mettent en Ɠuvre la politique HSTS.

Cependant, HSTS a certaines limites. Il oblige l'utilisateur Ă  visiter d'abord le site Web pour connaĂźtre sa politique HSTS, ce qui peut exposer la premiĂšre demande Ă  des attaques potentielles. C'est lĂ  que le prĂ©chargement HSTS entre en jeu. Le prĂ©chargement HSTS permet aux sites Web d'ĂȘtre inclus dans une liste de sites HSTS qui est distribuĂ©e avec les navigateurs, Ă©liminant ainsi la nĂ©cessitĂ© pour l'utilisateur de visiter d'abord le site pour connaĂźtre sa politique HSTS.

La configuration du prĂ©chargement HSTS nĂ©cessite quelques Ă©tapes, notamment la dĂ©finition d'en-tĂȘtes spĂ©cifiques et la soumission de votre site Ă  la liste de prĂ©chargement HSTS. Bien qu'il puisse ĂȘtre un peu complexe Ă  mettre en place, il offre une couche de sĂ©curitĂ© supplĂ©mentaire qui mĂ©rite d'ĂȘtre prise en compte.

En outre, le préchargement HSTS peut également améliorer les performances du site Web en réduisant le délai avant le premier octet (TTFB), ce qui peut conduire à une meilleure expérience utilisateur.

Enfin, HSTS offre une large compatibilité avec les navigateurs, notamment Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, Opera, Safari et le navigateur BlackBerry 10.

Informations sur l'auteur

Vous avez des doutes ? Vous ne savez pas par oĂč commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions systÚme GNU/Linux avancées orientées vers la haute performance. Avec un modÚle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accÚs à des technologies avancées en matiÚre d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils systÚme sur les systÚmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. dĂ©tient les droits de Red HatÂź, RHELÂź, RedHat LinuxÂź et CentOSÂź ; AlmaLinuxℱ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky LinuxÂź est une marque dĂ©posĂ©e de la Rocky Linux Foundation ; SUSEÂź est une marque dĂ©posĂ©e de SUSE LLC ; Canonical Ltd. dĂ©tient les droits sur UbuntuÂź ; Software in the Public Interest, Inc. dĂ©tient les droits sur DebianÂź ; Linus Torvalds dĂ©tient les droits sur LinuxÂź ; FreeBSDÂź est une marque dĂ©posĂ©e de la FreeBSD Foundation ; NetBSDÂź est une marque dĂ©posĂ©e de la Fondation NetBSD ; OpenBSDÂź est une marque dĂ©posĂ©e de Theo de Raadt. Oracle Corporation dĂ©tient les droits sur OracleÂź, MySQLÂź et MyRocksÂź ; PerconaÂź est une marque dĂ©posĂ©e de Percona LLC ; MariaDBÂź est une marque dĂ©posĂ©e de MariaDB Corporation Ab ; REDISÂź est une marque dĂ©posĂ©e de Redis Labs Ltd. F5 Networks, Inc. dĂ©tient les droits sur NGINXÂź et NGINX PlusÂź ; VarnishÂź est une marque dĂ©posĂ©e de Varnish Software AB. Adobe Inc. dĂ©tient les droits sur MagentoÂź ; PrestaShopÂź est une marque dĂ©posĂ©e de PrestaShop SA ; OpenCartÂź est une marque dĂ©posĂ©e d'OpenCart Limited. Automattic Inc. dĂ©tient les droits sur WordPressÂź, WooCommerceÂź et JetPackÂź ; Open Source Matters, Inc. dĂ©tient les droits sur JoomlaÂź ; Dries Buytaert dĂ©tient les droits sur DrupalÂź. Amazon Web Services, Inc. dĂ©tient les droits sur AWSÂź ; Google LLC dĂ©tient les droits sur Google Cloudℱ et Chromeℱ ; Facebook, Inc. dĂ©tient les droits sur FacebookÂź ; Microsoft Corporation dĂ©tient les droits sur MicrosoftÂź, AzureÂź et Internet ExplorerÂź ; La Fondation Mozilla dĂ©tient les droits sur FirefoxÂź. ApacheÂź est une marque dĂ©posĂ©e de The Apache Software Foundation ; PHPÂź est une marque dĂ©posĂ©e du groupe PHP. CloudFlareÂź est une marque dĂ©posĂ©e de Cloudflare, Inc. ; NETSCOUTÂź est une marque dĂ©posĂ©e de NETSCOUT Systems Inc. ; ElasticSearchÂź, LogStashÂź et KibanaÂź sont des marques dĂ©posĂ©es d'Elastic NV. Ce site n'est affiliĂ©, sponsorisĂ© ou autrement associĂ© Ă  aucune des entitĂ©s mentionnĂ©es ci-dessus et ne reprĂ©sente aucune de ces entitĂ©s de quelque maniĂšre que ce soit. Tous les droits sur les marques et noms de produits mentionnĂ©s sont la propriĂ©tĂ© de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnĂ©es appartiennent Ă  leurs titulaires. MANAGED SERVERÂź est une marque dĂ©posĂ©e au niveau europĂ©en par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

Retour en haut de page