Squid3 https/ssl MITM ne fonctionne pas

fabienfs

Hello,

J'ai paramétrer un serveur proxy avec squid3 sur mon interface "WIRELESS" qui fonctionne correctement avec http, par contre impossible de faire de l'interception https.

Quand je vais sur un site https, je vois bien l'url dans le log squid, mais le MITM sur https ne se fait pas. D'ailleurs le certificat sur le poste client est le vrai certificat, pas celui de mon routeur pfSense non certifié par une autorité de certification que j'ai renseigné

Voici ma configuration :

(Toutes les configurations des les autres onglets sont celles par défaut. A part une ACL pour autoriser mon subnet wireless à utiliser squid)

Réseau Wireless : 10.0.0.1/24
Réseau WAN : PPPoE

Une idée ?

Merci

Bonne soirée

Est1303

Bonjour,

Moi j'ai utilisé SquidGuard en complément et pour bloqué les sites en https j'ai du ajouté une liste dans l'onglet "Target Cible" ou j'ai pu indiquer mes sites https à bloquer

"Cependant moi c'était avec un proxy en mode transparent donc je ne sais pas si ca va t'aider"

et j'ai du également exporter le certificat pour l'intégrer dans le navigateur.

fabienfs

@Est1303:

Moi j'ai utilisé SquidGuard en complément et pour bloqué les sites en https j'ai du ajouté une liste dans l'onglet "Target Cible" ou j'ai pu indiquer mes sites https à bloquer

Ici j'aimerais juste utiliser les ACL pour bloquer que quelque mots clés, donc à priori pas besoin de SquidGuard en plus

ccnet

Nouvelle édition d'une discussion qui a déjà eut lieu … souvent sur ce forum.
"Proxyfier", filtrer et inspecter le flux https pose de nombreux problèmes. A commencer par les aspects juridiques. Comme nous en avons un peu assez de répéter 100 fois les mêmes choses, deux sites à consulter :
1. Celui de la Cnil où vous comprendrez que vous ne feriez mieux de ne pas intercepter sans vrai raison extrêmement valables, et avec un sévère encadrement, les flux https des utilisateurs.
2. http://www.ssi.gouv.fr/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https/

Je cite pour vous rappeler le contexte :

Pour se préserver, l’employeur peut effectivement être amené à mettre en place un système de déchiffrement et de contrôle des échanges d’information réalisés par ses salariés sur les systèmes d’information qu’il met à leur disposition qui, s’il n’est pas strictement encadré, peut conduire l’employeur à engager sa responsabilité sur d’autres fondements.

Toujours dans le document de l'Anssi je vous recommande de lire avec attention les pages 28 et suivantes.

Et pour la 285789ieme fois le proxy n'a rien à faire sur le firewall.

ccnet

@Est1303:

Bonjour,

Moi j'ai utilisé SquidGuard en complément et pour bloqué les sites en https j'ai du ajouté une liste dans l'onglet "Target Cible" ou j'ai pu indiquer mes sites https à bloquer

"Cependant moi c'était avec un proxy en mode transparent donc je ne sais pas si ca va t'aider"

et j'ai du également exporter le certificat pour l'intégrer dans le navigateur.

Ne pas confondre liste d'url autorisées (ou non) et inspection de contenu.

je ne sais pas si ca va t'aider

Alors ne dites rien !

fabienfs

@ccnet:

Comme nous en avons un peu assez de répéter 100 fois les mêmes choses, deux sites à consulter :
1. Celui de la Cnil où vous comprendrez que vous ne feriez mieux de ne pas intercepter sans vrai raison extrêmement valables, et avec un sévère encadrement, les flux https des utilisateurs.
2. http://www.ssi.gouv.fr/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https/

Je sais très bien ce que je veux faire, et il s'agit ici de test technique sur mon réseau privé à domicile, donc aucune inquiétude la dessus.

@ccnet:

Et pour la 285789ieme fois le proxy n'a rien à faire sur le firewall.

Pour de l'apprentissage sur un réseau à domicile ça convient parfaitement. Je ne vais pas me payer un serveur pour faire des test… :-)

