Journal MD5 considered harmful today

Posté par .
Tags : aucun
4
31
déc.
2008
Je suis tombé là dessus sur la ML de Debian Security : http://www.win.tue.nl/hashclash/rogue-ca/

Ca fait peur que des autorités de certification comme Verisign utilisent encore MD5 pour signer leur certificats. Pour ceux qui ne veulent pas lire, vérifiez que les certificats des sites que vous visitez ne sont pas signés avec MD5.

PS : sésolé du petit journal (je n'ai pas eu le temps de tout lire travail oblige !), mais devant l'importance de la chose et le fait que personne encore n'en a parlé ici j'ai décidé de poster le lien sans détailler.
  • # La réponse de verisign

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

    Verisign a publié une réponse[1] où ils expliquent que MD5 n'est plus utilisé pour les certificats.

    [1] https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabi(...)
  • # Mouais

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

    Il y a des choses qui me font plus peur genre https://bugzilla.mozilla.org/show_bug.cgi?id=470897

    Une autoritée acceptée par les navigateurs qui donne des certificats sans vérifier qu'on est propriétaire du domaine en question, et une semaine après que cela ait été signalé aucune mesure n'a encore été prise contre ce CA.

    Un autre problème. Le certificat en question a été révoqué par le CA après le bruit que ca a fait, mais comme je le dis en commentaire de http://taosecurity.blogspot.com/2008/12/traffic-for-revoked-(...) ça n'empeche pas de l'utiliser pour une attaque...
  • # "We basically broke SSL" annonce Alex Sotirov au CCC

    Posté par . Évalué à 5.

    L'implémentation de l'attaque est assez originale et relativement peu coûteuse (non, ce n'est pas une ferme de PIII), vu que ça a été fait avec la mise en parallèle de plus de 200 PS3.
    Cependant Satirov se veut plutôt rassurant : Selon lui l'attaque est difficile à répéter : il faudrait plus de 6 mois pour arriver à contrefaire un certificat avec une implémentation naïve.
    Enfin, ça va (peut-être ?) être le branle-bas de combat : révoquer les certificats utilisant MD5, mettre à jour les navigateurs pour générer une alerte de sécurité quand MD5 est utilisé.
    http://blogs.zdnet.com/security/?p=2339

    Le Web aura eu la vie dure cette année : les certificats SSL de Debian frelatés, la faille du protocole DNS…
    • [^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC

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

      Le Web aura eu la vie dure cette année : les certificats SSL de Debian frelatés, la faille du protocole DNS…

      Ça montre peut-être que, grâce à son expension, le web devient plus sérieux.

      Le problème, à mon avis, c'est que les gens qui utilisent le web avec des applications critiques mais dont le web n'est pas le métier (genre les banques) ne se posent pas la question de savoir si leur site sécurisé est vraiment sécurisé (enfin les banques ont autre chose à faire pour le moment).

      « 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: "We basically broke SSL" annonce Alex Sotirov au CCC

      Posté par . Évalué à 4.

      > Le Web aura eu la vie dure cette année : les certificats SSL de Debian frelatés, la faille du protocole DNS…

      Pour Debian, ça a été pire : ce ne sont pas que les certificats, mais toutes les clés générées par OpenSSL, qui ont été touchées - et comme on peut le voir, la liste de ce qui est potentiellement impacté est longue [1]. Dailleurs, depuis, je me suis acheté des smartcards : je ne les utilise pas pour tout (il m'en faudrait trop, et sur les serveurs, en cas de redémarrage, ce serait très chiant), mais c'est déjà ça.



      Par contre, pour le protocole DNS, ce n'est pas tant une faille qu'une vulnérabilité intrinsèque... autant DNS est quelque chose de crucial, autant ça se trimballe une sécurité de loutre bourrée : stateless avec UDP, en pratique : pas de chiffrement/authentification des DNS récursifs des FAI et cie, entropie artisanale comme garde-fou le plus courant contre la forge de réponse erronées...

      Sans compter le côté "si-si, je fais tout - je suis un enfer à configurer, et j'ai tendance à avoir une conf anti-sekioure par défaut, mais je fais tout" de Bind, probablement le serveur le plus utilisé dans le monde libre (chez moi, c'est pdns-recursor pour la récursion interne, unbound pour le cache commun à tout le monde, et nsd pour l'autoritaire - et l'expérience m'a montré qu'avec cette ségrégation, d'autant que j'utilise plusieurs pdns-recursor et nsd, pour reproduire le comportement des "views" de bind, il y a moins de danger de se tirer une balle dans le pied).

      Bah, forcément : avec, par exemple, l'augmentation des vitesses des connexions et l'augmentation du nombre de machines sur le net, ça _devait_ arriver... ça doit faire dans les 15 ans qu'on _sait_ que DNS est fragile comme de la porcelaine, et que si on peut gagner de l'entropie pour rendre plus ardu la forge de réponse malintentionnées, il _faut_ le faire... youpi : les ténors gras comme des loukoums se sont bougés en même temps pour tous mettre une rustine à un problème maintenant antique - m'enfin, à terme, ce n'est toujours pas ça qui va empêcher que ça va trancher...



      [1] http://wiki.debian.org/SSLkeys
      • [^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC

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

        Bind, probablement le serveur le plus utilisé dans le monde libre
        Le fait qu'un logiciel soit très utilisé ne reflète pas sa qualité. Clairement, bind est un exemple :-) Pourquoi les unixiens seraient plus malins que les autres ? On leur a appris bind à l'école, alors ils utilisent bind.
        En entretien d'embauche j'ai eu un questionnaire dont la partie dns était uniquement composée de question genre "quel est le nom du fichier de configuration d'un serveur dns ?" "quelle est la syntaxe pour déclarer un CNAME ?" etc. Ca n'est pas passé lorsque j'ai répondu genre "avec pdns c'est xxx" "avec djbdns c'est yyy". Le super informaticien qui avait pondu ce truc ne savait même pas qu'il existait autre chose que bind.

        pdns-recursor [...] unbound [...] nsd
        Même chose ici. Simple. Robuste. Fiable.
        Un reproche à pdns: dès qu'on veut des informations précises, la seule documentation valable est le code source. C'est moyen :-)
      • [^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC

        Posté par . Évalué à 2.

        Et si seulement ces logiciels portaient des noms refletant leur fonctionnalité principale genre:

        DNS-recursor
        DNS-common-cache (ok, unbound fait plus que ça)
        DNS-auth

        ça serait fichtrement plus simple, non?
        • [^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC

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

          Ca ne va pas être facile:

          apache --> famous-web-server
          Boa --> another-web-server
          Caudium --> another-again-web-server
          lighttpd --> light-web-server
          TUX web server --> stupidly-named-web-server

          linux --> os-kernel
          lynx --> web-broswer-for-real-men
          Mozilla Firefox --> challenger-web-broswer
          Opera --> less-known-challenger-web-broswer
          etc etc
          • [^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC

            Posté par . Évalué à 1.

            Premier arrivé, premier servi/

            Tu sais, il n'y a pas que l'anglais pour créer des noms de projet... un même nom commun balancé dans une autre langue (russe, turc, italien...) et hop, une particularité, une!.

            Biensûr on pourrait également jouer sur la graphie de certains mots, histoire d'ajouté une ptite note stylistique.

            Enfin...
  • # MD5 considered harmful today

    Posté par . Évalué à 3.

    Today ?
    C'est un vieux problème il me semble. Au moins 1 ans. Probablement 2.
  • # et OpenVPN?

    Posté par . Évalué à 1.

    Utilisant OpenVPN depuis quelques jours (ce logiciel utilise OpenSSL) et ayant lu comme quoi SSL n'est pas sûr, je me demande s'il faudrait que que change de VPN? si oui quelqu'un pourrait il m'en conseiller un ? IPSEC peux être?
    • [^] # Re: et OpenVPN?

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

      SSL n'est pas sûr

      De quoi tu parles ? Si tu fais référence à la précédente faille OpenSSL Debian, elle est corrigé depuis plusieurs mois.
      • [^] # Re: et OpenVPN?

        Posté par . Évalué à 2.

        L'authentification via SSL est quand même largement remise en cause.
        Après, la partie chiffrement est intacte, et je pense que pour le VPN ça n'aura pas d'impact (je peux me tromper, cependant).
      • [^] # Re: et OpenVPN?

        Posté par . Évalué à 1.

        Je parle de cela:
        << "We basically broke SSL" annonce Alex Sotirov au CCC>>
        • [^] # Re: et OpenVPN?

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

          Ah ouais ok, j'avais pas fait le lien. Bah il suffit de vérifier que le certificat n'est pas signé en utilisant MD5 ;-) Et puis bon, c'est pas courant 200 PS3 en réseau, il faut relativiser un peu.
          • [^] # Re: et OpenVPN?

            Posté par . Évalué à 2.

            Oui, puis, en plus, pour ce cas là :
            1. Ça demande une attaque Man-in-the-Middle, ce qui a au final assez peu de chance d'arriver au niveau du particulier utilisant un VPN (pas vraiment utile de passer plusieurs jours de temps machine pour un gain aussi faible, d'aller arnaquer les DNS ou des caches ARP si tu utilises directement ton IP).
            2. L'attaque est encore une fois assez complexe, et il est dit qu'avec une implémentation naïve elle prendrait au moins 6 mois avant d'aboutir.
            3. Je me demande si l'attaque marcherait dans ce cas : le certificat étant a priori auto-signé et c'est tout, pas de dispersions de certificats fils. Faudrait lire l'attaque avec soin, ce que j'avoue avoir la flemme de faire là maintenant.
      • [^] # Re: et OpenVPN?

        Posté par . Évalué à -1.

  • # L'avis de Bruce

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

    De toute façon, tout le monde (Tata et tonton ginete) s'en branle de SSL

    Dixit Bruce Schneier:

    But SSL doesn't provide much in the way of security, so breaking it doesn't harm security very much. Pretty much no one ever verifies SSL certificates, so there's not much attack value in being able to forge them. And even more generally, the major risks to data on the Internet are at the endpoints -- Trojans and rootkits on users' computers, attacks against databases and servers, etc -- and not in the network.

    http://www.schneier.com/blog/archives/2008/12/forging_ssl_ce(...)

Suivre le flux des commentaires

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