La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G SFR / RED => 
5G/4G SFR => Discussion démarrée par: benoit75015 le 16 mars 2013 à 13:31:17
-
Un article de Pierre Col sur la neutralité du net selon SFR...
Comment SFR viole délibérèment la neutralité du Net, et pourquoi c'est grave
Probablement pour diminuer le trafic sur son réseau 3G, SFR s'est arrogé le droit de modifier arbitrairement les pages HTML et même les images des sites web que visitent ses abonnés connectés en 3G. Effectuée à leur insu, cette manipulation est une violation caractérisée de la neutralité du Net qui peut avoir des conséquences graves dans le cadre d'une utilisation professionnelle de l'Internet mobile.
C'est le blogueur Olivier Laurelli, alias Bluetouff, qui a sorti l'information hier soir sur le site Reflets.info (http://reflets.info/sfr-modifie-le-source-html-des-pages-que-vous-visitez-en-3g/) : alors qu'il visitait un site web syrien en passant par une connexion Internet en 3G fournie par l'opérateur mobile SFR, il a eu la très grande surprise, en examinant le code source d'une page HTML, d'y découvrir des éléments qui n'y figuraient certainement pas à l'origine et avaient donc été insérés dans la page par l'opérateur filiale de Vivendi.
Code source de la page web en 3G SFR :
(https://lafibre.info/images/3g/201303_code_source_via_sfr.png)
Source Reflets.info
Code source de la page web via « le vrai Internet » :
(https://lafibre.info/images/3g/201303_code_source_via_internet.png)
Source Reflets.info
Pire encore, certains internautes avaient déjà découvert que le proxy transparent mis en place par SFR pour les connexions Internet mobiles modifiait également les images des sites web, leur appliquant des algorithmes de compression qui en diminuent le volume… quitte à altérer leur aspect. Vous pouvez le constater très clairement sur cette image, et en savoir plus en lisant ce billet de blog publié en 2011 par Pierre Dandumont ou celui-ci par Vincent Bernat.
(https://lafibre.info/images/3g/201303_images_via_sfr.png)
Source Pierre Dandumont
Pour avoir travaillé de 1997 à 2006 chez Jet Multimédia, qui développait et hébergeait des applications mobiles, je sais que le développement de l'Internet mobile, à l'époque du WAP et de la 2G puis du Edge, avait amené les opérateurs à mettre en place des proxy transparent qui appliquaient des modifications sur les pages HTML des sites visités, pour alléger le trafic sur leur réseau. J'imaginais, naïvement, que cela n'avait plus cours à l'époque de l'Internet mobile à haut débit.
Il s'avère donc que cette pratique perdure alors qu'elle ne se justifie plus vraiment d'un point de vue technique compte tenu des débits désormais disponibles en 3G ou 4G... Mais il est clair que le tripatouillage de code HTML et d'images permet d'optimiser encore l'utilisation du réseau, et donc le compte de résultats de l'opérateur mobile qui choisit de déployer de tels artifices plutôt que d'investir dans des capacités réseau supplèmentaires.
SFR s'était déjà fait prendre les doigts dans le pot de confiture il y a quelques années, lors de la mise en place de « DNS menteurs » qui interceptaient les erreurs de saisie d'URL de ses clients.
On se trouve donc là face à une violation caractérisée de la neutralité du Net, effectuée par SFR à l'insu de ses abonnés : si vous êtes abonné SFR, l'Internet que vous utilisez en 3G n'est pas le même que celui que vous utilisez depuis votre connexion ADSL ou fibre !
Imaginons maintenant, dans un contexte professionnel, le cas d'un infographiste freelance qui met les travaux de création graphique qui lui ont été commandés à disposition de ses clients via un site web. Imaginons ensuite que un de ses clients, en déplacement, télécharge l'image dont il a besoin depuis une connexion 3G SFR : il va récupérer une image de piètre qualité et pourra croire, de bonne foi, que l'infographiste a fait un mauvais travail !
Tant qu'on y est, on peut aussi imaginer qu'un FAI décide de réencoder à la volée les fichiers MP3 transitant sur son réseau, transformant des fichiers de bonne qualité, encodés en stéréo à 256 kb/s, en fichiers encodés en mono à 64 kb/s... Pourquoi ne pas aussi trafiquer les flux vidéo, ou les fichiers PDF ?!?
L'Internet 3G et maintenant 4G étant désormais massivement utilisé, tant en usage personnel qu'en usage professionnel, de telles pratiques sont à mes yeux totalement inadmissibles. Je considère que la non-altération par le FAI du code des pages web, des images diffusées sur le web ou de tout autre élèment reçu par un utilisateur doit être la règle par défaut. L'opérateur peut éventuellement proposer à ses clients un service optionnel d'optimisation de son trafic réseau, mais en ce cas il faut que le client sache exactement quels seront les traitements appliqués – optimisation du code HTML des pages, modification du codage des images, des vidéos, des sons - et que le client demande explicitement à bénéficier d'un tel service, forcèment optionnel.
Pour moi, c'est la cupidité des opérateurs les amène à agir ainsi, et la seul façon de protéger les internautes de tels agissements est de protéger la neutralité des réseaux par une loi qui prévoie de lourdes sanctions en cas d'infraction. C'est d'ailleurs ce qu'a récemment proposé le Conseil National du Numérique.
Qu'en pensez-vous ? Que va en penser l'ARCEP ? Qu'en est-il chez les autres opérateurs mobiles ?
Si vous êtes abonné 3G ou 4G chez Orange, Bouygues Telecom ou Free, pouvez-vous examiner les pages HTML que vous recevez et nous dire ici ce qu'il en est ?
Affaire à suivre...
Source : Pierre Col / ZD Net (http://www.zdnet.fr/actualites/comment-sfr-viole-deliberement-la-neutralite-du-net-et-pourquoi-c-est-grave-39788294.htm)
-
Bon en 3G, tous les opérateurs Français sont dans le même lot pour le respects de la neutralité du net. Le pon pon, c'est quand même Free en itinérance Orange.
Pourtant les offres neutre offrant un véritable accès à Internet existent. C'est dommage de ne pas les commercialiser que pour les pro.
Je verrais bien une option 5€/mois pour avoir un internet parfaitement neutre et une IPv4 publique + une plage d'IPv6.
J'ai mis des fichiers sur https://testdebit.info/neutralite.html (https://testdebit.info/neutralite.html) il suffit de regarder la taille : si ce n'est pas celle annoncée, il y a eu compression. Les fichiers les plus faciles a compresser, ce sont les images jpeg.
-
Ouais je sais pas pourquoi tout le monde s'excite maintenant alors que ca fait longtemps qu'ils font ca.
-
C'est dommageable sur le fond, et il faudrait que cette pratique disparaisse, mais sur la forme ce ne sont pas les abonnes qui iront se plaindre de la 3G de SFR.
C'est bien de le relever, de le savoir, mais de la a crier au scandale telecom. Je n'arrive à être plus choqué que ça même si je condamne l'opacite du mécanisme
-
C'est bien de le relever, de le savoir, mais de la a crier au scandale telecom. Je n'arrive à être plus choqué que ça même si je condamne l'opacite du mécanisme
C'est un problème de société de plus en plus répandu. Plus rien ne nous choque. Donc ces pratiques ne disparaissent pas. Et le problème de ne plus être choqué et de ne rien dire amène à une privation de liberté de plus en plus grande !!
-
Je pense que ça serait acceptable si les opérateurs communiquaient sur ce qu'ils font, et si c'était une option qui était désactivable facilement par l'utilisateur final. Parce que ça peut rendre service à certains : alléger les pages web. Mais ça déplait à beaucoup de gens.
Leon.
-
Si un opérateur impose la transformation des pages Web, il ne devrait pouvoir appeler son offre "Internet mobile" mais "simili accès au Web"!
-
En effet le problème est toujours la non information. Si cela était connu et affiché pas de problème, la concurrence permettrait de s'en affranchir.
-
Oui, si il y a une véritable concurrence.
Sur les secteurs avec un "ticket d'entrée" très important, ce n'est pas toujours le cas...
-
Malheureusement, les services marketing ne comprennent pas l’intérêt d'un accès neutre à Internet et ils entendent les discourt des vendeurs de plate-forme de compression qui expliquent que la compression améliore le ressenti du client (et c'est vrai en EDGE).
Perso, je travaille beaucoup avec une clé 3G (là encore ce dimanche matin, je suis dans le train pour aller voire ma grand-mère) et cela m’embêterais d'avoir une compression des images.
-
C'est marrant ça : à l'époque où j'ai connecté pour la première de ma vie un modem au nain ternet (un 14400, quelle émotion, je m'étais dit "par ce simple câble téléphonique je suis connecté au monde entier"), PERSONNE en France ne parlait de proxy HTTP qui recompressent, alors que les proxy HTTP étaient assez courants : on parlait uniquement de proxy cache (notamment Squid).
Aujourd'hui on parle de HAUT débit mobile, de "clé 3G" (donc clairement dans le but d'accéder au net sur un PC et pas sur un minuscule écran de mobile)... so WTF?
-
Les ressources CPU nécessaires pour compresser en temps réel des centaines Mb/s de flux avec des images sont assez conséquentes.
C'est l'évolution des microprocesseurs qui rend la chose abordable.
-
Les ressources CPU nécessaires pour compresser en temps réel des centaines Mb/s de flux avec des images sont assez conséquentes.
C'est l'évolution des microprocesseurs qui rend la chose abordable.
Quand je me connectais en 14400 bits/s (débit théorique que je n'atteignais quasiment jamais à cause des très nombreuses pertes de paquets, quand je téléchargeais à 500 o/s j'étais content), il n'y avait pas "des centaines Mb/s de flux avec des images" chez un FAI grand public : tout le monde ne télécharge pas des pages HTTP en même temps (on ne parle pas de télécharger de gros fichiers archives, ceux là n'ont pas à être modifiés par le proxy). Si on inclut un facteur d'utilisation réel de 10 % de la ligne avec le HTTP, ce qui est déjà beaucoup, cela représenterait de l'ordre de 1 M connexions téléphoniques simultanées, je suis certain qu'aucun FAI n'avait 1 M lignes de téléphone!
Et je pense que tu te trompes concernant l'évolution des processeurs, c'est plutôt l'inverse : à l'époque le CPU n'était JAMAIS l'élèment ralentissant le PC accédant au Web, maintenant il l'est SOUVENT quand on surf en haut débit! (Je ne parle pas de télécharger et sauvegarder de gros fichiers, je ne parle pas de très haut débit.)
Les processeurs ont donc beaucoup régressé pour assurer l'accès au net!
-
Je confirme les propos de Vivien.
A l'époque, il y a 15 ans, juste faire tourner un proxy cache (seulement cache), pour plusieurs centaines d'utilisateurs, ça nécessitait déjà un serveur à la hauteur. Il n'était pas envisageable de triturer les images à la volée.
Les solutions permettant de redimensionner en live des images, pour des milliers d'abonnés, c'est beaucoup plus récent.
Je crois que tu te trompes concernant l'évolution des processeurs. En fait c'est exactement l'inverse : à l'époque le CPU n'était JAMAIS l'élèment ralentissant le PC accédant au Web, maintenant il l'est SOUVENT!
Pas d'accord avec ça. Le web sur win3.1 avec un pentium 1, c'était souvent limité par les capacités du PC, même avec un modem n'offrant que 33kb/s. La page s'affichait quelques fois plusieurs secondes après la fin de son chargement. Les GIF animées avaient parfois du mal à s'animer correctement, etc...
Leon.
-
Il est encore d'actualité le proxy pour les images là (c'est une histoire qui date de quelques temps) ? Quand je surf sur mon mobile ou en thethering je n'ai pas l'impression mais bon je n'ai pas vérifié. Je le ferai surement tout à l'heure.
Sinon je lisais que changer l'APN (pour sl2sfr ?) permettait de désactiver tout ça. Quoi qu'il en soit ce n'est pas normal de l'activer ainsi et de ne pas documenter la façon de l'enlever.
-
Je profite donc d'être dans le TGV pour tester ça. Avec un APN sl2sfr (ou websfr si il utilise celui nommé "Option Modem") je trouve bien les 1 000 000 octets du fichier jpg (sur le page "neutralite.htm" donnée par vivien).
Et a priori pas d'IP bizarre dans le code source de cette page par exemple.
Dans les APN de mon téléphone, seul le "wapsfr" contient l'url d'un proxy dans ses caractéristiques.
-
En passant sur wapsfr, j'ai bien cette compression des images (et mon ping qui ne tourne plus). En prenant sur lafibre.info la miniatures du sujet "visite du réseau Orange" on passe de 30,4ko à 16,4ko.
Bon après cet APN porte bien son nom :).
EDIT : Ajout des fichiers jpg, par contre je n'ai toujours pas croisé d'IPs clandestins dans le code source.
-
Des infos sur le tethering et les APN sous Android sur le fascinant blog de David Madore :
http://www.madore.org/~david/weblog/2013-03.html#d.2013-03-15.2120 (http://www.madore.org/~david/weblog/2013-03.html#d.2013-03-15.2120)
-
Sur l'image donnée, pas de dégradation de l'image visible.
Il y a par contre des images qui supportent bien moins bien la compression destructive.
C'est notamment le cas du logo SFR. Quand il y a des logo SFR, je suis obligé d'augmenter la qualité de l'image ou la passer en PNG.
Il y a compression des PNG ? C'est pas facile sans être fortement destructeur sur la qualité.
(https://lafibre.info/images/altice/logo_SFR_original_2012.jpg)
-
Après Pierre Col, c'est donc au tour de Korben (https://korben.info/violer-la-neutralite-sfr-elle-sait-faire.html) d'aller un peu plus loin que le message de Bluetouff. En effet le seul APN qui - selon les constatations des gens qui ont pris le temps de tester - compresse les images (cf. mon post plus haut) est un "vieil" APN qui n'est pas vraiment activé par défaut sur les téléphones vendus (par défaut il y a sl2sfr pour le tel et websfr pour le mode modem).
Bon il est vrai que si on enlève la partie "images compressées" de leurs articles, ça fait moins sensationnaliste (course au clic ?) et surtout ça enlève l'excuse "c'est pour réduire le trafic".
Quoi qu'il en soit il y a toujours cette "injection" d'IPs en 91.68.*.* qui mérite une réponse de la part de SFR, et si quelqu'un ici a une idée de l'utilité de faire ça, je suis preneur.
-
Quoi qu'il en soit il y a toujours cette "injection" d'IPs en 91.68.*.* qui mérite une réponse de la part de SFR, et si quelqu'un ici a une idée de l'utilité de faire ça, je suis preneur.
Le but est de charger un script bmi.js qui suivant l'opérateur fait plus ou moins de chose. (https://www.google.com/search?q=bmi-int-js%2Fbmi.js&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fr:unofficial&client=firefox-a)
-
Les modifications réalisés par SFR consistes en Différentes techniques pour avoir plusieurs connexions TCP en parallèle afin de remplir plus rapidement le tuyau. Le but est uniquement d'afficher la page plus vite.
-
Beaucoup d'affolement et de paranoïa pour pas grand chose. Ces sites crient fort pour aller chercher du clic, rien de plus.
Je dirais même que le système de SFR est la pour améliorer la navigation sur mobile plus qu'autre chose et si ça peut réduire le trafic total, c'est encore mieux vu que tout les forfaits data 3G sont limités...
Je prefere un FAI qui fait ca plutot qu'un FAI qui bride le débit avec un certain site de streaming video ou bloque les pubs...la on peut vraiment parler de violation de la neutralité du Net :P
-
Je prefere un FAI qui fait ca plutot qu'un FAI qui bride le débit avec un certain site de streaming video ou bloque les pubs...la on peut vraiment parler de violation de la neutralité du Net :P
Du moment que l'ISP modifie les flux, il y a une violation de la neutralité du Net. Point final.
Et cela entraine un surcout au niveau des éditeurs de sites qui doivent défendre leurs codes des modifications de bmi.js (il y a un certain nombre de bug rapport dont la root cause est bmi.js).
Au final, le passage des gros sites en HTTPS s'expliquent mieux: ils se foutent de la confidentialité, ce qu'ils veulent c'est l’intégrité des communications !
-
Arrêtons de faire les étonnés !
Perso depuis le 1er jour SFR pratique ce genre de chose lors de leur lancement de "clé USB" en 2007...
l'arnaque était de signer 24 mois pour cet internet bien pourri que les commerciaux oublient de vous dire, sans compter les ports fermés et surtout qui saturait en heure de pointe...
leurs réseau 3G était à la ramasse sur Paris, et personne n'en faisait des articles à l'époque à l'instar de Free...
cette clé me servait de dépannage pour mon boulot (heureusement d'ailleurs !)
n'oubliez pas BT qui injectait des paquet TCP bien pourri dès les 10 Mo entamés, quand y'avait de la 3G ! car je vous rappel que BT c'était synonyme de "Edge" tellement que la 3G n'existait pas chez eux. Le mode Modem était interdit, port fermé également, Skype était bridé...
Mon iphone 3GS a été utilisé pleinement quand Free Mobile a débarqué et à libéré tous les usages possibles...
Bref, a coté Free Mobile qui bride via l'itinérance Orange ? Avec les galères des 3 gros à coté ces dernières années, j'm'en cogne grave !!!
à méditer je pense...
-
Du moment que l'ISP modifie les flux, il y a une violation de la neutralité du Net. Point final.
Et cela entraine un surcout au niveau des éditeurs de sites qui doivent défendre leurs codes des modifications de bmi.js (il y a un certain nombre de bug rapport dont la root cause est bmi.js).
Au final, le passage des gros sites en HTTPS s'expliquent mieux: ils se foutent de la confidentialité, ce qu'ils veulent c'est l’intégrité des communications !
si on va par la tout les FAI modifient les flux quand ils font du PAT (dans la box ou le réseau 3G)...
Mais faut pas être intégriste non plus. si le FAI informe et donne le choix d'opt-in ce n'est plus de la violation de la neutralité ça devient "un service" qu'offre le FAI.
C'est vers ca que devrait aller les FAI. L'ideal serait que le FAI 'proxise' les sites non optimisés pour mobile et ne touche pas ceux qui le sont. car faut l'admettre y'a 100 fois plus de sites non opti que de sites qui doivent defendre leur code des modifs de bmi.js... ca deviendrait même un argument de vente.
Quant au passage des gros sites en HTTPS c'est surtout a cause des problèmes de SEO (http referer non transmit en SSL vers un site non SSL) et de sécurité sur les réseaux Wifi publics de plus en plus utilisés.
Sur des sujets complexes comme ça, c'est rapide de dériver vers la désinformation et les amalgames.
-
- PAT = modification des en-têtes des PAQUETS TCP/UDP = modification de la charge UTILE de IP
MAIS : PAS de modification de la charge utile TCP/UDP
Je suis CONTRE ça. Mais il parait qu'il n'y a plus d'adresses IP. (On devrait avoir tous adopté IPv6 depuis plusieurs années.)
- proxy HTTP = modification de la charge utile TCP!!!
Ce n'est pas DU TOUT la même chose!!!
-
n'oubliez pas BT qui injectait des paquet TCP bien pourri dès les 10 Mo entamés, quand y'avait de la 3G !
Tu peux expliquer ce dont ils'agit, stp? Bouygtelrajoutait des paquets inutiles? Pour quoi faire?
Leon.
-
-> http://grapsus.net/blog/post/Bouygues-Telecom-filtre-malhonnetement-son-reseau-3G-et-inspecte-vos-donnees (http://grapsus.net/blog/post/Bouygues-Telecom-filtre-malhonnetement-son-reseau-3G-et-inspecte-vos-donnees)
Après faudrait voir si c'est toujours d'actualité
Du moment que l'ISP modifie les flux, il y a une violation de la neutralité du Net. Point final.
Ce serait aussi simple si chacun n'avait pas sa définition propre de la NN...
(je ne dis pas que la tienne est mauvaise, juste qu'on entends de tout en ce moment)
-
Je vais expliquer la problématique de la coupure TCP au-delà de 10 Mo téléchargé sur la même connexion TCP.
Il y a quelques années (3ans je dirais) Bouygues Telecom vendait des forfaits mobile avec 500 Mo de data, débit réduit au-delà du far-use. Pour les clé 3G, on était à 1 Go débit réduit au-delà.
Ça c'est le contrat. En réalité, de nombreux clients l'avait noté : il n'y avais pas de limitation de débit au-delà du fare-use. De nombreux client utilisait plus de 10 Go par mois sans problème. Il n'y avait pas non plus de blocage du mode modem.
Pour "protéger" le réseau, des limitations à 10 Mo (la taille différait selon le type d'abonnement) par connexion TCP avait été mis en place.
J'ai remonté les plaintes des clients concernant ces limitations par connexion TCP qui empêchaient de télécharger de gros fichiers. Bouygues Telecom était effectivement en faute car cette limitation n’étais présente nul part dans les CGV. Le fare-use lui étant prévu dans les CGV, il a été mis en place et la limitation par connexion TCP a été levée.
A noter que les modems Android vendu par Bouygues Telecom ont tous les modem modem activable simplement et sans blocage au niveau réseau. Ce n'est pas la même choses chez nos concurrents.
Il y avait également des limitations vers Skype qui ont été levées.
Boris.
-
c'est clair que tant que tout le monde n'est pas d'accord sur une définition commune de la neutralité du Net ça en restera a des conjectures et amalgames.
c'est a qui de la definir ? l'ARCEP ou quelque chose de plus 'mondial' ? genre l'ITU ou l'IETF ? ou alors les législateurs de chaque pays ?
la NN doit elle n’être qu'un avis ou une obligation légale des opérateurs ?
doit-elle être interprétée stricto sensus ou pas ? on sait tous que pour les lois y'a l'esprit et la lettre.
si on prend un definition de wikipedia:
Transmission des données par les opérateurs sans en examiner le contenu ;
Transmission des données sans prise en compte de la source ou de la destination des données ;
Transmission des données sans privilégier un protocole de communication ;
Transmission des données sans en altérer le contenu.
si je compresse des images pour accelerer le débit sans que cela soit visible par l'utilisateur (pas au pixel pres mais visuellement sur un écran de téléphone) est-ce que j’altère le contenu ? techniquement oui mais en pratique pas vraiment (parce la tout revient a l’interprétation du mot 'contenu'). Par contre dans ce cas je privilégie un contenu mais pas un protocole donc je ne viol pas la 3eme regle non plus. mais je viol la 2eme règle car je prend en compte la destination (réseau mobile). De meme pour "examiner le contenu", ca ne va pas être la même chose si c'est par des humains ou par des dispositifs automatiques a des fins de routage ou de fluidité du trafic.
bref ca n'a rien de simple et de dogmatique. D'ailleurs même dans wikipedia il y a 2 définitions cote a cote qui ne sont pas équivalentes (les 4 regles (https://fr.wikipedia.org/wiki/Neutralit%C3%A9_du_r%C3%A9seau#D.C3.A9finition) ci dessus et l'image (http://upload.wikimedia.org/wikipedia/commons/thumb/6/67/Neutralit%C3%A9_du_Net.svg/500px-Neutralit%C3%A9_du_Net.svg.png)). si on prend la proposition de loi (http://www.assemblee-nationale.fr/14/propositions/pion0190.asp), la définition est encore differente.
-
Des humains?
Tu veux dire qu'il y a des indiens/chinois qui analysent chaque paquet?!!
-
Comme toujours il suffirait de communiquer pour que cela soit accepter ou non.
" Dans un souci de confort et d'amélioration de votre ressenti de la navigation par internet sur notre réseau, nous vous indiquons que les images peuvent être compressées sans que le rendu à votre écran ne soit perceptible. Aucune information n'est enlevée ou ajoutée."
C'est simple non???
-
Changer les variables Flash du player Youtube va largement au-delà d'une simple optimisation ...
-
OK pour pour qu'il y ai un résumé tout public de ce qui est fait, mais à condition qu'il soit lié à un exposé en profondeur qui parle aux spécialiste.
Les défenseur auto-proclamés de "Mme Michu" (je peux pas les encadrer, Mme Michu ne leur a jamais rien demandé) vont protester comme ils le font toujours (c'est à dire de façon inepte), mais personne n'est obligé de lire les explications détaillées; et il suffit de demander à un spécialiste "est-ce que ce qu'ils racontent sur cette page a un sens?"
-
J'avais constaté ce bridage sur une clé 3G+ SFR fin 2012.
Le proxy transparent utilisé est celui conçu par l'entreprise ByteMobile, il est également utilisé par de nombreux opérateurs à l'international (Vodafone, O2...).
Quelques une des modifications effectuées sur les pages web :
- Remplacement des retours à la ligne par des espaces. J'avais trouvé ça complètement stupide, dans les deux cas ça fait un octet...
- Modification des headers HTTP liés au cache. Résultat : comportements non-voulus sur de nombreux sites lors de l'utilisation de la touche F5, ou de l'envoi de formulaires.
- Modification des balises <img> pour faire passer les images par un proxy transparent correspondant à une adresse IP SFR. Sale.
- Injection d'un fichier JS hébergé sur http://1.2.3.4/ (http://1.2.3.4/). Il modifiait notamment les paramètres des lecteurs vidéo YouTube.
- Fusion du code JavaScript des fichiers .js avec les .html, ce qui au final alourdissait les pages et augmentait la bande passante à partir du moment où on chargeait plusieurs pages sur le site web, complètement stupide ici aussi car l'effet inverse de ce qui était recherché était produit.
- Il y avait aussi probablement de la recompression d'images, je n'avais pas vérifié.
Pour contourner cette immondice, j'avais trouvé une solution : ajouter le header Cache-Control: no-transform aux requêtes HTTP, en utilisant une extension navigateur ou bien un proxy local. Cela permettait d'être ignoré par le proxy ByteMobile.
De mémoire, cela fonctionnait aussi bien si le header était envoyé côté client, que s'il l'était client serveur, donc webmasters, si vous souhaitez que votre site ne soit pas souillé par ce genre de proxy, la première chose à faire est d'ajouter une ligne à votre .htaccess (ou équivalent si vous êtes sous nginx/lighttpd/autre) pour que ce header soit envoyé dans chaque réponse.
-
Moi j'ai trouvé la solution pour empocher la modification par des proxy du code envoyé / compression d'images : full https ;D
-
Oui, ça fonctionne très bien aussi. :)
-
Remplacement des retours à la ligne par des espaces. J'avais trouvé ça complètement stupide, dans les deux cas ça fait un octet...
Sur Windows, un retour a la ligne c'est 2 octets (CR puis LF) mais c'est sur que globalement je ne pense que ça impacte beaucoup sur le volume total vu le peu de pages crées sous Windows (encore que, faut voir...statistiquement certaines pages très demandées sont peut-être d'origine Windows).
ou c’était juste une protection contre les attaques de type 'CRLF Injection' mais faire ça a cet endroit c'est curieux.
-
Moi j'ai trouvé la solution pour empocher la modification par des proxy du code envoyé / compression d'images : full https ;D
Dès qu'un contenu est personnalisé pour l'utilisateur, je considère que l'on doit se diriger vers du 100 % HTTPS; en résumé : quand tu es identifié, tu es en HTTPS.
Sachant que générer du contenu personnalisé est déjà non trivial par rapport au fait d'envoyer un fichier statique, le chiffrement par dessus ne rajoute pas tellement; si c'est trop cher, on peut utiliser un frontend SSL/TLS optimisé.
(Bien sûr, cela n'empêchera pas forcèment la NSA de se placer derrière le frontend pour espionner tout le monde, mais ça limite quand même les indiscrétions et les modifications.)
-
J'avais constaté ce bridage sur une clé 3G+ SFR fin 2012.
Le proxy transparent utilisé est celui conçu par l'entreprise ByteMobile, il est également utilisé par de nombreux opérateurs à l'international (Vodafone, O2...).
Quelques une des modifications effectuées sur les pages web :
- Remplacement des retours à la ligne par des espaces. J'avais trouvé ça complètement stupide, dans les deux cas ça fait un octet...
- Modification des headers HTTP liés au cache. Résultat : comportements non-voulus sur de nombreux sites lors de l'utilisation de la touche F5, ou de l'envoi de formulaires.
- Modification des balises <img> pour faire passer les images par un proxy transparent correspondant à une adresse IP SFR. Sale.
- Injection d'un fichier JS hébergé sur http://1.2.3.4/ (http://1.2.3.4/). Il modifiait notamment les paramètres des lecteurs vidéo YouTube.
- Fusion du code JavaScript des fichiers .js avec les .html, ce qui au final alourdissait les pages et augmentait la bande passante à partir du moment où on chargeait plusieurs pages sur le site web, complètement stupide ici aussi car l'effet inverse de ce qui était recherché était produit.
- Il y avait aussi probablement de la recompression d'images, je n'avais pas vérifié.
Pour contourner cette immondice, j'avais trouvé une solution : ajouter le header Cache-Control: no-transform aux requêtes HTTP, en utilisant une extension navigateur ou bien un proxy local. Cela permettait d'être ignoré par le proxy ByteMobile.
De mémoire, cela fonctionnait aussi bien si le header était envoyé côté client, que s'il l'était client serveur, donc webmasters, si vous souhaitez que votre site ne soit pas souillé par ce genre de proxy, la première chose à faire est d'ajouter une ligne à votre .htaccess (ou équivalent si vous êtes sous nginx/lighttpd/autre) pour que ce header soit envoyé dans chaque réponse.
Mais que c'est crade... et stupide.
Seule la re-compression pourrait à la rigueur, dans certains cas, en informant bien l'utilisateur de ce qu'on fait et pourquoi et à condition de donner un moyen de le désactiver, se justifier.
Merci pour l'analyse en tous cas.
-
Jamais pris le temps de mesurer, mais un VPN avec la compression activée, cela fait gagner du volume ou c'est négligeable ?
-
La compression activée introduit-elle une vulnérabilité pour l'accès à un compte perso sur un site HTTP?
-
La compression activée introduit-elle une vulnérabilité pour l'accès à un compte perso sur un site HTTP?
A mon avis on est sur de la compression post-chiffrement, avec des gains minimes comme pourrait le faire Winrar par exemple : sur un fichier chiffré stocké, on compresse pour l'envoyer et on le décompresse à l'arrivée. Pas de compression ou d'accélérateur web comme peut le faire un proxy
-
Ce serait plutôt de la compression avant chiffrement, non ? Compresser des données chiffrés me semble un peu idiot ???
-
Avant, Après, ce que je voulais maladroitement dire c'est que cela n'était pas une compression "intelligente" (à mon avis) à détecter des images et les recompresser par exemple. Ça compresse surement tout le flux global, du txt, du binaire etc.
D'ou mon interrogation sur les gains que cela apporte (ou pas)
-
Oui, c'est de la compréhension simple (exacte), type deflate, gzip. Il n'est pas question d'algo de compression d'images (approximative) bien sûr.
Donc, je repose la question : faille? pas faille?
-
Pourquoi compresser avant de chiffrer poserait un problème de sécurité ? Si le tuyau est sur, peu importe ce qu'il passe dedans en toute logique non ?
-
Corrector : si je ne m'abuse, la compression de ssh / openvpn agit sur les données qui transite : le bout du tunnel compresse, envoye, et l'autre bout decompresse. Il n'y a donc aucun impact sur la sécurité.
-
Ce n'est pas parce que ssh et openvpn le font qu'il n'y a pas un risque.
-
Ben, j'avoue ne pas comprendre le risque tu crains : quelle partie du process doutes-tu ?
-
(http://makeameme.org/media/created/cfmlfi.jpg)
-
Je crains le fait même de compresser les données qu'on veut protéger.
-
J'suis désolé, j'ai toujours pas compris :-[
-
U mean backdoor dans le binaire de compression ?
-
Je veux dire que le fait même de compresser est un risque!
-
C'est la ou j'ai besoin aussi d'explication. En quoi la manipulation de données en local est un risque supplèmentaire ? C'est vrai que je ne vois pas le danger non plus. Peu importe ce qu'on envoie dans le tunnel VPN, ce n'est pas la donnée qui fait la sécurité, mais le chiffrement. La sécurité ne repose en rien sur la compression ou non des données.
Peut être et sûrement je loupe une étape, mais je pige pas.
-
Peut-être corrector fait-il référence aux bombes de décompression (https://fr.wikipedia.org/wiki/Bombe_de_d%C3%A9compression) (dont les navigateurs modernes semblent savoir se protéger sans problème quand ça se passe en mémoire vive) ? Ou peut-être juste au niveau de complexité ajouté par une couche de compression supplèmentaire, et donc potentiellement les failles encore inconnues qu'elle apporte (c'est vague). Sinon je ne vois pas trop.
De la compression sur des données inconnues, notre système en utilise en permanence, que ce soit pour les images, les pages web, les vidéos... Et je n'ai pas l'impression que ce soit très problématique dans la vie de tous les jours.
-
compresser c'est trouver des patern dans le fichiers
corrector craint une diminution de l'entropy qui permettrait du coup de déchiffrer le le fichier, je suppose
-
Ben, tu ne trouves pas les pattern, vu que la compression arrive avant le chiffrement.
Si je ne m'abuse :
Sans compression :
- clair -> chiffré -> clair
Avec compression :
- clair -> compressé -> chiffré -> compressé -> clair
-
compresser c'est trouver des patern dans le fichiers
corrector craint une diminution de l'entropy qui permettrait du coup de déchiffrer le le fichier, je suppose
Par définition, l'entropie ne diminue jamais! (ou alors il y a un bug)
L'entropie d'un message diminue quand on perd de l'information et la compression ne perd pas d'information (ou alors il y a un bug).
-
Ben, tu ne trouves pas les pattern, vu que la compression arrive avant le chiffrement.
Si je ne m'abuse :
Sans compression :
- clair -> chiffré -> clair
Avec compression :
- clair -> compressé -> chiffré -> compressé -> clair
et il n'y a pas collision?
-
Ce n'est pas du hashage mais du chiffrement :-)
Une collision peut apparaître quand pour un nombre infini d'entrée tu as un nombre fini de sortie
-
Il faut rappeler que pour la plupart des entrées, le résultat de la compression est plus gros que la données d'origine.
-
Ça arrive souvent, cela ?
Même en compressant une vidéo avec gzip, je ne dépasse pas la taille de l'original (je ne gagne pas beaucoup non plus, m'enfin c'est évident)
-
Le principe est que ça arrive rarement en pratique.
Mais mathématiquement, la sortie doit être plus grande que l'entrée le plus souvent.
-
Quelques une des modifications effectuées sur les pages web :
- Remplacement des retours à la ligne par des espaces.
Je remarque que les retours à la ligne sont retirés, même dans les <pre> (ou plutôt le contenu en white-space: pre;). C'est malin... Les blocs de code sur les DokuWiki par exemple se retrouvent complètement défigurés.
Pour ces quelques jours sur clé 3G, je privilégie le chiffrement, notamment grâce à l'extension HTTPS Everywhere (https://www.eff.org/https-everywhere), afin d'éviter au maximum le détournement de mon trafic. Au passage, j'ai remarqué qu'il y a beaucoup de sites qui supportent le HTTPS, mais dont l'implèmentation est cassée : sites avec de nombreux liens/formulaires/images/scripts qui pointent vers la version HTTP, certificats invalides/expirés/pour le mauvais nom de domaine... c'est un peu dommage.
-
Si on modifie le HTML, ce n'est plus de l'accès à Internet, ni même l'accès au Minitel, c'est un sous-sous-minitel... >:(