SlideShare une entreprise Scribd logo
1  sur  18
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
Survol

    •   TLS et SSL – rappels

    •   TLS et SSL - domaines d'application

    •   Limites et risques de SSL

    •   DNSSEC

    •   DANE

    •   Implications

    •   Questions ?



2
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
Questions...




18

Contenu connexe

Tendances

La sécurité sur le web
La sécurité sur le webLa sécurité sur le web
La sécurité sur le web
Softeam agency
 
Zabix formation-zabbix-supervision-d-infrastructure
Zabix formation-zabbix-supervision-d-infrastructureZabix formation-zabbix-supervision-d-infrastructure
Zabix formation-zabbix-supervision-d-infrastructure
CERTyou Formation
 
Tester la sécurité de votre annuaire Active Directory : top 10 des menaces et...
Tester la sécurité de votre annuaire Active Directory : top 10 des menaces et...Tester la sécurité de votre annuaire Active Directory : top 10 des menaces et...
Tester la sécurité de votre annuaire Active Directory : top 10 des menaces et...
Microsoft Décideurs IT
 

Tendances (20)

Webinar bonnes pratiques securite
Webinar   bonnes pratiques securiteWebinar   bonnes pratiques securite
Webinar bonnes pratiques securite
 
DDoS, la nouvelle arme des hackers
DDoS, la nouvelle arme des hackersDDoS, la nouvelle arme des hackers
DDoS, la nouvelle arme des hackers
 
Sécurité des applications Web
Sécurité des applications WebSécurité des applications Web
Sécurité des applications Web
 
Mini projet Zabbix
Mini projet ZabbixMini projet Zabbix
Mini projet Zabbix
 
Sécurité Active Directory : détecter l’indétectable !
Sécurité Active Directory : détecter l’indétectable !Sécurité Active Directory : détecter l’indétectable !
Sécurité Active Directory : détecter l’indétectable !
 
La sécurité sur le web
La sécurité sur le webLa sécurité sur le web
La sécurité sur le web
 
Présentation sécurité open_ssl
Présentation sécurité open_sslPrésentation sécurité open_ssl
Présentation sécurité open_ssl
 
Zabix formation-zabbix-supervision-d-infrastructure
Zabix formation-zabbix-supervision-d-infrastructureZabix formation-zabbix-supervision-d-infrastructure
Zabix formation-zabbix-supervision-d-infrastructure
 
Présentation Microsoft Advanced Threat Analytics | Deep-Dive - MSCloud Summi...
Présentation Microsoft Advanced Threat Analytics  | Deep-Dive - MSCloud Summi...Présentation Microsoft Advanced Threat Analytics  | Deep-Dive - MSCloud Summi...
Présentation Microsoft Advanced Threat Analytics | Deep-Dive - MSCloud Summi...
 
Introduction à La Sécurité Informatique 2/2
Introduction à La Sécurité Informatique 2/2Introduction à La Sécurité Informatique 2/2
Introduction à La Sécurité Informatique 2/2
 
Sécuriser mes applications avec ZF2
Sécuriser mes applications avec ZF2Sécuriser mes applications avec ZF2
Sécuriser mes applications avec ZF2
 
Rapport sécurité
Rapport sécuritéRapport sécurité
Rapport sécurité
 
VPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCO
VPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCOVPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCO
VPN NOMADE AVEC AUTHENTIFICATIO AD SOUS ROUTEUR CISCO
 
Free radius
Free radiusFree radius
Free radius
 
Sécurité Active Directory: Etablir un référentiel
Sécurité Active Directory: Etablir un référentielSécurité Active Directory: Etablir un référentiel
Sécurité Active Directory: Etablir un référentiel
 
OWASP Québec - octobre 2016 - présentation sur les mots de passe
OWASP Québec - octobre 2016 - présentation sur les mots de passeOWASP Québec - octobre 2016 - présentation sur les mots de passe
OWASP Québec - octobre 2016 - présentation sur les mots de passe
 
Comment choisir son certificat ssl fr v01
Comment choisir son certificat ssl fr v01Comment choisir son certificat ssl fr v01
Comment choisir son certificat ssl fr v01
 
