Problème Squid, filtrage https

sysAdmy

Contexte : Stage au sein d'une mairie. Je dois filtrer les recherches par mot clé.

Besoin : Mise en place d'un proxy pour filtrer le contenu des recherches internet d'une école primaire.

Schéma :
-un réseau Lan : 172.16.0.0/16
-un réseau wan : 192.168.10.0/24
-un poste avec une interface : 172.16.1.1/16

sur le réseau 192.168.10.0/24 il n'y a que le pfSense et une box révolution.

Les paquets installés sont Squid, Squid3 et SquidGuard.

Le serveur proxy est configurer en transparent sur l'interface LAN et pour intercepeté les requête ssl.(beaucoup de moteur de recherche utilise https par défaut.)

Le seul mot clé bloqué est "test"

Question :

J'ai déjà fais une configuration exactement identique depuis mon domicile personnel et tout fonctionne; les requêtes ssl sont correctement intercepté et je peux filtrer les url https. Le certificat interne(non signé par une autorité de certificat) que j'ai créé sur pfsense est bien pris en compte et ça marche.

Cependant lorsque que je le déploie sur le réseau de l'école, Le certificat interne de mon pfsense est ignoré la majeur partie du temps (en 6 jour de test le navigateur a du le prendre en compte qu'une dixaine de fois.). Ce qui fait que je ne peux pas filtrer les url https. Le navigateur affiche quand même que l'origine du certificat n'a pas pu être déterminé, ce qui montre que l'interception des requête ssl fonctionne. Mais c'est le certificat du site web qui est utilisé et non celui de mon pfSense.

D'où pourrais bien provenir le problème? Comment forcer l'utilisation du certificat interne que j'ai crée?

Logs et tests :

J'ai effectuer des test sur plusieurs navigateur(Opera, Firefox, Safari, Internet Explorer), J'ai vidé le cache sll, supprimé les certificat officiel, supprimé les fichier temporaire(sur le client et sur pfsense), et même passé un coup de Ccleaner, Mais le problème persiste.

La seul différence dans le configuration du réseau entre l'école et mon réseau personnel et le fournisseur d'accès internet(J'ai une bbox(Bouygue telecom) et le réseau de l'école passe par une box révolution(free).

Merci d'avoir pris le temps de lire mon post et pour toute réponse que vous pourrez m'apporter.

chris4916

c'est extrêmement simple:
1 - HTTPS = normalement pas de filtrage de contenu ;) mais possibilité de filtrer les URL
2 - Transparent proxy = pas de contrôle de HTTPS… sauf si tu active l'horrible (à mon sens) MITM (Man In The Middle)
3 - MITM requière un certificat au niveau du proxy. Si celui-ci est signé par un Certificate authority qui n'est pas connu du navigateur, ce dernier affiche non pas une erreur mais un warning, laissant normalement le choix à l'utilisateur d'aller plus loin en trustant ce certificat, provisoirement ou définitivement
4 - la manière de procéder, dans ce cas, consiste à installer sur la machine cliente (ou à truster, ce qui va revenir au même) par partie publique du certificat (CA) ayant signé le certificat du serveur pour ne plus avoir ce warning

sysAdmy

Le problème n'est absolument pas le warnning.

J'ai activé le man in the middle pour pouvoir filtrer les url HTTPS par mot clé.

Le problème est que le certificat de mon pfsense n'est pas utilisé par le navigateur même si l'interception de la requête ssl à eu lieu. Je ne peux donc pas filtrer les url HTTPS car c'est le certificat du site distant qui est utilisé(et donc la clé publique du site distant).

Juve

@chris4916:

c'est extrêmement simple:
1 - HTTPS = normalement pas de filtrage de contenu ;) mais possibilité de filtrer les URL

Ca ca veut rien dire :)

En https, rien n'est visible sur le transit, pas plus l'url demandée que le contenu obtenu, tout simplement parce que le chiffrement SSL est établi avant tout envoi de données. On etabli un canal sécurisé puis on echange des informations ( GEt ou POST, puis obtention du contenu)

La seule et unique solution, pour filtrer HTTPS, c'est de réaliser un MAN in the Middle, comme précisé. Pour SQuid, on utilise généralement SSL Bump (squid v3). Tous les peoduits payants du marché (trend, cisco, checkpoint, bluecoat etc. Etc.) utilisent ce principe.

jdh

Un proxy dédié (séparé de pfSense) est une solution simple et efficace : pas de certificat, pas de (scabreux) Man In The Middle !
Avec WPAD, la config des clients est très facile. Le stockage des logs est naturel. La visualisation par un LightSquid est immédiate.
Que des avantages … (la config hardware du pfsense est réduite !)

Le seul effort : construire son proxy ! (Rien n'interdit de s'inspirer des fichiers de conf actuel ...)

chris4916

@Juve:

@chris4916:

c'est extrêmement simple:
1 - HTTPS = normalement pas de filtrage de contenu ;) mais possibilité de filtrer les URL

Ca ca veut rien dire :)

Discutons en alors pour que tu m'expliques pourquoi ;)

