Faille dans SSL 3.0 et TLS 1.0

Posté par  . Modéré par patrick_g. Licence CC By‑SA.
49
25
sept.
2011
Sécurité

Une faille de sécurité dans le protocole SSL 3.0 (et inférieur) et TLS 1.0 a été découverte. Ces protocoles garantissent l’accès chiffré aux serveurs Web. Il n’y a donc plus aucun site Web qui est à l’abri d’une attaque « man in the middle ».

Concrètement, l’attaque consiste à injecter du texte connu dans une page Web (via du JavaScript introduit dans une publicité vérolée, par exemple). Après, il suffit d’écouter la conversion (il faut quand même une session de 30 minutes pour l’exploit actuel) pour découvrir la clef AES. L’exploit permet donc de déchiffrer la page, mais aussi les cookies, et donc de s’identifier sur le site visé.

La faille concerne la version 1.0 de TLS et est corrigée dans la version 1.1, sortie en 2006. En outre, OpenSSL propose un contournement depuis 2004 ; il consiste à injecter des données aléatoires dans la transaction. Malheureusement, les navigateurs utilisent principalement NSS plutôt qu’OpenSSL, et même si sur le serveur on peut forcer l’utilisation de TLS 1.1 ou 1.2, très peu de navigateurs Web les supportent, ce qui freine le déploiement sur les serveurs. Actuellement, seuls IE 9 et Opera en sont capables !

Il faut cependant noter que ces failles sont connues depuis longtemps, c’est ce qui avait mené au correctif dans OpenSSL et à la création de TLS 1.1. Mais c’est la première fois qu’une attaque est publiée, validant ces propositions.

Quelques conseils de navigation :

  • utiliser l’extension Firefox noscript ;
  • actuellement, là où l’attaque pourra faire le plus de dégât, est sur les webmails ou sur les systèmes de paiement tels que Paypal (ben oui, si quelqu’un pirate ma connexion sur LinuxFr.org, ce ne sera pas très grave, car j’utilise différents mots de passe). Privilégiez donc les clients de messagerie électronique comme mutt ou Thunderbird, en désactivant le HTML.

Merci à Altor pour son aide lors de la rédaction de cette dépêche.

