La bonne idée

ajouté le 2013-09-11T04:56:17 dans Suisse • par SwissTenguCommentaires (1)
Tags: idée assurance bêtise LAMal

Vous connaissez mon amour pour le système d'assurance maladie suisse : des entreprises privées, censées ne pas pouvoir faire de bénéfice, collectent de l'argent auprès des citoyens et citoyennes pour assurer une couverture minimale des frais médicaux. Vraiment minimale, d'ailleurs, puisque des choses dont on ne peut pas vraiment se passer, comme des lunettes, ne sont pas remboursées pour les adultes, et au compte goutte pour les enfants. De même, les soins dentaires ne sont remboursés que sous certaines conditions, et encore faut-il avoir une complémentaire… Bref, du grand entubage comme on les aime tant.

Il faut aussi savoir que les primes ont tendance à augmenter chaque année de manière très régulière : quand on ne parle pas trop des assureurs et de leur système à la noix, on se ramasse 12% dans les dents, et quand on est en pleine période de votation et discussions autour d'une caisse unique, on se ramasse soit 0% soit un tout petit 2%… Dans tous les cas, l'augmentation depuis la mise en place de la LAMal (loi sur l'assurance maladie) en 1996 est d'environ 100%…
Pour des prestations et remboursements en baisse, de l'augmentation de publicité mensongère, une absence complète de transparence des finances (sociétés privées, n'oublions pas), des effets d'annonce complètement vaseux, et une grogne grandissante. La joie en somme :).

L'organisme censé surveiller les primes étant légèrement déficient (pensez donc, on ne va pas affecter du personnel de l'état pour contrôler les milliers de primes différentes, ça ne touche que le peuple, on s'en fiche, du peuple), avec des manques de droits et pouvoirs flagrants (impossibilité d'imposer une baisse de primes — l'OFSP ne peut imposer qu'une augmentation !), les citoyens en sont réduits à voir passer une bonne part de leur budget familial dans une prime dont ils ne bénéficieront, si tout va bien, jamais des retombées.
Tout cela sous l'œil bienveillant de Santé suisse, l'organisme faîtier des assureurs maladie, qui se targue de "défendre les assurés" au travers des assurances — faut pas se leurrer, ils ne défendent que les intérêts de leurs membres fortunés, les assurés étant un poids mort tout juste bon à payer les primes sans rien avoir en retour.

Ajoutons à cela le prix même des soins en Suisse, comme par exemple les médicaments. On arrive à des situations grotesques comme des médicaments suisses produits en Suisse qui sont plus chers dans leur pays d'origine qu'à l'étranger… De qui se moque-t-on ?!

Et c'est au sujet du prix des médicaments qu'une idée d'une luminescence obscure a vu le jour dans l'esprit de Stefan Meierhans, notre surveillant national des prix en tous genres. "Youpi !" pourrions-nous de prime abord crier. Oui, mais… non.
L'idée est la suivante :
de manière à faire baisser les prix des génériques en Suisse (qui sont en moyenne 42% plus cher ici que dans le reste de l'Europe…), les préparations ayant le même principe actif ne seraient remboursées qu'à hauteur du prix du générique le meilleur marché… Sous-entendu : la différence sera à la charge du malade, et tant pis si un des composants du médicament le moins cher ne lui convient pas pour une raison ou une autre ou s'il ne peut simplement pas changer de traitement pour X ou Y raisons que seul son médecin traitant pourra expliquer.

Si l'idée de faire baisser les prix des médicaments est louable (il y a vraiment un abus certain — mais c'est comme 99% de ce qu'on achète en Suisse), la manière me laisse quelque peu perplexe : pour quelle raison l'industrie va-t-elle baisser les prix, vu qu'au final elle touchera la même somme ?
Alors certes, "pour ne pas perdre de parts de marché, elle baissera le prix" — mais ça prendra du temps, et au final on se fera entuber sans vaseline une fois de plus.

On peut ajouter cette idée à la grosse pile des baisses de prestations des assureurs, qui interviennent toutes pour le même motif : faire baisser les coûts, et par là même diminuer l'augmentation des primes. Sauf que cette diminution d'augmentation, le plus sûr moyen de l'avoir, c'est de lancer une votation pour une caisse unique au niveau fédéral : en 2008, l'augmentation a été d'à peine 0.5% — la raison : votation en 2007 pour la caisse unique. En 2003, une votation pour "la santé à prix abordable" a débouché sur une augmentation d'à peine 4.3% en 2004 (l'augmentation en 2003 était de plus de 9%…).

Le pire, c'est que ces effets d'annonce ont été efficaces, vu que le mouton suisse, transformé en vache à lait pour l'occasion, a voté de telle sorte que le système puisse se maintenir. L'absence chronique de logique est quelque peu affligeante.

On peut compter sur nos chers assureurs pour ne jamais répercuter les 400 à 500 millions d'économie que l'idée de Monsieur Prix permettrait de faire. Les assurés payeront toujours aussi cher, auront toujours leurs augmentations régulières (sauf en cas de votations sur le sujet), et verront leurs prestations diminuer au fil du temps.

