Bug SSL Bump Squid/SquidGuard
-
Bonjour, je viens d'installer la nouvelle version de pfsense et j'ai décidé d'installer Squid en mode transparent et de l'utiliser pour faire du SSL Bump.
Une fois configuré (juste Squid) tout fonctionnait à merveille, le SSL Bump marchait, mais depuis l'installation de squidGuard (Sans le configurer juste le mettre en running dans les Services) j'ai cette erreur qui vient quand je veux aller sur un site en HTTPS.
Je ne sais pas ce que c'est, mais on dirait une mauvaise redirection, peut-être un conflit entre squid et squidguard ? Bien que cela m'étonnerais.
Quelqu'un aurait une idée ?Cordialement, Bluschift.
 -
Une petite idée svp ?
Cordialement, Bluschift.
-
<mode réflexion="" générale="">L'utilisation d'un proxy est une bonne idée :
- une seule machine a un vrai accès complet en http/https = meilleur contrôle
- cache
- capacité à filtrer (Squid + SquidGuard)
L'accès à un proxy peut être transparent ou explicite.
Le mode 'transparent' est une FAUSSE bonne idée : ne fonctionne qu'en http, pas d'authentification !
Le mode 'explicite' est une bonne idée : utilisation de http, https et ftp; mais il faut indiquer au navigateur le proxy.
Heureusement WPAD facilite la découverte automatique du proxy !Quid de SSL Bump :
SSL Bump est une méthode de type 'Man-In-The-Middle', qui prétend passer en mode 'transparent' le trafic https (normalement impossible).
Alors que https crypte intégralement entre client et serveur, SSL Bump casse ce cryptage et permet de filtrer via un proxy placé au milieu.
Cela impose que le client voit le certificat de SSL Bump, qui remplace le vrai certificat du serveur : un client pointilleux ne peut accepter une telle modification !Il y a donc, 2 attitudes :
- choisir le mode transparent et utiliser SSL Bump pour https,
- choisir le mode explicite.
Le mode explicite impose la mise en place de WPAD pour faciliter la conf des navigateurs, et permet le filtrage normal d'un proxy.
Le mode transparent et SSL Bump montre aux clients que l'on peut casser sa connexion sécurisée (https).Clairement, la méthode transparent + SSL Bump est, pour moi, totalement inacceptable, mais c'est mon avis.</mode>
<mode réflexion="" firewall="">Placer un proxy sur un firewall est, en général, un erreur, selon la taille et le trafic.
Les raisons :- la charge générée peut être excessive et finir par pénaliser le bon fonctionnement du firewall,
- la nature de package, donc sans garantie, et sans doute incomplet n'offre pas toutes les possibilités d'un proxy dédié.
De plus, en créant son proxy dédié, on ajuste, complètement, la solution à son besoin, et sans aucun impact sur le firewall.
Mais cela exige aussi, plus d'expertise …</mode> -
Toujours à titre de réflexion générale, dans quel contexte voulez vous utiliser SSL Bump ?
-
Bonjour tout le monde,
j'ai fait la même expérience que celle de Bluschift et j'ai eu le même problème
1. j'ai installer pfsense
2. installer la mise a jour 2.3.1
3. configurer DHCP
4. j'ai installer squid et j'ai configurer le filtre http et https avec ceryaficat sans problème.
5. mais après l'installation de squidguard le certificat ne fonctionne plusJe pense qu'il y'a effectivement un bug quelque part
-
Et bien j'utilise cette méthode dans le cadre d'une école composé d'enfant qui ont entre 8-12 ans.
Ce genre d'école n'ont pas les moyens de payer un FAI avec un filtrage et un gros débit internet, grâce à cette solution, le filtrage ce fera grâce au routeur et ils pourront ce permettre d'avoir une plus grande bande passante, du coup ils économiseront pas mal d'argent.Cordialement, Bluschift.
-
Si l'objectif est de gagner de la bande passante, il est fort possible que tu sois déçu par le résultat.
Il y a tellement de "pragma no-cache" et de cache-control que l'efficacité du cache au niveau du proxy (et au niveau du client) est souvent assez faible, même pour une école où les élèves vont souvent consulter les mêmes pages et les mêmes sites.En revanche, permettre, grâce à SSL-Bump, de contrôler et surtout filtrer le contenu du flux HTTPS peut avoir un intérêt si on suppose que des sites autorisés contiennent potentiellement des virus.
Il faut bien comprendre que Squidguard permet de contrôler (comprendre interdire) l'accès à des URL, même en HTTPS, la granularité du filtre étant le fqdn puisque le HTTP CONNECT passe en clair.
La valeur ajoutée de SSL-bump, c'est le contrôle du contenu des pages :- partie "droite" de l'URL
- virus-check
- mime-type
…
Du coup, est-ce vraiment indispensable ?
-
L'objectif n'est pas d'avoir une meilleurs bande passant étant donné que leurs fournisseurs d'accès internet n'offre pas plus de 20Mb/s et que j'ai pus tester avec 50Mb/s et que cela marche parfaitement, le réel objectif est qu'ils n'achètent pas un filtrage à leur FAI, cela leur permettra donc d'économiser là-dessus et d'avoir un plus gros budget pour au niveau informatique (acheter des ordinateurs etc…)
Cordialement.
-
…/... le réel objectif est qu'ils n'achètent pas un filtrage à leur FAI, cela leur permettra donc d'économiser là-dessus et d'avoir un plus gros budget pour au niveau informatique .../...
C'est plus clair.
Dans ce cas, comme je l'explique dans le message précédent, SSL-Bump n'est absolument pas une obligation :- tu peux très bien activer des blacklists basées sur des nom de domaines et fqdn qui votn déjà filtrer très efficacement les sites autorisés vs. ce qui ne l'est pas.
- ça va éliminer la très grande majorité des sites avec un contenu qui justifie un filtrage basé sur le contenu.
Si tu as besoin d'un filtrage plus fin (i.e. autoriser certains sites mais pas tout le contenu), alors effectivement SSL-bump est nécessaire.
Dans une école, déployer WPAD pour s'assurer que tous les postes vont bine utiliser le proxy de manière explicite est assez facile et efficace.
-
Comme conseillé par Chris, à votre place j'en resterai au filtrage d'url sur les fqdn.
L'interception et le déchiffrement d'une connexion SSL pose aussi de sérieux problèmes juridiques.