Prouver la propriété d’un nom d’hôte sans certificat

Tout produit qui laisse un client saisir un nom d’hôte puis le contrôle chaque minute a construit deux choses. La première est de la supervision. La seconde est un générateur de requêtes distribué, pointé là où le client le souhaite, avec le nom de votre entreprise dans l’agent utilisateur et l’adresse de facturation de votre client derrière.

L’objection habituelle est que la cible a une adresse publique, donc que n’importe qui pourrait lui envoyer du trafic de toute façon. C’est vrai et ce n’est pas la question. Une adresse publique n’est pas une autorisation de mesurer quelqu’un, et « n’importe qui pourrait » n’est pas une défense qui survit au premier signalement d’abus, en particulier quand le trafic est périodique, soutenu et provient d’une plateforme commerciale identifiable.

Une cible désignée par un nom d’hôte doit donc se mériter. Voici la conception que nous avons retenue, y compris les parties moins évidentes qu’elles n’en ont l’air.

Deux méthodes qui prouvent des choses différentes

Il existe deux façons pratiques pour quelqu’un de démontrer qu’un nom lui appartient, et il vaut la peine d’être clair sur un point : elles ne sont pas équivalentes.

Un enregistrement TXT dans le DNS prouve le contrôle de la zone. Celui qui peut y placer une valeur décide où le nom pointe, ce qui est la revendication la plus forte qui existe au sujet d’un nom.

Un fichier sur le serveur web prouve le contrôle de la machine vers laquelle le nom pointe actuellement. C’est plus faible : en hébergement mutualisé, plus de gens peuvent le produire que de gens capables de modifier la zone. C’est aussi bien plus réalisable pour un client qui a un serveur mais aucun accès au fournisseur DNS de son employeur.

C’est le même couple de compromis que font les autorités de certification avec leurs deux types de challenge courants, et la même conclusion s’ensuit : proposez les deux, notez lequel a été utilisé, et ne prétendez pas qu’ils portent le même poids.

La forme du challenge

L’enregistrement TXT va sous son propre libellé plutôt que sur le domaine lui-même. Ce n’est pas de la propreté. Un enregistrement sur l’apex atterrit à côté des enregistrements de politique de messagerie du client, là où chaque chaîne supplémentaire rapproche la réponse de la taille où les résolveurs commencent à passer une mauvaise journée, et là où le nettoyage des « vieux enregistrements TXT » par quelqu’un d’autre le supprime sans malice. Sous son propre libellé, il est seul.

Le fichier vit sous un chemin réservé avec le jeton comme nom de fichier, et le fichier contient le jeton et rien d’autre.

Le jeton lui-même fait trente-deux caractères hexadécimaux, soit cent vingt-huit bits. Ce n’est pas un secret et ce n’est pas une clé : il va se retrouver dans le DNS public ou sur un serveur web public. Ce qu’il doit être, c’est imprévisible, parce que quiconque peut prédire un jeton valide peut revendiquer un nom qui ne lui appartient pas en le plaçant d’abord sur son propre serveur. L’hexadécimal en minuscules le garde sûr pour un enregistrement DNS, sûr dans une URL, et exempt de caractères qui peuvent être mal lus quand un client le recopie à la main.

Une règle structurelle : exactement un morceau de code écrit le challenge, et le résultat voyage avec la requête jusqu’à celui qui effectue le contrôle. Si les deux côtés connaissaient le préfixe indépendamment, il finirait par y avoir un jour où le panneau affiche un libellé et où le vérificateur en interroge un autre, et le message qui en résulte est « l’enregistrement n’est pas là » au sujet d’un enregistrement qui est là. Rien n’est plus coûteux à supporter qu’une réponse juste à une question que personne n’a posée.

Pourquoi c’est l’agent qui va chercher

C’est la décision dont dépend tout le reste.

