Journal Des trusted proxies dans HTTP/2.0

Posté par . Licence CC by-sa
32
25
fév.
2014

Ericsson et AT&T travaillent avec zèle au développement d'un web meilleur, d'un web plus sûr, d'un web avec des "proxies de confiance" capables de désencapsuler le trafic de connexions HTTPS des clients qu'ils servent. Les mauvaises langues qualifient déjà leur dernier draft commun de proposition dangereuse pour l'introduction de man-in-the-middle dans HTTP/2.0, mais ce sont de mauvaises langues… Les auteurs ont d'ailleurs consacré une section entière du document (section 7) aux problèmes soulevés en terme de vie privée.

https://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01

  • # De la section 7

    Posté par . Évalué à 10.

    Elle est, je trouve, on ne peut plus pertinente…

    • [^] # Re: De la section 7

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

      j'apprécie cette sobriété…

      If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

    • [^] # Re: De la section 7

      Posté par . Évalué à 10.

      En effet, clair et concis, elle ne laisse pas de place au doute et met tout le monde d'accord.

    • [^] # Re: De la section 7

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

      Au final c'est sur les trusted proxies ou les claviers qui blo

    • [^] # Re: De la section 7

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

      Elle est, je trouve, on ne peut plus pertinente…

      Personnellement, j'aurais ajouté un point d'exclamation à la dernière phrase, afin de mieux appuyer les propos de l'auteur.

  • # Un lien

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

    La réaction d'un consultant de chez Google :
    No, I Don't Trust You!—One of the Most Alarming Internet Proposals I've Ever Seen

    blog.rom1v.com

    • [^] # Re: Un lien

      Posté par . Évalué à 1.

      Merci pour le lien, ça répond en grande partie à mon commentaire suivant…

      • [^] # Re: Un lien

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

        En plus, ils s'y connaissent en non-respect de la vie privée chez Google :D

    • [^] # Re: Un lien

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

      Profiter de la Saint Valentin réputée occupant tous les geeks normatisants pour lancer un plan de domination du monde par les proxies, c'est moche.

    • [^] # Re: Un lien

      Posté par . Évalué à 10.

      En même temps, dès qu'il y a « trusted™ » dans le nom, je me méfie d'emblée.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Un lien

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

        Lorsque tu prendras de l'âge tu diras :

        En même temps , dès qu'il y a « trusted™ » dans le nom, je me méfie d'emblée.

  • # "trusted proxies" et décrytage pour M. Lambda

    Posté par . Évalué à 3.

    C'est de la novlangue, ou bien ?

    Je suis personnellement assez limité pour analyser moi-même des docs techniques relatives à l'ingénierie logicielle. Mon capteur à cynisme a toutefois bippé à la lecture de ce journal.

    J'ai du mal à l'étendue de la zone couverte par l'humour pince sans rire. Y aurait-il une bonne âme pour une explication ?

    • [^] # Re: "trusted proxies" et décrytage pour M. Lambda

      Posté par . Évalué à 2.

      Meme une totale absence de competence technique permet de comprendre pleinement la-dite section sept. Il suffit de la… heu… lire.

      • [^] # Re: "trusted proxies" et décrytage pour M. Lambda

        Posté par . Évalué à 1.

        J'ai bien « lu » la section 7. Mais une telle section « confidentialité » dans des spécifications d'un protocole que je n'utiliserai pas, ou qui serait utilisé uniquement pour des données publiques, je m'en care.

        Si j'ai bien compris le lien du commentaire précédent, il s'agit de proposition de spécifications pour permettre la mise en cache de données chiffrées par les intermédiaires, pour avoir un gain de performances réseau en réutilisant des données populaires pour plusieurs utilisateurs. Cela implique que l'intermédiaire puisse avoir des privilèges pour déchiffrer le contenu, identifier les parties « statiques ». C'est en soi incompatible avec le chiffrement « de bout en bout ».

        Pour comprendre en quoi la section 7 est importante, il faut comprendre le cadre du document et les applications qui en sont faites.

        • [^] # Re: "trusted proxies" et décrytage pour M. Lambda

          Posté par . Évalué à 10.

          L'idée est effectivement de permettre aux proxys de casser la sécurité de bout en bout d'une connexion HTTPS. Certains proxys permettent déjà de faire ce genre de choses, en affichant un faux certificat (qu'on peut faire avaler par les clients si on a le contrôle sur eux). En clair, c'est une attaque d'homme du milieu sur SSL, que ce draft se propose de standardiser et d'améliorer.

          Une fois ce flux déchiffré, on fait évidemment ce qu'on veut. On peut mettre en avant la mise en cache des données, mais il ne faut pas rêver, ça va surtout permettre :

          • De lire les communications théoriquement confidentielles ;
          • De mettre en place de techniques de filtrages basées sur des mots clefs et autre joyeusetés ;
          • Empêcher de contourner les proxys comme peuvent le faire des outils comme SSH via la commande CONNECT (cette dernière raison est citée dans l'introduction du document).

          Ou seront utilisés ces proxys ? Probablement en entreprises (certaines le font déjà), certainement dans de nombreux portails captifs, peut-être en bout de réseaux mobiles.

          À noter que dans les spécifications, ils sont trop sympa et fournissent une méthode pour refuser le déchiffrement. J'ai tendance à penser que c'est juste pour faire passer la pilule, si quelqu'un met en place un tel proxy, c'est certainement pas pour autoriser les utilisateurs à contourner la règle…

  • # En fait, pourquoi pas.

    Posté par . Évalué à -3.

    Ça permettrait de reconnaitre facilement les (un)trusted servers.
    De toute façon, je lance toujours mes logiciels avec "--consider-trusted-as-untrusted", donc je m'en fous.

    Par contre, flemme de lire ce genre de document dans son intégralité, quelqu'un sait comment se passe la mise en place technique de leur trusted MITM ?

    • [^] # Re: En fait, pourquoi pas.

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

      comment se passe la mise en place technique de leur trusted MITM ?

      Tu devrais plutôt te poser la question suivante :
      - « quoi de sérieux/utile/correct/honnête/respectueux peu bien servir ce truc ? »

      Si tu arrives à trouver une réponse qui tient debout, alors ok on pourra se pencher sur la mise en œuvre.

      • [^] # Re: En fait, pourquoi pas.

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

        Un cas d'utilisation possible, c'est pour utiliser les système de compression qu'on peut trouver dans Chrome ou Opera mais hébergé sur mon serveur.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: En fait, pourquoi pas.

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

          Il avait demandé quelque chose de sérieux/utile/correct/honnête/respectueux…

          blog.rom1v.com

          • [^] # Re: En fait, pourquoi pas.

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

            Explique moi en quoi un service hébergé sur mon serveur uniquement pour mon smartphone uniquement n'est pas honnête /respectueux/utile…

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: En fait, pourquoi pas.

              Posté par . Évalué à 4.

              Explique moi en quoi un service hébergé sur TON serveur uniquement pour TON smartphone à besoin de cette daube de "Trusted" Proxy …

              • [^] # Re: En fait, pourquoi pas.

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

                Parce que son service est HTTP1.1 pour le moment, et qu'il est peut-être plus simple d'avoir un reverse proxy HTTP2<->HTTP1.1 générique pour faire l'interface. Dans ce cas, s'il fait tourner ce proxy chez lui, le certificat qui l’intéresse est celui du proxy et plus celui du serveur.

                • [^] # Re: En fait, pourquoi pas.

                  Posté par . Évalué à 4.

                  S'il y a un reverse proxy le serveur n'a pas besoin d'être en HTTPS, il peut être accédé en clair par le proxy. Donc pas besoin de MITM…

        • [^] # Re: En fait, pourquoi pas.

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

          Qu'est ce qui t'empeche de le faire actuellement en installant une autorité de confiance sur ton smartphone ?

          • [^] # Re: En fait, pourquoi pas.

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

            Le fait que ce soit crade, là, on a justement un standard qui permet de faire ça proprement et de manière sécurisé.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: En fait, pourquoi pas.

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

        La raison officielle a du sens: pouvoir dedupliquer le contenu pour les clients qui accèdent aux mêmes ressources derrière le proxy. Ça ne me choquerait pas qu'un proxy d'entreprise fasse ça, par exemple.

        • [^] # Re: En fait, pourquoi pas.

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

          C'est utile si dans un réseau, plusieurs personnes utilisent Facebook par exemple.

          Comme les connexion sont faites avec SSL/TLS, en utilisant un proxy qui permettrait d'analyser le flux en clair, il y aura une grande économie en bande passante puisque beaucoup de contenu pourra être mis en cache, tel que le javascript, des images, et les pubs.

          C'est pareil pour Google+.

          Évidement, c'est pas sympa pour l'utilisateur final, qui aura une meilleurs expérience utilisateur mais plus du tout de confidentialité (quoique, sur les réseaux sociaux…)

          A+

          • [^] # Re: En fait, pourquoi pas.

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

            Comme les connexion sont faites avec SSL/TLS, en utilisant un proxy qui permettrait d'analyser le flux en clair, il y aura une grande économie en bande passante puisque beaucoup de contenu pourra être mis en cache, tel que le javascript, des images, et les pubs.

            Comment pour un développeur : ne jamais chercher à optimiser sans avoir au préalable mesuré.
            Lorsqu'on mesure, on se rend souvent compte que le coût du proxy est plus élevé (achat, gestion, etc) que l'ajout d'une bête seconde ligne ADSL avec un routeur à 60 € qui s'occupe de tout.

            Ceci dit, pourquoi pas sur de gros réseaux. Réseaux d'entreprise ou de collectivités. Pas des trucs en accès public.

            Maintenant que ça entre dans les esprits qu'il faut utiliser des connexions chiffrées… bam !
            C'est pour votre bien m'sieurs dames.

            • [^] # Re: En fait, pourquoi pas.

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

              Installer un proxy, c'est rapide, et on n'a plus vraiment besoin de s'en occuper, sauf aux mises à jours de sécu et un peu de monitoring.

              Une autre ligne ADSL, c'est tout de suite différent, bien que le coût soit déductible des bénéfices.

  • # Un autre point de vue

    Posté par . Évalué à -4.

    Ok, imaginez la situation fictive suivante : vous êtes RSSI d'une grosse entité gouvernementale, ou d'une grosse entreprise sensible française avec des enjeux économiques à l'étranger. Plusieurs fois par an, t'as des grosses intrusions sur tes postes de travail, avec des 0-days bien velues et référencées nulle part. T'as des utilisateurs qui vont sur gmail, et socialement c'est pas possible de les bloquer.

    Alors bon voilà, t'aimerais bien détecter les documents qui fuitent, mais les exploits installés sur tes postes de travail communiquent en HTTPS avec les serveurs de control&command situés au Kazakhstan en HTTPS, du coup, tu peux pas faire d'analyse de fuites à la volée. T'aimerais bien faire de la détection anti-malware à la volée, seulement voilà, les malwares sont distribués par des sites en .gouv.zog.zog compromis, avec du HTTPS. T'aimerais bien autoriser tes utilisateurs à faire des recherches google, et bloquer gmail, seulement voilà, maintenant les services google sont en HTTPS, du coup tu peux pas faire de filtrage a priori des URLs google, parce que la partie non-domaine de l'URL est chiffrée.

    Du coup tu fais quoi ? Ben tu montes un proxy MITM pour analyser le trafic web de tes utilisateurs, avec ton matos NetDemanQ. Alors oué, ça créée plein de problèmes avec les syndicats du coin, avec la CNIL, avec ta grand mère, avec ta conscience. Mais en même temps, t'as vraiment le choix ?

    Alors y'a des gars qui proposent d'encadrer ça par une norme internationale, pour que ça arrête d'être le foutraque-live-bordel-anarchique. Ben t'es plutôt favorable, ça limite le bouzin généralisé hors de contrôle.

    Toute ressemblance avec un cas réel serait purement fortuite.

    • [^] # Re: Un autre point de vue

      Posté par . Évalué à 9.

      Sinon tu éduque les employés, chiffre les documents sensibles et coupe fesseDeBouc, Google et autres grosse boite américaine à la botte de la NSA. La plus grosse faille en informatique se situe toujours entre la chaise et le clavier, tu pourras mettre toutes les protections du monde en place un utilisateur étourdi/malintentionné/drogué du clic arrivera a passer outre.

    • [^] # Re: Un autre point de vue

      Posté par . Évalué à 7. Dernière modification le 26/02/14 à 09:25.

      +1 j'ai bossé pendant dans une boite où il y avait une whitelist pour le péon de base (il me semble que Linuxfr était dans la whitelist). Tout autre utilisation du web nécessitait une autorisation valable 1 jour sur 1 poste pour 1 utilisateur (mode "hardcore paranoid").

      Là tu comprends l'utilité du man, j'ai passé plus de temps à explorer des nouvelles fonctions trouvées dans les man, et à rendre visite au cadors locaux de perl, de tcl, de vim. Et là tu comprends qu'il est impossible d'empêcher les gens de « perdre du temps ». La motivation et l'investissement du personnel ça se gère avec du management, et pas le management par les coups de fouet ;)

      Ensuite le top management se plaignait qu'on ne savait pas ce que faisait la concurrence… quoi d'autre lorsqu'on est coupé du monde ?

    • [^] # Re: Un autre point de vue

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

      Ok, imaginez la situation fictive suivante : vous êtes RSSI d'une grosse entité gouvernementale

      En fait les situations réelles dans lesquelle on trouve des MITM sont nombreuses. On peut toujours crier au loup mais :

      • Les proxy de sécurité des entreprises
      • Les proxys de controle légal des points d'accès publiques
      • Les système de contrôle parental des FAI
      • Les accélérateurs pour les liaisons satellite, rurales, mobiles
      • Les CDN et protections antidos de tout poil en font déjà.

      et sans doute beaucoup d'autres cas … font du MITM à gogo. Associé à de la réécriture d'url, le https, ne pose aucun problème.

      Ce draft vise à fournir pour les fournisseurs de ce genre de solution un moyen d'avertir l'utilisateur, qu'il est derrière un proxy. Du coup l'affaire ne me parait pas aussi simple. S'agit-il de légitimer une pratique plus que discutable ou de mettre un peu d'ordre dans l'existant ?

      • [^] # Re: Un autre point de vue

        Posté par . Évalué à 5.

        Ce draft vise à fournir pour les fournisseurs de ce genre de solution un moyen d'avertir l'utilisateur, qu'il est derrière un proxy

        Pourquoi pas. Reprenons les exemples que tu cites.

        Les proxy de sécurité des entreprises

        L'utilisateur peut être averti par la charte informatique de son entreprise (ou tout autre truc similaire, quelque soit son nom.)

        Les proxys de controle légal des points d'accès publiques

        L'utilisateur est bien averti par les nombreuses erreurs de certificat que ça génère. C'est d'ailleurs bien le but.

        Les système de contrôle parental des FAI

        Les parents peuvent être avertis par le FAI, dans le contrat, dans le mode d'emploi. Les enfants par leurs parents.

        Les accélérateurs pour les liaisons satellite, rurales, mobiles

        Idem, le FAI se doit d'avertir l'utilisateur de ce qu'il fait. Ce serait même pas mal qu'il lui explique avant de lui vendre l'abonnement.

        Les CDN et protections antidos de tout poil en font déjà

        Là c'est effectivement plus compliqué. Ça devrait être au site de t'avertir que ce que tu lui communiques est partagé avec une tierce personne.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Suivre le flux des commentaires

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