T, un peu plus désabusé chaque jour.
 

Tor : configurer votre relais maison — Le fun

ajouté le 2013-08-27T05:07:52 dans Documentation • par SwissTenguCommentaires (0)
Tags: tor relais privoxy privacy neutrality

Ce billet se veut avant tout "pour le fun" — il s'agit juste de 2-3 trucs et astuces pour jouer un peu avec Privoxy, Tor et votre navigateur favoris. Il part du principe que vous avez suivi les différentes étapes pour monter votre relais Tor, que vous avez mis Privoxy et Polipo, et que vous possédez, quelque part, un serveur capable de servir une page quelconque en SSL (oui, pas en clair, surtout !).

PAC

Non, pas Pacman. PAC. Pour Proxy Auto-Config. Un truc super-vieux, mis au point par Netscape (même pas certain que vous vous souveniez de ce vieux coucou). Il s'agit d'un fichier de configuration que l'on fait bouffer à son navigateur, et qui va configurer automagiquement les proxies, en fonction de plein de paramètres.

Pour pouvoir employer un fichier PAC, il convient d'avoir, quelque part, un serveur web permettant de servir le contenu par SSL — cela évitera quelques problèmes du genre "contenu modifié à la volée par un MitM quelconque qui vous enfume à votre insu".
La structure d'un tel fichier est assez simple — il s'agit d'un simple truc en javascript (oui… vous lisez bien). La meilleure référence trouvée pour ce vieux système est ici (avec une copie de la documentation originale). La plupart des documentations officielles ayant été supprimées il y a belle lurette, le PAC est tombé dans l'oubli. Il semblerait que des "pirates" brésiliens (comprendre : script-kiddies boutonneux) aient eu l'idée d'employer un PAC sur des machines infectées pour planter des MitM entre les utilisateurs et les sites bancaires. Logique en fait ;).

Bref. Voici un petit exemple de PAC permettant de configurer automagiquement le proxy en fonction de l'IP de votre machine. Ça part du principe que votre LAN possède deux subnets, 10.0.1.0/24 et 10.0.2.0/24, que vous avez par exemple un laptop avec Tor + Privoxy installés et configurés dessus (sans Polipo), et que vous voulez lui faire profiter du relais présent chez vous quand vous êtes à la maison :
Code: javascript
function FindProxyForURL(url, host) {
  var lhost = host.toLowerCase();
  host = lhost;
  if (!isResolvable(host)) {
    return "DIRECT";
  }
  proxy = '';
  // home network has its own privoxy/Tor entry-point
  if (
    isInNet(myIpAddress(), "10.0.1.0", "255.255.255.0") ||
    isInNet(myIpAddress(), "10.0.2.0", "255.255.255.0")
    ) {
    // this is Polipo on your LAN
    proxy = "PROXY 10.0.1.2:8123"
  } else {
    // We do not trust other proxy - use local Privoxy
    proxy =  "PROXY localhost:8118"; 
  }
  if ((host == "localhost") ||
      (shExpMatch(host, "localhost.*")) ||
      (host == "127.0.0.1")) {
    return "DIRECT";
  }
  // avoid Proxy for some hosts
  if ( (!isInNet(myIpAddress(), "10.0.1.0", "255.255.255.0") &&
        !isInNet(myIpAddress(), "10.0.2.0", "255.255.255.0")) &&
    (
      (shExpMatch(host, "mail.google.com")) ||
      (shExpMatch(host, "*.github.*")) ||
      (shExpMatch(host, "*.piratenpad.de")) ||
      (shExpMatch(host, "*.postfinance.*")) ||
      (shExpMatch(host, "*.ubs.*")) ||
      (shExpMatch(host, "*.paypal.*")) ||
      (shExpMatch(host, "*.gandi.net")) ||
      (shExpMatch(host, "*.freenode.net")) ||
      (shExpMatch(host, "*.500px.com")) ||
      (shExpMatch(host, "500px.com")) ||
      (shExpMatch(host, "*.smugmug.com")) ||
      (shExpMatch(host, "*.youtube.com"))
    )
    ) {
    return "DIRECT";
  }
  remote_ip = dnsResolve(host)
  if (
    isInNet(remote_ip, "10.0.0.0", "255.0.0.0") ||
    isInNet(remote_ip, "192.168.0.0", "255.255.0.0") ||
    isInNet(remote_ip, "169.254.0.0", "255.255.0.0") ||
    isInNet(remote_ip, "172.16.0.0", "255.255.0.0")
    ) {
    return "DIRECT";
  }
  return proxy;
}

Il est à noter que la partie permettant de bypasser le proxy n'est appliquée que sur votre laptop quand il est hors de votre LAN. Cela peut être évité si vous partagez aussi votre configuration Privoxy, via un dépôt Git, voire btsync.

