afin de rejeter les serveurs de publicité comme amazonaws.com, cette
plaie, j'ai trouvé l'idée de modifier mon fichier hosts, en y incluant
une lonn...ngue liste de serveurs à bannir, tout simplement.
il semble que ce soit radical ...
Les cookies radioactifs d'amazonaws, ça ouvre des myriades de
connections qui vous affichent toutes ces pubs ...
Ce coup là on est plus fort que ces pollueurs. Les addons pour firefox
n'ont pas réussis à me débarrasser de ... toute cette pub, et puis y'a
pas que firefox dans la vie.
Google n'apprécie pas, les liens publicitaires sur le moteur de
recherches deviennent incliquables, bravo ! :-)
ok merci.
La méthode est la plus simplissime que j'ai trouvé: hacker mon fichier
hosts ..... (oui, il est unique, et locké en root).
Sous ubuntu .... j'ai un script, il met à jour /etc/hosts, c'est:
/etc/cron.monthly/hosts
attention c'est un script, c'est un fichier texte avec l'attribut x;
il contient (ici je m'appelle ubuntu, pour l'exemple) :
Ce script modifie hosts pour y inclure le contenu de la page
http://winhelp2002.mvps.org/hosts.txt
PARCE QUE, j'ai essayé les antivirus les antipub pour le cas précis de
amazonaws (les cookies radioactifs!), y'a rien qui marche. Les petits
ADBlock ne marchent plus du tout, les cookies ont trop évolué ! sont
devenus radioactifs, de véritables virus qui passent à travers tous
les filtres de vos brouteurs ... en arriere-plan ils téléchargent UN
MAXIMUM de trucs ! :-) :-) C'est expliqué sur le web (évidemment).
Donc depuis ces petits virus par les cookies .... on trouve de plus
en plus des solutions .. de plus en plus définitives comme hacker hosts,
point barré, c'est radical si c'est maintenu (d'où le classement
en cron, que j'ai recopié, copié-collé et zou' ....... svp) c'est
autant radioactif pour eux que eux le sont pour vous.
....... J'ai voulu minimiser le travail à l'extreme ....
merci etherape, par contre wireshark c'est un bordel .. c'est devenu
compliqué ! J'y comprend absolument rien, je voudrais par exemple
tracer la totalité du trafic sur base du mot clef "amazonaws.com", ça
fait pourtant des années que j'essaye, de temps en temps je retrouve
la solution ... un autre jour peut-être.
--
Tu peux aussi configurer le proxy explicitement. Ainsi, le proxy voit passer pas mal de trucs. Cela permet de filtrer sans casser le SSL.
Autant je comprends ce dont parle Pascal (sauf erreur il s'agit de faire du Man in the middle) autant je ne comprends pas trop ce que tu suggères Kevin. Tu pourrais développer un peu s'il te plaît ?
Pour utiliser un proxy https, le navigateur envoie sa demande: CONNECT site.tld:443 HTTP/1.1 (headers eventuels) Ce qui veut dire que tu vois passer au moins le nom d'hôte. Ce qui permet de différencier simplement une connexion vers facebook.com de wikipedia.org sans casser le SSL. Ensuite, le MITM permet de faire beaucoup plus, bien évidemment. -- Kevin
Le 24-11-2016, Francois Lafont <francois.lafont@nospam.invalid> a écrit :
Tu peux aussi configurer le proxy explicitement. Ainsi, le proxy voit passer
pas mal de trucs.
Cela permet de filtrer sans casser le SSL.
Autant je comprends ce dont parle Pascal (sauf erreur il s'agit de faire du
Man in the middle) autant je ne comprends pas trop ce que tu suggères Kevin.
Tu pourrais développer un peu s'il te plaît ?
Pour utiliser un proxy https, le navigateur envoie sa demande:
CONNECT site.tld:443 HTTP/1.1
(headers eventuels)
Ce qui veut dire que tu vois passer au moins le nom d'hôte. Ce qui permet
de différencier simplement une connexion vers facebook.com de wikipedia.org
sans casser le SSL.
Ensuite, le MITM permet de faire beaucoup plus, bien évidemment.
--
Kevin
Tu peux aussi configurer le proxy explicitement. Ainsi, le proxy voit passer pas mal de trucs. Cela permet de filtrer sans casser le SSL.
Autant je comprends ce dont parle Pascal (sauf erreur il s'agit de faire du Man in the middle) autant je ne comprends pas trop ce que tu suggères Kevin. Tu pourrais développer un peu s'il te plaît ?
Pour utiliser un proxy https, le navigateur envoie sa demande: CONNECT site.tld:443 HTTP/1.1 (headers eventuels) Ce qui veut dire que tu vois passer au moins le nom d'hôte. Ce qui permet de différencier simplement une connexion vers facebook.com de wikipedia.org sans casser le SSL. Ensuite, le MITM permet de faire beaucoup plus, bien évidemment. -- Kevin
Francois Lafont
Bonjour, On 11/25/2016 12:23 PM, Kevin Denis wrote:
Le nom d'hôte permet de filtrer. De mémoire le client envoie aussi son user-agent, et un ou deux autres headers.
Ben perso, je m'inscris en faux par rapport à ça et si je me plante je serais ravi qu'on m'explique. Pour moi, ton proxy verra passer des segments TCP avec notamment IP:port source et IP:port destination parfaitement visibles. Mais tout ce qu'il y aura _dans_ ce segment TCP sera chiffré par SSL. Donc tout ce qu'il relève du http sera inaccessible. Tu parles du nom d'hôte par exemple. Si c'est du header "Host:" dans la requête du client dont tu parles, c'est dans la couche application (http), le proxy ne le verra pas. Idem pour le "User-Agent:" et en fait pour tout ce qui relève de la couche http. Éventuellement ton proxy, connaissant l'IP de destination, pourra tenter une résolution inverse mais ça ne sera pas forcément le nom d'hôte utilisé par le client http (ne serait-ce que parce qu'une même IP peut héberger plusieurs sites Web). -- François Lafont
Bonjour,
On 11/25/2016 12:23 PM, Kevin Denis wrote:
Le nom d'hôte permet de filtrer. De mémoire le client envoie aussi
son user-agent, et un ou deux autres headers.
Ben perso, je m'inscris en faux par rapport à ça et si je me plante
je serais ravi qu'on m'explique.
Pour moi, ton proxy verra passer des segments TCP avec notamment
IP:port source et IP:port destination parfaitement visibles. Mais tout
ce qu'il y aura _dans_ ce segment TCP sera chiffré par SSL. Donc tout
ce qu'il relève du http sera inaccessible.
Tu parles du nom d'hôte par exemple. Si c'est du header "Host:" dans la
requête du client dont tu parles, c'est dans la couche application (http),
le proxy ne le verra pas. Idem pour le "User-Agent:" et en fait pour tout
ce qui relève de la couche http.
Éventuellement ton proxy, connaissant l'IP de destination, pourra tenter
une résolution inverse mais ça ne sera pas forcément le nom d'hôte utilisé
par le client http (ne serait-ce que parce qu'une même IP peut héberger
plusieurs sites Web).
Bonjour, On 11/25/2016 12:23 PM, Kevin Denis wrote:
Le nom d'hôte permet de filtrer. De mémoire le client envoie aussi son user-agent, et un ou deux autres headers.
Ben perso, je m'inscris en faux par rapport à ça et si je me plante je serais ravi qu'on m'explique. Pour moi, ton proxy verra passer des segments TCP avec notamment IP:port source et IP:port destination parfaitement visibles. Mais tout ce qu'il y aura _dans_ ce segment TCP sera chiffré par SSL. Donc tout ce qu'il relève du http sera inaccessible. Tu parles du nom d'hôte par exemple. Si c'est du header "Host:" dans la requête du client dont tu parles, c'est dans la couche application (http), le proxy ne le verra pas. Idem pour le "User-Agent:" et en fait pour tout ce qui relève de la couche http. Éventuellement ton proxy, connaissant l'IP de destination, pourra tenter une résolution inverse mais ça ne sera pas forcément le nom d'hôte utilisé par le client http (ne serait-ce que parce qu'une même IP peut héberger plusieurs sites Web). -- François Lafont
Francois Lafont
On 11/25/2016 12:32 PM, Kevin Denis wrote:
Pour utiliser un proxy https, le navigateur envoie sa demande: CONNECT site.tld:443 HTTP/1.1 (headers eventuels)
Ben mince alors. Si c'est le cas ça relève alors de la tambouille proxy que je connais fort mal. Le client enverrait alors sa requête CONNECT en clair au serveur proxy ? -- François Lafont
On 11/25/2016 12:32 PM, Kevin Denis wrote:
Pour utiliser un proxy https, le navigateur envoie sa demande:
CONNECT site.tld:443 HTTP/1.1
(headers eventuels)
Ben mince alors. Si c'est le cas ça relève alors de la tambouille proxy
que je connais fort mal. Le client enverrait alors sa requête CONNECT
en clair au serveur proxy ?
Pour utiliser un proxy https, le navigateur envoie sa demande: CONNECT site.tld:443 HTTP/1.1 (headers eventuels)
Ben mince alors. Si c'est le cas ça relève alors de la tambouille proxy que je connais fort mal. Le client enverrait alors sa requête CONNECT en clair au serveur proxy ? -- François Lafont
Francois Lafont
On 11/25/2016 12:46 PM, Francois Lafont wrote:
Pour utiliser un proxy https, le navigateur envoie sa demande: CONNECT site.tld:443 HTTP/1.1 (headers eventuels)
Ben mince alors. Si c'est le cas ça relève alors de la tambouille proxy que je connais fort mal. Le client enverrait alors sa requête CONNECT en clair au serveur proxy ?
Et bien j'ai fait un test très rapide avec un squid3 out-of-the-box sur une Debian Jessie et en effet dans les logs de squid3 on voit bien passer la méthode CONNECT avec le host qui est sollicité même en https. J'avais donc tort et tu avais raison Kevin. Au temps pour moi, je crois que j'ai semé quelques bêtises sur ce fil. ;) Peut-être que c'est lié au fonctionnent d'un proxy http ou alors le https ne fonctionne pas comme je l'imaginais. Bref, si certains d'entre vous ont des explications ou des liens intéressants, le sujet m'intéresse beaucoup. Merci. -- François Lafont
On 11/25/2016 12:46 PM, Francois Lafont wrote:
Pour utiliser un proxy https, le navigateur envoie sa demande:
CONNECT site.tld:443 HTTP/1.1
(headers eventuels)
Ben mince alors. Si c'est le cas ça relève alors de la tambouille proxy
que je connais fort mal. Le client enverrait alors sa requête CONNECT
en clair au serveur proxy ?
Et bien j'ai fait un test très rapide avec un squid3 out-of-the-box sur
une Debian Jessie et en effet dans les logs de squid3 on voit bien passer
la méthode CONNECT avec le host qui est sollicité même en https.
J'avais donc tort et tu avais raison Kevin. Au temps pour moi, je crois
que j'ai semé quelques bêtises sur ce fil. ;)
Peut-être que c'est lié au fonctionnent d'un proxy http ou alors le
https ne fonctionne pas comme je l'imaginais.
Bref, si certains d'entre vous ont des explications ou des liens
intéressants, le sujet m'intéresse beaucoup.
Pour utiliser un proxy https, le navigateur envoie sa demande: CONNECT site.tld:443 HTTP/1.1 (headers eventuels)
Ben mince alors. Si c'est le cas ça relève alors de la tambouille proxy que je connais fort mal. Le client enverrait alors sa requête CONNECT en clair au serveur proxy ?
Et bien j'ai fait un test très rapide avec un squid3 out-of-the-box sur une Debian Jessie et en effet dans les logs de squid3 on voit bien passer la méthode CONNECT avec le host qui est sollicité même en https. J'avais donc tort et tu avais raison Kevin. Au temps pour moi, je crois que j'ai semé quelques bêtises sur ce fil. ;) Peut-être que c'est lié au fonctionnent d'un proxy http ou alors le https ne fonctionne pas comme je l'imaginais. Bref, si certains d'entre vous ont des explications ou des liens intéressants, le sujet m'intéresse beaucoup. Merci. -- François Lafont
Kevin Denis
Le 25-11-2016, Francois Lafont a écrit :
Bref, si certains d'entre vous ont des explications ou des liens intéressants, le sujet m'intéresse beaucoup.
Je n'ai pas trouvé de lien, mais en gros, c'est que la connexion du point de vue client doit passer par le proyx. Il envoie le CONNECT avec le nom d'hôte, ce qui permet au proxy de faire la résolution de nom et d'ouvrir la socket qui va bien entre le serveur et le client: le client ne sait pas forcément résoudre des noms de domaine... Ensuite, le client discute avec le serveur dans la socket, et les premières informations de connexions sont la montée du canal sécurisé. Le proxy ne voit alors plus rien de la connexion web. -- Kevin
Le 25-11-2016, Francois Lafont <francois.lafont@nospam.invalid> a écrit :
Bref, si certains d'entre vous ont des explications ou des liens
intéressants, le sujet m'intéresse beaucoup.
Je n'ai pas trouvé de lien, mais en gros, c'est que la connexion du
point de vue client doit passer par le proyx. Il envoie le CONNECT avec
le nom d'hôte, ce qui permet au proxy de faire la résolution de nom
et d'ouvrir la socket qui va bien entre le serveur et le client:
le client ne sait pas forcément résoudre des noms de domaine...
Ensuite, le client discute avec le serveur dans la socket, et les
premières informations de connexions sont la montée du canal sécurisé.
Le proxy ne voit alors plus rien de la connexion web.
--
Kevin
Bref, si certains d'entre vous ont des explications ou des liens intéressants, le sujet m'intéresse beaucoup.
Je n'ai pas trouvé de lien, mais en gros, c'est que la connexion du point de vue client doit passer par le proyx. Il envoie le CONNECT avec le nom d'hôte, ce qui permet au proxy de faire la résolution de nom et d'ouvrir la socket qui va bien entre le serveur et le client: le client ne sait pas forcément résoudre des noms de domaine... Ensuite, le client discute avec le serveur dans la socket, et les premières informations de connexions sont la montée du canal sécurisé. Le proxy ne voit alors plus rien de la connexion web. -- Kevin
Pascal Hambourg
Le 25/11/2016 à 12:46, Francois Lafont a écrit :
On 11/25/2016 12:32 PM, Kevin Denis wrote:
Pour utiliser un proxy https, le navigateur envoie sa demande: CONNECT site.tld:443 HTTP/1.1 (headers eventuels)
Ben mince alors. Si c'est le cas ça relève alors de la tambouille proxy que je connais fort mal. Le client enverrait alors sa requête CONNECT en clair au serveur proxy ?
Oui, mais ce n'est pas bien grave. Seule la connexion HTTP entre le client et le proxy est en clair. La connexion HTTPS entre le client et le serveur (via le proxy) est chiffrée de bout en bout.
Le 25/11/2016 à 12:46, Francois Lafont a écrit :
On 11/25/2016 12:32 PM, Kevin Denis wrote:
Pour utiliser un proxy https, le navigateur envoie sa demande:
CONNECT site.tld:443 HTTP/1.1
(headers eventuels)
Ben mince alors. Si c'est le cas ça relève alors de la tambouille proxy
que je connais fort mal. Le client enverrait alors sa requête CONNECT
en clair au serveur proxy ?
Oui, mais ce n'est pas bien grave. Seule la connexion HTTP entre le
client et le proxy est en clair. La connexion HTTPS entre le client et
le serveur (via le proxy) est chiffrée de bout en bout.
Pour utiliser un proxy https, le navigateur envoie sa demande: CONNECT site.tld:443 HTTP/1.1 (headers eventuels)
Ben mince alors. Si c'est le cas ça relève alors de la tambouille proxy que je connais fort mal. Le client enverrait alors sa requête CONNECT en clair au serveur proxy ?
Oui, mais ce n'est pas bien grave. Seule la connexion HTTP entre le client et le proxy est en clair. La connexion HTTPS entre le client et le serveur (via le proxy) est chiffrée de bout en bout.
Pascal Hambourg
Le 25/11/2016 à 12:36, Francois Lafont a écrit :
On 11/25/2016 12:23 PM, Kevin Denis wrote:
Le nom d'hôte permet de filtrer.
Sauf si le client fait la résolution de nom lui-même et indique l'adresse IP du serveur dans la requête CONNECT. Mais je suppose qu'un proxy sérieux doit être capable de refuser une requête CONNECT vers une adresse IP au lieu d'un nom d'hôte.
Tu parles du nom d'hôte par exemple. Si c'est du header "Host:" dans la requête du client dont tu parles
Non, il parle du nom d'hôte dans la requête CONNECT.
Le 25/11/2016 à 12:36, Francois Lafont a écrit :
On 11/25/2016 12:23 PM, Kevin Denis wrote:
Le nom d'hôte permet de filtrer.
Sauf si le client fait la résolution de nom lui-même et indique
l'adresse IP du serveur dans la requête CONNECT. Mais je suppose qu'un
proxy sérieux doit être capable de refuser une requête CONNECT vers une
adresse IP au lieu d'un nom d'hôte.
Tu parles du nom d'hôte par exemple. Si c'est du header "Host:" dans la
requête du client dont tu parles
Non, il parle du nom d'hôte dans la requête CONNECT.
Sauf si le client fait la résolution de nom lui-même et indique l'adresse IP du serveur dans la requête CONNECT. Mais je suppose qu'un proxy sérieux doit être capable de refuser une requête CONNECT vers une adresse IP au lieu d'un nom d'hôte.
Tu parles du nom d'hôte par exemple. Si c'est du header "Host:" dans la requête du client dont tu parles
Non, il parle du nom d'hôte dans la requête CONNECT.
(charlot)
David Sarella écrivait:
le 2016-11-21, charlot a plope ceci:
les cookies ont trop évolué ! sont devenus radioactifs, de véritables virus qui passent à travers tous les filtres de vos brouteurs ... en arriere-plan ils téléchargent UN MAXIMUM de trucs ! :-) :-) C'est expliqué sur le web (évidemment).
n'importe quoi !
Oui oui oui .... Dites-moi comment font carrefour - alibaba - amazonaws pour autant nous spammer ? Les cookies sont des virus à part entière, il faut que je pense à vous faire une démo de mes smarte-phones, androïdEs véritables, des bombes en pilote entierement automatique, c'est affolant, ils font tout eux-me ... j'en ai deux comme ça, des tamagotchis in domp ta bles, comme les virus des spammeurs, et le meilleur: ce sont les mêmes entreprises !!!! de ventes et de publicité. Mwahhaha. Allez, salut. --
David Sarella <oldchap@remote.cispeo.fr> écrivait:
le 2016-11-21, charlot a plope ceci:
> les cookies ont trop évolué ! sont
> devenus radioactifs, de véritables virus qui passent à travers tous
> les filtres de vos brouteurs ... en arriere-plan ils téléchargent UN
> MAXIMUM de trucs ! :-) :-) C'est expliqué sur le web (évidemment).
n'importe quoi !
Oui oui oui ....
Dites-moi comment font carrefour - alibaba - amazonaws pour autant nous
spammer ? Les cookies sont des virus à part entière,
il faut que je pense à vous faire une démo de mes smarte-phones,
androïdEs véritables, des bombes en pilote entierement automatique,
c'est affolant, ils font tout eux-me ... j'en ai deux comme ça, des
tamagotchis in domp ta bles,
comme les virus des spammeurs, et le meilleur: ce sont les mêmes
entreprises !!!! de ventes et de publicité.
les cookies ont trop évolué ! sont devenus radioactifs, de véritables virus qui passent à travers tous les filtres de vos brouteurs ... en arriere-plan ils téléchargent UN MAXIMUM de trucs ! :-) :-) C'est expliqué sur le web (évidemment).
n'importe quoi !
Oui oui oui .... Dites-moi comment font carrefour - alibaba - amazonaws pour autant nous spammer ? Les cookies sont des virus à part entière, il faut que je pense à vous faire une démo de mes smarte-phones, androïdEs véritables, des bombes en pilote entierement automatique, c'est affolant, ils font tout eux-me ... j'en ai deux comme ça, des tamagotchis in domp ta bles, comme les virus des spammeurs, et le meilleur: ce sont les mêmes entreprises !!!! de ventes et de publicité. Mwahhaha. Allez, salut. --
