Sauf les USA contrôlent déjà pleins d'autorités de certification. Donc, ils peuvent déjà signer pour le monde entier. Là, on limite à 3⁄4.
En pratique, tous les noms de domaines des sites à gros trafic sont en .com sous leur control, tu changes uniquement 100% par 99%. Sans parler du fait que la "racine" elle-même a besoin d'être signée
Il ne reste plus qu'à avoir un script qui permet de vérifier que .com, le .be, le .br, le .ru et le .cn sont bien les mêmes et tu as beaucoup de chance que le contenu n'ait pas été modifié ☺.
Ils n'ont pas besoin de changer l'enregistrement de .com et ton script n'y changera pas grand chose. Si ils ont la clé privée qui sert à certifier les sous-domaines de .com, alors ils peuvent très bien falsifier la résolution de google.com et tu n'y verras que du feu. Tout comme avec le système de CA actuel.
La seul solution à ça est de ré implémenter encore une fois le pinning, mais cette fois avec DANE, comme mentionné dans l'article originel.
J'ai par ailleurs de gros problème avec l'association 1-1 entre DNS et autorité de certification de DANE.
Je veux choisir à qui je fais confiance.
Avec le système actuel, je peux: je l’enlève simplement de la liste des CA de confiance de mon application.
Avec DNSSEC, je ne peux pas : cette autorité est liée d'office à mon nom de domaine.
A mon sens, les hypothétiques avantages de DNSSEC/DANE ne justifient pas sa complexité de déploiement ni les problèmes annexes qu'il génerent :
Quid des portails captifs qui faussent la résolution de noms de domaine ?
Quid de l'abandon de UDP pour TCP/TLS sur la latence / charge des serveurs DNS ?
Quid de la transitions entre les deux ? on va encore se taper les CA pour 10 ans en parallel ?
Des solutions comme TACKs, certificate transparency, ou convergence sont bien plus prometteuse que DANE à mon humble avis.
[^] # Re: Et DANE simplement
Posté par Firwen (site web personnel) . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à -1. Dernière modification le 20 avril 2015 à 16:35.
En pratique, tous les noms de domaines des sites à gros trafic sont en .com sous leur control, tu changes uniquement 100% par 99%. Sans parler du fait que la "racine" elle-même a besoin d'être signée
Ils n'ont pas besoin de changer l'enregistrement de .com et ton script n'y changera pas grand chose. Si ils ont la clé privée qui sert à certifier les sous-domaines de .com, alors ils peuvent très bien falsifier la résolution de google.com et tu n'y verras que du feu. Tout comme avec le système de CA actuel.
La seul solution à ça est de ré implémenter encore une fois le pinning, mais cette fois avec DANE, comme mentionné dans l'article originel.
J'ai par ailleurs de gros problème avec l'association 1-1 entre DNS et autorité de certification de DANE.
Je veux choisir à qui je fais confiance.
Avec le système actuel, je peux: je l’enlève simplement de la liste des CA de confiance de mon application.
Avec DNSSEC, je ne peux pas : cette autorité est liée d'office à mon nom de domaine.
A mon sens, les hypothétiques avantages de DNSSEC/DANE ne justifient pas sa complexité de déploiement ni les problèmes annexes qu'il génerent :
Des solutions comme TACKs, certificate transparency, ou convergence sont bien plus prometteuse que DANE à mon humble avis.