Je vous conseille de regarder les autres possibilités offertes par ce système, il y a de quoi jouer pendant pas mal de temps. Par contre, gardez en tête que votre navigateur va exécuter le JS lors de chaque requête. Il faut donc avoir une idée claire de ce que l'on veut, et faire des conditions précises en ayant, le plus vite possible, le résultat pour le retourner.
Aussi, pour debugger un peu votre PAC, vous pouvez aller regarder ce qu'il se passe dans la console d'erreurs de Firefox — vous y verrez les erreurs de parsing, ou encore, en employant la fonction "alert()", des messages de debug que vous pouvez ajouter au besoin.

Suis-je bien sur Tor ?

Le prochain truc concerne Privoxy, et sa capacité à altérer les contenus des pages à la volée. Par contre, comme déjà précisé, il ne peut pas déchiffrer les pages servies en SSL et ne pourra donc pas les altérer — tant mieux, ça évitera des problèmes de sécurité ;).
On va donc avoir besoin de 2-3 trucs :
- un serveur web dans un coin, accessible en SSL (oui, encore. Vaut mieux).
- une image cool, genre celle-ci
- un nouveau filtre dans Privoxy
- une action appliquée globalement, et annulée dans certains cas

Le filtre
Vous vous souvenez que Privoxy, c'est un gros truc plein d'expressions régulières, qu'on peut remplacer des choses dans les pages etc. Bon. Bin c'est simple au final :
Code:
FILTER: tor-in-use Displays some info if we are using Tor.

s|(</body>)|<img src="//share.tengu.ch/tor-ok.png" style="position:fixed;z-index:200;top:0px;left:0px" alt="TOR: OK"> $1|i

On a donc créé un filtre nommé "tor-in-use", qui va remplacer </body> par un truc un peu plus long, en l'occurrence une image qui sera en position fixe, en haut à gauche. Le $1 final est pour reprendre le </body>, j'ai la flemme de le réécrire ;).
Simple, efficace.

En passant : assurez-vous que le serveur vous servant l'image est réellement fiable — reprenez l'image chez vous. Ne pointez JAMAIS sur un contenu que vous ne maîtrisez pas à 100% ! Les risques de se faire avoir sont assez énormes. Si vous n'avez pas de possibilité de mettre une image, contentez-vous de mettre un bout de CSS dans une div, et basta.

L'action
Là encore, c'est simple : on a défini, dans user.action, une série de filtres et actions à appliquer de manière globale. Il suffit donc d'ajouter la ligne suivante dans le bloc :
Code:
+filter{tor-in-use} \

À ce stade, on a un logo Tor qui va apparaître sur toutes les pages non-chiffrées. Y compris quand on ne passe pas par Tor, ce qui est un peu con au final ;).
Et c'est là que vous vous dites "Han mais oui, on passe par une action pour dire à Privoxy de ne pas passer par Tor, c'est la méthode élégante mise en avant par SwissTengu !!" — Exactement ;). Là, ça devient de suite très simple de virer l'icône, sans duplication de code ou autres. Il suffit de rajouter cette ligne dans le bloc ayant le forward-override :
Code:
-filter{tor-in-use} \

Et voilà. Vous reloadez Privoxy, et naviguez un peu… Vous aurez un retour visuel direct pour savoir si vous passez par Tor ou pas — sauf, évidemment, pour les pages servies en SSL. Pour faire cela, il faudrait remplacer Polipo par Squid, le configurer pour qu'il fasse un MitM SSL qui va déchiffrer le contenu, modifier, et, si possible, le rechiffrer… mais avec une autre clef privée.
Vous perdez donc la possibilité de valider le certificat SSL du site que vous visitez ce qui, dans certains cas, peut s'avérer fort fâcheux…

"Désactiver" Flash partout

Comme vous le savez, Flash, c'est de la merde. Une faille de sécurité énorme dans votre navigateur, capable de remonter vos informations personnelles à votre insu, comme par exemple votre véritable IP publique, ou encore de poser des cookies pourris. Contre cela, il y a 2-3 mesures possibles.
La plus radicale, mais aussi la plus chiante, consiste à désactiver (voire désinstaller) le plugin directement dans le navigateur. C'est un peu chiant, parce que ça vous empêche de profiter de Youtube ou Grooveshark — le premier propose une version html5, mais le second laisse un peu à désirer à ce niveau.
La seconde méthode consiste à appliquer un filtre via Privoxy partout, sauf pour les sites ayant du flash de manière légitime. Pour cela, il y a un filtre présent dans le default.filter : shockwave-flash.
Il est malheureusement assez incomplet, ce d'autant que pas mal de sites emploient du javascript pour vous poser un flash bien vaseux à votre insu. Il conviendrait donc de modifier le filtre, de manière à supprimer aussi les bouts de JS qui vous polluent le navigateur, comme par exemple :
Code:
FILTER: my-shockwave-flash Kill embedded Shockwave Flash objects.

s|<object [^>]*macromedia.*</object>|<!-- Squished Shockwave Object -->|sigU
s|<embed [^>]*(application/x-shockwave-flash\|\.swf).*>(.*</embed>)?|<!-- Squished Shockwave Flash Embed -->|sigU
s|id="flashcontent"|id=""|sigU