S'il vous plait, des réponses techniques.. L'aspect juridique n'a rien à faire dans ce post :-)

merci

ccnet

L'aspect juridique n'a rien à faire dans ce post :-)

La technique n'entre pas pour plus de 50%, et encore, dans les problématiques de sécurité. Si vous ne faites que de la technique vous ne faites pas de sécurité.

Pour de l'apprentissage sur un réseau à domicile ça convient parfaitement.

C'est un apprentissage artificiel, sans rapport avec la réalité du terrain. Jamais sur le terrain on ne fera une mise en œuvre sérieuse dans ces conditions. C'est dire avec un package et des cases à cocher. Ce n'est pas avec cela que vous apprendrez comme fonctionne les choses et que vous pourrez en acquérir une maitrise. C'est à dire un savoir utilisable.

Si vous aviez tenu compte des recommandations avant de poster vous auriez lu que le contexte d'utilisation est la premier point à renseigner : https://forum.pfsense.org/index.php?topic=79600.0

Je ne vais pas me payer un serveur pour faire des test… :-)

La virtualisation bien comprise permet d'éviter de le faire. Cela permet aussi d'éviter les effets de bords (comme on le lit ici régulièrement) entre un test et une configuration destinée à l'usage quotidien, ou en production.

S'il vous plait, des réponses techniques.

Ha bon votre navigateur tente d'utiliser le "bon" certificat ?! Cà alors comment ça se fait ?
Un certificat autosigné, certes oui pourquoi pas si c'est correctement fait ! Savez vous si les caractéristiques cryptographiques du certificat que vous utilisez sont acceptables par le navigateur et quel navigateur ? Il faut comprendre le fonctionnement des différentes versions de SSL (qui ne doit plus être utilisé) et de TLS.
Pour les réponses techniques que vous réclamez de tout votre être, cela tombe bien, il y a une bonne dizaines de pages qui traitent de votre problème dans le document de l'ANSSi. Il n'y a pas de réponse en 3 lignes à votre problème. Ce forum n'est pas un distributeur de recettes. Et je ne vais pas prétendre refaire le travail, excellent, de l'ANSSI par un groupe de spécialistes ultra compétents. En lisant et en comprenant ce document vous en apprendrez infiniment plus qu'en cochant des cases dans un package de Pfsense.

jdh

Une solution simple, efficace, peu contraignante et qui offre de nombreux plus : le proxy dédié et son complément naturel WPAD.

Parmi les avantages :

séparation firewall et proxy : évite les problèmes liés à la charge machine dus à la grande différence entre les 2 outils,
pas d'horrible bricolage comme le man in the middle avec ce rituel problème de certificat
facilité à stocker les logs en vue du respect de la loi
suppression de la très fausse bonne idée du 'proxy transparent'

Parmi les inconvénients :

faire soi-même le proxy (mais est ce vraiment un inconvénient ?)
pas d'interface web de paramétrage (mais combien de fois en a-t-on besoin une fois la solution au point ?)
nécessite une bonne expertise (mais c'est le moyen de l'acquérir, ce qui ne sera pas le cas d'interface clickodrome)
les navigateurs de visiteurs devront être correctement configuré (moins pire que d'importer le certificat du firewall !)

Bref j'ai choisi depuis longtemps …

NB : prenez le temps de lire ce qu'écrit ccnet : il n'écrit rien par hasard

fabienfs

@ccnet:

C'est un apprentissage artificiel, sans rapport avec la réalité du terrain

@jdh:

Une solution simple, efficace, peu contraignante et qui offre de nombreux plus : le proxy dédié et son complément naturel WPAD.

Je vous remercie pour vos réponses et pour votre expertise. Je vois que vous poussez à chaque fois la réflexion plus loin pour trouvez la meilleur solution (même au delà de l'aspect technique). J'avais déjà lu le document sur les recommandations de l'ANSSI.

Mais ici j'aimerais précisément faire fonctionner le MITM https depuis SQUID3 sur pfSense. D'autres l'ont déjà fait. Je cherche juste à comprendre pourquoi le MITM ne se fait pas malgré que tout semble bien paramétrer (voir ma config dans le premier post)