Tester la sécurité de votre annuaire Active Directory : top 10 des menaces et...
Tester la sécurité de votre annuaire Active Directory : top 10 des menaces et...Tester la sécurité de votre annuaire Active Directory : top 10 des menaces et...
Tester la sécurité de votre annuaire Active Directory : top 10 des menaces et...
 
Authentification TLS/SSL sous OpenVPN
Authentification TLS/SSL sous OpenVPNAuthentification TLS/SSL sous OpenVPN
Authentification TLS/SSL sous OpenVPN
 
Vpn d’acces avec cisco asa 5500 et client
Vpn d’acces avec cisco asa 5500 et clientVpn d’acces avec cisco asa 5500 et client
Vpn d’acces avec cisco asa 5500 et client
 

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

Strong Authentication with PKI
Strong Authentication with PKIStrong Authentication with PKI
Strong Authentication with PKI
Sylvain Maret
 
07 03 sécurisation d'un serveur dns
07 03 sécurisation d'un serveur dns07 03 sécurisation d'un serveur dns
07 03 sécurisation d'un serveur dns
Noël
 
chap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdfchap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdf
depinfo
 
Sécurités & Annuaires
Sécurités & AnnuairesSécurités & Annuaires
Sécurités & Annuaires
Paulin CHOUDJA
 
ssl-presentation-180811194533.pdf
ssl-presentation-180811194533.pdfssl-presentation-180811194533.pdf
ssl-presentation-180811194533.pdf
Iyadtech
 
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
Cyber Security Alliance
 
Securite des Web Services (SOAP vs REST) / OWASP Geneva dec. 2012
Securite des Web Services (SOAP vs REST) / OWASP Geneva dec. 2012Securite des Web Services (SOAP vs REST) / OWASP Geneva dec. 2012
Securite des Web Services (SOAP vs REST) / OWASP Geneva dec. 2012
Sylvain Maret
 

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

Strong Authentication with PKI
Strong Authentication with PKIStrong Authentication with PKI
Strong Authentication with PKI
 
Projet Pki Etapes Clefs
Projet Pki   Etapes ClefsProjet Pki   Etapes Clefs
Projet Pki Etapes Clefs
 
BSidesQuebec2013-ssl
BSidesQuebec2013-sslBSidesQuebec2013-ssl
BSidesQuebec2013-ssl
 
07 03 sécurisation d'un serveur dns
07 03 sécurisation d'un serveur dns07 03 sécurisation d'un serveur dns
07 03 sécurisation d'un serveur dns
 
Rapport sécurité
Rapport sécuritéRapport sécurité
Rapport sécurité
 
Comment publier vos applications Web avec Windows Server 2012 R2
Comment publier vos applications Web avec Windows Server 2012 R2 Comment publier vos applications Web avec Windows Server 2012 R2
Comment publier vos applications Web avec Windows Server 2012 R2
 
chap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdfchap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdf
 
Cours HTTPS pour UnPointZero
Cours HTTPS pour UnPointZeroCours HTTPS pour UnPointZero
Cours HTTPS pour UnPointZero
 
Rétro-ingénierie de protocole crypto: Un "starter pack"
Rétro-ingénierie de protocole crypto: Un "starter pack"Rétro-ingénierie de protocole crypto: Un "starter pack"
Rétro-ingénierie de protocole crypto: Un "starter pack"
 
Domain Name System Security Extensions (aka. DNSSEC pour les intimes)
Domain Name System Security Extensions (aka. DNSSEC  pour les intimes)Domain Name System Security Extensions (aka. DNSSEC  pour les intimes)
Domain Name System Security Extensions (aka. DNSSEC pour les intimes)
 
Architecture Lync - Deep dive avec nos experts
Architecture Lync - Deep dive avec nos experts Architecture Lync - Deep dive avec nos experts
Architecture Lync - Deep dive avec nos experts
 
Sécurités & Annuaires
Sécurités & AnnuairesSécurités & Annuaires
Sécurités & Annuaires
 
