Vous avez raison, c'est assez vulnérable.
Le vrai problème est que la plupart des gens veulent quelque chose de peu cher et rapide, voire quasi instantané (tout en parlant sécurité). Donc les CAs font des vérifs de ce genre passant par le DNS (un autre classique est aussi d'envoyer une vérif par email à une des adresses enregistrées pour ce domaine dans le DNS, ce qui est aussi tout à fait vulnérable à une interception).
Le top de la sécurité serait bien entendu que deux personnes (un représentant le domaine, l'autre le CA) se rencontrent en vrai, physiquement, pour s'échanger des informations d'identité puis — si tout semble en ordre — des infos d'identification au service. Mais ça prendrait du temps, et surtout ça coûterait une blinde (le temps humain est ce qui coûte le plus cher!). Cela va à l'encontre du besoin.
Donc des compromis sont faits. De toutes façons peu de gens comprennent vraiment ce qu'ils font avec HTTPS, même ceux qui sont payés pour cela.
Pour minimiser le risque ceci dit, la vérification de présence du fichier est faite sur le serveur en https (c'est à dire https://example.com, et non http://example.com). Voir la page d'explication des technos. Donc tant que le renouvellement se fait avec un certificat encore valide (ce devrait être le cas, puisqu'automatique), cela assure une certaine sécurité. Le risque de MITM n'apparaît donc qu'à la demande initiale. Bien sūr, l'attaquant pourrait alors demander à passer par un canal moins sécurisé (comme un enregistrement DNS), et ce serait donc bien si un possesseur/administrateur de domaine avait la possibilité de bloquer certains canaux de vérification.
Dans tous les cas, oui. Il y a toujours à un moment donné au moins 1 instant (l'échange initial) où la sécurité est faible et sujette à attaque si toutes communications passent par Internet. C'est le coût de tout faire à distance et c'est la raison pour laquelle les geeks sécurité font des "key signing party" pour s'échanger et signer leurs clés personnelles avec rencontre physique et vérification d'identité, afin d'éliminer ce risque de l'échange initial.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Automatisme ?!?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 2.
Vous avez raison, c'est assez vulnérable.
Le vrai problème est que la plupart des gens veulent quelque chose de peu cher et rapide, voire quasi instantané (tout en parlant sécurité). Donc les CAs font des vérifs de ce genre passant par le DNS (un autre classique est aussi d'envoyer une vérif par email à une des adresses enregistrées pour ce domaine dans le DNS, ce qui est aussi tout à fait vulnérable à une interception).
Le top de la sécurité serait bien entendu que deux personnes (un représentant le domaine, l'autre le CA) se rencontrent en vrai, physiquement, pour s'échanger des informations d'identité puis — si tout semble en ordre — des infos d'identification au service. Mais ça prendrait du temps, et surtout ça coûterait une blinde (le temps humain est ce qui coûte le plus cher!). Cela va à l'encontre du besoin.
Donc des compromis sont faits. De toutes façons peu de gens comprennent vraiment ce qu'ils font avec HTTPS, même ceux qui sont payés pour cela.
Pour minimiser le risque ceci dit, la vérification de présence du fichier est faite sur le serveur en https (c'est à dire https://example.com, et non http://example.com). Voir la page d'explication des technos. Donc tant que le renouvellement se fait avec un certificat encore valide (ce devrait être le cas, puisqu'automatique), cela assure une certaine sécurité. Le risque de MITM n'apparaît donc qu'à la demande initiale. Bien sūr, l'attaquant pourrait alors demander à passer par un canal moins sécurisé (comme un enregistrement DNS), et ce serait donc bien si un possesseur/administrateur de domaine avait la possibilité de bloquer certains canaux de vérification.
Dans tous les cas, oui. Il y a toujours à un moment donné au moins 1 instant (l'échange initial) où la sécurité est faible et sujette à attaque si toutes communications passent par Internet. C'est le coût de tout faire à distance et c'est la raison pour laquelle les geeks sécurité font des "key signing party" pour s'échanger et signer leurs clés personnelles avec rencontre physique et vérification d'identité, afin d'éliminer ce risque de l'échange initial.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]