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.
--
Le Thu, 24 Nov 2016 16:53:22 +0100, Francois Lafont a écrit :
Et du coup, qu'on m'arrête si je dis une bêtise, je dirais que le trafic HTTPS de Christophe passe très certainement par son proxy
Il me semble bien :) # grep REDIRECT /etc/shorewall/rules REDIRECT loc 8080 tcp www - !192.168.0.102 Je présume (sans avoir encore trouvé la réponse dans les docs nombreuses shorewall) que www = http+https
Dans /etc/services, www est juste un alias de http, donc a priori non.
mais celui ne pourra pas analyser grand chose. Il verra juste les IPs et ports source et destination mais part ça rien du tout.
En effet. A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en clair sans déclencher d'alerte, il faut que le poste client soit configuré pour accepter le certificat présenté par le proxy pour n'importe quel site.
Le 24/11/2016 à 18:09, Christophe PEREZ a écrit :
Le Thu, 24 Nov 2016 16:53:22 +0100, Francois Lafont a écrit :
Et du coup, qu'on m'arrête si je dis une bêtise, je dirais que le trafic
HTTPS de Christophe passe très certainement par son proxy
Il me semble bien :)
# grep REDIRECT /etc/shorewall/rules
REDIRECT loc 8080 tcp www - !192.168.0.102
Je présume (sans avoir encore trouvé la réponse dans les docs nombreuses
shorewall) que www = http+https
Dans /etc/services, www est juste un alias de http, donc a priori non.
mais celui ne pourra pas analyser grand chose. Il verra juste les IPs
et ports source et destination mais part ça rien du tout.
En effet.
A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en
clair sans déclencher d'alerte, il faut que le poste client soit
configuré pour accepter le certificat présenté par le proxy pour
n'importe quel site.
Le Thu, 24 Nov 2016 16:53:22 +0100, Francois Lafont a écrit :
Et du coup, qu'on m'arrête si je dis une bêtise, je dirais que le trafic HTTPS de Christophe passe très certainement par son proxy
Il me semble bien :) # grep REDIRECT /etc/shorewall/rules REDIRECT loc 8080 tcp www - !192.168.0.102 Je présume (sans avoir encore trouvé la réponse dans les docs nombreuses shorewall) que www = http+https
Dans /etc/services, www est juste un alias de http, donc a priori non.
mais celui ne pourra pas analyser grand chose. Il verra juste les IPs et ports source et destination mais part ça rien du tout.
En effet. A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en clair sans déclencher d'alerte, il faut que le poste client soit configuré pour accepter le certificat présenté par le proxy pour n'importe quel site.
Kevin Denis
Le 24-11-2016, Pascal Hambourg a écrit :
A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en clair sans déclencher d'alerte, il faut que le poste client soit configuré pour accepter le certificat présenté par le proxy pour n'importe quel site.
Tu peux aussi configurer le proxy explicitement. Ainsi, le proxy voit passer pas mal de trucs. Cela permet de filtrer sans casser le SSL. -- Kevin
Le 24-11-2016, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en
clair sans déclencher d'alerte, il faut que le poste client soit
configuré pour accepter le certificat présenté par le proxy pour
n'importe quel site.
Tu peux aussi configurer le proxy explicitement. Ainsi, le proxy voit passer
pas mal de trucs.
Cela permet de filtrer sans casser le SSL.
--
Kevin
A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en clair sans déclencher d'alerte, il faut que le poste client soit configuré pour accepter le certificat présenté par le proxy pour n'importe quel site.
Tu peux aussi configurer le proxy explicitement. Ainsi, le proxy voit passer pas mal de trucs. Cela permet de filtrer sans casser le SSL. -- Kevin
Francois Lafont
On 11/24/2016 10:17 PM, Kevin Denis wrote:
Le 24-11-2016, Pascal Hambourg a écrit :
A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en clair sans déclencher d'alerte, il faut que le poste client soit configuré pour accepter le certificat présenté par le proxy pour n'importe quel site.
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 ? -- François Lafont
On 11/24/2016 10:17 PM, Kevin Denis wrote:
Le 24-11-2016, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en
clair sans déclencher d'alerte, il faut que le poste client soit
configuré pour accepter le certificat présenté par le proxy pour
n'importe quel site.
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 ?
A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en clair sans déclencher d'alerte, il faut que le poste client soit configuré pour accepter le certificat présenté par le proxy pour n'importe quel site.
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 ? -- François Lafont
Christophe PEREZ
Le Thu, 24 Nov 2016 18:55:33 +0100, Francois Lafont a écrit :
Ok mais quand tu dis "sites que je considère comme interdits", c'est suivant quels critères techniques ? En fonction de l'url suivant qu'elle se trouve oui ou non dans je ne sais quelle « liste noire » ?
Tout à fait.
Parce que si c'est ça par exemple, alors c'est pas possible car ton Squid qui voit passer la requête ne sait pas quelle est url associée à cette requête (le ssl empêche d'avoir cette information).
Ah. Bon, j'y connais pas grand chose, et je ne vois pas bien pourquoi, mais ce n'est pas très important, voir plus bas pourquoi :)
Ce n'est pas pour critiquer bien sûr, c'est juste pour t'avertir que, à mon humble avis (et sauf erreur Nicolas et Pascal vont plutôt dans ce sens également)
Aucun problème, je n'ai pas ce genre de susceptibilité exacerbée.
ton Squid risque de ne rien filtrer du tout en https.
Bon, l'avantage, c'est que tout ceci date de 10 ans, et que, le temps étant passé, les enfants ont forcément pris de l'âge, et ne sont plus sujets à ce "filtrage". Du coup, si je comprends bien, ils ont du voir des choses que j'aurais préféré qu'ils ne voient pas. Ceci dit, je me souviens qu'à l'époque j'avais suivi des tutos qui me semblaient assez sérieux, avec une base de blacklist de l'université de Toulouse. Quand je pense à ce que j'ai pu me faire ch... à mettre tout ça en place, je peux t'assurer que si j'avais su que ça ne servait à rien, je m'en serais dispensé :D
Le Thu, 24 Nov 2016 18:55:33 +0100, Francois Lafont a écrit :
Ok mais quand tu dis "sites que je considère comme interdits", c'est
suivant quels critères techniques ? En fonction de l'url suivant qu'elle
se trouve oui ou non dans je ne sais quelle « liste noire » ?
Tout à fait.
Parce que
si c'est ça par exemple, alors c'est pas possible car ton Squid qui voit
passer la requête ne sait pas quelle est url associée à cette requête
(le ssl empêche d'avoir cette information).
Ah. Bon, j'y connais pas grand chose, et je ne vois pas bien pourquoi,
mais ce n'est pas très important, voir plus bas pourquoi :)
Ce n'est pas pour critiquer bien sûr, c'est juste pour t'avertir que, à
mon humble avis (et sauf erreur Nicolas et Pascal vont plutôt dans ce
sens également)
Aucun problème, je n'ai pas ce genre de susceptibilité exacerbée.
ton Squid risque de ne rien filtrer du tout en https.
Bon, l'avantage, c'est que tout ceci date de 10 ans, et que, le temps
étant passé, les enfants ont forcément pris de l'âge, et ne sont plus
sujets à ce "filtrage".
Du coup, si je comprends bien, ils ont du voir des choses que j'aurais
préféré qu'ils ne voient pas.
Ceci dit, je me souviens qu'à l'époque j'avais suivi des tutos qui me
semblaient assez sérieux, avec une base de blacklist de l'université de
Toulouse.
Quand je pense à ce que j'ai pu me faire ch... à mettre tout ça en place,
je peux t'assurer que si j'avais su que ça ne servait à rien, je m'en
serais dispensé :D
Le Thu, 24 Nov 2016 18:55:33 +0100, Francois Lafont a écrit :
Ok mais quand tu dis "sites que je considère comme interdits", c'est suivant quels critères techniques ? En fonction de l'url suivant qu'elle se trouve oui ou non dans je ne sais quelle « liste noire » ?
Tout à fait.
Parce que si c'est ça par exemple, alors c'est pas possible car ton Squid qui voit passer la requête ne sait pas quelle est url associée à cette requête (le ssl empêche d'avoir cette information).
Ah. Bon, j'y connais pas grand chose, et je ne vois pas bien pourquoi, mais ce n'est pas très important, voir plus bas pourquoi :)
Ce n'est pas pour critiquer bien sûr, c'est juste pour t'avertir que, à mon humble avis (et sauf erreur Nicolas et Pascal vont plutôt dans ce sens également)
Aucun problème, je n'ai pas ce genre de susceptibilité exacerbée.
ton Squid risque de ne rien filtrer du tout en https.
Bon, l'avantage, c'est que tout ceci date de 10 ans, et que, le temps étant passé, les enfants ont forcément pris de l'âge, et ne sont plus sujets à ce "filtrage". Du coup, si je comprends bien, ils ont du voir des choses que j'aurais préféré qu'ils ne voient pas. Ceci dit, je me souviens qu'à l'époque j'avais suivi des tutos qui me semblaient assez sérieux, avec une base de blacklist de l'université de Toulouse. Quand je pense à ce que j'ai pu me faire ch... à mettre tout ça en place, je peux t'assurer que si j'avais su que ça ne servait à rien, je m'en serais dispensé :D
Christophe PEREZ
Le Thu, 24 Nov 2016 22:25:59 +0100, Francois Lafont a écrit :
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 ?
J'avais pensé qu'il parlait de configurer l'accès au proxy dans le navigateur, donc sans proxy transparent, mais peut-être ai-je mal imaginé. Mais si c'est ça, c'est quand même bcp plus compliqué à gérer quand tu as divers appareils qui viennent s'inclure dans le réseau (wifi).
Le Thu, 24 Nov 2016 22:25:59 +0100, Francois Lafont a écrit :
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 ?
J'avais pensé qu'il parlait de configurer l'accès au proxy dans le
navigateur, donc sans proxy transparent, mais peut-être ai-je mal imaginé.
Mais si c'est ça, c'est quand même bcp plus compliqué à gérer quand tu as
divers appareils qui viennent s'inclure dans le réseau (wifi).
Le Thu, 24 Nov 2016 22:25:59 +0100, Francois Lafont a écrit :
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 ?
J'avais pensé qu'il parlait de configurer l'accès au proxy dans le navigateur, donc sans proxy transparent, mais peut-être ai-je mal imaginé. Mais si c'est ça, c'est quand même bcp plus compliqué à gérer quand tu as divers appareils qui viennent s'inclure dans le réseau (wifi).
Pascal Hambourg
Le 24/11/2016 à 22:17, Kevin Denis a écrit :
Le 24-11-2016, Pascal Hambourg a écrit :
A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en clair sans déclencher d'alerte, il faut que le poste client soit configuré pour accepter le certificat présenté par le proxy pour n'importe quel site.
Tu peux aussi configurer le proxy explicitement. Ainsi, le proxy voit passer pas mal de trucs. Cela permet de filtrer sans casser le SSL.
Mais cela ne permet pas au proxy de voir le contenu des connexions HTTPS, y compris l'URL. Au mieux le proxy ne voit que l'adresse IP ou le nom d'hôte du serveur auquel le client lui demande de se connecter.
Le 24/11/2016 à 22:17, Kevin Denis a écrit :
Le 24-11-2016, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en
clair sans déclencher d'alerte, il faut que le poste client soit
configuré pour accepter le certificat présenté par le proxy pour
n'importe quel site.
Tu peux aussi configurer le proxy explicitement. Ainsi, le proxy voit passer
pas mal de trucs.
Cela permet de filtrer sans casser le SSL.
Mais cela ne permet pas au proxy de voir le contenu des connexions
HTTPS, y compris l'URL. Au mieux le proxy ne voit que l'adresse IP ou le
nom d'hôte du serveur auquel le client lui demande de se connecter.
A ma connaissance pour qu'un proxy puisse examiner le trafic HTTPS en clair sans déclencher d'alerte, il faut que le poste client soit configuré pour accepter le certificat présenté par le proxy pour n'importe quel site.
Tu peux aussi configurer le proxy explicitement. Ainsi, le proxy voit passer pas mal de trucs. Cela permet de filtrer sans casser le SSL.
Mais cela ne permet pas au proxy de voir le contenu des connexions HTTPS, y compris l'URL. Au mieux le proxy ne voit que l'adresse IP ou le nom d'hôte du serveur auquel le client lui demande de se connecter.
Francois Lafont
On 11/24/2016 11:08 PM, Christophe PEREZ wrote:
Parce que si c'est ça par exemple, alors c'est pas possible car ton Squid qui voit passer la requête ne sait pas quelle est url associée à cette requête (le ssl empêche d'avoir cette information).
Ah. Bon, j'y connais pas grand chose, et je ne vois pas bien pourquoi, mais ce n'est pas très important, voir plus bas pourquoi :)
En gros, ça vient de considérations sur la notion de couches du réseau Internet. En gros (je ne pourrais de toute façon pas rentrer dans les détails sans dire plein de bêtises), avec https, entre le client Web (le navigateur) et le serveur Web, avant même que ça commence à parler « HTTP » entre les 2 extrémités, il y a une connexion TCP qui se crée. Un peu comme un canal de communication (même si c'est un canal un peu abstrait). Le protocole TCP se situe dans une couche en dessous de la couche « HTTP » (la couche application). TCP c'est le canal de communication en somme et HTTP c'est le type de données que tu vas faire circuler dedans. avec HTTP*s*, c'est la connexion TCP elle-même qui sera chiffrée d'un bout à l'autre. Et donc sur ce canal sécurisé va circuler les requêtes du client et les réponses http du serveur. L'url demandée par le client fait partie de ces données. Un équipement réseau entre le client et le serveur ne peut normalement pas le connaître.
ton Squid risque de ne rien filtrer du tout en https.
Bon, l'avantage, c'est que tout ceci date de 10 ans, et que, le temps étant passé, les enfants ont forcément pris de l'âge, et ne sont plus sujets à ce "filtrage". Du coup, si je comprends bien, ils ont du voir des choses que j'aurais préféré qu'ils ne voient pas.
Pour le HTTPS uniquement, oui c'est possible. :)
Ceci dit, je me souviens qu'à l'époque j'avais suivi des tutos qui me semblaient assez sérieux, avec une base de blacklist de l'université de Toulouse. Quand je pense à ce que j'ai pu me faire ch... à mettre tout ça en place, je peux t'assurer que si j'avais su que ça ne servait à rien, je m'en serais dispensé :D
Ben non, tu ne l'as pas fait pour rien non plus car pour le HTTP a priori ton filtrage devait marcher je pense. Comment ça, tu ne l'avais pas testé par toi-même ? :p Et bon... je suis pas un expert hein... mais je crois que souvent les sites porno sont plutôt en HTTP et pas en HTTPS et c'était sans doute encore plus vrai il y a 10 ans (bon... j'ai pas fait d'études statistiques hein :p). -- François Lafont
On 11/24/2016 11:08 PM, Christophe PEREZ wrote:
Parce que
si c'est ça par exemple, alors c'est pas possible car ton Squid qui voit
passer la requête ne sait pas quelle est url associée à cette requête
(le ssl empêche d'avoir cette information).
Ah. Bon, j'y connais pas grand chose, et je ne vois pas bien pourquoi,
mais ce n'est pas très important, voir plus bas pourquoi :)
En gros, ça vient de considérations sur la notion de couches du réseau
Internet. En gros (je ne pourrais de toute façon pas rentrer dans les
détails sans dire plein de bêtises), avec https, entre le client Web
(le navigateur) et le serveur Web, avant même que ça commence à parler
« HTTP » entre les 2 extrémités, il y a une connexion TCP qui se crée.
Un peu comme un canal de communication (même si c'est un canal un peu
abstrait). Le protocole TCP se situe dans une couche en dessous de la
couche « HTTP » (la couche application). TCP c'est le canal de
communication en somme et HTTP c'est le type de données que tu vas faire
circuler dedans.
avec HTTP*s*, c'est la connexion TCP elle-même qui sera chiffrée d'un
bout à l'autre. Et donc sur ce canal sécurisé va circuler les requêtes
du client et les réponses http du serveur. L'url demandée par le client
fait partie de ces données. Un équipement réseau entre le client et le
serveur ne peut normalement pas le connaître.
ton Squid risque de ne rien filtrer du tout en https.
Bon, l'avantage, c'est que tout ceci date de 10 ans, et que, le temps
étant passé, les enfants ont forcément pris de l'âge, et ne sont plus
sujets à ce "filtrage".
Du coup, si je comprends bien, ils ont du voir des choses que j'aurais
préféré qu'ils ne voient pas.
Pour le HTTPS uniquement, oui c'est possible. :)
Ceci dit, je me souviens qu'à l'époque j'avais suivi des tutos qui me
semblaient assez sérieux, avec une base de blacklist de l'université de
Toulouse.
Quand je pense à ce que j'ai pu me faire ch... à mettre tout ça en place,
je peux t'assurer que si j'avais su que ça ne servait à rien, je m'en
serais dispensé :D
Ben non, tu ne l'as pas fait pour rien non plus car pour le HTTP a priori
ton filtrage devait marcher je pense. Comment ça, tu ne l'avais pas testé
par toi-même ? :p
Et bon... je suis pas un expert hein... mais je crois que souvent les sites
porno sont plutôt en HTTP et pas en HTTPS et c'était sans doute encore plus
vrai il y a 10 ans (bon... j'ai pas fait d'études statistiques hein :p).
Parce que si c'est ça par exemple, alors c'est pas possible car ton Squid qui voit passer la requête ne sait pas quelle est url associée à cette requête (le ssl empêche d'avoir cette information).
Ah. Bon, j'y connais pas grand chose, et je ne vois pas bien pourquoi, mais ce n'est pas très important, voir plus bas pourquoi :)
En gros, ça vient de considérations sur la notion de couches du réseau Internet. En gros (je ne pourrais de toute façon pas rentrer dans les détails sans dire plein de bêtises), avec https, entre le client Web (le navigateur) et le serveur Web, avant même que ça commence à parler « HTTP » entre les 2 extrémités, il y a une connexion TCP qui se crée. Un peu comme un canal de communication (même si c'est un canal un peu abstrait). Le protocole TCP se situe dans une couche en dessous de la couche « HTTP » (la couche application). TCP c'est le canal de communication en somme et HTTP c'est le type de données que tu vas faire circuler dedans. avec HTTP*s*, c'est la connexion TCP elle-même qui sera chiffrée d'un bout à l'autre. Et donc sur ce canal sécurisé va circuler les requêtes du client et les réponses http du serveur. L'url demandée par le client fait partie de ces données. Un équipement réseau entre le client et le serveur ne peut normalement pas le connaître.
ton Squid risque de ne rien filtrer du tout en https.
Bon, l'avantage, c'est que tout ceci date de 10 ans, et que, le temps étant passé, les enfants ont forcément pris de l'âge, et ne sont plus sujets à ce "filtrage". Du coup, si je comprends bien, ils ont du voir des choses que j'aurais préféré qu'ils ne voient pas.
Pour le HTTPS uniquement, oui c'est possible. :)
Ceci dit, je me souviens qu'à l'époque j'avais suivi des tutos qui me semblaient assez sérieux, avec une base de blacklist de l'université de Toulouse. Quand je pense à ce que j'ai pu me faire ch... à mettre tout ça en place, je peux t'assurer que si j'avais su que ça ne servait à rien, je m'en serais dispensé :D
Ben non, tu ne l'as pas fait pour rien non plus car pour le HTTP a priori ton filtrage devait marcher je pense. Comment ça, tu ne l'avais pas testé par toi-même ? :p Et bon... je suis pas un expert hein... mais je crois que souvent les sites porno sont plutôt en HTTP et pas en HTTPS et c'était sans doute encore plus vrai il y a 10 ans (bon... j'ai pas fait d'études statistiques hein :p). -- François Lafont
Christophe PEREZ
Le Thu, 24 Nov 2016 23:38:30 +0100, Francois Lafont a écrit :
En gros, ça vient de considérations sur la notion de couches du réseau Internet.
Merci pour la vulgarisation ;)
Pour le HTTPS uniquement, oui c'est possible. :)
Je comprends. Cependant, c'est surprenant que toutes les lectures que j'avais pu faire sur le sujet à l'époque n'en aient pas fait état.
Ben non, tu ne l'as pas fait pour rien non plus car pour le HTTP a priori ton filtrage devait marcher je pense. Comment ça, tu ne l'avais pas testé par toi-même ? :p
Si si, bien sûr. La preuve c'est que j'en ai parlé ici pour le filtrage des pubs, ce qui continue à fonctionner ;) Mais je suis un peu du genre à penser que si ce n'est pas parfait, c'est inutile (j'ai dit : *un peu*)
Et bon... je suis pas un expert hein... mais je crois que souvent les sites porno sont plutôt en HTTP et pas en HTTPS et c'était sans doute encore plus vrai il y a 10 ans (bon... j'ai pas fait d'études statistiques hein :p).
On ne peut plus qu'espérer et se raccrocher à ça :)
Le Thu, 24 Nov 2016 23:38:30 +0100, Francois Lafont a écrit :
En gros, ça vient de considérations sur la notion de couches du réseau
Internet.
Merci pour la vulgarisation ;)
Pour le HTTPS uniquement, oui c'est possible. :)
Je comprends. Cependant, c'est surprenant que toutes les lectures que
j'avais pu faire sur le sujet à l'époque n'en aient pas fait état.
Ben non, tu ne l'as pas fait pour rien non plus car pour le HTTP a
priori ton filtrage devait marcher je pense. Comment ça, tu ne l'avais
pas testé par toi-même ? :p
Si si, bien sûr. La preuve c'est que j'en ai parlé ici pour le filtrage
des pubs, ce qui continue à fonctionner ;)
Mais je suis un peu du genre à penser que si ce n'est pas parfait, c'est
inutile (j'ai dit : *un peu*)
Et bon... je suis pas un expert hein... mais je crois que souvent les
sites porno sont plutôt en HTTP et pas en HTTPS et c'était sans doute
encore plus vrai il y a 10 ans (bon... j'ai pas fait d'études
statistiques hein :p).
On ne peut plus qu'espérer et se raccrocher à ça :)
Le Thu, 24 Nov 2016 23:38:30 +0100, Francois Lafont a écrit :
En gros, ça vient de considérations sur la notion de couches du réseau Internet.
Merci pour la vulgarisation ;)
Pour le HTTPS uniquement, oui c'est possible. :)
Je comprends. Cependant, c'est surprenant que toutes les lectures que j'avais pu faire sur le sujet à l'époque n'en aient pas fait état.
Ben non, tu ne l'as pas fait pour rien non plus car pour le HTTP a priori ton filtrage devait marcher je pense. Comment ça, tu ne l'avais pas testé par toi-même ? :p
Si si, bien sûr. La preuve c'est que j'en ai parlé ici pour le filtrage des pubs, ce qui continue à fonctionner ;) Mais je suis un peu du genre à penser que si ce n'est pas parfait, c'est inutile (j'ai dit : *un peu*)
Et bon... je suis pas un expert hein... mais je crois que souvent les sites porno sont plutôt en HTTP et pas en HTTPS et c'était sans doute encore plus vrai il y a 10 ans (bon... j'ai pas fait d'études statistiques hein :p).
On ne peut plus qu'espérer et se raccrocher à ça :)
David Sarella
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).
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).
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).
Tu peux aussi configurer le proxy explicitement. Ainsi, le proxy voit passer pas mal de trucs. Cela permet de filtrer sans casser le SSL.
Mais cela ne permet pas au proxy de voir le contenu des connexions HTTPS, y compris l'URL. Au mieux le proxy ne voit que l'adresse IP ou le nom d'hôte du serveur auquel le client lui demande de se connecter.
Le nom d'hôte permet de filtrer. De mémoire le client envoie aussi son user-agent, et un ou deux autres headers. -- Kevin
Le 24-11-2016, Pascal Hambourg <pascal@plouf.fr.eu.org> 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.
Mais cela ne permet pas au proxy de voir le contenu des connexions
HTTPS, y compris l'URL. Au mieux le proxy ne voit que l'adresse IP ou le
nom d'hôte du serveur auquel le client lui demande de se connecter.
Le nom d'hôte permet de filtrer. De mémoire le client envoie aussi
son user-agent, et un ou deux autres headers.
--
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.
Mais cela ne permet pas au proxy de voir le contenu des connexions HTTPS, y compris l'URL. Au mieux le proxy ne voit que l'adresse IP ou le nom d'hôte du serveur auquel le client lui demande de se connecter.
Le nom d'hôte permet de filtrer. De mémoire le client envoie aussi son user-agent, et un ou deux autres headers. -- Kevin
