quelques sécurisations de sites Web

Un site Web peut être sécurisé de plusieurs manières différentes, cumulables. Regardons-en quelques unes, à quoi elles servent et comment les mettre en place.

À présent, le nom de la norme est « TLS ». Mais à l’oral, on dit encore « SSL » (qui est l’ancien nom de la même norme, « ancien » = avant 1999).

Le TLS rajoute une couche de chiffrement au flux HTTP standard : on parle alors de flux HTTPS.

Le chiffrement permet :

1. une confidentialité du trafic échangé entre l’internaute et l’entreprise qui possède le site ; l’intérêt le plus évident est la transmission du numéro de carte bancaire, ou la transmission de n’importe quelle donnée personnelle (cf. le règlement européen RGPD) ;
2. une authentification de l’entreprise par l’internaute, c’est-à-dire que l’internaute sait que c’est bien cette entreprise-là chez qui il se connecte, et pas une autre qui usurpe son identité.

On parle bien ici de TLS correctement configuré, avec un vrai certificat valide. Sinon, ça ne vaut rien !

HSTS signifie « HTTP Strict Transport Security ». Cette norme est parfois aussi appelée seulement « STS ».

Le HSTS est une norme qui redirige le site en version non chiffrée vers sa version chiffrée. En gros, elle redirige « http://site-web » vers « https://site-web ». Elle garantit donc que le site Web sera affiché en HTTPS par l’internaute.

Quelle différence entre le HSTS et une simple redirection Web de type « 301 » / « RedirectPermanent » ?

1. Dans le cas d’une redirection permanente, le webmaster doit créer un hébergement vide en HTTP et programmer une redirection permanente vers l’autre hébergement en HTTPS.
2. Dans le cas du HSTS, c’est le navigateur Web qui sait si le site Web doit absolument être affiché en HTTPS ou pas. Si le HSTS est activé, alors le navigateur, de lui-même, réécrira l’URL de « http » vers « https », et la première requête sortante vers Internet sera en HTTPS, aucune requête HTTP ne sortira.

Le HSTS est une entête HTTP :

Strict-Transport-Security "max-age=31622400; includeSubDomains; preload"

Cette entête fait partie de la réponse en HTTPS. Elle indique au navigateur que :