Il existe (malheureusement) une tonne de librairies permettant de vous planter du Flash, mais on peut compter sur le manque d'imagination des gens pour mettre en place 1-2 filtres permettant de virer des id comme ci-dessus. "flash", "flashmove", "flashcontent" et autres "swfobject" sont autant de termes qui peuvent être virés à grands coups de pied au cul.

AdBlock dans Privoxy

Tout le monde (ou presque) connaît l'addon "AdBlock" pour Firefox ou Chrome. Son efficacité n'est plus à démontrer je pense, et il serait intéressant de pouvoir planter les listes d'AdBlock directement dans Privoxy, de manière à alléger notre Firefox de quelques addons.

L'avantage de bosser avec des logiciels opensource, c'est qu'il y a en général du monde qui les utilise, et qui développe des outils à côté pour simplifier la gestion.
En l'occurrence, au détour du Net, je suis tombé sur ceci : privoxy-blocklist, un script bash (et sed) faisant la moulinette nécessaire pour convertir les listes d'AdBLock en un truc comestible pour Privoxy.

Il vous suffit de le télécharger, de le rendre exécutable et de le lancer en tant que root pour avoir les configurations adéquates. Notez au passage qu'il vous faudra sans doute modifier les URLs mises par défaut dans le script — pour ma part j'ai mis ces deux-ci:
https://easylist-downloads.adb... et https://easylist-downloads.adb....

Le résultat est sans appel : non seulement le script est d'une rapidité bluffante, mais en plus il vous configure automagiquement Privoxy pour employer les fichiers nouvellement créés. Et que dire de la navigation… Un Firefox sans AdBlock ou autres addons se retrouve sans la moindre publicité et, mieux encore, sans les disclaimers vous disant "booo vilain tu désactives notre publicité". Vous pouvez faire la comparaison "avant/après" sur, au hasard, generation-nt.com… Ce site est un excellent benchmark pour tester vos règles (enfin, celles crachées par le script ;) ).
Il suffira de mettre le script dans un cron pour mettre à jour les listes régulièrement, et basta :).

Évidemment, pour activer les publicités sur les sites que vous soutenez, ça complique un tout petit peu les choses : il vous faudra désactiver certains "block" et "filters" dans le user.action, par exemple :
Code:
{ \
-block{easylist} \
-filter{easylist} \
}
.numerama.com
.reflets.info


Tester votre setup

Maintenant qu'on a fait ce qu'il fallait pour passer par Tor et qu'on a joué avec notre Privoxy, il serait temps de faire 2-3 tests.
Le plus simple est d'abord de contrôler si on passe bien par Tor. La page https://check.torproject.org/ vous donnera cette information, bien qu'il faille tenir compte des règles de routing que vous avez intégrées dans Privoxy (voire dans votre PAC).
Le "test ultime" semble être, à l'heure actuelle, http://ip-check.info/?lang=en. En effet, ce site va non seulement s'assurer que vous passez bien par Tor, mais que vous avez aussi une configuration correcte de manière à éviter les problèmes type plugins vaseux activés, informations remontées par le navigateur etc.

Certains trucs ne marchent pas

Après pas mal de tests, je me suis rendu compte que, manifestement, certaines choses ne marchent pas correctement, comme par exemple la modification du User-Agent. Polipo ne semble pas le masquer, et Privoxy ne semble pas le modifier correctement. Ce qui est assez frustrant, je trouve.
Après 2-3 recherches, j'ai trouvé comment faire dans Firefox :
allez dans about:config, trouvez (ou créez) le booléen general.useragent.enable_override, mettez-le à True. Créez une String nommée general.useragent.override, et mettez comme valeur un navigateur standard, tel que :
Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20130401 Firefox/21.0
Il s'agit d'un Firefox 21 sur un Windows 7
Selon Panopticlick, cela correspond à 1 navigateur sur 8'317, ce qui est déjà pas mal.

Et j'ai aussi remarqué qu'il en va de même pour le header Accepted-Language. A ce niveau, la solution élégante est de mettre en-us, en. De toutes façons, une majorité de sites ne prennent pas ce header en compte, principalement quand on vient de Suisse d'ailleurs : on se ramasse toujours la page en allemand -.-.

Conclusion

Il faut garder en tête que l'anonymat complet n'est pas possible. On peut, par contre, se fondre dans la masse. En envoyant le moins de données personnalisées possible, on devient un John Doe. On n'est personne, jusqu'à ce qu'un élément ne révèle qui on est réellement.

La série d'articles autour de Tor et des moyens de se protéger sert avant tout d'aide-mémoire et d'introduction à la protection de ses données personnelles, à son retour dans un anonymat relatif.

Il ne faut pas perdre de vue que, de toutes façons, nous sommes tracés. Notre fournisseur d'accès peut être obligé de garder des traces de nos activités sur le Net, les sites que nous visitons gardent eux aussi des traces, et les sites tiers, visités à notre insu via des appels javascript, cookies ou autres, en savent nettement plus sur nous que ce que nous pourrions imaginer.

Sortez couverts, et soyez toujours sûrs des sites que vous visitez. Désactivez au maximum les choses inutiles, et vous serez un peu plus Doe-esque que d'habitude ;).

