Journal Légalité de l'interception du flux SSL au sein d'une entreprise

Posté par  . Licence CC By‑SA.
Étiquettes :
35
23
juil.
2018

Bonjour,

Mon entreprise à récemment mis en place un certificat sur les machines utilisateurs et un 'proxy' afin de pouvoir décrypter le flux SSL.

Je ne reviens pas sur comment cela fonctionne, le principe étant simple: le proxy intercepte la demande et fait la requête au serveur a la place du client. Il usurpe le certificat du serveur en ayant installé le certificat sur ma machine.

Mes 2 questions:
- Est ce légal en France ? L'argument usuel trouvé ici et là sur le net est 'mon réseau, mes règles', mais les utilisateurs ont l'autorisation de faire un usage modéré et libre a des fins personnelles de l'accès internet, et ils n'ont pas été avertis de ce changement qui n'est pas anodin :maintenant quand on va sur le site de sa banque / paypal, si on ne passe pas sa sourie sur le certificat, on ne vois pas de différence et l'utilisateur peut penser être toujours protégé.

  • Y a t-il moyen de passer outre ? Je pense à du SSL over HTTPS (j'imagine que l'outil interceptera la 1ere demande, fera sa magouille, mais enverra une demande SSL au serveur cible. Le second certif etant sur une clé USB :D. Ou un chiffrage dans le code (javascript ?) de la page ?

  • # Legal sous certaine conditions

    Posté par  . Évalué à 7.

    Ceci est une pratique courante dans la plupart des grosses boites (DSI presé qui achète une solution de cyber-sécurité sur étagère).
    Mais effectivement tu as le droit d'aller lire modérement tes mails perso ou ton compte en banque depuis ton travail et ceci doit rester privé. Donc généralement ces solutions ont des listes blanches de services autorisés qui ne passe pas par l'intercepteur/proxy SSL.
    Fait un test avec ta banque et regarde qu'elle certificat ssl est utilisé. Si c'est celui du proxy et qu'aucun information spécifique vous a été faite sur ce sujet, je doute très très fort de la légalité de la solution mise en place.

    • [^] # Re: Legal sous certaine conditions

      Posté par  (site web personnel) . Évalué à 3.

      Mais effectivement tu as le droit d'aller lire modérement tes mails perso ou ton compte en banque depuis ton travail et ceci doit rester privé. Donc généralement ces solutions ont des listes blanches de services autorisés qui ne passe pas par l'intercepteur/proxy SSL.

      Pas sûr. De ce que j'ai compris c'est qu'on ne peut sanctionner un employé car il a fait des choses persos via la connexion du boulot sur son temps de travail (dans la limite du raisonnable). Mais cela ne signifie pas que l'entreprise doit tout mettre en œuvre pour que cela soit possible (s'ils filtrent le site de ta banque ou Youtube, ils ne sont pas dans l'obligation de les débloquer).

      Personnellement cela me semble logique.

      Donc cette solution ne me semble pas illégale, ce qui est illégal par contre ce serait que quiconque dans la boîte lise en clair ce que tu fais et puisse récupérer tes identifiants ou usurper ta connexion.

      • [^] # Re: Legal sous certaine conditions

        Posté par  . Évalué à 10.

        La boite à le droit de bloquer les connexions. Par contre si elle fait du MITM SSL sur ta banque la y a soucis. Elle n'a pas le droit "d'espionner" ce type de communication.
        Donc soit elle bloque purement et simplement soit elle laisse passer sans le Proxy/MITM SSL.

        • [^] # Re: Legal sous certaine conditions

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 23 juillet 2018 à 19:50.

          Il me semble compliqué d'exiger des entreprises qu'elles identifient les sites des banques des employés (pour ne parler que de ça).

          À mon avis, elle n'a pas le droit de mettre ça en place sans prévenir les employés, mais à partir du moment où ils sont au courant (par exemple en donnant à lire une charte informatique), je ne pense pas qu'il y ait de problème légal.

          • [^] # Re: Legal sous certaine conditions

            Posté par  . Évalué à 4. Dernière modification le 24 juillet 2018 à 09:34.

            Il me semble compliqué d'exiger des entreprises qu'elles identifient les sites des banques des employés (pour ne parler que de ça).

            Ma boîte le fait très bien. Les sites « sensibles » comme les banques, ameli.fr, impots.gouv.fr, etc, ne sont pas interceptés. Par contre, le reste… Si :) Souvent l'interception sert à faire une redirection vers une page interne de blocage. Parfois (comme linuxfr ou GitHub, mais pas tout le temps), c'est juste pour rechiffrer.

            Apparemment, ça utilise WebSense. Je n'ai pas plus creusé que ça.

    • [^] # Re: Legal sous certaine conditions

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 25 juillet 2018 à 14:18.

      Dans la même situation, j'ai fait quelques recherches. L'employeur a le droit de déchiffrer les paquets mais ne peut pas lire le contenu. Dans le cas du HTTP, il a juste de droit de regarder les en-têtes pour avoir l'URL par exemple.
      Après, dans mon cas, il me semble qu'ils sont dans l'illégalité :
      - Il faut prévenir avant.
      - Il faut informer du pourquoi.
      - Il faut informer sur le temps de rétention des données (pour la CNIL, c'est 6 mois max)
      - Il faut informer le droit d’accès : On a la possibilité de demander tout notre historique de connexion !
      - On doit pouvoir consulter les procédures d’accès à ces données : Qui y a accès ? Quand ? Comment sont journalisé les accès à ces données (il doit y avoir impossibilité de falsification ou de passage outre, pour des raisons juridique) …
      - etc…

      L'ANSSI est assez frileuse sur le sujet. D'un point de vu sécurité ça apporte beaucoup de problèmes.

      • [^] # Re: Legal sous certaine conditions

        Posté par  . Évalué à 3.

        L'employeur a le droit de déchiffrer les paquets mais ne peut pas lire le contenu.

        Si, il peut. Le principe de n'importe quel antivirus, de flux ou de fichier, ou même d'une solution de DLP, c'est de s'intéresser au contenu et pas juste aux métadonnées ; solutions qui à ma connaissance ne sont pas interdites en France. Il faut juste que ce soit écrit et (réputé) connu du salarié.

        • Il faut prévenir avant.

        Oui. Mais attention, le coup de la signature obligatoire de la charte, c'est un coup oui, un coup non. Dans certains cas l'annexion au règlement intérieur peut suffire (c'est ce que m'avait indiqué le cabinet d'avocats dans mon ancienne boîte)

        • Il faut informer du pourquoi.

        Oui, mais il ne faut pas oublier qu'à ton niveau c'est une information, pas une négociation. T'as le droit de ne pas être d'accord, tout comme l'employeur n'est pas tenu de te fournir l'internet.

        • Il faut informer sur le temps de rétention des données (pour la CNIL, c'est 6 mois max)

        Non, la CNIL dit qu'une durée de l'ordre de 6 mois est généralement suffisante, pas que c'est le max. C'est écrit ici. Dans le cas où ça peut être aussi utilisé en réponse à incident, on peut très bien vendre un an.

        On doit pouvoir consulter les procédures d’accès à ces données

        Individuellement, à ma connaissance, tu n'as aucune base de droit pour ça. Pas plus que tu n'as le droit de consulter les procédures de Facebook pour t'assurer que tes données sont secure. L'autorité de contrôle, par contre, oui.

        L'ANSSI est assez frileuse sur le sujet.

        C'est surtout pas vraiment son sujet et ils ont d'autres chats à fouetter.
        Dans la note technique de l'Agence pointée plus bas, il y a un élément qui va dans le sens du journal : la R22 avec l'exemple des banques. Cependant c'est toujours une histoire de bénéfice/risque. A priori, je serai enclin à ne pas intercepter le trafic vers paypal ou la BNP, par contre ne pas le faire avec le webmail d'Octave serait suicidaire. Donc c'est pas une généralité. Dans ce cas, je préfère bosser un peu avec le fournisseur pour mon registre de traitements gédépéhère.

        (la R4 avec le gag sur l'IGC/A me fait hurler de rire)

  • # Passer outre grâce aux réseaux de téléphonie mobile

    Posté par  (site web personnel) . Évalué à 8. Dernière modification le 23 juillet 2018 à 11:40.

    Le plus simple pour passer outre, c'est d'utiliser un téléphone pour aller sur le site de ta banque.

    • [^] # Re: Passer outre grâce aux réseaux de téléphonie mobile

      Posté par  . Évalué à 8.

      À condition d'avoir du réseau. Mon bâtiment est un bâtiment "moderne", dont la déco consiste en des plaques de métal peint. Résultat, je bosse dans une cage de Faraday et je ne capte pas le réseau téphélonique.

      Ça, ce sont les sources. Le mouton que tu veux est dedans.

      • [^] # Re: Passer outre grâce aux réseaux de téléphonie mobile

        Posté par  . Évalué à 1. Dernière modification le 23 juillet 2018 à 18:36.

        Une solution d'évasion ?

        Le hotspot 4G est composé de la sorte :
        Netgear AC810-100EUS Hotspot Mobile 4G+ LTE Wi-Fi 1200 Mbps Noir
        +
        Netgear DC112A-100EUS Station d'accueil pour Modem 3G/4G Aircard AC785/AC790/AC810
        +
        Netgear 6000450 Antenne Mimo AirCard Booster de Performance Noir

        c'est pas très discret hein ? ;)

        • [^] # Re: Passer outre grâce aux réseaux de téléphonie mobile

          Posté par  . Évalué à 9.

          Effectivement, c'est pas très discret :P. J'ai opté pour une approche encore moins discrète, vu que le boulot était de toutes façons pas intéressant : j'en ai trouvé un autre, puis j'ai gentiment remis ma lettre de démission. A priori, mon futur bâtiment sera plus ancien et laissera passer le réseau téléphonique.

          Ça, ce sont les sources. Le mouton que tu veux est dedans.

  • # TLS over TLS

    Posté par  (site web personnel) . Évalué à 7.

    Perso, j’avais développé ça pour shunter le proxy de mon ex-boîte :
    https://github.com/aeris/firewall-piercer

    Ça fait du TLS avec un serveur, qui sert ensuite de proxy SOCKS5 distant.
    Du coup le proxy de la boîte est aveugle.

    Ça nécessite quand même de trouver un port accessible par le proxy (généralement ça filtre assez violamment).

    • [^] # Re: TLS over TLS

      Posté par  . Évalué à 1.

      Oui c'est quelquechose comme ça auquel je pensais. Problème: l'outil de monitoring va détecter les requêtes à mon proxy (fingerprinting). Je pensais faire cela avec un PHP proxy (PHPROXY ou Glyphe), mais :
      - Un admin sur le proxy de ma boite pourra toujours voir ce que je regarde.
      - Ce n'est pas automatisé.

      Il faudrait crypter une partie de la page en réponse avec mon certificat…

      • [^] # Re: TLS over TLS

        Posté par  (site web personnel) . Évalué à 3.

        Il fingerprintera pas grand chose, sauf à avoir une sonde dédiée SOCKS5…
        Et le contenu qui passe dans le tunnel est chiffré si tu consultes un site en HTTPS. Il y a alors 2 couches de chiffrement, celle du tunnel (que le proxy de ta boîte shootera peut-êter) et celle du site directement (que ta boîte ne pourra pas shooter car elle n’est plus en position de MITM, la négociation étant faite à l’autre bout).

      • [^] # Re: TLS over TLS

        Posté par  (site web personnel) . Évalué à 6.

        Hmm t'es tu posé la question de la légalité ou des conséquences potentielles pour ton emploi du contournement volontaire de ce système ?

        • [^] # Re: TLS over TLS

          Posté par  . Évalué à 10.

          il ne contourne pas, il chiffre de manière profonde ses communications par habitude.

  • # SSL over HTTPS

    Posté par  . Évalué à 4.

    Pour avoir expérimenter cette 6#$%«» je n'ai pas trouvé de moyen simple de le contourner. En générale ces solution, font du DPI dans l’intervalle de la communication déchiffré. J'ai tenté de mettre en place un tunnel avec mon serveur @home via SSH+CNTLM+SSLH sur le port 443 mais ça n'est jamais passé.

  • # Article de la CNIL

    Posté par  . Évalué à 9.

    Pas le plus récent (décembre 2015) mais ça peut servir de base : la CNIL indique que l'information des salariés est obligatoire.

  • # usurpation

    Posté par  . Évalué à 1.

    Je pense que si le navigateur ne voit pas la supercherie, alors c'est que ton entreprise a usurpé l'indentité de certains sites, et une autorité de certification a validé cette usurpation. Et ça, ce n'est pas joli.

    Ça me fait penser à une affaire il y a quelques années :

    https://www.theregister.co.uk/2013/12/10/french_gov_dodgy_ssl_cert_reprimand/

    Extrait :

    A French government agency has been caught signing SSL certificates and impersonating Google.

    The bogus certificates were endorsed by the certificate authority of the French Treasury, DG Trésor. And the Treasury's own authorisation certificate was, in turn, vouched for by IGC/A (Infrastructure de Gestion de la Confiance de l'Administration) and ultimately ANSSI, the French equivalent of the CESG assurance wing of GCHQ.

    It seems the French Treasury department created the counterfeit certificate in order to monitor employee traffic that would otherwise pass through its network wrapped in encryption. The dodgy certificate allowed man-in-the-middle SSL interception, a heavily frowned on practice that violates the trust model of internet security.

    • [^] # Re: usurpation

      Posté par  (site web personnel) . Évalué à 5. Dernière modification le 23 juillet 2018 à 12:45.

      ton entreprise a usurpé l'indentité de certains sites, et une autorité de certification a validé cette usurpation.

      C'est dit explicitement dans le journal : l'entreprise force à installer un certificat en plus sur les clients, et signe les réponses HTTP avec ce certificat. Pas besoin de passer par une autorité de certification existante (là ça serait effectivement très embêtant), c'est juste une histoire interne au réseau de la boîte.

  • # Limitation du scope de l'interception

    Posté par  . Évalué à 5.

    Pour moi, ton entreprise doit à minima mettre à jour sa charte informatique pour préciser cela et notifier les utilisateurs de la mise à jour de la charte informatique.
    L'ANSSI a publié une note là-dessus, mais j'avoue ne pas avoir pris le temps de la lire :P
    https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_TLS_NoteTech.pdf

    Sinon, dans les best practices, l'interception est normalement désactivée sur certaines catégories de site type banques (vu que tu parles de proxy, ils font forcément du filtrage sur la catégorie de site aussi) car l'interception est là uniquement pour protéger l'entreprise de certains risques (fuite de données, sécurité des échanges depuis internet, …). Si l'interception a été activée globalement, je trouve cela inutile et utilise des ressources pour rien.

    • [^] # Information et transfert de responsabilité

      Posté par  . Évalué à 9.

      Au début de la page 29 du document de l'ANSSI, il est clairement mentionné la chose suivante :

      « La mise en place par une entité d’un mécanisme de déchiffrement des flux doit s’accompagner du respect des principes généraux suivants :
      – transparence et loyauté de l’employeur vis-à-vis de ses salariés en les informant sur la nature des mesures informatiques prises sur le réseau informatique de l’entité et en recueillant leur consentement individuel sur la charte informatique ainsi qu’en consultant les
      instances représentatives
      du personnel »

      Donc CHAQUE individu doit avoir signé un papier.

      Ensuite, il faut savoir que cette note rappelle aussi un point important : ce n'est plus l'utilisateur qui fait la connexion, mais l'entreprise. En effet, à partir du moment où c'est elle qui chiffre, c'est elle qui devient responsable de la communication sortante. Je ne sais pas si les entreprises ont bien compris ce qu'implique cette responsabilité. En cas d'activité frauduleuse, ce sera donc à l'entreprise de démontrer que ce n'est pas elle qui est à l'origine de l'activité, et surtout de désigner le coupable. C'est pas évident.

      • [^] # Re: Information et transfert de responsabilité

        Posté par  (site web personnel) . Évalué à 6.

        On peut même ajouter que certaines boites noir MiM utilisent des versions de openSSL complètement obsolètes et troués.

        "La première sécurité est la liberté"

      • [^] # Re: Information et transfert de responsabilité

        Posté par  . Évalué à 3.

        En cas d'activité frauduleuse, ce sera donc à l'entreprise de démontrer que ce n'est pas elle qui est à l'origine de l'activité, et surtout de désigner le coupable. C'est pas évident.

        Elle va montrer sa bonne et foi et balancer les logs. Ca tombe bien, un des avantages des boîtes magiques type Zscaler/Bluecoat, c'est que ça fait des logs de fou et que ça authentifie. Quel est le truc compliqué, ici ?
        En faisant ça, paradoxalement, elle se compliquera moins la vie qu'avec un proxy à l'ancienne qui n'intercepte pas le traffic SSL et non authentifié/journalisé (puisqu'à priori ce n'est pas obligatoire), où elle risque une perquisition à grosse maille pour trouver d'où vient la merde. Parce que bon, ça ne se termine pas à "désolé, msieur le policier, j'ai pas de logs parce que je ne suis pas obligé".

        • [^] # Re: Information et transfert de responsabilité

          Posté par  . Évalué à 2.

          Oui, c'est pas faux, les solutions clés en main ont un vrai historique, bien gros.

          Par contre, c'est en général pas impossible de récupérer les identifiants d'un collègue. Surtout quand les communications internes vers le système d'authentification ne sont pas chiffrées.

          • [^] # Re: Information et transfert de responsabilité

            Posté par  . Évalué à 2.

            C'est pas impossible mais en l'espèce, on ne désigne pas un coupable, on cible méchamment une perquisition/enquête, donc ce n'est pas le seul élément qui entre en ligne de comte. D'autant que si tu ne veux pas te faire gauler, il ne faut pas juste chopper les credentials d'un collègue. C'est pour ça qu'en entreprise on limite (ou on essaye de limiter) ce que peuvent faire les gens avec les machines, c'est pas juste parce qu'on est des nazis.

            Mais encore une fois, ici, tu vas te faciliter la vie par rapport à un proxy openbar et la problématique sera à peu près identique qu'avec un proxy authentifiant classique.

  • # Attention au contournement

    Posté par  . Évalué à 8.

    Bon on est d'accord que ton entreprise doit t'informer de ce qui a été mis en place !

    Par contre attention si tu tentes de passer au travers de leur système, ceci pourrait être considéré comme une tentative de hack ou autres… et c'est puni par la loi.
    Donc fait très attention, même s'ils ne sont pas carrés, ne va pas te mettre en porte-à-faux pour un accès Internet ;)

    • [^] # Re: Attention au contournement

      Posté par  . Évalué à 1.

      On est bien d'accord là dessus. D'ailleurs ma question de "comment contourner la chose" était plus à but technique (ai ce faisable ? la solution est elle pérenne etc..):

      Monter un proxy / web socket sur mon serveur perso est toujours une solution (et je sais le faire), sauf qu'en cas de détection, c'est le ban d'IP et adieu mon site (du moins depuis mon taf).

      Non, ma question est de savoir si une solution existe. Je n'envisage pas de la mettre en place.

      J'en suis arrivé à la solution suivante: un serveur web en https, qui recevrait un requête (façon phproxy / glyphe) qu'il interrogerait pour moi, et qui chiffrerait une partie de la réponse avec un certificat connu que de moi (sur une clé usb) et le serveur.

      L’entête de cet réponse contiendrai un code javascript et une partie montrant le site interrogé (facon phproxy/glyphe) et le données crypté avec le second certif. Le code javascript décrypterai la page (via le certificat local sur clé usb)

      Vous en pensez quoi ? Je réinvente la roue ? J'ai rien compris au process ?

      Par contre me reste le problème du ykafokon pour le mettre en place :)

      • [^] # Re: Attention au contournement

        Posté par  (site web personnel) . Évalué à 2.

        Tu réinventes la roue… oui et non.

        Ce type de contournement est presque toujours possible, tant les possibilités sont nombreuses. Donc : oui, ça peut être fait ; oui, ça a probablement déjà été fait.

        Le problème est que la situation est différente au sein de chaque entreprise, voire au fil du temps dans une même entreprise, ce qui fait que tu es un peu obligé de faire du sur-mesure à chaque fois. Par exemple, tu parles là d’avoir un certificat sur une clef USB ; eh bien moi, je travaille à un endroit où les périphériques USB ne sont pas reconnus (désactivation des ports).

        Donc, c’est possible mais (comme déjà dit) non recommandé, et il n’y a pas de recette miracle qui convient à toutes les situations.

  • # Déjà en 2014...

    Posté par  (site web personnel) . Évalué à 2.

    Plus d'infos sur les aspects juridiques de la chose, dans cet article de 2014 : https://www.silicon.fr/5-questions-comprendre-dechiffrement-ssl-100250.html/

    Mes messages engagent qui je veux.

  • # 4g

    Posté par  . Évalué à 3.

    le mieux étant d'utiliser son téléphone perso pour ses affaires perso :)

    • [^] # Re: 4g

      Posté par  . Évalué à 1.

      Cela concerne aussi (surtout, à vrai dire) les communications professionnelles. Je me demande comment ce genre de pratique peuvent encore être justifiées avec le règlement sur les données personnelles (GDPR). Il s'agit bel et bien d'un traitement automatique de données, y compris (forcément) de données personnelles appartenant tant à l'employé, ou à un tiers avec lequel cet employé communique. Et pour lequel aucune autorisation n'a été accordée…

  • # Ma méthode

    Posté par  . Évalué à 7.

    Bon je ne sais pas si c'est malin d'écrire publiquement à ce sujet alors que mon employeur vend ce genre de solutions, mais il y a une technique pour bypasser cela, si tu as un serveur quelque part.

    1/ Sur ton serveur, tu installes un serveur web et un serveur ssh
    2/ tu mets en place un webmail accessible en https (avec un certificat valide, en utilisant let's encrypt par exemple)
    3/ tu installes sslh afin de pouvoir répondre à la fois en HTTPS et en SSH sur le port 443
    4/ tu demandes à ton service informatique à pouvoir accéder à ton webmail sans passer par le MITM (s'ils voient que c'est bien un webmail ils devraient accepter)
    5/ plus rien ne t'empêchera de faire un tunnel SSH sur le port 443 de ton serveur !

    Si un de tes paquets TCP était capturé ou tué, je nierai avoir eu connaissance de tes agissements.

    Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

    • [^] # Re: Ma méthode

      Posté par  (site web personnel) . Évalué à 10.

      Je crois qu'en analysant le trafic on peut détecter l'utilisation de sslh. (le traffic ssh n'est pas le même qu'https). Je propose une autre solution, qui nécessite un peu plus de configuration, mais permet d'être complètement invisible : faire passer le traffic ssh dans une connexion https standard (Si tu n'as pas peur d'encapsuler les couches, et que tu as validé l'étape 4)

      Configuration apache

      Tu crée une conf apache qui ressemble à ça :

      <VirtualHost *:443>
        Use ssl_conf
        SSLCertificateFile /etc/letsencrypt/live/....pem
        SSLCertificateKeyFile /etc/letsencrypt/live/....pem

        ServerName localhost

        DocumentRoot /var/www

        ProxyRequests On
        AllowConnect 22

        <Proxy *>
            Order deny,allow
            Deny from all
        </Proxy>

        <Proxy mydest>
            Order deny,allow
            #Deny from all
            Allow from "IP de l'entreprise"
        </Proxy>

</VirtualHost>

      Cette conf permettre d'ouvrir une connexion sur le port 22 (ssh), seulement pour une seule destination, et en provenance des ips autorisées.

      configuration ssh

      Ensuite, installe proxytunnel (par exemple) et mets dans ta conf ssh :

      Host mydest
    ProxyCommand  proxytunnel -X -p proxy_interne_de_lentreprise:8080 -r webmail.domain.tld:443 -d mydest:22 -H 'Host: webmail.domain.tld:443' -H 'User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0'

      Cette commande va utiliser les relais proxy que tu souhaites (proxytunnel peut en prendre en charge deux ce qui est bien utile), et ajouter des headers à la connexion https qui vont faire croire qu'il s'agit d'une requête venant d'un navigateur.

      Tests

      Super important avant de prendre la confiance !

      Tu installes wireshark, et tu compares le traffic de ton navigateur allant consulter son webmail, et ta connexion ssh.

      Ensuite, tu fais un script qui récupère le certificat https de ton webmail, et lève une alerte dès que la signature change (je ressors ça de mon grenier, si ça se trouve le script ne fonctionne plus comme il faut, à tester)

      #!/bin/bash

if [[ ! -z $https_proxy ]]; then
    proxy=`echo ${https_proxy} | sed -e 's|http://||' -`
    host=$(echo ${proxy} | cut -d: -f 1)
    port=$(echo ${proxy} | cut -d: -f 2)
    echo using proxy : ${host}:${port}
    #socat  TCP4-LISTEN:2022 "PROXY:${proxy} |TCP:$1" & echo -n | openssl s_client -connect localhost:2022  | openssl x509 -noout -sha1 -fingerprint
    socat TCP4-LISTEN:2022  "PROXY:${host}:$1,proxyport=${port}" &  echo -n | openssl s_client -connect localhost:2022  | openssl x509 -noout -sha1 -fingerprint
else
    echo -n | openssl s_client -connect $1  | openssl x509 -noout -sha1 -fingerprint
fi

    • [^] # Re: Ma méthode

      Posté par  . Évalué à 1. Dernière modification le 24 juillet 2018 à 21:47.

      Ça fonctionne pas avec du DPI (Deep Packet Inspection).

      • [^] # Re: Ma méthode

        Posté par  . Évalué à 2.

        Je ne sais pas quelle techno est en question ici, mais au moins chez McCafee la whitelist outrepasse le DPI.

        Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

        • [^] # Re: Ma méthode

          Posté par  . Évalué à 3.

          Souvent dans ces machins, t'as plusieurs niveaux de whitelist, avec des effets de bords en fonctions de whitelist. Essayé et détesté avec un manteau bleu.

    • [^] # Re: Ma méthode

      Posté par  . Évalué à 6.

      J'ai déjà mis en place une telle solution qui fonctionne assez bien. Le seul point délicat est l'étape 4, ils peuvent tout aussi bien te répondre que ce n'est pas possible, pas autorisé, que tu n'as pas a consulter tes mails perso au boulot, etc.

      Je l'avais joué un peu pus fine en mettant une en place une page avec une iframe d'un blog technique et en tant que dev demandé l'ouverture de ce site pour une consultation professionnel.

  • # MITM au Ministère de l'Intérieur

    Posté par  . Évalué à 5. Dernière modification le 25 juillet 2018 à 07:58.

    Au ministère de l'Intérieur, ils déchiffrent les flux HTTPS à la volée sur les postes de travail, probablement avec un proxy et une/des certificats ajoutés dans le Mozilla Firefox maison. Ce qui est gênant, c'est qu'ils n'informent pas clairement le personnel de cela et il y a plein de personnes qui se connectent à leur compte bancaire, Amelie etc.

Suivre le flux des commentaires

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