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 aiolos . Évalué à 10.
Elle est, je trouve, on ne peut plus pertinente…
[^] # Re: De la section 7
Posté par palm123 (site web personnel) . Évalué à 10.
j'apprécie cette sobriété…
ウィズコロナ
[^] # Re: De la section 7
Posté par dantes94 . É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 Benoît Sibaud (site web personnel) . Évalué à 7.
Au final c'est sur les trusted proxies ou les claviers qui blo
[^] # Re: De la section 7
Posté par Atem18 (site web personnel) . Évalué à 4.
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 ®om (site web personnel) . É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 bobo38 . Évalué à 1.
Merci pour le lien, ça répond en grande partie à mon commentaire suivant…
[^] # Re: Un lien
Posté par zul (site web personnel) . Évalué à 9.
En plus, ils s'y connaissent en non-respect de la vie privée chez Google :D
[^] # Re: Un lien
Posté par Benoît Sibaud (site web personnel) . É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 zebra3 . É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 Kerro . Évalué à 10.
Lorsque tu prendras de l'âge tu diras :
# "trusted proxies" et décrytage pour M. Lambda
Posté par bobo38 . É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 Parleur . É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 bobo38 . É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 Florent Fourcot . É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 :
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 Elfir3 . É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 Kerro . Évalué à 4.
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 claudex . É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 ®om (site web personnel) . É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 claudex . É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 Crazy Diver . É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 rakoo (site web personnel) . É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 Antoine . É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 Juke (site web personnel) . É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 claudex . É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 rakoo (site web personnel) . É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 GG (site web personnel) . É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+
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: En fait, pourquoi pas.
Posté par Kerro . Évalué à 4.
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 GG (site web personnel) . É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.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# Un autre point de vue
Posté par zogzogzogzogzogzog . É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 Mimoza . É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 bobo38 . Évalué à 7. Dernière modification le 26 février 2014 à 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 Joris Dedieu (site web personnel) . Évalué à 2.
En fait les situations réelles dans lesquelle on trouve des MITM sont nombreuses. On peut toujours crier au loup mais :
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 2PetitsVerres . Évalué à 5.
Pourquoi pas. Reprenons les exemples que tu cites.
L'utilisateur peut être averti par la charte informatique de son entreprise (ou tout autre truc similaire, quelque soit son nom.)
L'utilisateur est bien averti par les nombreuses erreurs de certificat que ça génère. C'est d'ailleurs bien le but.
Les parents peuvent être avertis par le FAI, dans le contrat, dans le mode d'emploi. Les enfants par leurs parents.
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.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.