DANE    DNS-based Authentication of Named Entities                  état des lieux    Séminaire du Conseil scientifique de...
Survol    •   TLS et SSL – rappels    •   TLS et SSL - domaines dapplication    •   Limites et risques de SSL    •   DNSSE...
TLS et SSL - rappels    •   SSL: 1994, TLS: 1999    •   Rappel sur le fonctionnement de SSL        –   Connexion à un serv...
TLS et SSL – en résumé    •   Donc:        –   1. valider certificat        –   2. créer une clé de session (symétrique)  ...
Autres protocoles    •   Services Web    •   Applications        –   XMPP (Jabber)        –   SMTP        –   POP        –...
TLS/SSL – risques et limites    •   Plusieurs certificat dits de racine        –   Confiance en plusieurs autorités de cer...
TLS/SSL – risques & limites                       (2)    •   En raison des nombreuses autorités de certification présentes...
TLS/SSL – risques & limites                          (3)    •     Pour les navigateurs pas à jour, aucun moyen de vérifier...
DNSSEC    •   Introduction dune racine de confiance unique    •   Ce nest pas le cas de SSL        … on a vu les risques d...
DNSSEC (2)     •   Un certain nombre de choses deviennent possibles avec         DNSSEC         –   Signature des enregist...
DANE     •   En deux mots         –   Ajout dune empreinte (hash) dans le DNS du certificat associé au nom             à p...
DANE (2)     •   Cas dapplication typique         –   Je veux que les clients qui se connectent sur mon serveur puisse    ...
DANE (3)     •   Un autre cas dapplication plus intéressant         –   Je génère mes propre certificats auto-signés      ...
DANE (4)     •   Support applicatif         –   Nécessité dimplémenter le support dans les applications         –   Défini...
DANE-WG     •   Les documents du groupe de travail DANE     https://datatracker.ietf.org/wg/dane/15
Conclusion     •   La signature de la racine du DNS a moins dun an     •   Déjà un bon nombre de TLD signés     •   Des ap...
Liens utiles     •   https://datatracker.ietf.org/wg/dane/     •   http://tools.ietf.org/wg/dane/charters     •   http://w...
Questions...18
Prochain SlideShare
Chargement dans…5
×

Etat des Lieux DANE (DNS Based Authentication of Named Entities)

1 013 vues

Publié le

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

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 013
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
11
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Etat des Lieux DANE (DNS Based Authentication of Named Entities)

  1. 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 Center1
  2. 2. Survol • TLS et SSL – rappels • TLS et SSL - domaines dapplication • Limites et risques de SSL • DNSSEC • DANE • Implications • Questions ?2
  3. 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ées3
  4. 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ées4
  5. 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 dutiliser des certificats auto- signés (pas destampillage du certificat par une autorité de certification)5
  6. 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 nimporte qui peut faire ajouter son CA de racine aux côté de ceux livrés avec le navigateur • Un nombre dattaques 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 utilisateurs6
  7. 7. TLS/SSL – risques & limites (2) • En raison des nombreuses autorités de certification présentes, risque multiplié: rien nempêche un CA X démettre des certificats déjà émis par un CA Y! – Cest 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.com7
  8. 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 quun autre – Trop de certificats racine! – Facile dempêcher le navigateur de vérifier la liste de révocation des certificats (CRL) via OCSP – Il aura fallu 6 jours avant davoir un correctif ”en dur” dans Firefox! http://samuelsidler.com/2011/03/28/timeline-of-comodo-certificate-compromise/8
  9. 9. DNSSEC • Introduction dune racine de confiance unique • Ce nest pas le cas de SSL … on a vu les risques de cette approche • Le client qui valide (le résolveur/cache) na besoin que dune seule clé publique (”certificat”, mais cest 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. 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”) denregistrements moins répandus: SSHFP par exemple • Plus besoin de vérifier à la main la clé publique dun serveur auquel on se connecte la première fois, si un enregistrement SSHFP existe pour ce serveur dans le DNS … tant quon peut faire confiance au DNS10
  11. 11. DANE • En deux mots – Ajout dune 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 • Lidée nest 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.html11
  12. 12. DANE (2) • Cas dapplication typique – Je veux que les clients qui se connectent sur mon serveur puisse sassurer que mon certificat est bien émis par le CA que jai choisi, et pas un autre! • Un certificat émis par le CA X aura un hash unique – Cest celui qui est publié et signé dans ma zone DNS – Un client faisant une vérification DNSSEC, et à qui on présente12
  13. 13. DANE (3) • Un autre cas dapplication 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 – Jai une chaîne de confiance qui va de la racine du DNS jusquau nom que je veux protéger • À vous de conclure...:-)13
  14. 14. DANE (4) • Support applicatif – Nécessité dimplémenter le support dans les applications – Définir une politique de réaction face à une validation incomplète • Sassurer quune attaque en dégradation nest 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 navigateur14
  15. 15. DANE-WG • Les documents du groupe de travail DANE https://datatracker.ietf.org/wg/dane/15
  16. 16. Conclusion • La signature de la racine du DNS a moins dun 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” dun site de-commerce, façon Extended Validation • DNSSEC: Une vraie PKI ?16
  17. 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. 18. Questions...18

×