Squid Proxy Server



  • Bonjour,

    J'ai un réseau sans fil avec un portail captif, le traffic du réseau WIFI passe par l'interface LAN du Pfsense, sur l'interface LAN de Pfsense j'ai mis en place squid proxy server pour que je puisse intercepter le trafic des utilisateurs WIFI, mais j'intercepte que le trafic HTTP mais pas le HTTPS, J'ai vu qu'il faut créer un certificat SSL et l'exporter sur les équipements des utilisateurs connectés au réseau Wifi.
    Qlq aurait une solution pour voir le trafic HTTPS sans avoir à installer le certificat sur les équipements clients ?

    Merci en avance,



  • Mes réponses risquent de vous paraître un peu abruptes.

    le trafic du réseau WIFI passe par l'interface LAN du Pfsense

    C'est une première erreur de conception en terme d'architecture. Vous administrez Pfsense via l'interface Lan comme tout le monde le plus souvent. Comment peut on imaginer un instant sécuriser quelque chose en mélangeant le trafic sensible par définition de l'administration avec le trafic wifi et un réseau physiquement, par définition peu protégé ? Le réseau wifi devrait être connecté à une interface supplémentaire.

    j'ai mis en place squid proxy server pour que je puisse intercepter le trafic des utilisateurs WIFI

    Je vous recommande la lecture d'une de mes réponses récentes sur le sujet. Il est très fortement délicat de présenter l'objectif dans ces termes. C'est simplement illicite, illégal si vous préférez.
    https://forum.pfsense.org/index.php?topic=143433.msg781401#msg781401

    Qlq aurait une solution pour voir le trafic HTTPS sans avoir à installer le certificat sur les équipements clients ?

    La NSA peut être … Plus sérieusement cette question montre que vous ne comprenez pas le sujet. Sinon vous ne la poseriez pas.



  • Merci d'avoir répondu à mon post,

    Sur la question de sécurité, je ne comprends pas ce vous voulez dire

    Sur la question d'illégalité de l'interception des données, je peux vous dire que c'est bien légal par la loi de Sarkozy publié en 2006 (vous pouvez aller vérifier), ce qui n'est pas légal c'est l'interception du contenu des messages échangés, alors que squid donne des informations basiques loin du contenu des messages échanges (Date, IP, Statut, URL destination, User, IP destination).

    Sur la question de certificat, peut être que oui je ne comprends pas c'est pour ca que je suis venu demander de l'aide sur ce forum et j'aimerai bien avoir une réponse.



  • Sur la question de sécurité, je ne comprends pas ce vous voulez dire

    Un des principes de bases de la sécurité des SI en matière de réseau consiste à cloisonner les réseaux (et les systèmes)  et par conséquent à séparer les flux par nature, en particulier par niveau de sensibilité. Vous comprenez bien qu'un segment de réseau sur un support Wifi est par nature accessible et écoutable. Le trafic d'administration du firewall est par nature sensible. Mettre sur le même segment de réseau du filaire et du wifi revient à exposer le réseau filaire fortement ainsi que toutes les machines qui s'y connectent, comme par exemple votre firewall. Est ce bien raisonnable ? La réponse est non bien évidement. Une pratique de base dans les environnements sérieux consiste à mettre en place un réseau d'administration dédié. Dans cette architecture aucune interface d'administration n’est accessible sur le réseau de données (réseau métier ou utilisateur). Tous les systèmes possèdent au moins deux interfaces : une pour les flux applicatifs, l'autre pour l'administration. Le trafic du réseau d'administration est systématiquement chiffré et les utilisateurs on des comptes nominatifs avec des solutions d'authentification forte.
    Sans aller jusque là, dans votre cas, la séparation entre wifi et lan est un minimum.

    Sur la question d'illégalité de l'interception des données, je peux vous dire que c'est bien légal par la loi de Sarkozy publié en 2006 (vous pouvez aller vérifier), ce qui n'est pas légal c'est l'interception du contenu des messages échangés, alors que squid donne des informations basiques loin du contenu des messages échanges (Date, IP, Statut, URL destination, User, IP destination).

    Non. Vous confondez beaucoup de choses. Je connais bien tous les textes et les jurisprudences applicables. L'enregistrement, et non l'interception, des meta-données de connexion est bien une obligation légale en effet dès lors que vous mettez à disposition un accès à internet. C'est la jurisprudence qui prolonge cette obligation en assimilant notament les entreprise aux FAI et opérateurs télécoms.. L'interception du trafic https ne l'est pas (sauf contexte très spécifique qui nécessite d'être encadré fortement). En conséquence en ce qui concerne https vous n'avez pas besoin d'intercepter (déchiffrer) le trafic utilisateur. Vous pouvez enregistrer simplement les données de connexion telles que celle contenus dans la commande connect. Pour que cela soit cohérent vous devez authentifier les utilisateurs.

    Sur la question de certificat, peut être que oui je ne comprends pas c'est pour ca que je suis venu demander de l'aide sur ce forum et j'aimerai bien avoir une réponse.

    La réponse est que vous n'en avez pas besoin. Cette solution (l'interception) ne fonctionne probablement pas lorsque la connexion SSL a été établie en utilisant certaines configurations (notamment HSTS). Je ne vais pas expliquer ici ce qu'on appelle un certificat et ce qu'il y a derrière. Cela disant on omet de parler des clés et de la négociation des suites cryptographique lors de l’établissement de la session TLS. Dans les formations que j'anime l'exposé un peu complet de ces éléments nécessite environ deux heures.



  • Ah le problème du déchiffrement des connexions sécurisées (HTTPS, TLS/SSL) …

    Ccnet est un expert, donc vous pouvez lui faire confiance ... comme je lui fais confiance.

    La loi du 23 janvier 2006 dite "loi anti-terroriste". 3 liens utiles :

    Article 1384 alinéa 5 du Code civil : l’employeur est responsable de l’agissement de ses salariés, notamment sur les réseaux informatiques ! (Cité par l'ANSSI)

    En 2018, les choses ont bien évoluées :

    Se pose la question du déchiffrement des sessions HTTPS.
    Les bonnes recommandations (pour la France) :

    La diffusion automatique du certificat de remplacement est juste impossible, si on comprend un peu ce qu'on fait.
    J'ai les mêmes étonnements que ccnet sur votre maîtrise du sujet ...


Log in to reply