Autoriser HTTPS Squid transparent
-
En recoupant ceci aux logs de SQUID je peux déterminer que tel utilisateur a obtenu tel IP a telle heure, et donc quels sites il a visité.
Je ne crois pas me tromper en disant que c'est suffisant aux yeux de la loi ?Si vous êtes certain du caractère probant du recoupement des logs cela peut convenir. Ce problème n'est peut être pas aussi simple qu'il y parait. Qu'en est il des utilisateurs n'utilisant pas le portail captif, ou de la possibilité de ne pas panser par le portail captif ?
La solution qui permet https en proxy transparent existe. Elle pose un problème juridique puisqu'enne s'apparente très fort à une interception de type man in the middle. De mémoire elle est documente sur squid.org.
-
Merci à vous pour vos réponses. Désolé si je ne suis pas clair.
ouais cool,
mais concretement, quels tests avez vous mené pour en arriver a la conclusion que le https ne passait pas a cause de squid?
on veut bien vous aider, mais on attend toute votre enquête et tous vos contre-tests.
j ai testé sans le domaine avec https://ip
j ai fait ceci j ai fait cela
j en arrive a telle conclusion-
je n'accède pas à la page du portail captif en https://IPDEPFSENSE
ainsi qu'à aucune autre page en HTTPS -
en désactivant le CP, toujours pareil, pas de HTTPS
-
en mode authentifié, j'accède au HTTPS sans pb.
-
impossible pour moi de supprimer la couche SQUID puisque c'est elle qui m'apporte la connexion au net
j'utilise un proxy parent, renseigné dans l'onglet REMOTE CACHE
configuré de la sorte :- Allow miss : proxy only
- hierarchy : parent
- select method : round-robin
le reste des options sont par défaut.
EDIT : la seule option renseignée dans SQUID est never_direct allow all
Elle me permet, en mode authentifié, l'accès au HTTPS. Elle semble ne rien changer en mode transparent.Si vous êtes certain du caractère probant du recoupement des logs cela peut convenir. Ce problème n'est peut être pas aussi simple qu'il y parait. Qu'en est il des utilisateurs n'utilisant pas le portail captif, ou de la possibilité de ne pas panser par le portail captif ?
La solution qui permet https en proxy transparent existe. Elle pose un problème juridique puisqu'enne s'apparente très fort à une interception de type man in the middle. De mémoire elle est documente sur squid.org.
Je n'en suis pas certain, je pense juste que c'est suffisant aux yeux de la loi. A condition de bien organiser l'export de mes logs mais c'est une autre histoire.
Les utilisateurs de ce VLAN consacré au wifi hotspot ne sont que des machines hors domaine ou des tablettes. En se connectant à ce SSID on ne peut passer outre la page du portail captif si on veut accéder au net non ?J'ai trouvé de nombreuses infos sur ce que tu évoques. Mais il s'agit d'une configuration afin de loguer aussi l'HTTPS et cela implique la création de certificats et l'ajout de ce même certificat sur chacun des périphériques. Ingérable pour mon projet…
-
-
Si vous êtes certain du caractère probant du recoupement des logs cela peut convenir. Ce problème n'est peut être pas aussi simple qu'il y parait. Qu'en est il des utilisateurs n'utilisant pas le portail captif, ou de la possibilité de ne pas panser par le portail captif ?
La solution qui permet https en proxy transparent existe. Elle pose un problème juridique puisqu'enne s'apparente très fort à une interception de type man in the middle. De mémoire elle est documente sur squid.org.
antoincy, ccnet vous pointe du doigt le problème
rien n'est parfait, il y a des trafics dans lesquels vous ne pouvez mettre votre nez.
exemple : La hadopi vous met en demeure, pour montrer votre bonne foi vis a vis d'elle, vous devez retracer sur votre réseau le coupable.
vous avez un utilisateur qui a fait du torrent
manque de pot, voici le cas de figure:-> Il a téléchargé son torrent sur un site a torrents, OK mais il ne l'a pas fait depuis votre réseau, (donc on a un download de torrent sur un proto http qui s'est pas fait par votre squid)
-> il revient sur votre réseau, avec son torrent pris ailleurs, il le lance, et il se fait gauler, au fil des connexions a des peers.
-> je vous ecoute. qui est-ce?
vous l'avez dans le baba, c'est "hors squid"
tout ce qui vous reste, c'est : l'heure du mefait (ca vous permet déja d'écarter des users) et les volumes échangés. (signe d'une activité torrent)
mais ca reste tres relatif, si vous avez deux gros volume a cet horaire? vous faites quoi?
rien.
a part logger toutes les ip de destination demandées par les ip sources nat,
(ce qui vous permettra de savoir quelle ip nat s'est connecté a l'ip du serveur ssl et quand)vous n'avez pas d'autres choix…
concernant le SSL, comme vous l'a dit ccnet, vous ne pouvez être intermediaire d'une connexion https sécurisé de bout en bout.
d'ailleurs le site distant ne devrait pas autoriser une telle breche dans la session ssl. car manifestement altérée.
et si il ne le détecte pas, cela pose un probleme juridique vu que vous "piratez" une transmission sécurisée
dont le principe est bien de vous interdire les autres ET VOUS d'en avoir connaissance sur sa teneur.donc non, dans access.log, il ne rentre aucun "https://......."
exemple, avant que google passe en SSL, vous pouviez via les logs savoir ce que les utilisateurs cherchaient sur google, via la requete GET.
en SSL, google desormais confidentialise les recherches de ses utilisateurs.
-
Merci à vous pour vos réponses. Désolé si je ne suis pas clair.
ouais cool,
mais concretement, quels tests avez vous mené pour en arriver a la conclusion que le https ne passait pas a cause de squid?
on veut bien vous aider, mais on attend toute votre enquête et tous vos contre-tests.
j ai testé sans le domaine avec https://ip
j ai fait ceci j ai fait cela
j en arrive a telle conclusion-
je n'accède pas à la page du portail captif en https://IPDEPFSENSE
ainsi qu'à aucune autre page en HTTPS -
en désactivant le CP, toujours pareil, pas de HTTPS
-
en mode authentifié, j'accède au HTTPS sans pb.
-
impossible pour moi de supprimer la couche SQUID puisque c'est elle qui m'apporte la connexion au net
j'utilise un proxy parent, renseigné dans l'onglet REMOTE CACHE
configuré de la sorte :- Allow miss : proxy only
- hierarchy : parent
- select method : round-robin
le reste des options sont par défaut.
EDIT : la seule option renseignée dans SQUID est never_direct allow all
Elle me permet, en mode authentifié, l'accès au HTTPS. Elle semble ne rien changer en mode transparent.Si vous êtes certain du caractère probant du recoupement des logs cela peut convenir. Ce problème n'est peut être pas aussi simple qu'il y parait. Qu'en est il des utilisateurs n'utilisant pas le portail captif, ou de la possibilité de ne pas panser par le portail captif ?
La solution qui permet https en proxy transparent existe. Elle pose un problème juridique puisqu'enne s'apparente très fort à une interception de type man in the middle. De mémoire elle est documente sur squid.org.
Je n'en suis pas certain, je pense juste que c'est suffisant aux yeux de la loi. A condition de bien organiser l'export de mes logs mais c'est une autre histoire.
Les utilisateurs de ce VLAN consacré au wifi hotspot ne sont que des machines hors domaine ou des tablettes. En se connectant à ce SSID on ne peut passer outre la page du portail captif si on veut accéder au net non ?J'ai trouvé de nombreuses infos sur ce que tu évoques. Mais il s'agit d'une configuration afin de loguer aussi l'HTTPS et cela implique la création de certificats et l'ajout de ce même certificat sur chacun des périphériques. Ingérable pour mon projet…
la page du CP est contactable sur le port 8001
merci de desactiver squid et de faire une regle de sortie WAN sans votre proxy parent
et de tester pour bien identifier que le probleme vient de ce coin laca devrait fonctionner.
ps: bonjour les perfs avec votre double proxy….....
un proxy c est fait pour filtrer et logger, quelle est l'utilité de ce double passage
.. je presume que le proxy parent est distant ? -
-
antoincy, ccnet vous pointe du doigt le problème
rien n'est parfait, il y a des trafics dans lesquels vous ne pouvez mettre votre nez.
exemple : La hadopi vous met en demeure, pour montrer votre bonne foi vis a vis d'elle, vous devez retracer sur votre réseau le coupable.
vous avez un utilisateur qui a fait du torrent
manque de pot, voici le cas de figure:-> Il a téléchargé son torrent sur un site a torrents, OK mais il ne l'a pas fait depuis votre réseau, (donc on a un download de torrent sur un proto http qui s'est pas fait par votre squid)
-> il revient sur votre réseau, avec son torrent pris ailleurs, il le lance, et il se fait gauler, au fil des connexions a des peers.
-> je vous ecoute. qui est-ce?
vous l'avez dans le baba, c'est "hors squid"
tout ce qui vous reste, c'est : l'heure du mefait (ca vous permet déja d'écarter des users) et les volumes échangés. (signe d'une activité torrent)
mais ca reste tres relatif, si vous avez deux gros volume a cet horaire? vous faites quoi?
rien.
a part logger toutes les ip de destination demandées par les ip sources nat,
(ce qui vous permettra de savoir quelle ip nat s'est connecté a l'ip du serveur ssl et quand)vous n'avez pas d'autres choix…
Concernant le P2P, mon proxy parent se charge de le bloquer.
Cette connexion ne sera a terme en grande partie consacrée qu'à des IPAD/SURFACE.
Difficile d'imaginer du torrent là dessus. Dans tout les cas, c'est bloqué.concernant le SSL, comme vous l'a dit ccnet, vous ne pouvez être intermediaire d'une connexion https sécurisé de bout en bout.
d'ailleurs le site distant ne devrait pas autoriser une telle breche dans la session ssl. car manifestement altérée.
et si il ne le détecte pas, cela pose un probleme juridique vu que vous "piratez" une transmission sécurisée
dont le principe est bien de vous interdire les autres ET VOUS d'en avoir connaissance sur sa teneur.donc non, dans access.log, il ne rentre aucun "https://…...."
exemple, avant que google passe en SSL, vous pouviez via les logs savoir ce que les utilisateurs cherchaient sur google, via la requete GET.
en SSL, google desormais confidentialise les recherches de ses utilisateurs.
Je ne souhaite pas rentrer d'HTTPS dans access.log.
Je souhaite simplement autoriser ces requêtes. -
la page du CP est contactable sur le port 8001
Quand je dis que je n'attends pas le CP en https://IPDEPFSENSE j'entends https://IPDEPFSENSE:8000
merci de desactiver squid et de faire une regle de sortie WAN sans votre proxy parent
et de tester pour bien identifier que le probleme vient de ce coin laca devrait fonctionner.
ps: bonjour les perfs avec votre double proxy….....
un proxy c est fait pour filtrer et logger, quelle est l'utilité de ce double passage
.. je presume que le proxy parent est distant ?OK, je vais tester, merci.
Je n'ai pas le choix. Le proxy parent n'est pas distant, mais c'est un proxy fourni par la région se chargeant de l'authentification des postes du domaine (SQUID non-transparent et DANSGUARDIAN) sur lequel je n'ai AUCUNE POSSIBILITE de configuration. Je n'y ai pas la main. Pour ouvrir mon propre portail captif je n'ai guère le choix.
Cela fait 3 mois que je suis sur ce projet et croyez moi j'ai retourné le truc dans tous les sens. Cette solution est fonctionnelle et se rapproche au mieux de ce que nous souhaitons. Il me reste ce problème… -
Dans tout les cas, c'est bloqué.
arrêttez de réver tout haut…
donnez moi les rules de blocage utilisées pour le torrent svp ;)
-
Quand je dis que je n'attends pas le CP en https://IPDEPFSENSE j'entends https://IPDEPFSENSE:8000
et bien essayez d'entendre 8001
car 8000 c'est le port destiné AU CLAIR
;)
-
Je n'ai pas le choix. Le proxy parent n'est pas distant, mais c'est un proxy fourni par la région se chargeant de l'authentification des postes du domaine (SQUID non-transparent et DANSGUARDIAN) sur lequel je n'ai AUCUNE POSSIBILITE de configuration. Je n'y ai pas la main. Pour ouvrir mon propre portail captif je n'ai guère le choix.
Cela fait 3 mois que je suis sur ce projet et croyez moi j'ai retourné le truc dans tous les sens. Cette solution est fonctionnelle et se rapproche au mieux de ce que nous souhaitons. Il me reste ce problème…je ne vois pas comment un proxy peut authentifier des postes d'un domaine ….........................
pouvez vous schematiser a toutes fins utiles la tete de ce reseau?
-
arrêttez de réver tout haut…
donnez moi les rules de blocage utilisées pour le torrent svp ;)
Je ne rêve pas ! Pour avoir testé je vous assure, les torrents ne passent pas.
Comme dans la plupart des établissements scolaires (lycees/ecoles) ou j'ai pu être étudiant : pas de torrent.
Mais ce n'est pas vraiment le problème ici.
@Florian22:et bien essayez d'entendre 8001
car 8000 c'est le port destiné AU CLAIR
;)
Au temps pour moi. Accès toujours impossible à https://ipdepfsense:8001
je ne vois pas comment un proxy peut authentifier des postes d'un domaine ….........................
pouvez vous schematiser a toutes fins utiles la tete de ce reseau?
J'entends par là que ce proxy parent en mode authentifié :
- se charge de filtrer et de loguer les sites visités pour les postes fixes/laptop qui sont dans mon domaine pédagogique
- que les conf proxy sont appliquées par GPO
Voilà pourquoi je ne souhaite pas utiliser ceci pour des tablettes : configuration bien trop lourde !
Pour le schéma je n'ai pas vraiment le temps de faire un détail, en gros :
- j'ai un réseau pédagogique et son VLAN correspondant en 172.17/16 > squid non transparent, dansguardian & co sur mon proxy père
- je souhaite créer un nouveau réseau ainsi que son VLAN en 172.16/16 > dédié au portail captif… avec SQUID transparent pour n'avoir aucune configuration sur les devices : proxy fils
J'ai par ailleurs effectué d'autres tests en utilisant squid3-dev qui intègre le support SSL. Cela semble fonctionner mais je me tape une ERREUR 400 DANSGUARDIAN
Je suppose que c'est donc le proxy père qui est en cause ? Mais je n'ai en aucun cas la main dessus. -
faites la meme requete, sans pfsense, directement au cul du proxy pere comme vous dites.
(arrivée etablissement)
normalement squid se signale quand il genere une erreur,
vous pouvez ainsi déterminer le point de generation de l'erreur