La plateforme ne résout pas le nom et ne va pas chercher le fichier. Si elle le faisait, notre propre infrastructure établirait des connexions vers un nom saisi par un utilisateur, ce qui est une falsification de requête côté serveur avec un champ de formulaire comme surface d’attaque. Le résultat classique est une requête vers un point d’entrée de métadonnées cloud depuis l’intérieur de notre propre réseau, faite par nous, sur demande.

C’est au contraire l’agent du client qui s’en charge : le même agent qui exécutera les contrôles ensuite, installé à l’intérieur du réseau du client et ne se connectant que vers l’extérieur. Mentir sur le résultat ne rapporte rien, car la récompense est l’autorisation de mesurer quelque chose que l’agent pouvait déjà atteindre. La vérification est effectuée par la partie qui possède déjà l’accès, ce qui est le seul arrangement où l’intérêt à tricher disparaît.

Il y a une conséquence qui mérite d’être dite à voix haute, parce qu’elle ressemble à une protection manquante. Les recommandations pour ce genre de fonction disent d’ordinaire de bloquer les plages privées, la boucle locale, le lien-local et les adresses de métadonnées. Cette règle appartient aux sondes hébergées, c’est-à-dire aux points de mesure que nous exploitons et qui se trouvent dans notre réseau. Pour un agent situé à l’intérieur du réseau du client, les adresses privées sont le cas normal : leur hyperviseur, leur commutateur, leur stockage. Les bloquer désactiverait la seule source de mesure pour exactement la situation qu’elle existe pour servir.

Ce que les deux chemins partagent, c’est une fonction unique qui décide quelles adresses sont autorisées. Si la vérification et la mesure avaient chacune leur propre liste, il y aurait un jour où elles seraient en désaccord, et ce jour-là l’une des deux est un contournement de l’autre.

Refuser par défaut sur les réponses mixtes

Un nom peut pointer vers plusieurs adresses, et elles n’ont pas à être également acceptables.

Si un nom répond à la fois avec l’adresse publique du client et avec un point d’entrée de métadonnées, alors chaque exécution est un nouveau tirage. Neuf exécutions mesurent l’adresse publique et la dixième parle à tout autre chose. Le nombre de réponses acceptables ne porte donc aucune information : une seule adresse interdite dans l’ensemble rend le nom entier inutilisable, et le client se voit dire de quelle adresse il s’agissait, car un refus sur lequel il ne peut pas agir n’est qu’un message d’erreur.

Il en va de même pendant la vérification et pendant les contrôles ordinaires, ce qui est encore la raison pour laquelle il y a une politique d’adresses et non deux.

Des détails qu’on n’apprend qu’en le faisant tourner

Trois d’entre eux sont sortis de la construction du vérificateur ; le quatrième est une décision de conception qui a sa place à côté d’eux.

Comparez avec « contient », pas avec l’égalité. Un fournisseur DNS a le droit de présenter une valeur TXT entourée de guillemets, et certains panneaux de contrôle ajoutent des guillemets qu’ils retirent ensuite dans leur propre affichage. Le jeton est long et opaque : soit il est dedans, soit il n’y est pas, et exiger une correspondance exacte ne punit que les clients qui ont tout fait correctement.

Envoyez le nom dans l’en-tête Host et dans le nom de serveur TLS. La connexion va vers une adresse qui a déjà passé le contrôle de politique, mais un serveur web qui héberge plusieurs sites a besoin qu’on lui dise lequel est demandé. Sans les deux, un client correctement configuré échoue à la vérification parce qu’on lui a servi le site par défaut de quelqu’un d’autre.

Autorisez exactement une redirection. Un serveur web qui pousse tout vers HTTPS est normal, et refuser la redirection ferait échouer la moitié d’internet. En autoriser beaucoup laisserait la preuve finir tout à fait ailleurs. Un seul saut, et seulement vers le même hôte.

N’exigez pas HTTPS pour le challenge par fichier. La preuve, c’est le jeton. Un certificat ne lui ajoute rien, et en exiger un transforme un contrôle de propriété en un contrôle de certificat, ce qui est une autre question avec d’autres modes de défaillance. C’est le même raisonnement qui sous-tend le type de challenge en HTTP simple dans l’émission de certificats. Notez que cette valeur par défaut est propre à la vérification : quand le schéma est la chose mesurée, le deviner produirait une mesure verte de tout autre chose que ce que le client a configuré, et là le bon comportement est de refuser.