Surveillances de Nom de domaines : fonctionnement, bonnes pratiques et usages...
Surveillances de Nom de domaines : fonctionnement, bonnes pratiques et usages...Surveillances de Nom de domaines : fonctionnement, bonnes pratiques et usages...
Surveillances de Nom de domaines : fonctionnement, bonnes pratiques et usages...
 
Certifs x509
Certifs x509Certifs x509
Certifs x509
 
Présentation Nano Server MS Afterwork Nouméa
Présentation Nano Server MS Afterwork NouméaPrésentation Nano Server MS Afterwork Nouméa
Présentation Nano Server MS Afterwork Nouméa
 
ssl-presentation-180811194533.pdf
ssl-presentation-180811194533.pdfssl-presentation-180811194533.pdf
ssl-presentation-180811194533.pdf
 
Les défis les plus fréquents dans l’implémentation de HTTPS
Les défis les plus fréquents dans l’implémentation de HTTPSLes défis les plus fréquents dans l’implémentation de HTTPS
Les défis les plus fréquents dans l’implémentation de HTTPS
 
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
 
SSL.pdf
SSL.pdfSSL.pdf
SSL.pdf
 
Securite des Web Services (SOAP vs REST) / OWASP Geneva dec. 2012
Securite des Web Services (SOAP vs REST) / OWASP Geneva dec. 2012Securite des Web Services (SOAP vs REST) / OWASP Geneva dec. 2012
Securite des Web Services (SOAP vs REST) / OWASP Geneva dec. 2012
 

Plus de Afnic

JCSA2013 01 Tutoriel Stéphane Bortzmeyer "Tout réseau a besoin d'identificate...
JCSA2013 01 Tutoriel Stéphane Bortzmeyer "Tout réseau a besoin d'identificate...JCSA2013 01 Tutoriel Stéphane Bortzmeyer "Tout réseau a besoin d'identificate...
JCSA2013 01 Tutoriel Stéphane Bortzmeyer "Tout réseau a besoin d'identificate...
Afnic
 
Afnic Public Consultation overview on the Opening of 1 and 2 characters
Afnic Public Consultation overview on the Opening of 1 and 2 charactersAfnic Public Consultation overview on the Opening of 1 and 2 characters
Afnic Public Consultation overview on the Opening of 1 and 2 characters
Afnic
 

Plus de Afnic (20)

Alternative Dispute Resolution Trends 2015 (1st Semester)
Alternative Dispute Resolution Trends 2015 (1st Semester)Alternative Dispute Resolution Trends 2015 (1st Semester)
Alternative Dispute Resolution Trends 2015 (1st Semester)
 
Tendances PARL 2015 (1er trimestre)
Tendances PARL 2015 (1er trimestre)Tendances PARL 2015 (1er trimestre)
Tendances PARL 2015 (1er trimestre)
 
Securing Internet communications end-to-end with the DANE protocol
Securing Internet communications end-to-end with the DANE protocolSecuring Internet communications end-to-end with the DANE protocol
Securing Internet communications end-to-end with the DANE protocol
 
Sécuriser les communications sur Internet de bout-en-bout avec le protocole DANE
Sécuriser les communications sur Internet de bout-en-bout avec le protocole DANESécuriser les communications sur Internet de bout-en-bout avec le protocole DANE
Sécuriser les communications sur Internet de bout-en-bout avec le protocole DANE
 
Deploying DNSSEC: what, how and where ?
Deploying DNSSEC: what, how and where ?Deploying DNSSEC: what, how and where ?
Deploying DNSSEC: what, how and where ?
 
Déployer DNSSEC, comment, quoi, où ?
Déployer DNSSEC, comment, quoi, où ?Déployer DNSSEC, comment, quoi, où ?
Déployer DNSSEC, comment, quoi, où ?
 
.fr domain name life cycle
.fr domain name life cycle .fr domain name life cycle
.fr domain name life cycle
 
Cycle de vie d'un nom de domaine en .fr
Cycle de vie d'un nom de domaine en .frCycle de vie d'un nom de domaine en .fr
Cycle de vie d'un nom de domaine en .fr
 
