Nouveau cas de certificat SSL frauduleux (contre Google.com en Iran, autorité DigiNotar)

Posté par (page perso) . Modéré par Christophe Guilloux. Licence CC by-sa
24
30
août
2011
Sécurité

L'Electronic Frontier Foundation (EFF), qui défend la liberté d'expression sur Internet, a publié hier un article concernant l'attaque Man-in-the-middle contre les utilisateurs de Google en Iran, qui a eu lieu en douce pendant deux mois.

Une nouvelle fois, la vulnérabilité des systèmes de chiffrement sur le web basés sur des autorités de certification est mis en lumière : encore une fois l'attaquant a obtenu un certificat frauduleux d'une autorité (cette fois-ci DigiNotar). L'attaque a été détectée via le navigateur Google Chrome car celui-ci embarque en dur des vérifications pour les certificats de Google.

Pour mémoire je vous rappelle les deux entrées dans l'aide du site LinuxFr.org concernant le certificat SSL/TLS de LinuxFr.org et alertes dans les navigateurs et la réponse à la question Pourquoi ne prenez pas un certificat SSL/TLS gratuit ou payant de chez Machin qui est par défaut dans un navigateur ? Ce dernier lien comporte notamment des pointeurs vers des affaires précédentes autour des certificats SSL/TLS et des autorités de confiance (Comodo, Microsoft et Tunisie, Defcon 2010, CCC 2010, Verisign 2003/2004).

  • # boucler la boucle ?

    Posté par . Évalué à -1.

    Au lieu d'avoir une chaine de confiance, n'est-il pas possible de faire une boucle ? En gros, que le site web envoie un js ou que le navigateur envoie des informations au serveur pour vérifier le certificat ?

    "La première sécurité est la liberté"

    • [^] # Re: boucler la boucle ?

      Posté par (page perso) . Évalué à 9.

      que le site web envoie un js

      Lapin compris.

      que le navigateur envoie des informations au serveur pour vérifier le certificat

      Aucun intérêt : si le serveur n'est déjà pas le bon mais celui d'un intercepteur, il répondra sans aucun doute ce que ton navigateur attend.

      • [^] # Re: boucler la boucle ?

        Posté par . Évalué à -1.

        Le site web peut envoyer du code JavaScript à faire exécuter sur le navigateur web pour un affichage avec un warning, ou bien le JS peut renvoyer les informations vers le site web.

        Pour éviter l'attaque MiM, il faudrait que la réécriture ne soit pas trivial du tout, ou très couteuse en temps de calculs (genre 1000 tours de SHA-2 comme CRC).

        "La première sécurité est la liberté"

        • [^] # Re: boucler la boucle ?

          Posté par (page perso) . Évalué à 10.

          Bah, l'attaquant n'aurait qu'à remplacer ce code JavaScript par du rien…

          Il ne faut pas compter sur le contenu transmis pour garantir quoi que ce soit, puisque ce contenu n'est garanti que s'il n'y a pas d'attaque.

    • [^] # Re: boucler la boucle ?

      Posté par . Évalué à 2.

      A la CA, en fait.
      C'est le but d'OSCP et des CRL : vérifier avant utilisation qu'un certificat n'a pas été révoqué !

      • [^] # Re: boucler la boucle ?

        Posté par (page perso) . Évalué à 10.

        Acronym overflow.

        • [^] # Re: boucler la boucle ?

          Posté par . Évalué à 4.

          Ok, reprenons.
          Il y a déjà des mécanismes embarqués dans le navigateur inter^W web qui permettent de vérifier si un certificat est valide :
          - les CRL (certificate revocation list) qui sont des listes signées par les autorités de certification contenant les certificats révoqués. Normalement l'URL ou aller la chercher est embarquée dans le certificat.
          - OSCP qui permet au brouteur d'aller interroger une autorité de certification sur la validité d'un certificat qu'elle a généré(quand c'est bien implémenté, ie: pas de réponse "ok vazy" = problème).

          Normalement quand le brouteur n'arrive pas à faire la vérification d'un certificat, il ne devrait pas laisser l'accès au site.

          • [^] # Re: boucler la boucle ?

            Posté par (page perso) . Évalué à 9.

            Très bien, sauf que ces mécanismes ne répondent absolument pas au problème principal de sécurité, qui est la corruption d'une autorité de certification, qui est présenté ici.

            • [^] # Re: boucler la boucle ?

              Posté par . Évalué à 1.

              Non, mais ça montre qu'il y a des solutions techniques qui existent pour limiter la casse quand on s'en rend compte.
              A part rentrer à la main toutes les clefs publiques en vérifiant toutes les empreintes dans ton magasin de clef, tu ne pourras pas éviter le problème du tiers de confiance qui merde (la CA, le brouteur, ton pote qui te refile une clef "de confiance", etc). Et je ne vois pas comment faire autrement avec une solution qui "scale" (ie qui marche out of the box à l'échelle d'Internet/Web).

              • [^] # Re: boucler la boucle ?

                Posté par (page perso) . Évalué à 3.

                Un réseau de confiance à la PGP ?

                • [^] # Re: boucler la boucle ?

                  Posté par (page perso) . Évalué à 6.

                  Pour ceux qui opposeraient qu'un réseau de confiance est trop compliqué à construire, je rappellerai que de tels systèmes n'ont rien de moins que le système pyramidal X.509, mais uniquement une caractéristique de *plus* : la possibilité d'avoir plusieurs signatures sur un certificat.

                  Par conséquent, un système de réseau de confiance permet de faire tout ce qu'un modèle pyramidal permet. En particulier, il est tout à fait possible d'implémenter un modèle pyramidal ou hybride à partir d'un système de réseau de confiance.

                • [^] # Re: boucler la boucle ?

                  Posté par . Évalué à 1.

                  C'est le but du projet "perspectives" http://perspectives-project.org/
                  Au lieu de faire confiance à la CA, le certificat est validé par un contrôle de vraisemblance au cours du temps, de manière décentralisée.

                  Petit inconvénient, l'extension firefox ne cohabite pas bien avec certpatrol (http://patrol.psyced.org/) qui permet de détecter les changements de certificats.

        • [^] # Re: boucler la boucle ?

          Posté par . Évalué à 3.

          Un AO quoi!

      • [^] # CACert et sa CRL

        Posté par . Évalué à 3.

        Anecdote intéressante, la CRL de CACert fait plus de 4 Mo, ce qui rendrait son utilisation plutôt acrobatique dans le cadre d'un client interactif (type navigateur Web) :

        $ curl -I http://crl.cacert.org/revoke.crl
        HTTP/1.1 200 OK
        Date: Tue, 30 Aug 2011 17:32:55 GMT
        Server: TUNIX-httpscreen/4.0
        Last-Modified: Tue, 30 Aug 2011 17:29:40 GMT
        ETag: "4abbc5b408900"
        Accept-Ranges: bytes
        Content-Length: 4351360
        Vary: Accept-Encoding
        Content-Type: text/plain
        
        

        (quant à TUNIX-httpscreen, je ne connais pas et le site http://www.tunix.nl/ semble uniquement en néerlandais...)

        • [^] # Re: CACert et sa CRL

          Posté par (page perso) . Évalué à 2.

          Ce qui pose d'ailleurs souci avec Opera, car le fichier n'est pas caché très longtemps (quelques minutes) et se rendre sur un site signé par CACert occasionne le téléchargement complet de la liste à nouveau, et le site n'est pas affiché avant ça, soit ~15-20 secondes de latence à chaque site rencontré, horrible.

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

          • [^] # Re: CACert et sa CRL

            Posté par . Évalué à 2.

            C'est tout le dilemme de la révocation de certificats SSL. Soit on met souvent à jour la liste de révocation, et on fait chier le monde (d'autant plus que la liste augmente en taille). Soit on met à jour plus rarement, et on encourt le risque d'une fuite exploitée entre temps.

            Et ce n'est pas vraiment mieux avec OCSP (le protocole de vérification de validité), puisqu'il suffit à l'attaquant de rendre le serveur OCSP inaccessible pour que le client se rabatte sur la dernière info connue.

            Une solution (chiante) est de délivrer des certificats pour une courte durée, ce qui fait qu'ils n'encombrent pas les CRLs trop longtemps en cas de pépin (ils deviennent vite invalides rien que par la date). Ou d'en délivrer peu. Bref, rien de très compatible avec le modèle actuel, qui encourage très peu de très gros opérateurs.

            • [^] # Re: CACert et sa CRL

              Posté par . Évalué à 2.

              Mais si tes certificats sont souvent changé, dans un mode décentralisé, il y a aura peu de "contre-signature", non ?

              "La première sécurité est la liberté"

    • [^] # Re: boucler la boucle ?

      Posté par (page perso) . Évalué à 3.

      Un « web of trust » à la GPG donc ? Le contraire d'un système centralisé à base d'autorité(s) de confiance.

      • [^] # Re: boucler la boucle ?

        Posté par . Évalué à 1.

        Plutôt un deuxième canal de vérification du certificat par le code HTML.

        "La première sécurité est la liberté"

        • [^] # Re: boucler la boucle ?

          Posté par . Évalué à 2.

          J'ai un peu de mal à comprendre le principe, en fait. Si tu as un gars qui fait du MITM, comment pourras-tu garantir que ton canal de vérification est intègre ? Si tu peux faire le calcul attendu, hors éléments secrets, je ne vois pas ce qui pourrait empêcher ton attaquant de renvoyer les bonnes valeurs (à toi, ou au serveur) ...

          • [^] # Re: boucler la boucle ?

            Posté par (page perso) . Évalué à 3.

            Si tu peux faire le calcul attendu, hors éléments secrets, je ne vois pas ce qui pourrait empêcher ton attaquant de renvoyer les bonnes valeurs

            Pire : l'attaquant peut tout simplement faire sauter le code de vérification, c'est beaucoup plus simple.

      • [^] # Re: boucler la boucle ?

        Posté par (page perso) . Évalué à 3.

        Monkeysphere. Dommage qu'il nécessite de laisser tourner un agent Monkeysphere.

  • # Un autre lien

    Posté par (page perso) . Évalué à 2.

    Un article qui analyse les problèmes du modèle SSL : http://lair.fifthhorseman.net/~dkg/tls-centralization/

    • [^] # Re: Un autre lien

      Posté par . Évalué à 2.

      Je ne vois pas où est la critique du modèle SSL (Secure Sockets Layer).

  • # Mises à jour Debian

    Posté par (page perso) . Évalué à 2.

    Debian vient aussi de retirer l'autorité de certification DigiNotar de ses paquets ca-certificates (Debian Security Advisory DSA-2299-1) et nss (DSA 2300).

    • [^] # Re: Mises à jour Debian

      Posté par (page perso) . Évalué à 2.

      D'après Wikipédia ( http://en.wikipedia.org/wiki/Diginotar ), Mozilla, Microsoft et Google l'ont aussi retiré. Mais on apprend aussi qu'il s'agit de l'autorité de certification du gouvernement néérlandais, notamment pour les impôts en ligne (Mozilla a whitelister les certificats du gouvernement à sa demande, mais il n'est pas sûr qu'ils n'aient pas été compromis).

      Petite anecdote, le site web est attaqué avec succès depuis 2009 par des pirates turques et iraniens.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Mises à jour Debian

        Posté par (page perso) . Évalué à 2.

        Ce qui est amusant, avec ces autorités nationales, c'est qu'elles donnent aux États la possibilité d'émettre pour leur propre usage des certificats usurpant l'identité d'autres acteurs. Autrement dit, de jour à l'homme du milieu sans que cela puisse être détecté par les utilisateurs. Mais après tout, les autorités de certification privées ont aussi ce pouvoir… :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.