Voila ma compréhension, n'hésite pas à m'expliquer où je me trompe.

avec un proxy en mode explicite, même si le tunnel est effectivement établi entre le client (browser) et serveur web, la requête passe par le proxy, lequel, même si il ne connaît pas une partie (importante) de l'URL, est capable d'appliquer des ACL.
Un peu de lecture.
ça permet par exemple, d'interdire l'accès à facebook.com via le proxy, que ce soit http://facebook.com ou https://facebook.com

En https, rien n'est visible sur le transit, pas plus l'url demandée que le contenu obtenu, tout simplement parce que le chiffrement SSL est établi avant tout envoi de données. On etabli un canal sécurisé puis on echange des informations ( GEt ou POST, puis obtention du contenu)

rien est un peu excessif car tu connais le serveur de destination, donc la partie gauche de l'URL (à l’exception du protocole)

La seule et unique solution, pour filtrer HTTPS, c'est de réaliser un MAN in the Middle, comme précisé. Pour SQuid, on utilise généralement SSL Bump (squid v3). Tous les peoduits payants du marché (trend, cisco, checkpoint, bluecoat etc. Etc.) utilisent ce principe.

Pour faire du filtrage de contenu oui ;)

sagem2004

Bonjour ,

tu as aussi NethServer 6.6 c'est simple tu as besoin d une carte réseau la partie proxy très simple un peu limité à mon gout très bien pour une école Primaire.

Projet très prometteur.

très belle journée à tous .

ccnet

Projet prometteur pourquoi pas.

NethServer 6.6 c'est simple tu as besoin d une carte réseau la partie proxy

On ne peut pas raisonner comme cela dès lors que l'on a besoin d'un niveau de sécurité un minimum exigeant. L'utilisation d'une seule interface réseau qui va mélanger flux entrant, flux sortant et trafic d'administration n'est pas cohérent dès lors que l'on a des exigences de sécurité un peu sérieuse.

Juve

@chris4916:

@Juve:

@chris4916:

c'est extrêmement simple:
1 - HTTPS = normalement pas de filtrage de contenu ;) mais possibilité de filtrer les URL

Ca ca veut rien dire :)

Discutons en alors pour que tu m'expliques pourquoi ;)

Voila ma compréhension, n'hésite pas à m'expliquer où je me trompe.

avec un proxy en mode explicite, même si le tunnel est effectivement établi entre le client (browser) et serveur web, la requête passe par le proxy, lequel, même si il ne connaît pas une partie (importante) de l'URL, est capable d'appliquer des ACL.
Un peu de lecture.
ça permet par exemple, d'interdire l'accès à facebook.com via le proxy, que ce soit http://facebook.com ou https://facebook.com

En https, rien n'est visible sur le transit, pas plus l'url demandée que le contenu obtenu, tout simplement parce que le chiffrement SSL est établi avant tout envoi de données. On etabli un canal sécurisé puis on echange des informations ( GEt ou POST, puis obtention du contenu)

rien est un peu excessif car tu connais le serveur de destination, donc la partie gauche de l'URL (à lexception du protocole)

La seule et unique solution, pour filtrer HTTPS, c'est de réaliser un MAN in the Middle, comme précisé. Pour SQuid, on utilise généralement SSL Bump (squid v3). Tous les peoduits payants du marché (trend, cisco, checkpoint, bluecoat etc. Etc.) utilisent ce principe.

Pour faire du filtrage de contenu oui ;)

Dans le contexte énoncé,soit proxy transparent, je confirme ce que j'ai dit à savoir que rien ne sera vu en transit par le proxy car il n'y aura pas de HTTP CONNECT préalable à la connexion au site HTTPS.

Dans une configuration avec proxy explicite, oui il y aura émission d'un HTTP CONNECT en direction d'un serveur proxy, et on pourra alors filtrer sur le nom de machine uniquement. Mais là on est en dehors du contexte initial.

chris4916

@Juve:

Dans le contexte énoncé,soit proxy transparent, je confirme ce que j'ai dit à savoir que rien ne sera vu en transit par le proxy car il n'y aura pas de HTTP CONNECT préalable à la connexion au site HTTPS.

Dans une configuration avec proxy explicite, oui il y aura émission d'un HTTP CONNECT en direction d'un serveur proxy, et on pourra alors filtrer sur le nom de machine uniquement. Mais là on est en dehors du contexte initial.

Ton point de vue est beaucoup plus clair :)
J'aurai donc du écrire:

1 - Transparent proxy = pas de contrôle de HTTPS… sauf si tu active l'horrible (à mon sens) MITM (Man In The Middle)
2 - HTTPS = normalement pas de filtrage de contenu ;) mais possibilité de filtrer les URL sur le fqdn

au lieu de

1 - HTTPS = normalement pas de filtrage de contenu ;) mais possibilité de filtrer les URL
2 - Transparent proxy = pas de contrôle de HTTPS… sauf si tu active l'horrible (à mon sens) MITM (Man In The Middle)

;D ;D ;D

Juve

;) ;)