T.
 

Tor : configurer votre relais maison — III

ajouté le 2013-08-19T18:00:57 dans Documentation • par SwissTenguCommentaires (0)
Tags: tor privacy relais neutrality

Dans les épisodes précédents :
on a vu ce qu'est le réseau Tor, comment y accéder, comment monter un relais chez soi, comment employer Privoxy pour passer dans Tor.

Il reste maintenant une dernière brique, complètement optionnelle mais qui permet d'aller pas mal plus vite sur le Net : un proxy-cache.

Histoire de faire dans le léger et simple, j'ai choisi Polipo. C'est un simple proxy-cache, configuré en 5 minutes, et bien efficace.

Bref, assez de blah-blah, on y va !

Un proxy-cache, c'est quoi ?

Dans le cas qui nous intéresse, il s'agit d'une application qui se met entre votre navigateur et le Net, et qui va regarder ce qui transite, et voir si, par hasard, l'objet en question n'a pas déjà été téléchargé, auquel cas l'application va le servir directement.
Exemple :
vous allez sur votre blog préféré, qui possède quelques images et icônes pour simplifier la navigation. La première fois que vous y allez, le contenu est téléchargé intégralement, le proxy va se charger de garder une copie des éléments genre image, css etc; La seconde fois, outre le cache de votre navigateur (que vous avez, bien entendu, désactivé, de même que l'historique ;) ), Polipo va se charger de vous servir en local le contenu qui n'a pas changé.

Effet immédiat : les pages se chargent beaucoup plus vite.

Quand on passe par Tor, c'est un plus indéniable, le réseau étant assez lent de par son fonctionnement (et le peu de nodes, merci les Médias et les politiques…).

Non mais, c'est quoi ??

Un tampon qui vous ressert le contenu inchangé depuis votre LAN.

Pourquoi Polipo et pas Squid ?

Je vous laisse configurer un squid en moins de 5 minutes. Ah, et qui marche, en faisant suivre les contenus à Privoxy et tout. Go !

Bon ok, on y va ?

La configuration est on ne peut plus simple, vraiment. Il vous suffit de renseigner les variables suivantes dans /etc/polipo/config :
proxyAddress = "0.0.0.0"
allowedClients = 127.0.0.1, 10.0.1.0/24, 10.0.2.0/24
parentProxy = "127.0.0.1:8118"
dnsQueryIPv6 = no
censoredHeaders = from, accept-language, cookie2
censorReferer = false


Relancer le service, et Voilà.

Gosh… l'article est fini !

…

Je plaisante ;)

On va expliquer quelques options, de manière à vous permettre d'affiner au maximum la configuration. Il faut bien garder en tête que, si vous avez suivi tout le setup précédent, le contenu que reçoit Polipo a déjà été nettoyé par Privoxy (sauf le SSL, évidemment).
proxyAddress va renseigner l'interface réseau sur laquelle va écouter Polipo — en l'occurrence, on veut pouvoir accéder au proxy depuis notre LAN, donc il écoutera sur l'extérieur.
allowedClients va lister les subnets autorisés à discuter avec Polipo — en l'occurrence, localhost et les deux subnets définis dans le premier billet.
parentProxy permet de dire à Polipo de faire passer les requêtes sortantes par un proxy quelconque, en l'occurrence, Privoxy qui écoute sur localhost.
dnsQueryIPv6 permet d'activer ou non l'IPv6 — mon fournisseur d'accès étant une moule asthmatique, je dois désactiver l'IPv6 sous peine de me manger des problèmes de résolution de nom (ou, plutôt, d'accès à des contenus ayant une IPv6…)
censoreHeaders permet de lister les en-têtes à censurer — en l'occurrence, on va enlever quelques renseignements (qui seront, dans le cas des langues, réglés par Privoxy). Je vous laisse voir quels en-têtes vous voulez bloquer ;).
censorReferer permet, comme son nom l'indique, de faire venir des Martiens sur Terre pour péter la gueule à la NSA…

… heu bon… Bin c'est vraiment fini cette fois ;).

Prochain billet : make some fun with Proxies !

T.
 

Abus de terrorisme

ajouté le 2013-08-19T06:18:10 dans News • par SwissTenguCommentaires (1)
Tags: terrorisme abus uk davidMiranda nsa

Ce matin, petit titre dans la Tribune de Genève (qu'on va sans doute retrouver dans les autres titres de Tamédia ;) ) :
Le mari d'un journaliste lié à Snowden interpellé

En lisant l'article, on se rend compte qu'on a, de nouveau, affaire à une application vaseuse de loi antiterrorisme…

Pour rappel, ces lois (anglo-saxonnes) sont faites de telle sorte que :
- vous n'avez aucun droit
- vous n'avez pas d'avocat
- vous êtes gardé au secret pendant une période assez longue (9h dans ce cas), prolongeable à l'envi
- on peut vous extorquer vos mots de passe personnels
- on peut vous confisquer votre matériel électronique (appliqué dans ce cas justement)
- … encore plein de joyeusetés qu'il vaut mieux ne pas savoir

Autant de raisons qui me font dire ceci :
L’Occident démocratique et libre est mort.

Sauf que, vous vous en doutez, ça ne m'étonne pas, et c'est le cas depuis des années. Plus de 12 ans en fait. Le fameux 11 septembre 2001 (qualifié de "catastrophe mondiale" par certains) n'a fait qu'enfoncer un clou déjà bien planté : la loi appliquée dans le cas de David Miranda date de 2000…
Catastrophe mondiale, c'est le cas, mais pas pour les raisons évoquées — après tout, il s'agit "juste" de béton, armatures et verre sur le territoire US, pas d'une explosion nucléaire ayant créé un nuage couvrant la moitié de la planète (sauf la France, parce que ça s'arrête aux frontières ;) )…
Non, il s'agit d'une catastrophe mondiale dont on va payer le prix encore bien longtemps : une réduction drastique de nos libertés individuelles au nom de la protection de l'État (ou de toute autre entité du genre). Et, via une certaine collaboration des médias "mainstream", avec la bénédiction du bon Peuple : comptons donc les articles parlant de problèmes de sécurité — on va de suite remarquer une augmentation de la mise en avant de faits divers et (a)variés, au détriment de véritables informations.
Combien de fois avez-vous lu "vol à l'arraché", "viol", "détroussage" et autres mots assimilés en une semaine dans votre "journal" ? Autant de faits divers (certes, certains sont terribles et tout, mais restent des faits divers) permettant de valider le "sentiment d'insécurité" si cher à nos politiques (et nos médias — ça fait vendre !).

