Etat des Lieux DANE (DNS Based Authentication of Named Entities) par Phil Regnauld au Séminaire du Conseil scientifique de l’AFNIC du 10 juin 2011

1. DANE
DNS-based Authentication of Named Entities
état des lieux
Séminaire du Conseil scientifique de l’AFNIC
10 juin 2011
Phil Regnauld <regnauld@nsrc.org>
Network Startup Resource Center
1

2. Survol
• TLS et SSL – rappels
• TLS et SSL - domaines d'application
• Limites et risques de SSL
• DNSSEC
• DANE
• Implications
• Questions ?
2

3. TLS et SSL - rappels
• SSL: 1994, TLS: 1999
• Rappel sur le fonctionnement de SSL
– Connexion à un serveur sécurisé
– Le serveur présente un certificat au client
– Le client vérifie la ”validité” du certificat
• Émis par une entité dans laquelle on a confiance
• Validité en cours (non-expiré)
• Chiffrement ”suffisant”
– Le client émet une clé de session symétrique S, chiffrée avec la clé publique
(cP) associée au certificat, et la transmet au serveur
– Le serveur déchiffre cette clé S avec sa clé privée (cS)
– Mise en place du ”socket” protégé, et utilisation de la clé de session
symétrique S pour l'échange des données
3

4. TLS et SSL – en résumé
• Donc:
– 1. valider certificat
– 2. créer une clé de session (symétrique)
– 3. utilisation de la clé de session pour chiffrer les
données
4

5. Autres protocoles
• Services Web
• Applications
– XMPP (Jabber)
– SMTP
– POP
– IMAP
– VPN-SSL
• Ces applications ne vérifient pas nécessairement la chaîne de
confiance du certificat
– Dans le monde SMTP, traditionnel d'utiliser des certificats auto-
signés (pas d'estampillage du certificat par une autorité de
certification)
5