La preuve expire, parce que les domaines changent de mains

Un nom vérifié ne devrait pas rester vérifié pour toujours, et la raison n’est pas une paranoïa au sujet de nos propres enregistrements.

Les domaines changent de propriétaire sans prévenir personne. Un client laisse expirer une réservation, quelqu’un d’autre la reprend, et à partir de ce moment nous mesurons la machine d’un inconnu chaque minute avec le nom de notre client attaché au calendrier. Personne dans cette chaîne n’a rien fait de mal et le résultat reste inacceptable.

Quatre-vingt-dix jours est la validité que nous avons choisie, ce qui est du même ordre qu’un certificat à durée de vie courte et pour la même raison : assez court pour qu’un transfert soit remarqué rapidement, assez long pour que les clients n’aient pas de paperasse à faire toutes les semaines. La revérification commence quatorze jours avant l’expiration, ce qui est délibérément généreux, parce qu’une revérification échouée signifie d’ordinaire que l’agent était hors ligne ou qu’un résolveur était lent, plutôt qu’un changement de propriétaire.

Les tentatives sont limitées à une toutes les six heures, sans lien avec l’intervalle de supervision. Une vérification n’est pas une mesure : elle ne dit rien de la disponibilité, elle n’a pas sa place dans un taux de disponibilité, et demander plus souvent ne fait que générer du trafic contre le DNS du client. Six heures sur quatorze jours, cela fait plus de cinquante tentatives, ce qui transforme « expiré » en un vrai signal plutôt qu’en malchance.

Les états qui en découlent sont en attente, vérifié, en cours d’expiration, expiré et révoqué, et l’un d’eux n’est pas une barrière. « En cours d’expiration » existe pour que l’interface puisse avertir quelqu’un ; une preuve qui expire dans dix jours est valide aujourd’hui, et les contrôles continuent de tourner. La traiter comme un état de barrière distinct retirerait à un client sa supervision un jour où rien n’a changé.

La base de données impose l’appariement plutôt que de faire confiance au code : une ligne porte soit une date de vérification et une date d’expiration, soit aucune des deux. Une ligne vérifiée sans expiration est une autorisation permanente que personne n’a choisie, ce qui est précisément la chose que toute cette conception existe pour empêcher.

Ce que nous écririons

1. 01Décidez ce que le challenge prouve, le contrôle de la zone ou le contrôle de la machine, et stockez lequel a été utilisé.
2. 02Placez le challenge sous un libellé à vous, jamais sur l’apex à côté des enregistrements de messagerie de quelqu’un.
3. 03Faites du vérificateur la partie qui possède déjà l’accès. Si votre plateforme va chercher un nom fourni par un utilisateur, vous avez construit une fonction de falsification de requête.
4. 04Une seule politique d’adresses pour la vérification et la mesure. Deux listes deviennent deux comportements.
5. 05Refusez par défaut sur les réponses mixtes, et nommez l’adresse fautive dans le refus.
6. 06Donnez une expiration à la preuve, et commencez à la renouveler bien avant, car la défaillance contre laquelle vous vous protégez est silencieuse par nature.

Pour être clair sur notre propre état : c’est une conception qui existe dans du code avec ses propres tests, la supervision n’est pas quelque chose que vous pouvez nous acheter aujourd’hui, et rien de ce qui précède ne doit être lu comme une annonce de produit. C’est la forme que nous reconstruirions.

Issu du travail de supervision sur Provibr. La question voisine, mesurer sans toucher et combien d’octets un contrôle a le droit d’envoyer, est dans pourquoi un scanner doit envoyer zéro octet ; comment un agent décide lequel de plusieurs points de mesure utiliser est dans comment un agent choisit le bon serveur de bordure.