Vie privée sur le web, comment s'en prémunir ? - Page 1

Un article bien ficelé ce matin dans Libération "Numérique, la vie en liberté surveillée".

Dans "Mission invisible" quelques techniques pour mieux passer inaperçu sur la toile.
Déjà en terme de navigateur, exit EI (Internet Explorer de Microsoft), Chrome (Google) et Safari (Apple). Sur ce dernier, j'avais pourtant un avis positif...

FireFox de Mozilla est recommandé par l'article en mettant en avant le libre. D'ailleurs, les extensions sont très simple à trouver et à installer. Si AdBlock permet de ne pas afficher certaines pubs et de gagner en fluidité, l'article parle de "Disconnect" qui désactive les trackers, NoScript qui empêche la communication entre navigateur <> serveurs et "HTTPS everywhere" qui force les connexions codées (ce dernier, je ne l'ai pas trouvé sous FireFox).

Enfin, en terme de logiciels libres et gratuit et permet de surfer en tout tranquillité, le site Prism-break.org est mis en valeur avec divers soft qui viendront supplanter de nombreux service "gratuit" du web concocté par de grosses société (recherche de plan, partage de fichier collaboratif, moteur de recherche.

Mais le top étant de masqué son adresse IP en utilisant un proxy. Avoir un second ordinateur en guise de serveur / passerelle permet de limiter nos traces et filter les "éventuels" virus développés par les sociétés d'antivirus (chut, ça faut pas le dire, hein).

Utiliser un proxy m'a toujours effrayé.
Comment savoir si l'individu administrant le proxy ne conserve pas les données ?
Prenons par exemple des sites tels que Yaronet, pas de SSL, mon mot de passe transite donc par ce proxy.

Je dois être parano mais je n'ai absolument pas confiance dans les proxies.

Pour les trackers j'utilise "about:trackers" dans Firefox directement et c'est assez effrayant.

Ouais, les proxies anonymes, c'est le mal absolu.
Sinon, comment dire... vu les dernières infos qui sont sorties sur la NSA et le tracking des URL (putain, mais comment ça se fait qu'ils n'aient pas pensé à encoder les URL dans le HTTPS ?!), je pense que la réponse est simple : on ne peut pas, à part faire brûler son matériel info couler les cendres dans du béton et jeter le tout au milieu du Pacfique.

Se prémunir de la vie privée ? C'est simple, il suffit d'utiliser Facebook, et vous serez sûr que vous n'en aurez plus

Sinon, il y a TOR, à condition d'avoir un nœud de sortie dans un pays qui n'est pas du genre Big Brother, et en prenant soin de désactiver le maximum de choses (rien ne sert de cacher son IP si vous avez Javascript ou Flash activé...). Bien sûr, n'utilise qu'un pseudonyme et éviter les réseaux sociaux, service Google, etc.

Le souci de TOR, c'est que dès que tu l'utilises t'es forcément étiqueté "mec qui a des trucs à se reprocher". Et que désactiver le js et le flash c'est de plus en plus difficile pour un usage quotidien.

J'ai pas dit le contraire

Nhut (./5) :
https://prism-break.org/#en

Sauf que, comme la sibyllinement souligné YN, ça ne permet pas de passer au travers de Keyscore.

Au fait :

Nil (./5) :
putain, mais comment ça se fait qu'ils n'aient pas pensé à encoder les URL dans le HTTPS ?!

Elles le sont.

oui ça m'aurait étonné, dès que TLS est établi, tout ce qui passe dans le tuyau est protégé.

Pour le nom de domaine, je ne sais plus comment ça fonctionne.
Je crois que le ndd est négocié pendant le handshake TLS (faut voir exactement comment, vu que le certificat présenté par le serveur dépend a priori du virtualhost demandé).


Par contre, je ne suis pas franchement convaincu que Firefox protège vraiment mieux la vie privée qu'un autre navigateur (à part Chrome)

le nom de domaine est transformé en IP puis le serveur est contacté

ceci posait des problèmes jusqu'à il y a peu car il n'y avait pas moyen de distinguer des vhosts SSL différents autrement qu'avec un certificat wildcard.

depuis on a inventé l'extension SNI qui permet de prendre en compte la notion de virtual host, et dans les versions récentes c'est activé par défaut.

http://wiki.gandi.net/fr/ssl/multiplecertononehostipport

Ça ne répond pas à la question comment le ndd peut-il être dans le tunnel SSL alors qu'il n'est pas encore créé ^^

Ben de toute façon, à ma connaissance les requêtes DNS ne sont pas protégées, donc le NDD non plus. Et quand bien même elles le seraient, au final il y a bien des paquets envoyés au serveur du NDD, donc on peut le savoir comme ça (c'est juste qu'on ne saura pas quel est le NDD précis si le serveur en héberge plusieurs).

Sans aller jusqu'à crypter le ndd (ok, pour des raisons évidentes, ça ne me semble pas trivial), pourquoi est-ce qu'on ne peut pas crypter tout ce qui est après le / qui suit le tld ?

C'est le cas.

Bah euh... non ?
Quand on logge ce qui passe sur nos matériels actifs au boulot, on a l'URL complète même pour le https...

Ça ne semble pas normal. Quelqu'un a une idée ?

Je viens de lire un truc similaire aussi... faut que je regarde un peu plus loin, c'est peut-être que le test rapide qu'on a fait n'était pas correct...

je suis pas au courant d'un STARTTLS comme pour le smtp, donc normalement c'est SSLisé dès le premier octet.

très inquiétant, sauf cette phrase sur bitcoin à la fin qui fait un peu bullshit.

Nil (./18) :
Bah euh... non ?Quand on logge ce qui passe sur nos matériels actifs au boulot, on a l'URL complète même pour le https...

Heu... ?

C'est bien le "vrai" certificat qui apparaît quand vous visitez un site en HTTPS, pas un certificat de chez vous dont l'autorité racine aurait été ajoutée par défaut dans toutes vos postes ?

en fait Nil il nous le cache, mais en fait il travaille à la DGSE

Nil (./20) :
Je viens de lire un truc similaire aussi... faut que je regarde un peu plus loin, c'est peut-être que le test rapide qu'on a fait n'était pas correct...

Non, j'ai la réponse... on a testé sur un serveur de chez nous qui centralise tout et le système de log mixe tout ce qu'il récupère, du coup il y avait non seulement les requêtes en sortie de la machine de test aux quelles étaient agglomérées les requêtes enregistrées par le serveur et qui concernaient ladite machine. Donc effectivement, il n'y avait pas les url dans le flux réseau mais sur le serveur final.

Zerosquare (./15) :
Ben de toute façon, à ma connaissance les requêtes DNS ne sont pas protégées, donc le NDD non plus. Et quand bien même elles le seraient, au final il y a bien des paquets envoyés au serveur du NDD, donc on peut le savoir comme ça (c'est juste qu'on ne saura pas quel est le NDD précis si le serveur en héberge plusieurs).

En meme temps vu comment marche les requetes DNS avec les systeme de cache et les navigatueur modernes qui vont aller préventivement faire un resolve sur tous les DNS présent sur une page, on peux imaginer un systeme qui flood le serveur de cache DNS avec des domaines bidons et le bon au milieu comme ça, ça risque d'être dur de savoir ce qui est demandé...

Tu as quand même toujours l'IP distante à laquelle est associée le trafic. Sur un serveur mutualisé ça laisse une ambiguïté, mais pour les gros sites c'est plié.

En plein dans le sujet :

Un jeu vidéo pour dénoncer le commerce des données personnelles sur Internet
http://www.challenges.fr/high-tech/20130803.CHA2845/un-jeu-video-pour-denoncer-le-commerce-des-donnees-personnelles-sur-internet.html

J'attends "Watchdog" sérieusement ^_^