1. le site doit être consulté en HTTPS ;
2. c’est vrai pour le site et tous ses sous-domaines (https://site-web et https://sous-domaine.site-web) ;
3. cette information est valable pendant 31622400 secondes (1 an) ;
4. cette information doit être chargée dans la mémoire du navigateur web.

OK. Mais vous allez me dire que la toute toute première requête va quand même se faire en HTTP et sera redirigée en HTTPS via un « 301 », et vous allez donc légitimement me demander à quoi sert cette nouvelle norme.

En fait, les navigateurs contiennent une liste préchargée de sites Web configurés en HSTS. Lorsque vous n’êtes jamais allé sur un tel site et que vous y allez pour la toute première fois en HTTP, votre navigateur va déjà réécrire l’URL en HTTPS. Il n’y a plus besoin de cette première requête HTTP.

Lorsqu’un webmaster crée un site Web en HSTS, il peut simplement rajouter l’entête HTTP vue ci-dessus, et ça marchera. Et avec la fameuse toute toute première requête qui sera en HTTP, car son nouveau site Web ne fait pas partie de cette fameuse liste préchargée. Et il peut également demander à ce que son site Web soit inséré dans cette fameuse liste préchargée.

Mon avis personnel :

HPKP signifie « HTTP Public Key Pinning ».

Cette norme rajoute une entête HTTP (come pour HSTS). Cette entête HTTP contient la signature du certificat TLS utilisé pour le site Web. Ainsi, si le certificat est valide mais que sa signature n’est pas présente dans l’entête HTTP, le site Web sera considéré comme frauduleux.

En fait, cette entête HTTP ne contient pas uniquement la signature du certificat, mais une liste de signatures. C’est primordial, car sinon il serait impossible de gérer le renouvellement légitime du certificat TLS.

Cette norme est loin d’avoir fait l’unanimité. Elle n’est pas supportée par Internet Explorer et Edge, et Chrome est en train de s’en défaire.

Cette norme est extrêmement délicate à manipuler :

1. Une erreur humaine lors de l’insertion du header dans les entêtes HTTP (configuration du serveur Web) et c’est la coupure définitive du site Web, pendant la durée du cache de la page Web (dans le navigateur de l’internaute, dans le proxy du réseau de l’internaute…).
2. Le renouvellement du certificat HTTPS ne s’improvise pas, il s’anticipe longtemps en avance, ne serait-ce qu’à cause du cache de la page Web.
3. Les systèmes automatisés de renouvellement de certificats, avec des durées de vie courtes de ces certificats (comme avec Let’s Encrypt) sont difficilement compatibles avec cette technologie (besoin de 2 certificats valides simultanément et avec des dates de validité qui ne se chevauchent pas totalement…).
4. Le sysadmin sépare deux actions indépendantes l’une de l’autre : la configuration du serveur Web (Apache / Nginx / …) et le renouvellement du certificat TLS. Dans certaines entreprises, ces actions sont tellement indépendantes que ce sont deux équipes distinctes qui sont en charge de chacune d’elles. Donc la création d’une dépendance entre ces deux actions va poser des problèmes structurels et il faudra revisiter les procédures et méthodes de mises en production.

Mon avis personnel :

CSP signifie « Content Security Policy ».

Cette norme se positionne, encore et toujours, comme les précédentes, au niveau des entêtes HTTP.

Ces nouvelles entêtes HTTP sont des directives restreignant l’origine du contenu multimedia de la page Web concernée. On peut ainsi restreindre, vis-à-vis de l’internaute, le téléchargement des JavaScripts à un seul sous-site Web qui hébergerait tous les codes JS. Ces entêtes peuvent restreindre :

• JavaScript
• CSS
• fonts (polices de caractères)
• images
• iframes
• pages à ouvrir par des scripts (XHR)
• objets (Flash, vidéos…)
• service workers

L’intérêt principal est de se prémunir contre toute modification non désirée des pages Web du site qu’on gère (attaque XSS principalement), en déclarant une liste blanche d’autorisations. La sécurité réside dans la séparation des tâches : d’une part la conception des pages (le webmaster et/ou le pirate informatique), et d’autre part l’hébergement de ces pages (le sysadmin).

L’utilisation de cette norme est très difficile, car elle implique que le développeur des pages Web maîtrise à 100 % tout les chargements externes de tous ses éléments actifs. Là où le bât blesse, c’est quand le webmaster utilise un CMS (comme WordPress, Drupal…) : le webmaster dépend du fonctionnement de son CMS, fonctionnement qui peut être modifié d’une version à l’autre, fonctionnement qui est également modifié par chaque module inséré dans le CMS. Il y a aussi le problème du développeur qui utilise des frameworks de développement « front » (jQuery, Angular, Vue…) : il se heurtera au même problème que précédemment.

Mon avis personnel :

« CAA », ou « DNS CAA », signifie « DNS Certification Authority Authorization ».

Cette norme s’appuie sur un nouvel enregistrement DNS. Celui-ci contient le nom de l’autorité de certification autorisée à signer des certificats pour l’entrée DNS ou le nom de domaine concerné.

Cet enregistrement ne sert pas à vérifier qu’un certificat est valide ou non. Il sert davantage à l’autorité de certification, qui peut ainsi vérifier si elle est légitime pour signer une demande de certificat. Cela permet d’améliorer en partie l’authentification du demandeur d’un certificat auprès de l’autorité de certification.

Mon avis personnel :

Ces technologies permettent de réduire les risques suivants :