Ce qui est intéressant, c'est de voir aussi que ça touche la Presse directement : David Miranda étant le compagnon d'un journaliste ayant bossé sur le cas Snowden et ses révélations, on peut se permettre d'avoir quelques doutes quant au motif réel de la mise au frais (il a été relâché, donc on ne parle pas de mise en arrestation).

Je crains qu'il ne faille s'attendre à de plus en plus d'abus de ce genre, après tout, ces lois sont là pour permettre de faire tout et n'importe quoi. Y compris fouiller un avion présidentiel d'un pays censé être ami, ou tout du moins pas ennemi…

Tout va pour le mieux dans le meilleur des mondes possibles ;). Vous êtes en sécurité !

T.
 

Tor : configurer votre relais maison — II

ajouté le 2013-08-19T05:01:33 dans Documentation • par SwissTenguCommentaires (0)
Tags: tor privacy relais neutrality

On a vu dans un précédent article ce qu'est Tor, dans un autre un moyen simple d'y accéder, et pour finir comment monter un relais sur une machine "dédiée". J'avais laissé entendre, à la fin de ce dernier article, qu'on allait empiler quelques autres logiciels derrière Tor de manière à ajouter un peu de protections.

Configurer Privoxy


Tout d'abord, privoxy, c'est quoi ?
Il s'agit d'un proxy filtrant, permettant entre autres de :
- bloquer l'accès à certains sites, en se basant sur des URL, le contenu ou des metas, ou bloquer des pages d'un site en se basant sur des expressions régulières
- filtrer et/ou modifier le contenu des pages à la volée
- régler différentes préférences de "routing" pour les requêtes — i.e. telle ou telle URL passe par tel ou tel autre proxy, celle-ci passe en direct, etc

On voit déjà à ce stade les choses intéressantes que permet de faire Privoxy, je pense. Il va sans dire que de telles possibilités, entièrement paramétrables, demandent une configuration un peu lourde et, selon comment, compliquée. Je vais donc tâcher de limiter un peu les explications à ce qui est vraiment nécessaire pour le but fixé, sinon ce billet va être kilométrique :). Il y aura aussi 1-2 choses propres à Privoxy dans le quatrième et dernier billet, celui concernant les choses funs à faire. Il se peut aussi que je fasse un billet sur "comment filtrer avec Privoxy", mais pas de suite.

En résumé, Privoxy permet d'appliquer une série d'actions employant un ou plusieurs filtres, en fonction de bouts d'url ou de domaine, ou de manière globale.

On y va !
On va d'abord dresser l'inventaire du contenu de /etc/privoxy — le package Debian est pas trop mal foutu, et fournit des moyens d'éviter de se tirer une balle dans le pied.
config : son nom ne l'indique peut-être pas, mais il s'agit du fichier de configuration de base de Privoxy; celui que vous n'allez pour ainsi dire pas toucher, et qui référence le reste du contenu du dossier :).
default.action : il s'agit des actions définies par défaut. On verra après comment appliquer des règles. Ce fichier n'est pas à éditer, il est géré à 100% par le package.
default.filter : contient les filtres définis par défaut — ils sont employés tant dans le default.action que le user.action. Là aussi, c'est le package qui le gère, donc il vaut mieux éviter de l'éditer.
match-all.action : active quelques actions par défaut — là encore, on touche pas ;).
templates : on va éviter de trifouiller dans ce dossier, mais si vous voulez modifier un peu l'apparence des pages d'erreur remontées par Privoxy, c'est par là que ça se passe. Ce billet ne s'y intéresse absolument pas.
trust : là, on touche à la partie "proxy bloquant" de Privoxy — je ne vais pas m'étaler dessus, mais si vous comptez par exemple filtrer ce que vos bambins font sur le Net, ce fichier vous intéressera. Je vous laisse lire la doc embarquée et faire vos tests, cette fonctionnalité ne sera pas abordée dans ce billet (mais si demande il y a, je pourrais faire un billet dédié ;) ).
user.action : là, on commence (enfin) à accéder à des choses qu'on peut aller modifier, casser, réparer et tout :). On va définir là-dedans les actions qu'on veut faire faire à Privoxy.
user.filter : et comme les actions demandent des filtres, c'est dans ce fichier qu'on pourra définir des filtres personnalisés. Cette possibilité ne sera abordée que superficiellement dans ce billet, mais sera employée dans le dernier.

