JeromeJ's links
614 shaares
28 results
tagged
security
Bon, sachant que sebsauvage lit rarement ses mails, je vais tenter de le contacter par ici. :)
Ton implémentation est non sécurisée. C'est mal car d'autres personnes risquent de s'en inspirer sans savoir les problèmes liés à cette implémentation.
1) " Warning - When comparing the output of hexdigest() to an externally-supplied digest during a verification routine, it is recommended to use the compare_digest() function instead of the == operator to reduce the vulnerability to timing attacks." https://docs.python.org/3.4/library/hmac.html#hmac.HMAC.hexdigest
2) "The digestmod argument to the hmac.new() function may now be any hash digest name recognized by hashlib. In addition, the current behavior in which the value of digestmod defaults to MD5 is deprecated: in a future version of Python there will be no default value. (Contributed by Christian Heimes in issue 17276.)" https://docs.python.org/3/whatsnew/3.4.html#hmac
Donc il faudrait mieux commencer à spécifier une valeur pour digestmod.
Comme suggéré par l'issue (1) et cette réponse sur SO (2), je proposerais d'utiliser SHA-256 ou SHA-512 comme suit :
hmac.compare_digest(hmac.new(key, name, digestmod=hashlib.sha256).hexdigest(), signature)
(+ remplacer partout où il faut bien sure et ne pas oublier import hashlib)
(1) https://bugs.python.org/issue17276
"As of now the hash algorithm for HMAC defaults to MD5. However MD5 is considered broken. HMAC-MD5 is still ok but shall not be used in new code. Applications should slowly migrate away from HMAC-MD5 and use a more modern algorithm like HMAC-SHA256.
Therefore I propose that default digestmod should be deprecated in Python 3.4 and removed in 3.5. Starting with Python 3.5 developer are forced to choose a hash algorithm like SHA256. Our documentation shall suggest it, too."
(2) http://crypto.stackexchange.com/a/9340/18518
"Yes, there are currently no known attacks on HMAC-MD5.
[…]
However, this does not mean you should use HMAC-MD5 in new cryptosystem designs. To paraphrase Bruce Schneier, "attacks only get better, never worse." We already have practical collision attacks for MD5, showing that it does not meet its original security goals; it's possible that, any day now, someone might figure out a way to turn those into a preimage attack, which would compromise the security of HMAC-MD5. A much better choice would be to use HMAC with a hash function having no known attacks, such as SHA-2 or SHA-3."
Ton implémentation est non sécurisée. C'est mal car d'autres personnes risquent de s'en inspirer sans savoir les problèmes liés à cette implémentation.
1) " Warning - When comparing the output of hexdigest() to an externally-supplied digest during a verification routine, it is recommended to use the compare_digest() function instead of the == operator to reduce the vulnerability to timing attacks." https://docs.python.org/3.4/library/hmac.html#hmac.HMAC.hexdigest
2) "The digestmod argument to the hmac.new() function may now be any hash digest name recognized by hashlib. In addition, the current behavior in which the value of digestmod defaults to MD5 is deprecated: in a future version of Python there will be no default value. (Contributed by Christian Heimes in issue 17276.)" https://docs.python.org/3/whatsnew/3.4.html#hmac
Donc il faudrait mieux commencer à spécifier une valeur pour digestmod.
Comme suggéré par l'issue (1) et cette réponse sur SO (2), je proposerais d'utiliser SHA-256 ou SHA-512 comme suit :
hmac.compare_digest(hmac.new(key, name, digestmod=hashlib.sha256).hexdigest(), signature)
(+ remplacer partout où il faut bien sure et ne pas oublier import hashlib)
(1) https://bugs.python.org/issue17276
"As of now the hash algorithm for HMAC defaults to MD5. However MD5 is considered broken. HMAC-MD5 is still ok but shall not be used in new code. Applications should slowly migrate away from HMAC-MD5 and use a more modern algorithm like HMAC-SHA256.
Therefore I propose that default digestmod should be deprecated in Python 3.4 and removed in 3.5. Starting with Python 3.5 developer are forced to choose a hash algorithm like SHA256. Our documentation shall suggest it, too."
(2) http://crypto.stackexchange.com/a/9340/18518
"Yes, there are currently no known attacks on HMAC-MD5.
[…]
However, this does not mean you should use HMAC-MD5 in new cryptosystem designs. To paraphrase Bruce Schneier, "attacks only get better, never worse." We already have practical collision attacks for MD5, showing that it does not meet its original security goals; it's possible that, any day now, someone might figure out a way to turn those into a preimage attack, which would compromise the security of HMAC-MD5. A much better choice would be to use HMAC with a hash function having no known attacks, such as SHA-2 or SHA-3."
"Qqn" m'a passé ce lien en réponse à ce lien de sebsauvage qui date un peu : http://sebsauvage.net/links/?miNiXQ
Je sais pas ce qu'il en ressort depuis… Qqn sait ? Quid des agissements actuels de la NSA ? Quid de Yahoo ?
En tout cas c'est joyeux ce chantage de la NSA :/
Je sais pas ce qu'il en ressort depuis… Qqn sait ? Quid des agissements actuels de la NSA ? Quid de Yahoo ?
En tout cas c'est joyeux ce chantage de la NSA :/
So, except few exceptions, almost all passwords shouldn't have "any" limit on the size of them upward (= no maximum length). Riiiight? :)
(Since they aren't supposed to be stored in raw form anyway and most (if not all?) hashing algorithm accept any size of password and always return unique constant length string)
So why HTML doesnt prevent bad ideas to be working? Like setting a maximum length on a password input… The way I see it, that would just not work and be reported in the console for debbugging purpose.
For the things I, so called "exceptions", I was thinking about PIN codes for instance. I could imagine letting HTML implements a new tag (or a new type of input tag) allowing a max length, but surely it would surely be abused though… Maybe those "PIN code" input should allow one fixed-length of password (as expected from a PIN code anyway and that would induce way less abuse too):
Finally, my browser (maybe some others too, mine is currently Palemoon, a implementation of Firefox) only prevent me to type more characters when I reach the maximum allowed by max-length, …, it doesnt warn me, it does nothing but preventing… The problem is that, if it was plain text, I could notice it easily, but as it is a password input and that my password is longer than the visible length of the field, then I have no fucking clue that what I'm currently typing is thrown away as I type it… -_-
So, some fucking warning would be appreciated at least!
(Since they aren't supposed to be stored in raw form anyway and most (if not all?) hashing algorithm accept any size of password and always return unique constant length string)
So why HTML doesnt prevent bad ideas to be working? Like setting a maximum length on a password input… The way I see it, that would just not work and be reported in the console for debbugging purpose.
For the things I, so called "exceptions", I was thinking about PIN codes for instance. I could imagine letting HTML implements a new tag (or a new type of input tag) allowing a max length, but surely it would surely be abused though… Maybe those "PIN code" input should allow one fixed-length of password (as expected from a PIN code anyway and that would induce way less abuse too):
Finally, my browser (maybe some others too, mine is currently Palemoon, a implementation of Firefox) only prevent me to type more characters when I reach the maximum allowed by max-length, …, it doesnt warn me, it does nothing but preventing… The problem is that, if it was plain text, I could notice it easily, but as it is a password input and that my password is longer than the visible length of the field, then I have no fucking clue that what I'm currently typing is thrown away as I type it… -_-
So, some fucking warning would be appreciated at least!
Bonne question … (Good question)
Peu de réponses … (Few answers)
Peu de réponses … (Few answers)
Quoi ?! Relayer le problème en utilisant la connexion via Google/FB & co? C'est une blague ?
J'ai pas encore regardé le reste de la vidéo. :)
J'ai pas encore regardé le reste de la vidéo. :)
À propos de:
A Popular Ad Blocker Also Helps the Ad Industry | MIT Technology Review [5]
http://www.technologyreview.com/news/516156/a-popular-ad-blocker-also-helps-the-ad-industry/
------------------------------------
Un article vous paraît louche ?
Vous voulez avoir l'opinion d'autres personnes, peut-être plus informées que vous ?
Bref, vous aimerez soit plus d'informations pour vous forger votre propre opinion et/ou vous n'avez pas trop envie de vous taper la lecture de ce tl;dr ?
Ben si vous avez de la chance, d'autres l'ont déjà commenté. Il y a plusieurs façons de vérifier ça. ☺
Comme par exemple, copier/coller le lien dans shaarli.fr.
Alors dans ce cas ci, je peux voir que des personnes ont, du coup, fuient Ghostery, mais sebsauvage nous donne, ce qui ressemble à, une analyse pertinente allant dans le sens opposé de l'article.
Et vu que l'article est tl;dr, je crois que je me fierais à sebsauvage et aux commentaires trouvé sur la source (commentaires que j'avais zappé, j'avais directement cliqué sur le lien, intrigué).
Via: https://news.ycombinator.com/item?id=7811455
A Popular Ad Blocker Also Helps the Ad Industry | MIT Technology Review [5]
http://www.technologyreview.com/news/516156/a-popular-ad-blocker-also-helps-the-ad-industry/
------------------------------------
Un article vous paraît louche ?
Vous voulez avoir l'opinion d'autres personnes, peut-être plus informées que vous ?
Bref, vous aimerez soit plus d'informations pour vous forger votre propre opinion et/ou vous n'avez pas trop envie de vous taper la lecture de ce tl;dr ?
Ben si vous avez de la chance, d'autres l'ont déjà commenté. Il y a plusieurs façons de vérifier ça. ☺
Comme par exemple, copier/coller le lien dans shaarli.fr.
Alors dans ce cas ci, je peux voir que des personnes ont, du coup, fuient Ghostery, mais sebsauvage nous donne, ce qui ressemble à, une analyse pertinente allant dans le sens opposé de l'article.
Et vu que l'article est tl;dr, je crois que je me fierais à sebsauvage et aux commentaires trouvé sur la source (commentaires que j'avais zappé, j'avais directement cliqué sur le lien, intrigué).
Via: https://news.ycombinator.com/item?id=7811455
Bronco: "Une petite idée d'amélioration possible pour pickypaste: serait-il possible d'étendre la durée de validité du message pour le user ? (ou de cocher une case "permettre au destinataire de prolonger la durée de validité")
ça permettrait de ne pas perdre direct le message si on n'a pas le temps d'y répondre dès la lecture ^^"
J'aime beaucoup l'idée (si je l'ai bien comprise), mais je ne vois pas trop (pas encore ?) comment on pourrait implémenter ça par contre…
(Le fait que PickyPaste utilise un zerobin externe au lieu d'être un fork de zerobin limite quelques possibilités ou rend les choses plus complexes...)
ça permettrait de ne pas perdre direct le message si on n'a pas le temps d'y répondre dès la lecture ^^"
J'aime beaucoup l'idée (si je l'ai bien comprise), mais je ne vois pas trop (pas encore ?) comment on pourrait implémenter ça par contre…
(Le fait que PickyPaste utilise un zerobin externe au lieu d'être un fork de zerobin limite quelques possibilités ou rend les choses plus complexes...)
Petite mise à jour de PickyPaste.
La version indev (le lien que je viens de passer), renvoie le lien vers la version indev, c'est mieux.
À la proposition de Bronco, j'ai rajouté un chtit lien "Répondre via PickyPaste" si l'utilisateur a spécifié son adresse email.
Voilà, c'tout.
La version indev (le lien que je viens de passer), renvoie le lien vers la version indev, c'est mieux.
À la proposition de Bronco, j'ai rajouté un chtit lien "Répondre via PickyPaste" si l'utilisateur a spécifié son adresse email.
Voilà, c'tout.
Pu****, je ne dois sûrement pas être le premier à me plaindre.
"Votre mot de passe ne peut excéder plus de 16 caractères" WTF?!!
"Votre mot de passe contient des caractères illégaux" RE-WTF?!!
Si c'est pas super évident qu'ils stockent les mots de passes en clair ces saligauds…
Oui, je sais, je devrais quitter le navire. Pff.
"Votre mot de passe ne peut excéder plus de 16 caractères" WTF?!!
"Votre mot de passe contient des caractères illégaux" RE-WTF?!!
Si c'est pas super évident qu'ils stockent les mots de passes en clair ces saligauds…
Oui, je sais, je devrais quitter le navire. Pff.
Intéressant !
Ne vous faites pas avoir !
Ne vous faites pas avoir !
J'avais au début penser à une simple info à rajouter dans le lien après l'ancre (avec la clé de déchiffrement) mais je pense qu'on peut mieux faire.
* En effet, voyez-vous, ça induit un problème :
Si j'envoie un lien "Burn After Reading" sur un réseau non fiable, disons par exemple Skype, mais que l'information sur quand il expire serait elle-même contenue dans l'URL.
Alors, le méchant réseau (ça pourrait très bien être chez vous, à votre boulot, etc. = tout ce qui n'est pas chiffré bout-à-bout) pourrait éventuellement récupérer cette date d'expiration et tenter de l'ouvrir juste avant expiration.
De cette manière si vous avez oublié de l'ouvrir, il peut aisément savoir le moment le plus propice pour l'ouvrir sans risquer de se faire chopper.
En effet il est très peu probable que vous parveniez à l'ouvrir entre le moment où il l'a ouvert et le moment où il a expiré, tout au plus, cela vous laisserait seulement avec un doute qu'il se peut qu'il y ait eu un lag ou que les horloges entre vous et le serveur soient un peu décalées mais qu'au final, dans tous les cas, vous êtes peut-être arrivé un peu trop tard (Fin bref ça reste quand même extrême).
* SOLUTION:
La solution serait, je pense, et afin de ne pas être obligé de garder la métadonnée (quand ce paste était censé expiré) même après suppression du contenu des pastes expiré (pour clean up) d'avoir une clée privée côté serveur et d'avoir l'information de quand le paste devait expiré chiffré dans l'URL du paste et envoyé au serveur lors de la tentative de récupération du paste. Alors, si le serveur ne peut pas servir ce paste, il déchiffre l'information stockée dans l'URL (seul lui le peut, car elle aura été chiffré par sa clé publique) et il affichera l'information.
De cette manière on garde la fonctionnalité sans donner un moyen facile pour un réseau espion d'exploiter une faille potentielle.
(Seule faiblesse que je vois c'est que la clé privée privée du serveur est unique, y aurait-il moyen de, plutôt, la lier à l'id du paste ?
Genre peut-on créer une paire de clé à partir de "salt du serveur (privé, unique) + id du past" qui servirait à chiffrer l'info de façon unique pour chaque paste ?)
* En effet, voyez-vous, ça induit un problème :
Si j'envoie un lien "Burn After Reading" sur un réseau non fiable, disons par exemple Skype, mais que l'information sur quand il expire serait elle-même contenue dans l'URL.
Alors, le méchant réseau (ça pourrait très bien être chez vous, à votre boulot, etc. = tout ce qui n'est pas chiffré bout-à-bout) pourrait éventuellement récupérer cette date d'expiration et tenter de l'ouvrir juste avant expiration.
De cette manière si vous avez oublié de l'ouvrir, il peut aisément savoir le moment le plus propice pour l'ouvrir sans risquer de se faire chopper.
En effet il est très peu probable que vous parveniez à l'ouvrir entre le moment où il l'a ouvert et le moment où il a expiré, tout au plus, cela vous laisserait seulement avec un doute qu'il se peut qu'il y ait eu un lag ou que les horloges entre vous et le serveur soient un peu décalées mais qu'au final, dans tous les cas, vous êtes peut-être arrivé un peu trop tard (Fin bref ça reste quand même extrême).
* SOLUTION:
La solution serait, je pense, et afin de ne pas être obligé de garder la métadonnée (quand ce paste était censé expiré) même après suppression du contenu des pastes expiré (pour clean up) d'avoir une clée privée côté serveur et d'avoir l'information de quand le paste devait expiré chiffré dans l'URL du paste et envoyé au serveur lors de la tentative de récupération du paste. Alors, si le serveur ne peut pas servir ce paste, il déchiffre l'information stockée dans l'URL (seul lui le peut, car elle aura été chiffré par sa clé publique) et il affichera l'information.
De cette manière on garde la fonctionnalité sans donner un moyen facile pour un réseau espion d'exploiter une faille potentielle.
(Seule faiblesse que je vois c'est que la clé privée privée du serveur est unique, y aurait-il moyen de, plutôt, la lier à l'id du paste ?
Genre peut-on créer une paire de clé à partir de "salt du serveur (privé, unique) + id du past" qui servirait à chiffrer l'info de façon unique pour chaque paste ?)
Ouch, il y aurait eu une faille dans Cryptocat pendant 2 ans, arghhhh … :x
Ça serait maintenant corrigé en tout cas :/
Euh, vive OTR ?
Ça serait maintenant corrigé en tout cas :/
Euh, vive OTR ?
Je ne le dirais jamais assez souvent >.< N'utilisez pas Chrome !! Pas de FUCKING EXCUSE !!
Vous vous attendiez à quoi de la part d'un produit créé par ce big bro géant ? :)
(Hello Google, je ne t'aime pas ! Oups, désolé)
Vous vous attendiez à quoi de la part d'un produit créé par ce big bro géant ? :)
(Hello Google, je ne t'aime pas ! Oups, désolé)
:( fuuuuuuuuuuuuuuuuuuuuuuuuuuuu …
Faut également espérer que la manie ne se répande pas.
Dans un premier temps, perso, j'ai pas installé Flashblock pour ma sécurité. Pour avoir le choix d'abord et aussi pour éviter qu'il me lance plein de vidéos d'un coup lorsque j'ouvre plusieurs onglets Youtube par exemple.
(Je crois que NoScript est plus efficace à ce petit jeu, reste plus qu'à améliorer NoScript pour qu'il fonctionne sur base des md5 (par exemple) plutôt que par domaines (fin, ou les deux, mais perso je pref me baser sur l'identification d'un script, comme ça même si le site est compromis, j'suis safe))
EDIT: Bon, vu que ça a quand même une vocation d'identifier de façon sûre les scripts pouvant être exécuté, pierreghz me fait remarquer qu'utiliser SHA2 serait plus judicieux que MD5 vu qu'on a déjà détecté des collisions avec MD5.
Faut également espérer que la manie ne se répande pas.
Dans un premier temps, perso, j'ai pas installé Flashblock pour ma sécurité. Pour avoir le choix d'abord et aussi pour éviter qu'il me lance plein de vidéos d'un coup lorsque j'ouvre plusieurs onglets Youtube par exemple.
(Je crois que NoScript est plus efficace à ce petit jeu, reste plus qu'à améliorer NoScript pour qu'il fonctionne sur base des md5 (par exemple) plutôt que par domaines (fin, ou les deux, mais perso je pref me baser sur l'identification d'un script, comme ça même si le site est compromis, j'suis safe))
EDIT: Bon, vu que ça a quand même une vocation d'identifier de façon sûre les scripts pouvant être exécuté, pierreghz me fait remarquer qu'utiliser SHA2 serait plus judicieux que MD5 vu qu'on a déjà détecté des collisions avec MD5.
Découvrez à quel point vous êtes identifiable parmi une base de données de, actuellement, 3 millions de profiles.
Beaucoup de mes amis étaient, tout comme moi, tristement uniquement identifiable uniquement basé sur votre 'profil' (les plugins que vous utilisez, etc …)
Et vous quel est votre score ?
Je vous conseille de désactiver tous les plugins inutiles qui auraient pu s'installer sur votre PC, d'installer flash block.
Et si vous en avez le loisir, d'utiliser TOR pour les connections "passives" (ne donnez pas votre mot de passe, etc). https://www.torproject.org/dist/torbrowser/tor-browser-2.3.25-8_en-US.exe (Serait aussi dispo dans les dépôts Linux apparemment ;))
PS: Je sais que j'en ai déjà parlé mais c'était au milieu d'un long roman :) Voilà qui est bien plus propre !
Beaucoup de mes amis étaient, tout comme moi, tristement uniquement identifiable uniquement basé sur votre 'profil' (les plugins que vous utilisez, etc …)
Et vous quel est votre score ?
Je vous conseille de désactiver tous les plugins inutiles qui auraient pu s'installer sur votre PC, d'installer flash block.
Et si vous en avez le loisir, d'utiliser TOR pour les connections "passives" (ne donnez pas votre mot de passe, etc). https://www.torproject.org/dist/torbrowser/tor-browser-2.3.25-8_en-US.exe (Serait aussi dispo dans les dépôts Linux apparemment ;))
PS: Je sais que j'en ai déjà parlé mais c'était au milieu d'un long roman :) Voilà qui est bien plus propre !
Quid de https://en.wikipedia.org/wiki/Web_of_Trust ??
Il y a moyen de créer des réseaux de confiance (un peu comparable à ceux qu'on peut faire en vrai et/ou sur shaarli :p) et, au pire - ou plutôt au mieux ? Je sais pas … - le premier certificat validé pourrait très bien être validé IRL, non ?
Si tu vois où je veux en venir … C'est assez robuste les réseaux de confiance (de ce que j'en connais / comprend)
[btw: le lien que je donne au début ne parle pas "exactement" de ça je crois, mais plutôt dans un cadre spécifique ??)
Il y a moyen de créer des réseaux de confiance (un peu comparable à ceux qu'on peut faire en vrai et/ou sur shaarli :p) et, au pire - ou plutôt au mieux ? Je sais pas … - le premier certificat validé pourrait très bien être validé IRL, non ?
Si tu vois où je veux en venir … C'est assez robuste les réseaux de confiance (de ce que j'en connais / comprend)
[btw: le lien que je donne au début ne parle pas "exactement" de ça je crois, mais plutôt dans un cadre spécifique ??)
"Quand vous utilisez TOR pour aller sur le web "normal", cela veut dire que vos requêtes HTTP sortent par un participant aléatoire du réseau TOR. Le serveur web ne verra que cette adresse IP, pas la vôtre. Mais cela veut dire aussi que le nœud de sortie TOR verra votre trafic web ainsi que vos mots de passe. Et il y a déjà eu quelques affaires très sérieuses de vol de mots de passe liées à TOR. Et absolument n'importe qui peut mettre en route un nœud de sortie. Je vous recommande donc la prudence. En ce qui me concerne, je préfère ne pas pré-supposer qu'un membre du réseau TOR est forcément bienveillant (Bisounours outside™), donc je n'utilise pas TOR."
Et si tu ne te sers de TOR que pour la consommation passive ? ;) (ou pour diffuser "anonymement" évidemment, mais pas pour les connexions authentifiées)
À part une attaque man-in-the-middle qui remplacerait le contenu finale, tu as bien dit que le nœud de sortie ne peut pas savoir qui a émit la requête, etc ?
Et (ça ne va faire que la 3ème fois que je pose la question du coup (également dans mes 2 shaarliens précédent ^^)), il n'y pas moyen d'être "safe" via SSL ? :)
Sauf si, comme je le crains mais je n'en suis pas sûr, SSL ne signe pas les données qu'on envoie, il les chiffre juste pour le destinataire (enfin ça rendrait la substitution de données quand même plus délicate sauf si il s'agirait d'une requête atypique (donc pas besoin de connaître la nature du paquet émis, on le remplace juste par le notre))
Et si tu ne te sers de TOR que pour la consommation passive ? ;) (ou pour diffuser "anonymement" évidemment, mais pas pour les connexions authentifiées)
À part une attaque man-in-the-middle qui remplacerait le contenu finale, tu as bien dit que le nœud de sortie ne peut pas savoir qui a émit la requête, etc ?
Et (ça ne va faire que la 3ème fois que je pose la question du coup (également dans mes 2 shaarliens précédent ^^)), il n'y pas moyen d'être "safe" via SSL ? :)
Sauf si, comme je le crains mais je n'en suis pas sûr, SSL ne signe pas les données qu'on envoie, il les chiffre juste pour le destinataire (enfin ça rendrait la substitution de données quand même plus délicate sauf si il s'agirait d'une requête atypique (donc pas besoin de connaître la nature du paquet émis, on le remplace juste par le notre))
… dans une certaine mesure, troquer la confiance de la connexion "directe" à un serveur (le FAI ou le destinataire pouvant être 'vérolé' et/ou très peu soucieux de nos droits / note vie privée) contre la confiance en un tas de nœud piochés au hasard, on doit donc faire confiance à ces intermédiaires même sans les connaître (ce pourquoi je pense qu'il y aurait moyen de faire un système meilleur que TOR) à l'exception près qu'on bénéficie de la règle des 2 conneries à la seconde ( http://sametmax.com/deux-conneries-a-la-seconde/ ) qui nous protège bien mieux qu'une connexion directe en général.
Si je comprend bien son fonctionnement , je préconise quand même d'utiliser SSL (https) lorsque c'est possible (même si je ne suis pas sûr que ça puisse empêcher les attaques Man-In-The-Middle - voir mon précédent shaarlien).
Personnellement, j'utilise "TOR in a box" : https://www.torproject.org/dist/torbrowser/tor-browser-2.3.25-8_en-US.exe (via PoGo)
Il fournit NoScript par défaut même s'il n'est pas activé par défaut (je vous le conseille vivement). (NoScript ne permet pas le filtrage par somme md5 des scripts ? MAIS C'EST NUL de pouvoir filtrer uniquement par domaine -.- surtout si il y a une attaque man-in-the-middle)
Il y a moyen de visionner des vidéos flash avec TOR même si cela est déconseillé. Si vous le faites veillez bien à installer BetterPrivacy en plus … ça reste pas génial.
Perso j'ai aussi installer flashblock (inutile dans ce cas je pense car flash requiert toujours un démarrage manuel comparable à celui demandé par flashblock en temps normal)
Pourquoi je suis passé à TOR : https://panopticlick.eff.org/ Être détectable de façon unique sur l'entièreté de leur base de données (plus de 3M) … ça fait mal.
Pour limiter les dégâts (mais c'est malheureusement pas suffisant), désactivez tous les plugins à la con qui servent à rien (dans Firefox : Tools > Add-ons > Plugins), perso je n'ai gardé que flash (avec flash block)(un des plus traître avec Java) et le plugin VLC.
Vous pouvez aussi passer en navigation privée (avec Firefox : File > New private windows, mais la fonctionnalité est disponible avec les autres navigateurs aussi) mais pour ma part ce qui me gêne le plus alors est de ne pas pouvoir restaurer ma session en cas de crash (vu le nombre d'onglet que j'ai d'ouvert (+ de 200), ça m'énerverait).
Donc TOR est, selon moi, l'idéal pour pas mal de choses. Ou plutôt … le moins pire :)
Je reste quand même avec Firefox ouvert d'un côté et Firefox+TOR de l'autre pour utiliser l'un plutôt que l'autre en fonction des circonstances.
EDIT: http://www.sebsauvage.net/rhaa/index.php?2010/09/06/06/42/30-freenet-tor-i2p-meme-combat après relecture de cet article. Je vois quand même que c'est assez robuste :)
J'aimerais quand même bien un réseau de confiance perso (mais certains me diront ptet que ça c'est … inutile ?)
Si je comprend bien son fonctionnement , je préconise quand même d'utiliser SSL (https) lorsque c'est possible (même si je ne suis pas sûr que ça puisse empêcher les attaques Man-In-The-Middle - voir mon précédent shaarlien).
Personnellement, j'utilise "TOR in a box" : https://www.torproject.org/dist/torbrowser/tor-browser-2.3.25-8_en-US.exe (via PoGo)
Il fournit NoScript par défaut même s'il n'est pas activé par défaut (je vous le conseille vivement). (NoScript ne permet pas le filtrage par somme md5 des scripts ? MAIS C'EST NUL de pouvoir filtrer uniquement par domaine -.- surtout si il y a une attaque man-in-the-middle)
Il y a moyen de visionner des vidéos flash avec TOR même si cela est déconseillé. Si vous le faites veillez bien à installer BetterPrivacy en plus … ça reste pas génial.
Perso j'ai aussi installer flashblock (inutile dans ce cas je pense car flash requiert toujours un démarrage manuel comparable à celui demandé par flashblock en temps normal)
Pourquoi je suis passé à TOR : https://panopticlick.eff.org/ Être détectable de façon unique sur l'entièreté de leur base de données (plus de 3M) … ça fait mal.
Pour limiter les dégâts (mais c'est malheureusement pas suffisant), désactivez tous les plugins à la con qui servent à rien (dans Firefox : Tools > Add-ons > Plugins), perso je n'ai gardé que flash (avec flash block)(un des plus traître avec Java) et le plugin VLC.
Vous pouvez aussi passer en navigation privée (avec Firefox : File > New private windows, mais la fonctionnalité est disponible avec les autres navigateurs aussi) mais pour ma part ce qui me gêne le plus alors est de ne pas pouvoir restaurer ma session en cas de crash (vu le nombre d'onglet que j'ai d'ouvert (+ de 200), ça m'énerverait).
Donc TOR est, selon moi, l'idéal pour pas mal de choses. Ou plutôt … le moins pire :)
Je reste quand même avec Firefox ouvert d'un côté et Firefox+TOR de l'autre pour utiliser l'un plutôt que l'autre en fonction des circonstances.
EDIT: http://www.sebsauvage.net/rhaa/index.php?2010/09/06/06/42/30-freenet-tor-i2p-meme-combat après relecture de cet article. Je vois quand même que c'est assez robuste :)
J'aimerais quand même bien un réseau de confiance perso (mais certains me diront ptet que ça c'est … inutile ?)
Je me posais 2 petites question auxquelles personne ne m'a encore répondu :
(02:44:19) jeromej: Tiens par défaut TOR in a box n'est configuré pour être uniquement un client ? :o
(02:44:28) jeromej: je comprend pas les autres options par contre ...
(02:45:12) jeromej: quoique .. par contre je sais pas trop quoi choisir
(02:45:51) jeromej: non-exit relay, exit-relay ou "aider les utilisateurs censurés à accéder au réseau Tor"
Que choisir ?
______
(20:39:03) jeromej: quand on utilise SSL (https), ça chiffre avec la clé publique du site pour que l'information ne puisse pas être lue par d'autres, right ?
(20:39:45) jeromej: mais quid d'une attaque Man In The Middle ??? que je sache (mais je trompe ptet), le message en plus d'être chiffré pour le destinataire, n'est pas signé avec ma clée privée ?
(20:40:02) jeromej: donc il pourrait y avoir une subsitution des données sur leur trajet, non ?
(20:40:10) jeromej: (surtout dans le cas de TOR ?)
(02:44:19) jeromej: Tiens par défaut TOR in a box n'est configuré pour être uniquement un client ? :o
(02:44:28) jeromej: je comprend pas les autres options par contre ...
(02:45:12) jeromej: quoique .. par contre je sais pas trop quoi choisir
(02:45:51) jeromej: non-exit relay, exit-relay ou "aider les utilisateurs censurés à accéder au réseau Tor"
Que choisir ?
______
(20:39:03) jeromej: quand on utilise SSL (https), ça chiffre avec la clé publique du site pour que l'information ne puisse pas être lue par d'autres, right ?
(20:39:45) jeromej: mais quid d'une attaque Man In The Middle ??? que je sache (mais je trompe ptet), le message en plus d'être chiffré pour le destinataire, n'est pas signé avec ma clée privée ?
(20:40:02) jeromej: donc il pourrait y avoir une subsitution des données sur leur trajet, non ?
(20:40:10) jeromej: (surtout dans le cas de TOR ?)