Bye, bye, CloudFlare

Originalement, lors de la conception et du déploiement initial de l’infrastructure de Crypto.Québec, nous avions décidé d’utiliser les services de CloudFlare (CF), une compagnie californienne spécialisée dans la livraison de contenu et la mitigation d’attaques de déni de service distribuées. CloudFlare agit comme proxy inverse, permettant une gestion de cache rapide, une certaine répartition de charge (« load balancing ») en cas de surcharge et/ou d’attaque DDoS ainsi qu’une intégration conviviale de leur autorité de certification (CAs) avec notre propre certificat de sécurité SSL.

Or, ce sont ces mêmes avantages qui, dans le meilleur des cas, rendent l’utilisation des services de CloudFlare problématique ou, pour les plus paranoïaques d’entre-nous, une bombe à retardement orwellienne, dans le pire des cas. Nous en sommes venus à la conclusion que les désavantages pesaient plus lourd dans la balance que les avantages de l’utilisation des services de CloudFlare.

Bref, on a tiré la plug sur CF. Quelques explications s’imposent:

Un modèle de vérification de la réputation inadapté

CloudFlare est né de Project Honey Pot, qui a pour but de cataloguer l’ensemble des adresses IPs utilisées à des fins malicieuses: botnets, spammers, serveurs SMTPs compromis, hébergeurs de sites d’hameçonnage, etc. Une excellente initiative s’il en est une… mais qui vient avec son lot de faux positifs.

Project Honey Pot
Project Honey Pot

En effet, CF utilise ce service afin de vérifier la réputation d’une adresse IP effectuant une requête via son service de reverse proxy. Le problème est que CloudFlare semble très rapide sur la gâchette pour ce qui est d’imposer une vérification secondaire sur la livraison des pages (voir ci-dessous). En effet, des pans entiers d’adresses IP se retrouvent quasi-blacklistés; or, en 2016, le nombre d’IPv4 disponibles étant en décroissance accélérée, CF fini par mettre dans le même panier beaucoup, BEAUCOUP de pommes viables avec celles pourrîtes. C’est particulièrement problématique pour les utilisateurs d’IPs mutualisées, des hôtes en NAT et, ce qui accentue le problème dans notre cas étant donné notre vision et notre mission, pour les usagers de Tor (qui ne semblent pas être particulièrement appréciés chez CloudFlare).

Une expérience usager désagréable

Herse épeurante
Herse épeurante

Le plus gros problème, du point de vue d’une personne qui consulte notre site web (ou n’importe quel autre site utilisant CloudFlare), c’est l’étape de reCAPTCHA nécessaire avant la livraison de la page en cache par le proxy inverse de CF. En théorie, cette fonctionnalité existe principalement pour empêcher des crawlers, bots et autres scripts d’exécution/de lecture automatisés – souvent utilisés par des spammers – d’avoir accès au site web en question, les reCAPTCHAs modernes nécessitant absolument une interaction humaine.

Toutefois, CF impose ainsi une herse numérique intimidante pour l’utilisateur lambda, abaissant ainsi la confiance du visiteur envers le site qu’il désire visiter, sous prétexte de le protéger d’une menace qui, plus souvent qu’autrement, n’existe même pas (voir le point précédent).

Une énorme potentiel d’abus

Au final, CloudFlare reste une entreprise privée qui a pour but ultime, comme toutes les compagnies, la maximisation de ses profits. En tant qu’agent d’interception de requêtes et de livraison de contenu réécrit à coups de JavaScript, inutile de dire que le potentiel d’abus de ce modèle d’affaires est immense. Certains se souviendront du vieux slogan de Google, « Don’t be evil »… à la lumière de ce qu’on sait sur le modèle d’affaires de la compagnie de Mountain View (la mise en marché des habitudes, des goûts et des désirs de ses usagers), on peut se poser des questions sur les visées ultimes de l’entreprise de San Francisco, aussi.

Des critiques qui se multiplient

Nous ne sommes vraiment pas les seuls à se poser de sérieuses questions sur la réelle utilité de CloudFlare et la pertinence de certains de ses services.

Scott Helme démontre ici que l’aspect « Flexible SSL » de CF n’offre qu’une illusion de sécurité, facilement démontable:

The ability to present your site over https when the full route is not encrypted seems to be a breach of the trust that the user places on the indications their browser is giving them. There is the argument that encrypting part of the transport layer is better than encrypting none of it. Anyone between the user and their nearest CloudFlare server, like an attacker on a local network or even their ISP or government, wouldn’t be able to access their traffic, but after the CloudFlare server it’s back into the wild without any protection. Given that it’s really easy to create your own self signed certificate, or you can get a free one from StartSSL, I just can’t see the requirement for Flexible SSL.

D’autres, comme Sterling Poon, font la démonstration que CloudFlare n’est ni plus ni moins qu’une forme d’attaque de type Man-In-The-Middle avec laquelle nous choisissons de vivre :

By putting CloudFlare in this position, they are given a lot of power to change what is served to visitors. Furthermore, it is not possible right now to lock down how CloudFlare changes the site.

Ido Safruti de PerimeterX constate lui-aussi que le modèle utilisé par CF pour décider de la réputation d’une adresse, dans le contexte actuel du manque d’IPv4, n’est pas adapté à la réalité (particulièrement pour les utilisateurs de Tor):

Our conclusion is that relying on IP reputation as the sole indicator is highly susceptible to false positives (blocking legitimate users), and in the case of Tor network the risk is even higher. Even if you simply don’t want to allow any access by anonymous users, relying on the IP addresses is not enough, as they may carry requests/users that aren’t using Tor.

Conclusion

Malgré l’image d’en-tête utilisée pour ce billet (vous me permettrez ce coup de gueule) et le contenu de celui-ci, je tiens à le préciser: il n’y a pas que de mauvais côtés à CloudFlare et je crois qu’à la base, le raisonnement derrière l’implantation de ses fonctionnalités est légitime. En fait, certaines de celles-ci sont géniales, comme Rocket Loader, sa capacité de mitigation de DDoS qui n’est plus à prouver, et son service DNS, qui est l’un des plus rapides sur le marché.

Toutefois, pour nos besoins spécifiques ainsi que pour assurer la cohérence face à notre mission d’un point de vue d’accessibilité et de réduction du middle man, il nous est impossible de continuer à utiliser CF. En espérant que la compagnie sanfranciscaine écoutera les plaintes grandissantes face à son service dans un futur rapproché.

Facebooktwittergoogle_plusredditpinterestlinkedintumblrmailFacebooktwittergoogle_plusredditpinterestlinkedintumblrmail

Publié par

Jean-Philippe Décarie-Mathieu

Jean-Philippe Décarie-Mathieu

Co-fondateur de Crypto.Québec, administrateur de systèmes, consultant en sécurité informatique, conférencier, analyste, collaborateur à l'Actualité et übergeek assumé. Partisan du logiciel libre, hacktiviste et opérateur de nœud de sortie pour le Projet Tor. Cycliste, amateur de squash et de bières de microbrasserie pour compenser. Dort rarement.