Problème PfSense/SquidProxy/SSL

adm_ryu

Bonjour.

Avant toute chose soyez assuré(e)s que j'ai effectué une recherche avant d'ouvrir ce sujet.
Je me rends compte que beaucoup de personnes rencontrent le même problème que moi mais rarement des réponses ont été apportées (et quand ce n'est pas en FR ou ENG je ne comprends pas tout).

Voici mon problème :

J'utilise PfSense 2.4.5 à jour.
En package j'utilise Squid Proxy Server.
Quand je je regarde /services/SquidProxy Server/Real time je vois à quoi sont connectés les appareils de mon réseau domestique.
Cependant, en real time et en LightSquid Report ceci ne capture que le HTTP.
Pour capturer HTTPS j'ai suivi ce tuto : https://notamax.be/proxy-transparent-sous-pfsense/

ça fonctionne très bien, je peux monitorer tout traffic https

OUI MAIS

au fur et à mesure de notre navigation, on se rend compte que google.com, Gmail, Facebook, messagerie Bouygues, et la liste s'allonge, ne répondent plus.

Selon le navigateur j'ai un message de SSL invalide ou trop long !
vider le cache du navigateur n'y fait rien, générer un nouveau CA pour Squid à la taille minimum de 1024 en SHA256 non plus.

J'ai lu une astuce qui semble fonctionner pour certains sites : transformer l'adresse url httpS://truc.com en http://truc.com:443
cela semble générer une sorte d'apprentissage de Squid ou des navigateurs, et au bout d'un moment httpS://truc.com fonctionne.
Sauf que 1° ce n'est pas systématique 2° pas user friendly

Pourquoi ce problème SSL que beaucoup de monde rencontre avec interception HTTPS vi Squid, et comment résoudre le problème je vous prie ?

Merci.

jdh

Je ne réponds pas aux difficultés, j'éclaire sur la démarche erronée (et pas que pour moi) ... et d'autant plus qu'il est pas plus compliqué de faire sans !

De mon point de vue (et pas que le mien), l'interception de HTTPS est une mauvaise idée. Pour 3 raisons :

l'interception 'casse' le système de certificat qui est la base de la sécurité d'HTTPS,
le monitoring (des URL) ne nécessite absolument pas cette interception,
la mise en oeuvre d'HSTS mettra un terme à cette pratique (et cela ira bien plus vite que la généralisation de HTTPS).

En résumé, c'est voué à échouer, en outre de surcharger

En particulier, le premier point est particulièrement fautif : le certificat d'origine, qui "prouve' l'identité du site web source, est remplacé par un certificat interne à l'entreprise (généralement aoto accepté). De sorte qu'un utilisateur interne devient incapable de vérifier l"origine exacte.

En sus d'être 'déloyale', il est même possible que cette méthode soit illégale ...

De toute façon, HSTS mettre un terme à cette interception inutile.
cf https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security (en français et avec des détails)

adm_ryu

@jdh
Bonjour, merci pour votre réponse même si effectivement elle ne va pas dans le sens que j'attends.

Je me permets de réagir tout de même sur deux points :

"le monitoring (des URL) ne nécessite absolument pas cette interception"

Quel mécanisme employer dans ce cas avec PfSense/Squid, car seul le trafic HTTP est visible comme je le disais.

"En sus d'être 'déloyale', il est même possible que cette méthode soit illégale ..."

Je n'ai effectivement pas précisé qu'il s'agit d'un monitoring uniquement dans le cadre domestique et non pas professionnel. Le but étant pour moi de savoir ce qui se passe dans l'IoT que j'héberge à mon insu (comprendre, voir l'ensemble du trafic de tous les objets connectés de mon domicile, et croyez moi c'est très très très bavard les objets connectés).

jdh

Bien évidemment, je parle du 'proxy transparent' dans le contexte d'une entreprise.

Le proxy Squid supporte les protocoles HTTP, HTTPS et FTP. Il y a donc log pour tous ces protocoles.

Le point clé d'un proxy est que le logiciel client l'utilise et donc soit configuré pour l'utiliser. Typiquement Internet Explorer trouvait l'info dans les paramètres réseau (de Windows, ce qui pouvait être trouvé par d'autres outils). Mais de nombreux logiciels peuvent se mettre à jour via HTTP/HTTPS, d'où un config de proxy (adresse ip + port + identifiant/mdp). Sous Windows 10, il y a toujours la config d'un proxy dans les paramètres OS (valable pour les navigateurs 'internes' soit IE et Edge mais aussi Windows Update voire d'autre outils internes Windows.

La tentation était grande d'utiliser un 'proxy transparent' = au niveau de la passerelle, c'est à dire du firewall. Or cela ne fonctionne que pour HTTP (puisque HTTPS est crypté). D'où le 'cassage' de certificat (SSL-Bump) pour analyser HTTPS.

Dans une entreprise, ce qui est aisé et que je recommande, c'est de

utiliser un serveur proxy (typiquement une Debian avec Squid, SquidGuard, les blacklist de Toulouse, un outil de visu tel LightSquid),
mettre en oeuvre WPAD (cf le fil que j'ai écrit).

Les navigateurs IE, Edge et Chrome trouvent automatiquement le proxy via WPAD, Firefox nécessite une toute petite config.

Cette approche, pour entreprise, fonctionne dans tous las cas, y compris HSTS. (Tout au plus en cas de blocage d'un site HTTPS, la page est blanche et non redirigeable vers une page 'sens interdit'.)

Pour la maison, je ne sais pas ce qu'il faut faire de très simple. En tous cas, l'interception HTTPS ira de mal en pis.

jdh

De façon générale,

c'est au niveau du firewall/passerelle que l'on voit passer tout le trafic sortant,
de facto, passer par un proxy dédié n'est pas automatique,
dans ce dernier cas, il faut que la machine utilise un protocole HTTP ou HTTP, et accepte de passer par un proxy,
WPAD est un standard bien défini et reconnu par les navigateurs usuels, mais n'est pas utilisé par tout : vielle version Android/iPhone, pleins de logiciels pour leurs mises à jour.

La package NTopNG de pfSense est capable de fournir des stats, machine par machine pour le trafic sortant. C'est l'exemple des sondes de NetFlow.

NB :
une analyse permettra d'identifier ip source/ ip destination,/proto/port/taille, mais difficilement 'dns destination' car la passerelle voit des paquets ip.
Les proto HTTP et HTTPS contiennent à l'intérieur des paquets l'URL demandé, et donc le nom dns !

adm_ryu

Bonjour.

j'ai bien intégré le fait que vous soyez réticent à l'utilisation de Squid pour intercepter le trafic HTTPS.
Merci pour la proposition d'utiliser le package Ntop, je l'ai déjà employé par le passé, pour ce que je souhaite monitorer il n'offre aucun avantage par rapport à "States" ou "States summary" (fonction de base de PfSense).

Un des points forts de Squid et de pouvoir générer des rapports, il permet donc d'analyser quand on le souhaite ce qui s'est passé sur le réseau. Autre avantage des rapports de Squid : résolution de noms dans la majorité des cas et découpage horaire de l'activité (ce qui renseigne bien aussi : ma smartv s'est connectée à telle heure alors qu'elle est en VEILLE).

*peu de stats suite à réinstallation complète

img2t

alt text

Je viens de parcourir la documentation de NtopNG, il y à une possibilité de rapport https://www.ntop.org/guides/ntopng/web_gui/report.html mais on parle de "The Professional version of ntopng allows to generate custom traffic reports", je vais tenter une installation tout de même pour vérifier si le package Pfssense offre la même possibilité.

Reste à espérer que la résolution de noms soit offerte, c'est tout de même plus lisible que img4t

Sinon, je vous remercie mais je pense que je serai dans une impasse.
Je resterai donc comme des centaines d'utilisateurs sur ce problème.

jdh

@adm_ryu said in Problème PfSense/SquidProxy/SSL:

j'ai bien intégré le fait que vous soyez réticent à l'utilisation de Squid pour intercepter le trafic HTTPS.

Non, vous ne m'avez pas bien compris, je pensais pourtant être clair, je réécris donc mon point de vue :

je conteste l'utilisation de Squid en mode transparent, à cause de l'activation possible de SSL-Bump pour casser HTTPS,
je préconise l'utilisation de Squid en mode explicite, car il n'y a pas besoin de casser HTTPS.

Avec Squid en mode explicite, on peut visualiser, avec LightSquid (vos 3 images jointes), tous les accès : tant HTTP que HTTPS.

Bien évidemment, on interdit aux machines un accès direct à Internet pour HTTP et HTTPS et on autorise l'accès au proxy seulement. De facto les machines (IoT) sans config du proxy n'accèdent pas à Internet.

La démarche usuelle est

une règle LAN to 'any', parce que par défaut,
le package NtopNg créé les stats machine par machine du flux sortant proto par proto (sans précision ni des url pour HTTP/HTTPS ni du dns),
mise en place d'un proxy, dédié pour les entreprises et dans l'idéal,
config en manuel ou en auto (avec WPAD) pour les PC standard.

A ce niveau, on est capable d'identifier les autres machines qui accèdent à Internet et les proto utilisés. Et on constate que bien des machines sont comme beaucoup de logiciels, ils se croient tout seul et 'exigent' un accès direct à Internet !

Je conçois que c'est difficile :

le mode 'transparent' est tellement tentant,
il fonctionne sans défaut pour HTTP (sauf Authentification),
Il peut fonctionner avec HTTPS via une astuce qui 'brise' le certificat en le remplaçant, ce qui 'annule' la confiance qu'il est sensé apporter,
la mise en place de HSTS va annuler l'astuce.

Or les sites web sont maintenant majoritairement passés en HTTPS (depuis déjà plusieurs années), et vont aussi passer à HTTPS + HSTS ruinant l'astuce. Je vous sensibilise en fait à l'inexorable échec croissant.

On pourrait raisonner en cloisonnant :

un réseau standard avec proxy explicite pour les PC standard,
un réseau 'd'identification' avec mode tranparent + cassage HTTPS pour les machines inconnues' (mais sans accès depuis les PC standard)

Pas facile à la maison !
(Moi le firewall, les protos c'est mon métier depuis des années ...)