6. TLS/SSL – risques et limites
• Plusieurs certificat dits de racine
– Confiance en plusieurs autorités de certification (CA)
– Risque plus grand ( x le nombres de CA)
• Modèle fondamentalement commercial (part de marché et accord avec les
”vendors” (développeurs de navigateurs)
– Pas n'importe qui peut faire ajouter son CA de racine aux côté de ceux livrés
avec le navigateur
• Un nombre d'attaques existent
– SSL spoofing: émission à la volée de certificats prétendant appartenir au
domaine sollicité, mais signés par un CA local
• Facile dans le monde des entreprises qui incluent leur clé de CA dans les navigateurs
des employés
• Utilisé par certaines passerelles dites de sécurité pour ”surveiller” (intercepter) le trafic
SSL des utilisateurs
6

7. TLS/SSL – risques & limites
(2)
• En raison des nombreuses autorités de certification présentes,
risque multiplié: rien n'empêche un CA X d'émettre des
certificats déjà émis par un CA Y!
– C'est le cas de la vulnérabilité Comodo de Mars 2011
• Brèche de sécurité chez le CA
• Émission de certificats pour des noms existants:
login.yahoo.com, login.skype.com, addons.mozilla.com, login.live.com
7

8. TLS/SSL – risques & limites
(3)
• Pour les navigateurs pas à jour, aucun moyen de vérifier que ces certificats ne
devraient pas être issus de ce CA plutôt qu'un autre
– Trop de certificats racine!
– Facile d'empêcher le navigateur de vérifier la liste de révocation des
certificats (CRL) via OCSP
– Il aura fallu 6 jours avant d'avoir un correctif ”en dur” dans Firefox!
http://samuelsidler.com/2011/03/28/timeline-of-comodo-certificate-compromise/
8

9. DNSSEC
• Introduction d'une racine de confiance unique
• Ce n'est pas le cas de SSL
… on a vu les risques de cette approche
• Le client qui valide (le résolveur/cache) n'a besoin que d'une seule
clé publique (”certificat”, mais c'est un abus de langage) pour
valider toute la chaîne du DNS mondial
• Basé sur la hiérarchie existante du DNS, avec ses avantages
(décentralisation, responsabilité pour ses propres données)
9

10. DNSSEC (2)
• Un certain nombre de choses deviennent possibles avec
DNSSEC
– Signature des enregistrements DNS traditionnels (NS, SOA, A,
AAAA, PTR, CNAME, …)
– Signature (et ”certification”) d'enregistrements moins répandus:
SSHFP par exemple
• Plus besoin de vérifier à la main la clé publique d'un serveur auquel on
se connecte la première fois, si un enregistrement SSHFP existe pour
ce serveur dans le DNS
… tant qu'on peut faire confiance au DNS
10

11. DANE
• En deux mots
– Ajout d'une empreinte (hash) dans le DNS du certificat associé au nom
à protéger:
_443._tcp.www.afnic.fr. IN TLSA 1 1
9F007579E2D61B0F8B756C9F342BAA3904C15A909997A3DB78F24BE8FC9CF1C7
– Signature de cet enregistrement (RRSIG, NSEC*)
– Utilisation de cette association de confiance pour renforcer les
certificats SSL
• L'idée n'est pas nouvelle
Hash du certificat
– CERT RR (RFC4398) SSL de www.afnic.fr
– draft-schlyter-pkix-dns
http://www.ietf.org/mail-archive/web/dane/current/msg02402.html
11

12. DANE (2)
• Cas d'application typique
– Je veux que les clients qui se connectent sur mon serveur puisse
s'assurer que mon certificat est bien émis par le CA que j'ai choisi, et
pas un autre!
• Un certificat émis par le CA X aura un hash unique
– C'est celui qui est publié et signé dans ma zone DNS
– Un client faisant une vérification DNSSEC, et à qui on présente
12

13. DANE (3)
• Un autre cas d'application plus intéressant
– Je génère mes propre certificats auto-signés
• (Avec ou sans CA local)
– Je place le hash de mon certificat dans ma zone
– Je signe, je publie mon DS dans la zone parent
– J'ai une chaîne de confiance qui va de la racine du DNS jusqu'au
nom que je veux protéger
• À vous de conclure...:-)
13

14. DANE (4)
• Support applicatif
– Nécessité d'implémenter le support dans les applications
– Définir une politique de réaction face à une validation incomplète
• S'assurer qu'une attaque en dégradation n'est pas possible
– Blocage des enregistrements NSEC/RRSIG dans le DNS
– On fait quoi ? Valide ou pas ?
• INVALIDE
• Sinon, même risques que bloquer OCSP sur un navigateur
14

15. DANE-WG
• Les documents du groupe de travail DANE
https://datatracker.ietf.org/wg/dane/
15

16. Conclusion
• La signature de la racine du DNS a moins d'un an
• Déjà un bon nombre de TLD signés
• Des applications... intéressantes
• Peut-être une évolution de certaines pratiques commerciales
– Il reste certainement un marché pour une validation ”physique”
d'un site d'e-commerce, façon Extended Validation
• DNSSEC: Une vraie PKI ?
16

17. Liens utiles
• https://datatracker.ietf.org/wg/dane/
• http://tools.ietf.org/wg/dane/charters
• http://www.ietf.org/id/draft-ietf-dane-use-cases-02.txt
• http://www.ietf.org/mail-archive/web/dane/current/msg02402.htm
• http://www.ietf.org/mail-archive/web/keyassure/current/msg01078.html
• http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity
• http://www.theregister.co.uk/2011/03/23/gmail_microsoft_web_credential_forgeries
• http://www.theregister.co.uk/2011/05/24/comodo_reseller_hacked/
• http://www.theregister.co.uk/2009/02/19/ssl_busting_demo/
• http://www.theregister.co.uk/2009/07/30/universal_ssl_certificate/
• http://www.theregister.co.uk/2008/12/30/ssl_spoofing/
17

18. Questions...
18