Aller plus loin

  • # Alarmiste

    Posté par  (site web personnel) . Évalué à 10.

    Franchement cette dépêche est très alarmiste, alors que l'article de Stéphane Bortzmeier présenté dans la liste des sources ne l'est pas du tout.

    Il explique même que la presse s'est empressée de dénoncer la mort du SSL en l'absence de toutes preuves, ce que semble faire cette dépêche.

    Il n'y a donc plus aucun site web qui est à l'abri d'une attaque man in the middle.

    Je cite stéphane:

    C'est donc moins sexy qu'une nouvellement découverte faille du protocole mais la réalité est là : le problème principal est celui d'une non-mise à jour des logiciels, pour parer aux vulnérabilités connues. Les raisons de cette non-mise à jour sont nombreuses. Une d'elles est que gérer les nouvelles versions du protocole peut empêcher les connexions avec les serveurs bogués. En effet, le protocole TLS est conçu pour que les anciens clients puissent interagir avec les nouveaux serveurs et réciproquement, mais cela suppose que toutes les implémentations respectent la norme (qui décrit avec précision comment assurer la compatibilité des différentes versions, cf. annexe E du RFC 5246). Or, il existe beaucoup de programmes bogués, qui bloquent toute évolution du protocole (la faille de renégociation de TLS, corrigée par le RFC 5746, connaît des problèmes de déploiement similaires, un tiers des serveurs étaient encore vulnérables en 2010). Résultat, la plupart des serveurs TLS coupent TLS 1.1 et 1.2 pour éviter tout problème comme le montre l'excellente enquête de Qualys publiée à Blackhat.

    • [^] # Re: Alarmiste

      Posté par  . Évalué à 4.

      La faille reste tout de même sévère.
      Mais la dépêche n'est pas claire : il ne suffit pas d'insérer du texte, il faut injecter du JS qui soit exécuté et qui effectue une série de requêtes HTTPS vers la victime.
      Et il faut aussi avoir un moyen pour écouter le traffic réseau.

      Concrêtement, cette attaque réduit énormément la sécurité du HTTPS sur un réseau pas du tout sécurisé, genre un réseau wifi public. Mais heureusement, pas grand chose de plus...

      • [^] # Re: Alarmiste

        Posté par  (site web personnel) . Évalué à 7.

        cette attaque réduit énormément la sécurité du HTTPS sur un réseau pas du tout sécurisé, genre un réseau wifi public. Mais heureusement, pas grand chose de plus...

        Euh... Justement, c'est la l’intérêt de SSL : si tu as confiance dans ton réseau, point besoin de SSL! Si je comprend ce que tu dis, SSL serait donc utile à des moment où il est inutile, bizarre. SSL n'est-il pas utile quand tu n'as pas de réseau sécurisé?

        Et c'est pas comme si le Wifi public n'était pas fortement déployé (bars, hotels, FON...), et tout lem onde n'a pas li'dée de passer par un VPN (payant) au dessus.

        • [^] # Re: Alarmiste

          Posté par  . Évalué à 8.

          si tu as confiance dans ton réseau, point besoin de SSL!
          Si, tu as besoin de SSL parce que tu communiques pas que avec ton réseau. Mais après tu dois faire confiance en ton FAI pour qu'il te fasse pas une attaque MITM.

          • [^] # Re: Alarmiste

            Posté par  (site web personnel) . Évalué à 2.

            Question con : quelle différence fais-tu entre un mec qui se connecte au Wifi public et ton FAI? Parce que pour moi, les deux ont accès à exactement la même chose (le flux TCP/IP), et donc ont les mêmes moyens. Si l'un est faible, l'autre l'est tout autant.

            Pour quelle raison fais-tu la différence entre "sécurisé" (ton FAI seul) et "non sécurisé" (ton FAI + Wifi public) en matière de sécurité, à part le niveau de confiance dans ton FAI (qui n'empèche aucunement le MITM, juste tu imagine qu'il ne va pas le faire)?

        • [^] # Re: Alarmiste

          Posté par  . Évalué à 2.

          Et c'est pas comme si le Wifi public n'était pas fortement déployé (bars, hotels, FON...), et tout lem onde n'a pas li'dée de passer par un VPN (payant) au dessus.

          Pourquoi payant ? Rien ne t'empêche de créer un serveur VPN chez toi (openvpn par ex) et de t'y connecter lorsque tu es dans un réseau "glauque"...
          Le problème c'est que cette faille SSL compromet peut être aussi les tunnels VPN, à moins que ça ne touche que HTTPS dans ce cas on est sauvé...

          "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

          • [^] # Re: Alarmiste

            Posté par  (site web personnel) . Évalué à -4.

            Pourquoi payant ? Rien ne t'empêche de créer un serveur VPN chez toi (openvpn par ex) et de t'y connecter lorsque tu es dans un réseau "glauque"...

            Argh. Tu marques un point. Reste le prix de l'électricité du PC allumé (bon, pas chez moi, il est toujours allumé :) ) et de la complexité de mise en oeuvre pour Mr tout le monde.

            • [^] # Re: Alarmiste

              Posté par  (site web personnel) . Évalué à -1.

              t de la complexité de mise en oeuvre pour Mr tout le monde.

              aptitude install openssh-server un tunnel socks on a vu pire comme complexité.

              • [^] # Re: Alarmiste

                Posté par  (site web personnel) . Évalué à -4.

                j'ai tapé n'importe où avec le clavier vu que tu m'as pas dit ou taper ce texte, ça n'a rien fait. Tu peux parler une langue compréhensible par Mr tout le monde plutôt que de sortir du charabia de "Je me la pète, je suis un bidouilleur qui roxe et j'emmerde ceux qui ne parle pas ma langue"?

                Surtout que Mr tout le monde n'a pas Linux (<1% de part de marché de Mr tout le monde, super ta simplicité, faudrait ue j'installe un OS entier pour que ça soit "simple"!), et même sous Linux:
                [zenitram@localhost]# aptitude install openssh-server
                -bash: aptitude: command not found.
                (ben oui, chez d'autre c'est yum)

                Et après, c'est bien joli, j'ai installé openssh-server, et ça marche comment? Par miracle, n'importe quel PC à côté, je lui dis à haute voix "PC, fait un VPN", et il le fait?

                Bref, non, ce n'est pas aussi simple que tu veux le faire croire, tu fais juste l'élitiste qui ne veut surtout pas se mettre au niveau de Mr tout le monde, ça serait trop rabaissant.

                • [^] # Re: Alarmiste

                  Posté par  (site web personnel) . Évalué à 5.

                  Le lundi 26 septembre 2011 à 16:21 +0200, Zenitram a écrit :
                  > j'ai tapé n'importe où avec le clavier vu que tu m'as pas dit ou taper ce
                  > texte, ça n'a rien fait. Tu peux parler une langue compréhensible par Mr tout
                  > le monde plutôt que de sortir du charabia de "Je me la pète, je suis un
                  > bidouilleur qui roxe et j'emmerde ceux qui ne parle pas ma langue"?

                  On est sur dlfp pas au café du commerce, si c'est monsieur tout le monde qui me demande (faudrait déjà qu'il soit au courant des problèmes posés par TLS) là c'est toi qui parle de complexité de mise en œuvre, je dise juste que c'est pas si compliqué que ça (pour le "public dlfp")

                  Surtout que Mr tout le monde n'a pas Linux

                  les tunnels marchent avec putty. Les journalistes du boulot de ma nana l'utilisent sans problèmes pour accéder à leurs infra) et elles n'ont pas du tout un profil geek.

                  Et après, c'est bien joli, j'ai installé openssh-server, et ça marche
                  comment?

                  en gros tu monte un tunnel socks vers le serveur, et tu indique à tes appli de passer par le proxy socks

                  http://glr81.free.fr/pages/sshd-socks-proxy.htm

                  si tu veux rediriger tout le traffic tu peux utiliser tsocks ou sshuttle.

                  Depuis openssh 4.3 il est possible de monter des interfaces tunX mais je n'ai pas encore trop regardé comment ça fonctionne.

                  Bref, non, ce n'est pas aussi simple que tu veux le faire croire,

                  je veux rien te faire croire du tout. tu parle de vulnérabilité ssl, de
                  vpn, ça me semble pas hors de ta portée. J'ai pas posté ce commentaire
                  sur clubic.

                  tu fais juste l'élitiste qui ne veut surtout pas se mettre au niveau de Mr tout le monde, ça serait trop rabaissant.

                  non.

                  • [^] # Re: Alarmiste

                    Posté par  (site web personnel) . Évalué à -5.

                    On est sur dlfp pas au café du commerce, si c'est monsieur tout le monde qui me demande (faudrait déjà qu'il soit au courant des problèmes posés par TLS) là c'est toi qui parle de complexité de mise en œuvre, je dise juste que c'est pas si compliqué que ça (pour le "public dlfp")

                    Je me cite : "Et de la complexité de mise en oeuvre pour Mr tout le monde." (oui, c'est la phrase à laquelle tu as répondu).

                    les tunnels marchent avec putty.

                    Je ne savais pas que Putty faisait aussi serveur... (ben oui, Mr tout le monde n'a pas un serveur sous Linux sous la main, 99.99% des gens ont juste une machine chez eux, et encore, pas mal de gens ont juste un portable qu'ils baladent, et 99% des gens sont sous Windows ou Mac donc raté pour la "aptitude").

                    Bref, non, ce n'est toujours pas si simple, excepté pour de très rares personnes.

                    Désolé que je pense à Mr tout le monde et pas seulement aux lecteurs de LinuxFr... Mais je continuerai à penser à eux.

                    tu fais juste l'élitiste qui ne veut surtout pas se mettre au niveau de Mr tout le monde, ça serait trop rabaissant.

                    non.

                    Ben si, toujours.

                    • [^] # Re: Alarmiste

                      Posté par  (site web personnel) . Évalué à 6.

                      Le lundi 26 septembre 2011 à 17:31 +0200, Zenitram a écrit :
                      > oui, c'est la phrase à laquelle tu as répondu

                      effectivement je me suis un peu enflammé alors/

                • [^] # Re: Alarmiste

                  Posté par  . Évalué à 5.

                  Bref, non, ce n'est pas aussi simple que tu veux le faire croire, tu fais juste l'élitiste qui ne veut surtout pas se mettre au niveau de Mr tout le monde, ça serait trop rabaissant.

                  La complexité technique est un faux problème. Les gens sont parfaitement capables d'apprendre comment fonctionne un truc aussi complexe que Facebook, alors que pour un néophyte c'est affreusement compliqué. Perso, quand j'entends parler de "murs" ou "d'application Facebook" j'y pige absolument rien.

                  Le jour où j'ai voulu créer un compte MSN (y'a des années de ça), j'ai du m'y reprendre une demi-douzaine de fois pour passer la procédure complexe de création de compte, renseignement des données personnelles, saisie du captcha, de la question secrète, lecture et compréhension du CLUF, paramétrage du client.. alors qu'à l'époque je savais déjà installer une distro Linux et y configurer un VPN.

                  Ils sont capables de trouver leur chemin dans Poste de travail/clic droit/propriété/gestionnaire de périphérique/Internet pour changer les paramètres de leur navigateur Web, alors que ça n'a absolument rien d'intuitif ou d'évident comment chemin.

                  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

                  • [^] # Re: Alarmiste

                    Posté par  . Évalué à 0.

                    Ah là làààà, non, c'est pas "simple".
                    Pourquoi? Parce que l'utilisateur lambda ne veut pas apprendre à faire un truc pour faire un machin. Tu lui parles de VPN, il comprend qu'à la fin, il va sur internet, mais pas comme avant. Il sait pas trop s'il l'a fait ou pas. C'est compliqué (et surtout c'est chiant).
                    Tu lui demandes de s'adapter à la nouvelle nomenclature à la mode sur les systèmes de réseaux sociaux. Il va voir le résultat, c'est de l'utilisation directe, et ça, c'est coolࡊ!

                    Bref, aucun rapport!

        • [^] # Re: Alarmiste

          Posté par  . Évalué à 1.

          tout lem onde n'a pas li'dée de passer par un VPN (payant) au dessus

          Tu veux dire comme les solutions du genre vpntunnel.se, de type OpenVPN basé sur... OpenSSL ?

          D'ailleurs c'est une bonne question, ça. Est-ce que seul les browsers sont impactés, ou est-ce que cette faille peut être exploitée pour autre chose que de l'HTTPS ?

          • [^] # Re: Alarmiste

            Posté par  (site web personnel) . Évalué à 2.

            Si j'ai bien compris, OpenVPN utilise OpenSSL des deux côtés (client et serveurs), avec le patch qui va bien pour éviter ce genre d'attaque (pas de TLS 1.1 ou 1.2, mais des petites bidouilles autour de TLS 1.0), donc il ne semble pas que ce genre d'outil soit impacté à court terme (ça reste une faiblesse que d'utiliser TLS 1.0...). Le "hic" étant que les navigateurs n'utilisent pas OpenSSL, si encore une fois j'ai bien compris.

            • [^] # Re: Alarmiste

              Posté par  . Évalué à 8.

              Surtout que bon, pour injecter du Javascript dans un VPN, faut être imaginatif.

            • [^] # Re: Alarmiste

              Posté par  . Évalué à 2.

              Le "hic" étant que les navigateurs n'utilisent pas OpenSSL, si encore une fois j'ai bien compris.

              Bon, et pourquoi les navigateurs n'utiliseraient pas la même bidouille qu'OpenSSL dans leur propre pile crypto, ce qui règlerait le problème ?

    • [^] # Re: Alarmiste

      Posté par  . Évalué à 1.

      C'est donc moins sexy qu'une nouvellement découverte faille du protocole

      Même si ces failles ont été découvertes il y a longtemps, il y a désormais un exploit qui les mets en évidence. Je trouve justement l'article de Stéphane Bortzmeier trop peu alarmiste, ce n'est pas parce qu'on connait la faille depuis longtemps qu'elle devient moins dangereuse. Surtout qu'il n'y a quasiment aucun moyen de l'éviter, à part utiliser Opera vers des sites qui utilise TLS >= 1.1, ce qui doit fortement réduire tes possibilités de navigation.

      « 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: Alarmiste

      Posté par  (site web personnel) . Évalué à 2.

      Pour le problème de mauvais support, il "suffit" d'avoir un suite de test comme les test acid pour le css. On a vu que c'est très efficace pour pousser à l'amélioration.

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

  • # Chrome ne devrait pas être vulnérable

    Posté par  (site web personnel) . Évalué à -6.

    Ça fait quelques temps que Chrome interdit l'inclusion de Javascript non authentifié par les pages HTTPS (en tout cas, la beta le fait depuis plus d'un mois ). Un message apparaît demandant de valider manuellement le chargement du script.
    Google Chrome et Chromium ne devraient donc pas être vulnérables, ce qui illustre une fois de plus le soin apporté à la sécurité de ces navigateurs.

  • # En attendant, chez Microsoft et Opera, ils sont en avance

    Posté par  (site web personnel) . Évalué à 9.

    Bon, voyons voir, si on veut être super-secure, et interdire TLS 1.0 et n'accepter que des sites avec une version supérieure...
    Libre :
    Firefox : fail
    Chronium : fail

    Non libre :
    Opera : OK
    IE : OK

    Rigolo de voir que le non libre a une longueur d'avance sur le libre en matière de sécurité... Si on veut être en environnement secure (entre chez soit et le site), il faut accepter du proprio chez soit, pas mal comme bizarreté... Et moi qui croyait que le libre était sensible à la sécurité, ben non, Microsoft fait mieux!
    Eh! 2006 quand même, 5 ans... Et un "standard" fortement documenté (RFC tout ça...)

    • [^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance

      Posté par  . Évalué à -3.

      Ouais, enfin... Trouve des sites n'utilisant pas TLS 1.0, c'est beaucoup plus dur...

      • [^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance

        Posté par  (site web personnel) . Évalué à 9.

        Donc comme en face, c'est difficile, on ne fait pas évoluer le navigateur... super comme argument. Oeuf, poule... Le fait est la : client libre = TLS 1.0, client proprio = TLS 1.2, client proprio > client libre.
        Et si je maîtrise le serveur et qu'il est compatible TLS 1.2? ben voila : je dois utiliser du proprio pour être en sécurité. Ca reste un monde bizarre.

        Plutôt que de trouver des excuses, il faudrait accepter que parfois le proprio est en avance sur le libre en matière de sécurité, et arrêter avec cette idée que le libre est toujours meilleur en sécurité.

        • [^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance

          Posté par  . Évalué à 10.

          Pfff, tu veux argumenter comme ça ?
          OpenSSL contrait cette faille avant la sortie de TLS 1.1. Et Konqueror utilise OpenSSL.
          Après j'argumenterai pas sur le fait que c'est nul de la part de mozilla, vu que je le pense.

          • [^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance

            Posté par  (site web personnel) . Évalué à -8.

            Désolé, je m'étais arrêté aux navigateurs ayant plus de 0.1% de part de marché (j'ai zappé Safari, oups, mais la, comme ça, je ne trouve pas la version supportée).

            • [^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance

              Posté par  . Évalué à 2.

              Safari : TLS 1.0 (troisième lien de la dépêche). Aussi nul que Firefox et Chrome.

              Ce même lien montre bien (selon moi) que le fait que certains navigateurs se soient tournés les pouces pose un vrai problème pour ne plus être sujet à la faille (simplement passer à TLS 1.2 côté serveur signifie se couper d'une bonne partie du monde), et dit aussi un petit mot à propos des navigateurs pour mobiles.

              • [^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance

                Posté par  (site web personnel) . Évalué à 8.

                (troisième lien de la dépêche).

                Ca m'apprendra à ne pas cliquer sur tous les liens, oups.

                Ce même lien montre bien (selon moi) que le fait que certains navigateurs se soient tournés les pouces pose un vrai problème pour ne plus être sujet à la faille

                Clair. Perso, ce qui me "choque" est qu'on sait depuis 2004 que TLS 1.0 est "faible", mais "on" a laissé traîner les choses. Du moment où il y a une faiblesse détectée, on sait par expérience qu'il y aura quelque années plus tard une exploitation de la faiblesse. Mais "pas grave", jusqu'au moment où ça craint. Espérons que c'est une bonne piqûre de rappel et que les navigateurs vont prendre au sérieux le fait de gérer les protocoles plus récents.

                Ce que je trouve vraiment dommage est le fait que les logiciels libristes (à part Konqueror, OK!) ne font finalement pas mieux que les logiciels proprios au niveau importance sur la sécurité (=on laisse traîner). Firefox a été pas mal connu au début car il était accès sur la sécurité ("je te met Firefox, c'est moins troué que IE"), mais maintenant, Microsoft a remis des développeurs sur IE, et il se trouve qu'IE 9 a de sacrés atouts, alors que du côté de Firefox on a laissé la question de sécurité dans un coin, on dirait l'inversion des rôles : Microsoft devient l'outsider qui fait bien évoluer son navigateur alors que les autres se sont un peu trop reposé. Espérons que la concurrence fasse que tout le monde se réveille!

      • [^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance

        Posté par  . Évalué à 8.

        Euh la pour une fois il a raison, le libre est a la bourre sur le coup. Il reste konqueror a verifier dans la liste toutefois :)

        Et IE c'est tellement bourre de trou que une de plus, une de moins cela ne change pas grand chose mais c'est a noter que pour une fois le libre est pas a jour.

    • [^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance

      Posté par  . Évalué à 4.

      Konqueror utilise openssl.

      • [^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance

        Posté par  . Évalué à 1.

        Petite question à ce propos, sur un comportement qui m’inquiète. Lorsque je vais sur le site de ma banque (laposte) avec Konqueror j’ai quasi-systématiquement une alerte https lorsque la fenêtre d’identification s’ouvre. Avec Firefox pas de problèmes. D’autres ont constaté ce comportement ? Dois-je m’en inquiéter ? Est-ce lié au fait que les deux logiciels n’utilisent pas la même bibliothèque ?

  • # Précisions

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 25 septembre 2011 à 19:15.

    Une faille de sécurité dans le protocole SSL 3.0 (et inférieur) et TLS 1.0 a été découverte. Ces protocoles garantissent l'accès chiffrés aux serveurs web. Il n'y a donc plus aucun site web qui est à l'abri d'une attaque man in the middle.

    Faux.

    La faille n'a pas été découverte. Comme expliqué plus loin, c'est connu depuis longtemps. La nouveauté, c'est qu'un vecteur d'attaque a été découvert, et un exploit fonctionnel a été developpé.

    Concrètement, l'attaque consiste à injecter du texte connu dans une page web (via du JavaScript introduit dans une publicité vérolée par exemple). Après, il suffit d'écouter la conversion (il faut quand même une session de 30 minutes pour l'exploit actuel) pour découvrir la clef AES. L'exploit permet donc de déchiffrer la page mais aussi les cookies et donc de s'identifier sur le site visé.

    Totalement faux. L'exploit ne récupère pas la clef AES (d'ailleurs cette clef change entre chaque session) mais permet de récupérer des morceaux de cleartext, un byte à la fois.
    Le principe est le suivant : l'attaquant force la victime, via un JS introduit dans un flux non chiffré, à récupérer des éléments à des URLs précises, sur un site https (le simple fait d'inclure une image est suffisant). En utilisant des URL suffisamment longues et en introduisant des décalages, il est possible de deviner le dernier byte d'un bloc chiffré en AES-CBC.
    Il est donc possible de deviner le cookie pour https://www.paypal.com d'une victime, bien que cette victime ne visite pas le site.

    Il y a 3 manières de mitiger le problème :

    • Tout le monde passe en TLS 1.2. Ca va demander pas mal de temps de dev des deux côtés, vu que openssl ne supporte pas encore TLS1.2 et NSS non plus.
    • Les clients utilisent le workaround implémenté dans openssl, qui consiste à découper le premier paquet en deux. L'attaque n'est apparemment pas réalisable sur le deuxième paquet.
    • Les services sensibles sur https peuvent forcer la réécriture du cookie d'authentification à chaque accès, ou mieux, forcer la réécriture d'un cookie tampon contenant des valeurs aléatoires.

    Si TLS était mieux conçu, il aurait suffit d'activer AES256-CTR par défaut comme en SSH.

    • [^] # Re: Précisions

      Posté par  . Évalué à 7.

      Merci, j'en était arrivé aux même conclusions après avoir lu la publication des chercheurs.

      Et encore, le vecteur d'attaque demande de réussir à exploiter beaucoup de failles. Et même une fois le cookie obtenu, il sera difficile à la personne de l'exploiter pour se connecter réellement a un éventuel compte paypal s'il n'y a pas de session active au moment de l'attaque.

      • Il faut avoir un sniffeur sur le réseau.
      • Il faut avoir réussit à installer un script qui puisse faire des connections bidirectionnelles en SSL ou TLS avec le site web dont on veut obtenir le cookie. (websockets, plugins, java, etc..)
      • Il faut que le script puisse communiquer avec le sniffeur sur le réseau. (websocket, pugins, java etc...)
      • Il faut outrepasser les protections same-origin des navigateurs.
      • Il faut qu'une session sur le site visé soit ouverte pour effectivement espérer s'y connecter pour de vrai, car le cookie seul ne suffit pas à accéder à son compte paypal.

      Dans la pratique, cette attaque ne me semble réalisable qu'avec des moyens démesurés. Ce n'est pas impossible, cependant.

      • [^] # Re: Précisions

        Posté par  (site web personnel) . Évalué à 4.

        Donc pour une attaque de script-kiddie, ça le fait pas. Par contre, un attaquant expérimenté et persévérant peut venir à bout d'un utilisateur lambda sans trop de difficultés...

    • [^] # Re: Précisions

      Posté par  (site web personnel) . Évalué à 3.

      En gros, cela pousse à l'écriture d'un TLS 1.3 pour contrer tout problème future de mise à jour ? Il semble aussi que TLS 1.1 n'est pas vulnérable, est-ce que y passer est suffisant ?

      Est-ce que linuxfr est vulnérable ? :)

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

    • [^] # Re: Précisions

      Posté par  . Évalué à 2.

      A noter que TLSv1.1 suffit.

  • # Test sur LinuxFr.org

    Posté par  (site web personnel) . Évalué à 4.

    (identification du protocole utilisé par Wireshark 1.6.1)
    links 2.3 annonce du TLS v1.0.
    iceweasel 6.0.2 annonce du TLS v1.0.
    konqueror 4.6.5 annonce du TLS v1.0.
    Le serveur nginx utilisé propose SSLv2, SSLv3 ou TLSv1 (et dépend d'OpenSSL).

    • [^] # Re: Test sur LinuxFr.org

      Posté par  (site web personnel) . Évalué à 3.

      https://www.ssllabs.com/ssldb/analyze.html?d=https%3A%2F%2Flinuxfr.org

      This server supports secure renegotiation
      TLS 1.2 No
      TLS 1.1 No
      TLS 1.0 Yes
      SSL 3.0 Yes
      SSL 2.0+ Upgrade Support Yes
      SSL 2.0 No

      Bon, sécurité de 0 du fait que l'organisme root (CACert) n'est pas accepté par les navigateurs, dommage.

      • [^] # Re: Test sur LinuxFr.org

        Posté par  (site web personnel) . Évalué à 7.

        Bon, sécurité de 0 du fait que l'organisme root (CACert) n'est pas accepté par les navigateurs, dommage.

        Ouais, chacun place sa confiance où il veut (cf https://linuxfr.org/aide#aide-autrecertificatssl )

        https://www.ssllabs.com/ssldb/analyze.html?d=https%3A%2F%2Fdiginotar.com (dernier scandale en terme de certificat SSL) obtient 100% sur son certificat (!) et une mauvaise note sur le reste (leur boulot donc...).

        https://www.ssllabs.com/ssldb/analyze.html?d=comodo.com (scandale précédent) obtient 100% sur son certificat et une bonne note sur le reste (mais moins bonne que celle de LinuxFr.org).

        https://www.ssllabs.com/ssldb/analyze.html?d=verisign.com (encore un scandale) obtient 100% sur son certificat et une note pas trop mal sur le reste (mais moins bonne que celle de LinuxFr.org).

        • [^] # Re: Test sur LinuxFr.org

          Posté par  (site web personnel) . Évalué à 3.

          Oui, bon, en gros, un root qui n’intéresse personne, il est secure pas parce qu'il a fait tout ce qu'il fallait pour (comme se faire certifier), juste parce que peu de monde l'utilise. Certes, les root cités ont eu des problèmes, mais c'est aussi parce qu'ils... étaient intéressants pour les crackers. Sans compter le fait d'habituer les gens à se dire que les warnings des navigateurs, c'est pas méchants, allez hop on installe n'importe quel certificat (parce que pour aller chercher le certificat, il faut aller sur le site de CACert, avec un certificat qu'il a généré lui-même, donc je ne vois aucun moyen d'arriver sur linuxfr en milieu hostile sans me faire cracker dans le cas où quelqu'un veut)

          La sécurité par le non intérêt, c'est une façon de gérer la sécurité, chacun sa façon... Pas sûr que ce soit déployable à grand échelle.

          • [^] # Re: Test sur LinuxFr.org

            Posté par  (site web personnel) . Évalué à 9. Dernière modification le 25 septembre 2011 à 22:19.

            Certes, les root cités ont eu des problèmes, mais c'est aussi parce qu'ils... étaient intéressants pour les crackers.

            Dans certains cas, juste parce qu'on pouvait faire pression sur eux pour avoir des certificats génériques de complaisance ou pour avoir la main sur les certificats racine...

            je ne vois aucun moyen d'arriver sur linuxfr en milieu hostile sans me faire cracker dans le cas où quelqu'un veut)

            Je résume :

            • ce qui est affiché sur LinuxFr.org en clair, la somme de contrôle sur le certificat et l'autorité de confiance utilisée, on ne peut pas y faire confiance car il peut y avoir un MitM contre le site
            • le fait qu'un admin signe la somme de contrôle, on ne peut pas y faire confiance car il peut y avoir un MitM, l'admin n'en est peut-être pas un, et en plus il faut avoir un chemin de confiance GPG jusqu'à lui
            • en plus même en acceptant que CaCert est bien l'autorité de confiance de Linuxfr.org, sur leur site, ils ont un certificat autosigné ces fourbes (forcément), donc pas de raison d'avoir confiance.
            • et de toute façon mon navigateur - qui embarque des autorités de confiance dont on sait qu'elles ne sont pas de confiance et qui utilise un système dont on sait qu'il ne marche pas (faire confiance à des entreprises...) - bref mon navigateur me dit de ne pas avoir confiance, et sur ça je lui fais confiance.

            Bref on arrive à un des principes classiques en sécurité : à qui faire confiance ? Et si je ne fais confiance à personne, ben je n'ai pas grand chose... Sauf à réécrire tous mes logiciels de zéro et revalider toutes les RFC, les protocoles réseau et de chiffrement, etc.

            Globalement en environnement hostile, pour accéder au site (hypersensible :) LinuxFr.org :

            • soit je sais qu'il utilise CaCert (ça a été dit plein de fois), auquel cas je peux vérifier que tout est OK de zéro.
            • soit je ne sais pas qu'il utilise CaCert ou je n'ai pas confiance dans cette affirmation, et... ben à part essayer depuis un environnement non hostile pour comparaison, demander des confirmations à des gens, etc., je ne vois pas de solution miracle. Je ne vois pas trop ce que LinuxFr.org pourrait faire de plus qu'une chaîne de certificats valides par rapport à l'autorité de confiance choisie, l'affichage de la somme de contrôle sur le site en permanence, et même parfois signée par un des admins. Quelles sont les autres idées pour faire mieux ?

            Perso, plus ça va, plus j'aurais tendance à accorder ma confiance à un certificat autosigné par quelqu'un de sûr et connu, qu'à une hypothétique autorité de confiance dont je ne connais rien et qui a des consoeurs douteuses.

            • [^] # Re: Test sur LinuxFr.org

              Posté par  (site web personnel) . Évalué à 7.

              Tu oublis un point important : je fais confiance à la même personne depuis le début, c'est ce que je sais en voyant que le certificat ne change pas. C'est finalement le plus important : savoir que je discute avec la même entité depuis toujours.

              Sa réelle identité importe peu.

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

              • [^] # Re: Test sur LinuxFr.org

                Posté par  (site web personnel) . Évalué à 2.

                Je n'oublie pas, mais ça n'est valable que si tu as un jour été hors de l'environnement hostile... Si tu as un jour déjà utilisé LinuxFr.org en HTTPS dans une zone de confiance, tu as déjà validé le certificat par exemple et donc tout va bien. Si tu utilises LinuxFr.org depuis toujours depuis une zone louche, genre DictatureLand, beh... Quelques pistes : tâcher de se faire confirmer l'info par plusieurs personnes en espérant que..., vérifier sur archive.org et le cache google que le site avait bien la même tête et donnait bien la même signature du certificat il y a quelques mois en espérant que..., utiliser un autre moyen de communication pour avoir l'info (SMS, téléphone, courriel, etc.) en espérant...

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -1.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Commentaire supprimé

              Posté par  (site web personnel) . Évalué à 2. Dernière modification le 02 octobre 2011 à 12:40.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Test sur LinuxFr.org

                Posté par  . Évalué à 2.

                Ce commentaire a été supprimé par l'équipe de modération.
                

                ?????
                oui mais encore ?

                quelle entrée de http://linuxfr.org/regles_de_moderation a été activée pour ce commentaire ?

                Laurent

                • [^] # Re: Test sur LinuxFr.org

                  Posté par  (site web personnel) . Évalué à 3.

                  La suppression à la demande de l'auteur (moi). En l'occurrence la suppression par l'auteur lui-même, qui a répondu au commentaire en pensant qu'il s'agissait de la dépêche Hadopi et PDF, donc à côté de la plaque.

                  • [^] # Re: Test sur LinuxFr.org

                    Posté par  . Évalué à 3.

                    Peut-être le modérateur Benoît Sibaud devrait-il s'abstenir de corriger les erreurs de l'utilisateur Benoît Sibaud, au moins tant que les autres utilisateurs n'ont pas la même capacité.

                    • [^] # Re: Test sur LinuxFr.org

                      Posté par  (site web personnel) . Évalué à 1.

                      Les autres utilisateurs peuvent aussi demander à un modérateur de supprimer un commentaire. D'ailleurs, ça arrive de temps en temps.

                      • [^] # Re: Test sur LinuxFr.org

                        Posté par  . Évalué à 1.

                        Mais attention, avec les nouvelles failles de sécurité, je peux peut-être faire supprimer des commentaires appartenant à d'autres! (ou pas, mais vu que j'écrivais ça juste pour troller, pourquoi je devrais en plus vérifier la source de mes FUD?!?)

                        ---------> [ ]

                      • [^] # Re: Test sur LinuxFr.org

                        Posté par  . Évalué à 1.

                        La moindre des règles dans ce cas c'est de demander à un autre modérateur de le supprimer, et pas de le faire soi même, cf four eyes process.

                        Enfin bon, c'est une question d'éthique, après moi je m'en fous un peu. Pauvres drosophiles...

                      • [^] # Re: Test sur LinuxFr.org

                        Posté par  (site web personnel) . Évalué à 4.

                        Salut!

                        Vous pouvez supprimer ce commentaire?

            • [^] # Re: Test sur LinuxFr.org

              Posté par  . Évalué à 3.

              Je ne comprend pas le rapport avec la sécurité par l'obscurité.

              « 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: Test sur LinuxFr.org

              Posté par  . Évalué à 3.

              Oui, ben les virus ont pas été inventés pour animer nos vendredi:

              "Un ordinateur sous MS Windows non mis-à-jour et non protégé peut être contaminé en quelques minutes seulement en connexion directe à Internet!
              -Pffff... BeOS le faisait il y a 10ans!"

              -----------> [ ]

  • # La guerre des clones a commencé

    Posté par  . Évalué à 2.

    Voilà ce que j'ai lors d'une connexion IMAP chez gmail.com depuis Evolution :

    Erreur de certificat GMail

    Je vois également que j'ai une palanqué de packages à mettre à jour sur mon Lynx Lucide à cause de révocations de certificats.

    Fait chier.

  • # Config pour Apache

    Posté par  (site web personnel) . Évalué à 2.

    Hello,

    J'ai trouvé cela pour limiter les dégâts en attendant les mises à jour.
    (cela va prendre un peu de temps avec l'histoire de la poule et de l'oeuf)

    http://www.g-loaded.eu/2011/09/27/mod_gnutls-rc4-cipher-beast/

    SSLHonorCipherOrder on
    SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL

    En tout cas, le test sur SSLlabs semble se calmer avec cela.

    linux / linux / linux

Suivre le flux des commentaires

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