JCSA2013 08 - Isabelle Chrisment - L'initiative "PLATeforme d'observation de ...
JCSA2013 08 - Isabelle Chrisment - L'initiative "PLATeforme d'observation de ...JCSA2013 08 - Isabelle Chrisment - L'initiative "PLATeforme d'observation de ...
JCSA2013 08 - Isabelle Chrisment - L'initiative "PLATeforme d'observation de ...
 
JCSA2013 07 Pierre Lorinquer & Samia M'timet - Observatoire de la résilience ...
JCSA2013 07 Pierre Lorinquer & Samia M'timet - Observatoire de la résilience ...JCSA2013 07 Pierre Lorinquer & Samia M'timet - Observatoire de la résilience ...
JCSA2013 07 Pierre Lorinquer & Samia M'timet - Observatoire de la résilience ...
 
JCSA2013 06 Luigi Iannone - Le protocole LISP ("Locator/Identifier Sepration ...
JCSA2013 06 Luigi Iannone - Le protocole LISP ("Locator/Identifier Sepration ...JCSA2013 06 Luigi Iannone - Le protocole LISP ("Locator/Identifier Sepration ...
JCSA2013 06 Luigi Iannone - Le protocole LISP ("Locator/Identifier Sepration ...
 
JCSA2013 05 Pascal Thubert - La frange polymorphe de l'Internet
JCSA2013 05 Pascal Thubert - La frange polymorphe de l'InternetJCSA2013 05 Pascal Thubert - La frange polymorphe de l'Internet
JCSA2013 05 Pascal Thubert - La frange polymorphe de l'Internet
 
JCSA2013 04 Laurent Toutain - La frange polymorphe de l'Internet
JCSA2013 04 Laurent Toutain - La frange polymorphe de l'InternetJCSA2013 04 Laurent Toutain - La frange polymorphe de l'Internet
JCSA2013 04 Laurent Toutain - La frange polymorphe de l'Internet
 
JCSA2013 03 Christian Jacquenet - Nouveau shéma d'acheminement de trafic déte...
JCSA2013 03 Christian Jacquenet - Nouveau shéma d'acheminement de trafic déte...JCSA2013 03 Christian Jacquenet - Nouveau shéma d'acheminement de trafic déte...
JCSA2013 03 Christian Jacquenet - Nouveau shéma d'acheminement de trafic déte...
 
JCSA2013 02 Laurent Toutain - Introduction du Séminaire 2013
JCSA2013 02 Laurent Toutain - Introduction du Séminaire 2013JCSA2013 02 Laurent Toutain - Introduction du Séminaire 2013
JCSA2013 02 Laurent Toutain - Introduction du Séminaire 2013
 
JCSA2013 01 Tutoriel Stéphane Bortzmeyer "Tout réseau a besoin d'identificate...
JCSA2013 01 Tutoriel Stéphane Bortzmeyer "Tout réseau a besoin d'identificate...JCSA2013 01 Tutoriel Stéphane Bortzmeyer "Tout réseau a besoin d'identificate...
JCSA2013 01 Tutoriel Stéphane Bortzmeyer "Tout réseau a besoin d'identificate...
 
New gTLDs: a new Big Bang for domain names
New gTLDs: a new Big Bang for domain namesNew gTLDs: a new Big Bang for domain names
New gTLDs: a new Big Bang for domain names
 
Nouvelles extensions Internet : un nouveau Big Bang pour les noms de domaine
Nouvelles extensions Internet : un nouveau Big Bang pour les noms de domaineNouvelles extensions Internet : un nouveau Big Bang pour les noms de domaine
Nouvelles extensions Internet : un nouveau Big Bang pour les noms de domaine
 
Observatoire sur la résilience Internet en France-2012
Observatoire sur la résilience Internet en France-2012Observatoire sur la résilience Internet en France-2012
Observatoire sur la résilience Internet en France-2012
 
Afnic Public Consultation overview on the Opening of 1 and 2 characters
Afnic Public Consultation overview on the Opening of 1 and 2 charactersAfnic Public Consultation overview on the Opening of 1 and 2 characters
Afnic Public Consultation overview on the Opening of 1 and 2 characters
 

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

  • 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