1

DANEDNS-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

2

Survol

• TLS et SSL – rappels

• TLS et SSL - domaines d'application

• Limites et risques de SSL

• DNSSEC

• DANE

• Implications

• Questions ?

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

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

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)

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

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

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/

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)

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

11

DANE

• En deux mots

– Ajout d'une empreinte (hash) dans le DNS du certificat associé au nom à protéger:

– Signature de cet enregistrement (RRSIG, NSEC*)

– Utilisation de cette association de confiance pour renforcer les certificats SSL

• L'idée n'est pas nouvelle

– CERT RR (RFC4398)

– draft-schlyter-pkix-dns

_443._tcp.www.afnic.fr. IN TLSA 1 1 9F007579E2D61B0F8B756C9F342BAA3904C15A909997A3DB78F24BE8FC9CF1C7

http://www.ietf.org/mail-archive/web/dane/current/msg02402.html

Hash du certificatSSL de www.afnic.fr

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

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...:-)

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

15

DANE-WG

• Les documents du groupe de travail DANE

https://datatracker.ietf.org/wg/dane/

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 ?

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/

18

Questions...