Cloudbleed : le bug qui cache la forêt

Le mois dernier, un bug a été découvert par Tavis Omandy (un chercheur d’une équipe de Google) dans l’un des programmes utilisés par Cloudflare, une société américaine qui fournit différents services aux opérateurs de sites
Abonnez-vous ou connectez-vous pour lire le reste de cet article
Twitter Facebook Google Plus email

9 thoughts on “Cloudbleed : le bug qui cache la forêt”

  1. Excellent article. Et le coup du docteur Meluche est amusant

    Par contre, il y a une chose que je ne comprend/sais pas.
    Si vous faites du https, vous avez un certificat avec votre nom (ici reflet.info).
    Mais si je me connecte sur le site enmarche.fr via couldflare
    1) je devrai avoir un certificat couldflare.com et pas enmarche.fr-> pas de cadenas vert sur mon navigateur-> pas possible
    2) emarche.fr permet a cloudflare de decrypter ses communication en lui donnant ses cles prives -> je pense pas qu ils sont a ce point a la ramasse pour avoir fait ca
    3) il y a surement autre chose mais je sais pas quoi. Quelque un a une idee ?

    1. Solution 2: on fournit à cloudfare la clé privée (et on paie pour ça ^^’)

      https://support.cloudflare.com/hc/en-us/articles/200170466-How-do-I-upload-a-SSL-certificate-Business-or-Enterprise-only-

      Sinon c’est la solution 1:

      I have a certificate installed on my server, why am I seeing a Cloudflare certificate?

      When you use Cloudflare, we must decrypt the data at our edge in order to cache and filter any bad traffic. Depending on the SSL settings from above, we may re-encrypt or send it as plain text. (full vs flex) Since each certificate needs a dedicated IP address, we add your domain name and wildcard (*.domain.com) domain in the SAN (Subject Alt Name) to the certificate.

      https://support.cloudflare.com/hc/en-us/articles/204144518-SSL-FAQ

      1. vous voulez dire que cloudflare possede les cles prives de TOUS les sites qu ils protegent ?
        Eh ben, si j etait la NSA, j aurais cree cloudflare. Pourquoi s ingenier a espionner les gens s ils peuvent vous donner volontairement les clés …

    2. Alors, en entreprise (ou ailleurs), ça arrive (fréquement ?) de ne pas faire du https de bout en bout, en gros on arrête le https en bordure de DMZ ou autre. Concrètement, ça veut dire que oui, les clé privées ne sont pas sur le serveur qui publie réellement l’appli…
      Il y a de nombreuses raisons à ça, certaines pouvant se justifier (mais ça augmentera toujours le niveau de risque, il y a quelques cas assez spectaculaires lié à cette pratique…), d’autres étant totalement fumeuses !

      Après on peut très bien imaginer que cloudflare mette en pré requis de certains de ces services un chiffrement qui s’arrête à ses proxy… A votre avis que fait quelqu’un de « pas trop sensibilisé » à certaines thématiques qu’on connait bien ici ?

  2. Amusant comment la decentalisation technique du Web (par les reverse proxies entre autres) passe par sa centralisation commerciale (via CloudFlare et une poignee d’autres acteurs) et donc informationnelle (cette poignee d’acteurs voyant tout passer en clair, ce qui ne signifie pas necessairement qu’ils observent ces donnees).

    La seule maniere de decentraliser techniquement le Web sans passer par la centralisation economique serait de laisser les gerants de sites web effectuer la repartition du traffic eux-memes entre des proxies ou mirrors qu’ils gereraient eux-memes. La facture et/ou les requis en competence technique montant tres vite (comme vous le signalez dans l’article), c’est une solution encore lointaine.

  3. « nous nous contenterons donc de déplorer la tendance à la centralisation du Web, qui devient très préoccupante. »

    Bien d’accord.
    J’ai toujours pensé que cette omniprésence de cloudflare faisait plus de mal que de bien.
    Et quand en plus on utilise tbb, c’est infernal. Rien ne marche.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *