Problème Squid, filtrage https

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

;) ;)