Votre hébergeur de site statique vous demande de prouver que vous possédez bien votre nom de domaine, mais pourquoi donc ?

La situation de départ

Prenons l’exemple de ce site au moment de l’écriture de cet article, il est hébergé sur GitHub Pages grâce à l’enregistrement CNAME suivant:

notes.fcalvet.fr. 10800 IN CNAME fcalvet.github.io.

Note subsidiaire: n’oubliez pas le point racine dans vos enregistrements DNS !

L’en-tête Host

Wikipédia vous informera qu’il s’agit du “seul en-tête réellement important.”

Lorsque votre visiteur va chercher à visiter votre site, son résolveur va se charger d’obtenir une adresse IP à contacter pour le nom de domaine, ici notes.fcalvet.fr, il va lire le contenu de l’enregistrement DNS présenté en introduction, mais il ne contient pas d’IP. Il va donc continuer la résolution, et trouvera pour le domaine fcalvet.github.io un enregistrement de type A avec comme contenu, par exemple, 185.199.110.153.

Une adresse IP hébergent généralement plus d’un site, et ce depuis de nombreuses années, cela explique pourquoi vous devez communiquer à l’hébergeur le nome de domaine que vous souhaitez utiliser ! En effet, l’étape de résolution de nom ne va laisser au logiciel charger de contacter le serveur HTTP uniquement l’adresse IP obtenue, et non les possibles multiples enregistrements intermédiaires.

Il va donc demander le nom de domaine initial, grâce à l’en-tête Host, à un serveur de GitHub, qui n’a lui aucune raison d’en connaître la destination.

Et c’est heureux, sinon quel serait l’hôte à demander ? le premier CNAME ? le dernier ? les essayer un par un ?

Un aparté

Le CNAME est récemment “abusé” pour le traçage des internautes, notamment pour la publicité. En effet, les navigateurs Web ont progressivement restreint l’accès au stockage auquel peuvent prétendre les sites tiers, les fameux “cookies tiers”. Le cloisonnement ayant lieu au niveau du nom de l’hôte, utiliser un enregistrement CNAME peut permettre à un tiers de le contourner, non sans risques pour la sécurité.

L’affirmation que les domaines intermédiaires obtenus durant la résolution restent invisibles à l’application est à nuancer pour certains cas particuliers, et notamment pour la protection contre le traçage avec uBlock Origin associé à Firefox.

Un second aparté

Si l’en-tête Host n’est pas le seul à contenir le nom de domaine à contacter. En effet, aujourd’hui les connections HTTP sont dans leur grande majorité chiffrées par le protocole TLS, ce qui inclut les en-têtes et donc celui qui nous permet d’indiquer le domaine désiré !

La connexion étant établie sur la base d’un certificat associé au nom de domaine, impossible d’attendre qu’elle soit établie pour envoyer cette information. On utilise donc une extension de TLS, Server Name Indication ou SNI pour la transmettre au serveur de l’hébergeur.

Déclarer la redirection

On informe donc notre hébergeur que notre nom canonique doit être associé au nom où il héberge notre page, ainsi lorsqu’il recevra une requête, dûment décorée de son SNI puis de son en-tête Host, il saura quel contenu fournir.

Une première vérification

Il ne va cependant pas nous croire sur parole ! En effet, il serait dommageable que nous puissions faire passer à notre site le trafic d’un domaine que nous ne possédons pas mais dont l’enregistrement DNS pointerait vers le serveur Web de GitHub.

L’hébergeur va alors lire le contenu du CNAME, et vérifier que l’association est la même que celle que nous venons de lui déclarer. Il peut alors, sans crainte, distribuer le contenu de fcalvet.github.io à chaque requête désignant l’hôte notes.fcalvet.fr.

Et le réseau de diffusion de contenu ?

GitHub utilise Fastly comme réseau de diffusion de contenu pour les Pages. En réalité, c’est donc avec des serveurs Fastly que la connection est établie. Il y aurait donc un risque d’autant plus grand à ne pas vérifier le contrôle du domaine.

Donc en fonction de l’accord qui lie GitHub à Fastly, et des contrôles internes chez ce dernier, il est possible que Fastly réalise lui aussi une vérification similaire.

Une deuxième vérification (pour le certificat)

Notre hébergeur est probablement attentif à la sécurité de chacun, ainsi qu’à éviter une surveillance de masse trop aisée des visiteurs de votre site. Il va donc demander à votre place un certificat, auprès d’une autorité, très certainement Let’s Encrypt. Celle-ci s’intéresse aussi à vérifier que vous possédez bien votre domaine, c’est une validation de contrôle de domaine typique (en anglais Domain Control Validation, DCV).

Dans ce cas, les étapes intermédiaires de la requête importent moins, pas de question de CNAME, l’important est d’avoir le contrôle du contenu qui va être fourni à sa requête, du moins pour le challenge le plus couramment utilisé pour les sites web, HTTP01 du protocole ACME qui ne nécessite que pouvoir répondre le bon contenu à une requête GET arbitraire. Pas d’enregistrement DNS supplémentaire, ou de répondeur dédié !

Une troisième vérification ?

Jusqu’à maintenant un CNAME suffit, mais certains services vous demanderont de placer un enregistrement TXT avec un jeton généré pour prouver que vous possédez le domaine. C’est la méthode standard pour prouver le contrôle d’un domaine, que l’on peut aussi retrouver formalisée sous le nom DNS01 dans le protocole ACME (dans laquelle le CNAME peut cependant avoir une utilité).

Pour prouver le contrôle d’un domaine pour un autre usage que l’hébergement pourquoi pas, mais pour le cas qui nous occupe, pourquoi donc ? La possibilité d’utiliser un enregistrement A, plutôt qu’un CNAME, pour envoyer vos visiteurs chez votre hébergeur, pas moyen alors pour lui de vérifier que c’est bien vous le propriétaire. C’est ce qui est arrivé à GitLab.