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)

931 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
931
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
7
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

×