RFC 6698 : The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol : TLSA
À chaque seconde, d’innombrables transactions sur l’Internet sont protégées contre l’écoute et la modification malveillante par le protocole #TLS. Ce dernier est capable de chiffrer la session (pour la protéger contre l’écoute par un tiers) et d’authentifier le pair avec qui on parle (pour s’assurer qu’on n’est pas en train de communiquer avec un usurpateur). Comment TLS authentifie t-il ? La méthode la plus courante aujourd’hui est de se servir de certificats #X.509 vérifiés (en théorie) par une Autorité de Certification. Ce mécanisme repose sur une confiance aveugle dans de très nombreuses organisations, et a de nombreuses faiblesses, comme on l’a vu en 2011 où le piratage de plusieurs AC a permis à des attaquants d’obtenir de « vrais-faux » certificats, y compris pour des organisations qui n’étaient pas clientes des AC piratées. La démonstration étant ainsi faite que X.509 n’était pas digne de la confiance que certains lui accordent, il restait à concevoir une meilleure solution. Rendue possible par le déploiement de #DNSSEC, voici #DANE (DNS-based Authentication of Named Entities) et ses enregistrements #DNS #TLSA. DANE permet à chacun de publier de manière sécurisés ses certificats, bouchant ainsi les vulnérabilités de X.509, ou permettant même de s’en passer complètement.
DANE permettrait par exemple, d’accéder à SeenThis sans se faire engueuler par son navigateur. Aujourd’hui, SeenThis est accessible en #HTTPS mais avec un certificat auto-signé, et pour un nom invalide ("SeenThis" et pas "seenthis.net"). Ajouter un enregistrement TLSA à _443._tcp.seenthis.net permettrait de ne plus avoir d’avertissement de sécurité (pour les futurs navigateurs Web avec gestion de DANE/TLSA).
►http://www.bortzmeyer.org/6698.html
#RFC