Profiter de son domaine de premier niveau pour sécuriser un peu plus le web, avec HSTS

Sécurité de HTTP et HTTPS

Vous le savez, le protocole HTTP (Hypertext Transfer Protocol) existe en deux variantes, l’une en clair et donc vulnérable à bien des attaques, et l’autre chiffrée et authentifiée, HTTPS (Hypertext Transfer Protocol Secure). Cette deuxième variante est fortement recommandée, notamment pour tout site web un tant soit peu sensible. Une limite de HTTPS est, ou plutôt était, que la ou le responsable d’un nom de domaine ne pouvait pas facilement forcer l’utilisation de HTTPS pour tous les sous-domaines. Si il ou elle contrôle example.com, il était toujours possible qu’un service.example.com ne soit encore qu’en HTTP tout court, sans la sécurité que procure la cryptographie.

Bien sûr, pour un domaine de premier niveau ouvert au public, comme .fr ou .org, pas question de forcer tous les sites web des sous-domaine à quoi que ce soit, même au nom de la sécurité. Mais les TLD fermés offrent cette possibilité.

HSTS

HSTS (HTTP Strict Transport Security) est une technique de sécurité qui permet au gérant d’un domaine d’imposer HTTPS à tous ses sous-domaines. Il est à noter qu’il ne repose pas sur le DNS (Domain Name System) mais se fait uniquement en HTTP. Le principe ? Le serveur HTTP, lorsqu’on s’y connecte, indique que ce domaine et, si on le précise, tous les sous-domaines, n’ont que des serveurs HTTPS, sans HTTP classique. Le client HTTP utilisé (par exemple un navigateur web) va mémoriser cette information et, dans le futur, ne se connectera qu’en HTTPS, refusant absolument d’utiliser HTTP tout court, même si l’utilisateur lui demande.

Vous voulez un peu plus de technique ? Voici le champ renvoyé par un serveur HTTP qui fait du HSTS :

Strict-Transport-Security: max-age=2592000

La présence de ce champ dans l’en-tête de la réponse HTTP est la directive que suivra le navigateur. Et si on veut que cette directive s’étende aux sous-domaines ?

Strict-Transport-Security: max-age=2592000; includeSubDomains

Et, désormais, les sous-domaines du domaine où le client HTTP a récupéré cette directive seront concernés. Le ou la gérant·e du serveur HTTP ne doit évidemment ajouter ce includeSubDomains que si les sous-domaines ne sont pas délégués à d’autres organisations, organisations qui pourraient avoir leur propre politique de sécurité.

HSTS a été normalisé dans le RFC 6797 en 2012 et est aujourd’hui largement présent dans les logiciels du web.

Mais comment on fait dans le DNS ?

OK, mais, ici, c’est le blog de l’Afnic et vous vous attendez donc à ce que je parle de DNS (Domain Name System) et pas de web. Mais HSTS, qui est une technique de sécurité de HTTP, ne peut se configurer que via HTTP. Ne cherchez donc pas, comme pour SPF (Sender Policy Framework, pour authentifier le courrier) ou DANE (DNS – based Authentication of Named Entities, pour authentifier un certificat sans recourir à une autorité de certification), à mettre cette information dans le DNS.

Si vous avez votre domaine de premier niveau, et que vous êtes en position de définir une politique de sécurité pour tous les sous-domaines, vous allez devoir configurer un serveur HTTP sur le TLD (Top-Level Domain). Si votre domaine de premier niveau est .example, il faudra faire un serveur qui réponde à l’adresse https://example/, en renvoyant le champ HSTS vu plus haut.

Et, là, les ennuis commencent. Il y a plusieurs problèmes avec l’adresse web du paragraphe précédent mais je n’en citerai qu’un seul : l’ICANN (Internet Corporation for Assigned Names and Numbers) ne permet pas[1] aux TLD sous contrat avec elle de placer n’importe quel type d’enregistrement DNS à l’apex (le sommet) d’un domaine. Pour que https://example/ fonctionne, il faudrait pouvoir mettre sur .example un enregistrement de type A (adresse IPv4), AAAA (adresse IPv6) ou le plus récent type HTTPS. Or, c’est justement interdit par l’ICANN. Mais il y a une solution.

S’enregistrer dans les navigateurs

Une des limites de HSTS est qu’il faut une première connexion HTTP pour recevoir la directive HSTS. Du point de vue de la sécurité, ce n’est pas idéal, on préférerait que la politique stricte « pas de HTTP sans cryptographie » s’applique dès le début. Il y a une méthode pour cela, qui traite également le problème qui découlait de l’interdiction de mettre à l’apex du TLD les enregistrements dont HTTP aurait eu besoin.

Cette solution, c’est le pré-chargement (pre-loading). Le client HTTP (typiquement un navigateur web) est configuré avec une liste de domaines (pas forcément des TLD) qui sont considérés comme étant toujours en HSTS. Les principaux navigateurs web utilisent en général la même liste^[2], qui est gérée par l’équipe de Chromium, la version libre du navigateur web de Google.

Pour que votre .marque, .brand ou .corp soit placé sur cette liste, vous devez le demander en ligne. Attention, le temps de traitement peut être long, de l’ordre de plusieurs semaines. Il sera accéléré si votre domaine se trouve sur la Public Suffix List, ce qui est a priori le cas de tous les TLD.

Conclusion

Parmi les avantages d’avoir son propre TLD, il y a la possibilité de configurer HSTS pour améliorer la sécurité de tous vos sous-domaines. N’hésitez pas !

Notes :
[1] : Voir le Base Registry Agreement, exhibit A “Approved Services” : « The above language effectively does not allow, among other things, the inclusion of DNS resource records that would enable a dotless domain name».
Retour au texte.

[2] : Les passionnés de technique devront, pour voir cette liste, télécharger le code source de Chromium, et regarder le fichier net/http/transport_security_state_static.json.
Retour au texte.