Forum Linux.général Man in the middle ? Vérifier la validité du SSL

Posté par (page perso) . Licence CC by-sa
Tags : aucun
3
28
juin
2016

Bonjour,

j'utilise un réseau que je ne maitrise pas, sur une machine qui n'est pas la mienne, et je soupçonne que l'administrateur réseau utilise des techniques de man-in-the-middle, fin de s'adonner au déchiffrement SSL.

La machine en question possède en effet un certificat ROOT qui permettrait ce type de déchiffrement, de même que l'administrateur à la maîtrise du DNS.

La question n'est pas la légitimité d'une telle pratique, mais plutôt de savoir si les sites sur lesquels je vais sont soumis à du déchiffrement SSL. Il semble en effet que tous les sites web ne soient pas déchiffrés (utilisation de whitelist).

Aussi, est-ce que la méthode ci-dessous est valide, afin de vérifier l'authenticité / sécurité de la connexion SSL :
- Dans firefox, afficher les informations du certificat, et notamment le numéro de série. Pour LinuxFR, il s'agit actuellement de "00:FC:EE:49:C0:97:E1:77:95:F6:17:51:8E:E8:7D:CF:10"
- Aller sur https://www.sha2sslchecker.com/linuxfr.org , et vérifier que le "serial number" corresponde. Ici c'est "fcee49c097e17795f617518ee87dcf10", ce qui correspond, donc la connexion SSL vers LinuxFR ne semble pas trafiquée.

Bien sûr, la méthode est valide uniquement si l'administrateur ne s'amuse pas à modifier lui-même les résultats de "https://www.sha2sslchecker.com/" . Mais cela ne paraît pas raisonnable, car il semble exister plein d'autres sites de ce type:
https://certificate.revocationcheck.com/linuxfr.org
https://certificatedetails.com/b390a7d8c9af4ecd613c9f7cad5d7f41fd6930ea/fcee49c097e17795f617518ee87dcf10/.linuxfr.org
https://www.ct-observatory.org/cert/7801270/ (bizarrement, le serial number ne correspond pas)

