Question intéressante sur laquelle je ne m’étais pas penchée. Si un attaquant s’en prend à l’AFNIC et obtient le contrôle de la zone fr. (ou si l’attaquant est l’AFNIC, ce qui revient au même), que peut-il faire ?
L’option la plus simple, je pense, est de supprimer l’enregistrement DS pour example.fr., brisant ainsi la chaîne de confiance allant de la racine jusqu’au contenu de la zone. L’enregistrement TLSA pour www.example.fr. sera toujours là, mais en l’absence de délégation sécurisée cet enregistrement sera considéré non-sécurisé et le navigateur web devra obligatoirement l’ignorer (RFC 6698, §4.1). L’attaquant peut alors tenter son attaque MITM en présentant un faux certificat — la réussite ou l’échec de cette attaque dépendra des autres moyens de vérification implémentés dans le navigateur (PKIX, Convergence, éventuellement HPKP si ce n’est pas la première visite, etc.), mais l’attaquant ne sera plus gêné par DANE qui est hors-jeu à ce stade.
Une faiblesse de cette attaque est qu’elle est facilement détectable : une zone entière qui devient subitement non-sécurisée, il y a peu de chance que ça passe inaperçu. Par contre, un avantage est qu’elle offre un certain déni plausible : si l’AFNIC est prise la main dans le sac, elle peut facilement faire passer ça pour une honnête erreur (« oups, désolé, l’enregistrement DS a sauté à cause d’une bête erreur dans le script qui re-signe périodiquement le fichier de zone, (削除) on a viré le stagiaire (削除ここまで) ça n’arrivera plus, promis ») — un peu comme les CA prises à émettre des certificats frauduleux, d’ailleurs.
Donc il y a bien 2 intermédiaires. Dans mon exemple :
AFNIC -> Gandi -> example.fr
Oui, clairement. J’argumenterais que ça reste mieux que le système PKIX où il faut faire confiance à toutes les CA, mais dire que le bureau d’enregistrement est le seul tiers de confiance était exagéré.
Et je ne compte pas l'ICANN qui gère la racine
Il faudrait pourtant, même si une attaque à ce niveau serait probablement encore moins discrète qu’une attaque au niveau du TLD.
[^] # Re: shttp
Posté par gouttegd . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 5.
Question intéressante sur laquelle je ne m’étais pas penchée. Si un attaquant s’en prend à l’AFNIC et obtient le contrôle de la zone
fr.(ou si l’attaquant est l’AFNIC, ce qui revient au même), que peut-il faire ?L’option la plus simple, je pense, est de supprimer l’enregistrement DS pour
example.fr., brisant ainsi la chaîne de confiance allant de la racine jusqu’au contenu de la zone. L’enregistrement TLSA pourwww.example.fr.sera toujours là, mais en l’absence de délégation sécurisée cet enregistrement sera considéré non-sécurisé et le navigateur web devra obligatoirement l’ignorer (RFC 6698, §4.1). L’attaquant peut alors tenter son attaque MITM en présentant un faux certificat — la réussite ou l’échec de cette attaque dépendra des autres moyens de vérification implémentés dans le navigateur (PKIX, Convergence, éventuellement HPKP si ce n’est pas la première visite, etc.), mais l’attaquant ne sera plus gêné par DANE qui est hors-jeu à ce stade.Une faiblesse de cette attaque est qu’elle est facilement détectable : une zone entière qui devient subitement non-sécurisée, il y a peu de chance que ça passe inaperçu. Par contre, un avantage est qu’elle offre un certain déni plausible : si l’AFNIC est prise la main dans le sac, elle peut facilement faire passer ça pour une honnête erreur (« oups, désolé, l’enregistrement DS a sauté à cause d’une bête erreur dans le script qui re-signe périodiquement le fichier de zone,
(削除) on a viré le stagiaire (削除ここまで)ça n’arrivera plus, promis ») — un peu comme les CA prises à émettre des certificats frauduleux, d’ailleurs.Oui, clairement. J’argumenterais que ça reste mieux que le système PKIX où il faut faire confiance à toutes les CA, mais dire que le bureau d’enregistrement est le seul tiers de confiance était exagéré.
Il faudrait pourtant, même si une attaque à ce niveau serait probablement encore moins discrète qu’une attaque au niveau du TLD.