Commençons par regarder ce qu'il faut modifier dans config :
listen-address
Il s'agit de l'adresse sur laquelle va écouter Privoxy. Dans notre cas, on veut pouvoir accéder à Privoxy depuis une application tiers. Il convient donc de mettre :
listen-address 127.0.0.1:8118

permit-access
Tout comme Tor, on peut restreindre les accès à Privoxy. Il convient de mettre "localhost" comme seul et unique élément pouvant accéder à Privoxy. Rappelez-vous, on aura un troisième élément à ajouter, dans le prochaine article. Dans le cas où vous ne voulez pas de ce troisième élément, ou désirez pouvoir employer directement le système sans attendre la suite, il vous suffira d'ajouter autant d'entrées "permit-access" que vous avez de subnets (ou de machine, si vous faites par IP).
forward-socks5
Là, on va justement lier Privoxy à Tor. Cette directive indique à Privoxy "tu fais suivre les requêtes à travers ce socket". Comme Tor écoute sur localhost:9050, la directive devient donc :
forward-socks5 / localhost:9050

Note : le "/" indique "appliquer globalement". Cela permettra donc, par défaut, de faire suivre tout le traffic à travers Tor.

Le reste des options de configuration n'étant pas vitales pour le présent exercice, je vous laisse le soin de lire la doc embarquée dans le fichier — elle est très complète et claire ;).

En l'état, si vous redémarrez Privoxy, il devrait se lancer sans erreur, et, si vous avez autorisez votre machine à se connecter, vous devriez pouvoir accéder au Web à travers le proxy. On va dire que oui, et partir sur le reste — il s'agit maintenant de s'assurer que certains sites ne passent pas via Tor, par mesure de précautions.

Pour cela, on a deux solutions :
dans config, on peut mettre une série de directives sous cette forme :
forward-socks5 / 127.0.0.1:9050
forward example.com .
forward .youtube.com .
forward .postfinance.ch .
…

Sauf que ce n'est pas élégant, et c'est moins fun que l'autre solution, qui permet en outre de jouer un peu plus (voir le 4e article à venir — oui, je sais, je fais plein de teasing pour celui-ci, c'est normal ;) ).

L'autre solution, c'est de passer par la directive forward-override, en employer le fichier user.action.

Les filtres

On va voir ici comment ils fonctionnent, et de manière très rapide comment en ajouter un. Une explication plus détaillée viendra dans un prochain article — celui-ci est déjà bien assez long (et n'est pas terminé, courage !).

Tout d'abord, il faut distinguer trois types de filtres : FILTER, SERVER-HEADER-FILTER et CLIENT-HEADER-FILTER. À côté de cela, on trouve aussi deux "tagger" : CLIENT-HEADER-TAGGER et SERVER-HEADER-TAGGER
Le premier filtre s'occupe du contenu de la page, le second des en-têtes retournés par le serveur, et le troisième des informations retournées par le browser de l'utilisateur.
Les taggers servent à "marquer" des éléments, de manière à pouvoir s'y réfèrer plus tard pour, par exemple, appliquer des filtres.

Niveau création, ce sont des expressions régulières. Par exemple, pour remplacer un mot dans une page web, il vous suffit de faire ceci :
FILTER replace-banquier Replace word "banquier" by "bankster"
s/banquier/bankster/ig

Les options "ig" en bout de ligne sont là pour enlever la sensibilité à la casse (minuscules/majuscules) et que le filtre sera appliqué à chaque occurrence du mot.

On verra de manière plus détaillée comment créer ses propres filtres — il est à noter que Privoxy fournit, de base, une bonne quantité de filtres assez efficaces :).
Il est à noter une chose importante : Privoxy ne sait pas faire un MitM SSL — autrement dit, il ne déchiffre pas les pages servies par httpS, et donc ne pourra pas appliquer de filtres dessus !

Les actions

Une action sert à appliquer un ou plusieurs filtres à un ou plusieurs sites, en fonction du domaine ou de bouts d'url, de TAGS ajoutés précédemment, ou de portions d'url, voire globalement. C'est là que toute la magie s'opère.