Et vous, comment vous feriez ?

  • # vérifier l'autorité qui a délivré le certificat

    Posté par . Évalué à 2.

    Salut,

    Dans ma boîte, ça se passe aussi comme ça. Nous avons un proxy filtrant (sites ou contenus interdits, antivirus, …) qui déchiffre aussi le contenu SSL (sauf pour certains sites reconnus, comme ceux des banques, gmail, et quelques autres). Cela peut se faire de façon transparente parce que le proxy génère à la volée un certificat correspondant au site visité mais signé par l'AC de l'entreprise (et le certiticat racine est diffusé sur tous les postes, Windows, via la GPO).
    Le moyen le plus simple que j'ai trouvé pour savoir si le site visité est filtré par le proxy est de vérifier l'autorité qui a délivré le certificat : lorsque le proxy déchiffre, il s'agit de l'AC interne, sinon c'est une AC "reconnnue" (Gandi, Commodo, Thawte, Verisign, let's Encrypt, …)
    Bien évidemment, tout cela est clairement annoncé par l'entreprise (il s'agit peut-être d'une obligation) mais la liste des sites en liste blanche n'est pas publiée (il me semble que cette liste ainsi que la détection de contenus "illicites" s'appuient sur des données fournies par un prestataire externe).

    Il faut cependant noter que ce mécanisme, introduit pour des raisons de sécurité et de confidentialité (ça peut permettre de tracer des fuites de données) peut aussi induire des problèmes : la gestion des certificats serveur non valides (certificats expirés, autosignés ou signés par une AC non présente sur la machine locale) n'est plus possible du côté de l'utilisateur final. Soit le serveur intermédiaire accepte tout sans discernement (avec un risque d'usurpation d'identité) soit il rejette,sans laisser la possibilité à l'utilisateur de choisir (il existe des mécanismes pour gérer ces cas mais cela reste délicat et imparfait).

    • [^] # Re: vérifier l'autorité qui a délivré le certificat

      Posté par (page perso) . Évalué à 2.

      lorsque le proxy déchiffre, il s'agit de l'AC interne, sinon c'est une AC "reconnnue" (Gandi, Commodo, Thawte, Verisign, let's Encrypt, …)

      C'est ce que je pensais faire initialement, mais rien n'empêche l'admin de se créer un certificat root qui s'appellerait "Verisign", "Thawte", ou autre, et qu'il utilise pour signer tout les sites.

      Ou utiliser un nom très proche, comme "Verisig*m*".

      D'où l'idée d'utiliser un site web externe qui permette de comparer le certificat officiel avec ce qu'affiche le navigateur.

      • [^] # Re: vérifier l'autorité qui a délivré le certificat

        Posté par (page perso) . Évalué à 3.

        Rien n'empêche non plus d'admin de modifier à la volée ce qu'indiquent ces sites Web externes.

        • [^] # Re: vérifier l'autorité qui a délivré le certificat

          Posté par . Évalué à 2.

          Il faut tout de même réussir à recadrer un minimum le débat. On est là dans le cadre professionnel d'une entreprise, pas sur un hotspot WIFI ou un réseau public, avec du matériel fourni par l'entreprise et des règles qui sont normalement communiquées aux collaborateurs (salariés ou prestataires). Si l'on en arrive à un tel niveau de paranoïa vis à vis de ses admin réseau et système, il faut effectivement réduire au minimum les échanges personnels, voire professionnels comme indiqué plus bas, sur ce matériel et ce réseau (actuellement avec un téléphone perso ou une tablette + un accès 4G, ça n'est pas bien compliqué).

          Mais je ne pense pas que l'objectif (premier) de ce type d'infrastructure soit de venir découvrir les codes d'accès aux sites bancaires ou les mots de passe des comptes LinuxFr.org. J'ai vu des entreprises mettre en place ces proxy SSL filtrant au fur et à mesure que les flux https se sont développés de façon à filtrer de la même façon les contenus https ou http. Sans vouloir défendre ces pratiques, il faut aussi comprendre les contraintes auxquelles sont soumises les entreprises :
          - responsabilité en cas d'accès à certains sites ;
          - irresponsabilité/manque de compétences des utilisateurs qui téléchargent un peu n'importe quoi ou cliquent n'importe où (avec des risques d'infection qu'un antivirus local ne suffit pas toujours à réduire) ;
          - obligation de conserver certaines logs de connexion pendant un certain temps (cette obligation n'est pas forcément légale mais peut être liée à certaines procédures de sécurité ou à des agréments).

          Donc, je ne pense pas que ces entreprises aient un intérêt particulier à dissimuler leur AC derrière un nom particulier, l'objectif n'étant pas de tromper les collaborateurs mais de protéger le réseau interne (ou au pire de surveiller les employés ou des les dissuader d'utiliser les ressources professionnelles pour des besoins perso). Je pense même qu'elles auraient tout intérêt à communiquer largement sur ce filtrage.
          La vérification de l'AC émettrice du certificat me semble donc suffisante. Si ce n'est pas le cas, rien ne le sera (et il faut alors certainement penser à changer de boite).

          • [^] # Re: vérifier l'autorité qui a délivré le certificat

            Posté par (page perso) . Évalué à 3.

            Je ne nie pas la nécessité de mettre en place un mécanisme de déchiffrement du SSL, du moins au niveau des entreprises.

            Ce qui me gène, c'est que l'utilisateur est mal informé du fait que le SSL va être cassé, déchiffré, et les données éventuellement stockées pour une post-analyse.

            Peu de personnes savent que le "petit cadenas" dans le navigateur veut dire que la connexion est sécurisée. Mais maintenant, il faut expliquer à ces rare personnes que non, la présence du cadenas ne suffit pas, et qu'il faut vérifier le "Root certificat". C'est nettement moins simple… :(

            Aussi, je pense que lorsqu'une entreprise se livre à du déchiffrement SSL, il faudrait que le proxy SSL rajoute à la volée un morceau de code HTM/Javascript à la 1ère page, afin d'afficher une popup, ou un bandeau du style de ceux qui s'affiche actuellement "le site sur lequel vous surfez contient des cookies". Histoire qu'avant de taper son login/password, l'utilisateur se dise "Tiens, je vais me faire piquer mon mot de passe, je vais peut-être ne pas le faire".

  • # machine de confiance

    Posté par . Évalué à 4.

    Salut,
    Sur une machine que tu n'as pas installée toi-même ou en laquelle tu n'as pas confiance, il n'y a pas grand chose à faire parce que l'administrateur peut avoir installé tout un tas de trucs pour espionner l'utilisateur, et pas seulement un certificat racine: keylogger, prise de contrôle / screenshot à distance, etc.
    La solution est de ne pas l'utiliser pour des activités personnelles "sensibles".

    • [^] # Re: machine de confiance

      Posté par . Évalué à 3. Dernière modification le 28/06/16 à 14:09.

      La solution est de ne pas l'utiliser pour des activités personnelles "sensibles".

      Il peut aussi être sensible de l'utiliser pour certaines tâches de l'entreprise. Les admins systèmes n'étant pas au-dessus de tout le monde en entreprise ( quand ce n'est pas un prestataire qui traite même ), ils n'ont pas à savoir quelques secrets ( identifiants banques ou autre, etc… ).

      • [^] # Re: machine de confiance

        Posté par (page perso) . Évalué à 4.

        Il peut aussi être sensible

        Pertinent. Sensible, c'est quand on on détecte et qu'on est facilement affecté par des conditions particulières, par exemple sensible au froid ou au bruit.

  • # risque juridique

    Posté par . Évalué à 1.

    Pour les entreprises qui réalisent ce genre de pratique, elles s'exposent à des risques juridiques, dans le cas d'un piratage bancaire et qui s'avère que les certificats ont été modifiés par l'entreprise, pour moi il y a rupture de la chaîne de confiance.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.