Nous sommes sur LinuxFr.org et je pense qu'il n'est pas essentiel d'expliquer ô combien les traqueurs sont dangereux pour nous.
gateGhost est un logiciel proxy anti-traqueur de publicité qui prévient les risques de tracking sur l'intégralité d'un réseau.
Il fonctionne comme plugin de gatejs et est distribué sous licence GPL v3.
Il est basé sur un système de détection de traqueurs qui fonctionne avec une base de données CSV. Celui-ci permet de bloquer lesdits traqueurs soit par une fermeture de connexion, soit avec un code d'erreur 403. Il est aussi possible d'ajouter d'autres bases de données.
Mode de fonctionnement
Les cookies
Le système d'inspection de cookie permet d'éliminer ceux qui n'ont pas été envoyés par le site consulté, ceux qui sont hors de son contrôle. Là aussi, il y a une base de données de noms de cookie à éviter. Le cookie de l'utilisateur est modifié puis forgé avant d'être renvoyé au serveur. Nous n'avons pas constaté d'impact sur la navigation en utilisant cette technique.
Le Referer
L'entête Referer trahit aussi nos mouvements sur la toile, il indique au site consulté d'où provient précisément la requête (le lien source).
L'utilisation de cet entête est tout à fait normale et même importante. Cependant, dans certains cas, il n'est pas souhaitable d'envoyer cette information.
gateGhost enlèvera systématiquement les Referer d'une requête quand le domaine n'est pas estimé comme proche.
En outre, une requête vers ads.tracker.com mais provenant de www.example.com ne sera pas considérée comme de confiance puisque tracker.com ne correspond pas à example.com. Dans ce cas, l'entête Referer est supprimée.
Etag
Une autre technique, plus rare, consiste à faire passer des mouchards par l'entête ETag. Une petite recherche "tracking without cookie" vous permettra de comprendre le mécanisme.
En tout état de cause, et parce que le ETag ne sert plus réellement aux systèmes de cache, l'entête est systématiquement supprimé de la réponse du serveur. Cette option est activée par défaut.
Tout est activable et désactivable à volonté.
Le SSL
Côté inconvénient, gateGhost peut poser problème quand une application, en général pour smartphones, fait du « certificat pinning », c'est-à-dire que le CA de confiance est hardcodé dans l'application. Cela empêche l'interception SSL sans erreur par l'installation d'un CA de confiance.
J'ai encore pas mal de choses à ajouter au projet telles que l'interception « propre » du SSL et la détection d'envoi de données de géolocalisation. Je précise que les contributions sont ouvertes.
Il faut aussi savoir que gateGhost est complémentaire à l'utilisation d'ads blockers ou anti-tracker installés comme greffons sur le navigateur (tel que adblocks ou ghostery), sauf que ces derniers ne s'installent pas sur un réseau et ne protègent donc pas les smartphones. Aussi, gateGhost exécute plus vite les règles via un gestionnaire spécial de mémoire associative disponible dans gatejs sous le nom de NREG.
En tout état de cause le job est fait, et ce, de manière très performante.
Points clefs
- Conçu pour les grosses architectures
- ~1900 traqueurs enregistrés dans la base de données avec un système de recherche rapide
- Système d'inspection des cookies avec jusqu'à 100 noms de cookie connus
- Système de confiance sur l'entête Referer qui est enlevé quand il est non-voulu
- Technique de blocage du "tracking without cookie" basée sur l'entête HTTP ETag
- Possibilité d'ajouter vos traqueurs
Aller plus loin
- gateGhost sur Github (521 clics)
- gatejs sur Github (266 clics)
# ETag Obsolète
Posté par kaliko (site web personnel) . Évalué à 7.
Que veux tu dire par là ?
J'ai récemment écrit un client http pour un web service qui me donne des ressources avec ETag.
Après un rapide état des lieux du langage que j'utilise j'ai vu que le ETag était d'ailleurs géré dans plusieurs bibliothèques http.
Mon cache s'appuie sur les entêtes ETag si présentes.
Est-ce un aspect de http obsolète ou en court d'abandon ?
[^] # Re: ETag Obsolète
Posté par Michael Vergoz . Évalué à 3.
Non on ne peut pas dire qu'il soit obsolète ou en court d'abandon.
C'est juste un doublon avec quelques chose qui existe déjà Last-Modified If-Modified-Since… Mais qui ne décline pas une ressource précise (ce que fait ETag). Je vais essayé de le faire que quand le ETag me semble louche ;))
[^] # Re: ETag Obsolète
Posté par Gof (site web personnel) . Évalué à 2.
Je travailles sur le client de synchronisation de ownCloud, et on utilise beaucoup les ETag. Si l'ETag n'est plus là, le client ne fonctionne plus. (Et on a déjà eu des rapport de bug car un proxy retirait l'ETag des requêtes.)
[^] # Re: ETag Obsolète
Posté par Michael Vergoz . Évalué à 2.
Malheureusement tu ne pourras pas empêcher une personne d'utiliser des filtres. Pourquoi ne pas te baser sur Last-Modified ?
# Interception ssl
Posté par _jordan_ . Évalué à 2.
Je ne suis pas sur d'avoir compris la phrase suivante, tu peux expliciter ?
En tout cas, c'est très intéressant, je m'en vais essayer.
[^] # Re: Interception ssl
Posté par voxmundix . Évalué à 2.
Si je ne m'abuse cela signifie que le certificat ssl est transcris dans le code de l'application se qui permet de ne pas avoir a importer le certificat lors de a première connexion, ni d'avoir un dossier vulnérable stockant les certificats.
Par contre si pour une raison ou l'autre le certificat change, il faut obligatoirement mettre le code de l'application à jours.
[^] # Re: Interception ssl
Posté par Michael Vergoz . Évalué à 2. Dernière modification le 03 juillet 2014 à 12:18.
En gros pour le SSL une liste officielle est consolidée dans le navigateur. Ce sont les les CA qui servent à signer les clés régulières pour nos domaines. Il y a donc du Verisign, THAWTE ou encore Comodo .. ceux qui sont autorisés à signer nos certificats.
Si je veux intercepter du SSL il suffi de:
- de créer une clés
- de la signer avec mon CA
- de configurer le CA + ma clés dans gatejs
- d'installer le CA sur le device et le tour et joué
Sauf que dans certain cas, le CA de confiance est codé en dur dans l'application. Cela a pour effet de bloquer la connexion puisque le CA et CRT ne sont pas les mêmes qu'annoncés. C'est une "sécurité" de l'application pour éviter ce genre d'interception.
[^] # Re: Interception ssl
Posté par rakoo (site web personnel) . Évalué à 3.
gatejs est un proxy, c'est a dire qu'il fait du MitM, sauf que l'utilisateur est d'accord. Du coup quand un client veut faire du TLS avec un serveur, elle ne sécurise plus les applications jusqu'au bout mais seulement jusqu'au proxy, qui va lui se charger de chiffrer les données jusqu'au serveur distant. Le truc c'est que pour signaler que le proxy est de confiance, il faut bien le dire d'une manière ou d'une autre sur le client.
Le problème, c'est quand il n'y a aucune flexibilité dans les certificats gérés par l'applicaiton, et que celle-ci interdit tout intermédiaire…
[^] # Re: Interception ssl
Posté par whity . Évalué à 1.
Cela veut aussi dire que tu crées un « single point of failure » dans ton architecture réseau. Si le serveur MitM est corrompu, c’est l’ensemble des communications de l’entreprise qui est dérobée, et ce indépendamment de la sécurité sous-jacente de ces communications.
C’est un argument très fort contre ce genre de systèmes (cela dit, je pense que gatejs peut déjà rendre pas mal de services sans cette partie mitm).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Interception ssl
Posté par Michael Vergoz . Évalué à 1.
Je ne pense pas créer un "SPOF", peut être en ajouter … donc ca devient plus un "point of failure" ;) Les architectures traditionnelle ne sont en général pas super super safe ….
Je dirais qu'au contraire en faisant du MITM on peut trouver qui a été compromis dans le réseau.
L'utilisation de javascript permet aussi de réduire le risque de vulnérabilité dans gatejs
[^] # Re: Interception ssl
Posté par jokoe . Évalué à 1.
A ce sujet, cet article :
Trois-quarts des entreprises stockent leurs clés de chiffrement dans leurs applications
[^] # Re: Interception ssl
Posté par Aris Adamantiadis (site web personnel) . Évalué à 3.
Article poubelle : il parle de "clef de chiffrement", ce qui n'a absolument rien à voir avec du certificate pinning (dans ce cas il s'agit d'un certificat). L'article parle peut-être des clefs d'application, mais vu le rapport information/mots de l'article c'est difficile à dire.
Il faut savoir que le certificate pinning est une bonne pratique, elle réduit considérablement la surface d'attaque des applis vis à vis des attaques contre les CA. Et les clefs d'applications, c'est malheureusement une pratique commune pour protéger les apps contre la création d'applis compatibles (il faut la clef d'application pour pouvoir accéder à certaines parties de l'appli). Dans ces cas le certificate pinning permet de protéger (pendant 10 minutes si on s'y prend mal :p) la clef d'application.
Le résultat c'est que ces applications cesseront de fonctionner avec un proxy SSL. Est-ce une bonne chose ou une mauvaise, je n'ai pas d'avis tranché.
[^] # Re: Interception ssl
Posté par Michael Vergoz . Évalué à 2.
Aris a raison ;]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.