Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Problème Pfsense Squid HTTPS

    Scheduled Pinned Locked Moved Français
    10 Posts 4 Posters 1.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      amx15
      last edited by

      Bonjour à toutes et à tous,

      Je travaille actuellement sur la mise en place d'un proxy transparent en HTTPS pour journaliser le trafic de l'ensemble de nos bornes WIFI. Nous ne pouvons pas installer de certificat sur les clients, je précise qu'ils seront avertis de la journalisation à l'aide d'un portail captif.

      J'ai installé Pfsense 2.4.4-RELEASE-p3 et les paquets Squid, LightSquid et SquidGuard. J'ai configuré mon Squid en suivant les tutoriels dédiés, il fonctionne bien en HTTP mais pas en HTTPS les requêtes passent par exemple sur Qwant mais pas sur Google ou le monde.

      Voici un extrait des logs Squid : 1561207310.647 461 192.168.1.242 TAG_NONE/409 4000 CONNECT www.lemonde.fr:443 - HIER_NONE/- text/html
      1561207310.647 257 192.168.1.242 TAG_NONE/409 4000 CONNECT www.lemonde.fr:443 - HIER_NONE/- text/html
      1561207310.943 17 192.168.1.242 TAG_NONE/200 0 CONNECT 151.101.2.217:443 - HIER_NONE/- -
      1561207310.944 0 192.168.1.242 TAG_NONE/409 4000 CONNECT www.lemonde.fr:443 - HIER_NONE/- text/html
      1561207311.035 51 192.168.1.242 TCP_MISS/200 484 GET http://detectportal.firefox.com/success.txt - ORIGINAL_DST/92.122.218.154 text/plain
      1561207311.769 10086 192.168.1.242 TCP_TUNNEL/200 4340 CONNECT www.qwant.com:443 - ORIGINAL_DST/194.187.168.100 -
      1561207312.425 11010 192.168.1.242 TCP_TUNNEL/200 4778 CONNECT api.qwant.com:443 - ORIGINAL_DST/194.187.168.106 -

      Cela fait maintenant 3 semaines que je cherche en vain, pouvez-vous svp m'aider?
      Cordialement

      1 Reply Last reply Reply Quote 0
      • O
        Orion2K32
        last edited by

        Bonjour amx15,

        Je pense que ton problème vient du faite que tu utilise le mode transparent. (de souvenir le mode transparent ne fonctionne correctement qu'avec un certificat valide).

        Je te conseil d'utiliser le mode proxy normal et d'utiliser la technologie WPAD (fichier de conf envoyer automatiquement au browser client) ca devrais beaucoup mieux fonctionner.

        Et si tu veut aller plus loin tu peu utilisez une autre solution qui s'appelle ALCASAR un projet opensource portail captif et proxy legal http://www.alcasar.net/

        Et dans ce cas tu utilise le pfsense comme un routeur firewall.

        A 1 Reply Last reply Reply Quote 0
        • A
          amx15 @Orion2K32
          last edited by

          Merci de votre aide @Orion2K32 , j'ai essayé de générer un certificat SSL valide avec Acme plugins de Let's enscrypt mais je n'ai pas réussi.
          Pour le WPAD il me semble qu'il faut changer la configuration du navigateur pour prendre en compte le paramétrage automatique. Je vais tester Alcasar.
          Cdt

          1 Reply Last reply Reply Quote 0
          • O
            Orion2K32
            last edited by Orion2K32

            Par defaut le navigateur est en detection automatique c'est a dire qu'il fait une requete dns lors de sont lancement sur wpad.localdomain.lan si ca repond il fait une requete sur les different fichier wpad pour adaptez ca configuration.

            Ca marche assez bien.

            Concernant alcasar c'est une solution de portail captif tres complete et repondant aux exigence legal.

            1 Reply Last reply Reply Quote 0
            • C
              ccnet
              last edited by

              @amx15 said in Problème Pfsense Squid HTTPS:

              Pour le WPAD

              Le mode transparent ne fonctionne pas en https.
              WPAD est fortement vulnérable est à proscrire
              https://www.ssi.gouv.fr/guide/definition-dune-architecture-de-passerelle-dinterconnexion-securisee/ page 35.

              A J 2 Replies Last reply Reply Quote 0
              • A
                amx15 @ccnet
                last edited by

                Merci @Orion2K32 mais je n'ai pas besoin d'un portail captif.
                D'accord @ccnet , avez-vous une solution pour journaliser la totalité de l'accès au web ?

                1 Reply Last reply Reply Quote 0
                • J
                  jdh @ccnet
                  last edited by

                  @ccnet

                  La référence que tu indiques est assez nouvelle (document du 18 juin 2018).
                  Elle m'a fortement surpris, en particulier par son côté définitif, ...

                  Il existe des vulnérabilités, mais elles semblent largement sur la même 'base', à savoir une faiblesse sur les requêtes dns ... qui est intrinsèque au protocole et donc connue !

                  Et de plus l'implantation de DNS sur des serveurs Windows limite fortement le risque, puisque Microsoft, depuis 2008, a créé une 'blocking query list'.

                  Je résume : un réseau avec un dhcp qui fournit 'nom.local' comme domaine par défaut.
                  Un client va chercher 'wapd.nom.local', à défaut 'wpad.local', à défaut 'wpad'. Il est clair que le propriétaire de 'wpad.com' peut faire du dégât ! (Normalement .local ne peut être requêté sur Internet !)

                  En fait, contrairement à ce qui est affirmé, je pense qu'on a tout intérêt à définir wpad.nom.local même sans l'utiliser ou mieux avec une réponse vide, car ainsi, on évite à permettre des requêtes 'wpad.local'

                  La première reco que je ferais serait d'utiliser en interne un nom .local par défaut, car cela limite les requêtes dns incorrectes ou, autre possibilité, d'utiliser en interne un .com avec un DNS interne qui aurait juste une petite partie du .com externe.

                  Comme IE, Edge, et donc Chrome, font une tentative wpad, ma deuxième reco est de définir un wpad local pour éviter une remontée justement.

                  Enfin un article qui suggère d'utiliser des GPO pour fixer automatiquement les paramètres de proxy me fait largement sourire puisque, d'une cela ne fonctionne que sur Windows, de deux chacun sait que Windows est le modèle de sécurité à suivre ...

                  Donc l'avis de l'ANSSI me parait très surprenante et mal argumenté, et cela ne me fait pas plaisir ...

                  Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                  1 Reply Last reply Reply Quote 0
                  • O
                    Orion2K32
                    last edited by

                    Je vais dans le sense de jdh, de plus la requête dns ce fait sur ton serveur local sans sortie internet puisque tu as un proxy donc le transit vers des DNS externe doit etre bloquer seul ton serveur DNS local doit pouvoir repondre.

                    Apres les problemes de configuration dns c'est un autre probleme.

                    Pour la petite histoire l'ansii ne certifie pas les pfsense comme des firewall fiable.(qui a dit aberation ???) Donc si on veut etre parfaitement dans les clous de l'Ansii faut utilisé autre chose :)

                    C 1 Reply Last reply Reply Quote 0
                    • C
                      ccnet @Orion2K32
                      last edited by ccnet

                      @Orion2K32 said in Problème Pfsense Squid HTTPS:

                      Pour la petite histoire l'ansii ne certifie pas les pfsense comme des firewall fiable.(qui a dit aberation ???) Donc si on veut etre parfaitement dans les clous de l'Ansii faut utilisé autre chose :)

                      Je ne pense pas qu'il faille le comprendre comme cela. Si l'Anssi ne qualifie pas Pfsense cela ne signifie pas qu'il n'est pas fiable. Cela signifie simplement que Netgate n'a pas initié de démarche auprès de l'Anssi pour qualifier Pfsense. Et rien d'autre. Il y a des milliers de produits non qualifiés Anssi qui sont tout à fait fiable.
                      Une qualification Anssi, comme celle de Gatewatcher par exemple obtenue récemment, demande environ 3 ans de travail soutenu. L'effort pour une PME est important, pour Thales qui a obtenu aussi une qualification sur le même type de produit, c'est beaucoup plus accessible.
                      Il n'y a dons rien d'anormal ou aberrant.

                      En ce qui concerne WPAD, je n'ai pas eu le temps de creuser ce qui motive cet avis tranché.

                      J 1 Reply Last reply Reply Quote 0
                      • J
                        jdh @ccnet
                        last edited by

                        L'ANSSI peut certifier les matériels qu'on lui présente !

                        Les matériels Stormshield sont certifiés parce que Stormshield est filiale d'AIRBUS et a fait cet effort.

                        Il est probable que pfSense ne sera jamais certifié, comme d'autres firewall open source.

                        Le document cité par ccnet est extrêmement intéressant et rappelle toutes les bonnes pratiques en matière de firewall, zone, virtualisation.
                        Sauf le passage sur WPAD, sans doute mal compris par le rédacteur !

                        Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.