Il faut avoir en tête une chose très importante :
Une requête passe à travers toutes les actions — la dernière action appliquée fait force de loi. Cela implique donc que l'ordre de passage dans les actions, et donc l'ordre dans lequel elles sont écrites dans le user.action, est très important.

On va voir une manière élégante de :
- modifier le "forward" à la volée selon le domaine
- changer les filtres appliqués selon le domaine (pas mal important, selon les sites c'est vite le bronx)

On va commencer par appliquer quelques filtres "par défaut" (attention, certains sont déjà appliqués via le match-all.action — j'avoue que par acquis de conscience, je préfère faire ma tambouille dans mon coin.
On va d'abord définir quelques aliases, qui vont permettre d'appliquer plusieurs règles d'un coup (oui, bon, OK, ils sont fournis de base dans le user.action ;) ):
{{alias}}
# crunch all cookies
+crunch-all-cookies = +crunch-incoming-cookies +crunch-outgoing-cookies
# do not crunch cookies
-crunch-all-cookies = -crunch-incoming-cookies -crunch-outgoing-cookies
# allow all cookies, and don't crunch them
allow-all-cookies = -crunch-all-cookies -session-cookies-only -filter{content-cookies}
# authorize all popups
allow-popups = -filter{all-popups} -filter{unsolicited-popups}
# do not display images
+block-as-image = +block{Blocked image request.} +handle-as-image
# do not block anything
-block-as-image = -block
# fragile sites need some cookies, work with referers and some stuff like that
fragile = -block -crunch-all-cookies -filter -fast-redirects -hide-referer -prevent-compression
# shops need cookies, some have popups
shop = -crunch-all-cookies allow-popups
# allow ads ­— only for website you really love
allow-ads = -block -filter{banners-by-size} -filter{banners-by-link}

Les commentaires sont assez explicites je pense ;).

Appliquons de manière globale une série de filtres :
{ \
-deanimate-gifs{last} \
+filter{js-annoyances} \
+filter{html-annoyances} \
+filter{google} \
+filter{yahoo} \
+hide-accept-language{en,en-us;q=0.5} \
+hide-user-agent{Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0 (Tor Browser Bundle)} \
+hide-referrer{conditional-forge} \
+session-cookies-only \
}
/

La première permet d'avoir les gifs animés — le match-all.action les désactive en ne montrant que la dernière frame de l'animation; le reste permet de supprimer les javascript vaseux et envahissants, les pubs google et yahoo, et de nettoyer un peu le html. Les trois suivants permettent de masquer des informations sur le navigateur — notez que les deux premiers "hide" correspondent assez bien à ce que Tor préconise ;).
Le hide-referrer, et plus particulièrement son argument, permet de masquer les referrer en étant un peu plus subtil : sachant que certains sites emploient le referrer pour "protéger" des contenus, il est donc nécessaire de le transmettre. Le "conditional-forge" va s'arranger pour fabriquer un referrer en fonction du site en cours de visite, mais ne l'envoyer qu'au sein de ce site (et des ressources employées), tout en masquant la véritable page employée. Le dernier sert à shooter les cookies persistants. Kill 'em all !
Rien que là, vous allez remarquer plusieurs choses : exit une bonne partie des publicités, et, par conséquent, un chargement "légèrement" plus rapide des pages. Même à travers Tor !

Une fois ces règles mises en place, vous pourrez, en-dessous, ajouter des règles propres à des sites web. Par exemple, de manière à laisser smugmug.com fonctionner correctement, ce bloc est nécessaire :
{ \
fragile \
shop \
-session-cookies-only \
allow-all-cookies \
}
.smugmug.com

Ouais, c'est moche : on se retrouvera avec une tonne de cookies etc. — mais il faut avouer que le site est assez propre, et, franchement, j'aime bien Smug ;).

Aussi, pour éviter que certains sites ne passent à travers Tor, ceci est très utile :
{ \
+forward-override{forward .} \
}
.sourceforge.net
.sf.net
mail.google.com
.epfl.ch
.github.com
.piratenpad.de
.tengu.ch
.postfinance.ch
.ubs
.paypal
.gandi.net
.freenode.net
.500px.com
.smugmug.com
.youtube.com

Le forward-override permet de reconfigurer le forward-socks5 précédemment mis par défaut.

Il suffit de recharger le service Privoxy, and Voilà. Vous avez maintenant un Privoxy qui fait suivre, ou pas, les requêtes à travers Tor, et qui, en plus, vous allège les pages en supprimant les contenus moisis. Il est clair que, niveau configuration des filtres etc, il y a du boulot. Je ne peux que vous conseiller de regarder les filtres existants — certains sont vraiment bons, bien que très agressifs, en particulier celui permettant de virer les contenus flash ;).

N'oubliez pas non plus qu'un filtre activé globalement peut être désactivé pour un ou plusieurs sites, mais que la règle doit se mettre après son activation globale !
La suite : on va jouer à cache-cache. On va voir comment mettre un proxy-cache en bout de chaîne, de manière à accélérer encore la navigation. Le billet sera court, ce n'est pas très compliqué ;).

Enjoy !

T.