GuiGui's Show

« Au milieu des années 1990, Le Grand Secret, le livre de Claude Gubler – docteur de François Mitterrand – dans lequel il expose l'état de santé de l'ancien président, est diffusé sur Internet malgré son interdiction en France. En réaction, le mythe d'un « Internet zone de non-droit » (par exemple l'Expansion, 8 février 1996, ou l'Humanité 25 janvier 1996) apparaît comme élément de langage dans les discours médiatique et politique pour ne plus jamais le quitter, de « l'amendement Fillon » de 1996 (Libération 13 septembre 1996), qui tentait – en vain – d'imposer un filtrage administratif des contenus, à la loi « terrorisme » de Bernard Cazeneuve fraîchement adoptée qui valide leur blocage extra-judiciaire, en passant par « l'Internet civilisé » cher à Nicolas Sarkozy.

[...]

Malheureusement, le mythe s'est progressivement réalisé. L'accumulation de mesures législatives et pseudo-contractuelles imposées par le pouvoir politique pour les premières et par des entreprises privées pour les secondes a réussi à transformer Internet en « zone de non-droit ». Non pas que le citoyen y court un risque accru d'être victime de diffamation, de propos haineux ou de n'importe quel autre crime perpétué en toute impunité par des anonymes, mais que sa capacité à opposer ses droits à des atteintes à ses libertés diminue de manière progressive et persistante.

[...]

Sur le terrain de la liberté d'expression, les mécanismes de censure reposant sur des intermédiaires techniques plutôt que sur des juges ne cessent d'être élargis à des catégories de contenus toujours plus nombreuses. Depuis 2004, elles ont ainsi été étendues des crimes considérés comme les plus graves (apologie de crime contre l'humanité, pédo-pornographie, incitation à la haine raciale…) à des infractions secondaires (homophobie, sexisme, handiphobie…), provoquant la censure arbitraire de toujours plus de contenus [2]. En parallèle, les mesures de blocage et de filtrage administratifs se sont elles aussi développées – sans faire l'objet d'application réelle à ce jour, faute de publication des décrets – permettant théoriquement au pouvoir exécutif de censurer des contenus, là aussi sans contrôle du juge malgré la gravité de ces décisions.

[...]

Alors que, par essence, Internet pourrait être le lieu privilégié et concret de l'application réelle de nos droits fondamentaux, nous assistons peu à peu à leur émiettement et à l'apparition de la « zone de non-droit ». Ironiquement, alors que cette menace était agitée par une puissance publique prétendant défendre l'intérêt général pour justifier ses tentatives de reprise de contrôle sur un outil lui échappant, c'est finalement sous la forme d'un recul de la capacité des citoyens à faire valoir leurs droits face à l'exercice arbitraire du pouvoir qu'elle se réalise. Si ces évolutions vers le contournement systématique du pouvoir judiciaire et la privation de libertés imposées par le pouvoir législatif ou par des acteurs privés n'empêchent pas la création et la diffusion grandissantes d'outils permettant l'émancipation de tous (des licences libres aux outils de chiffrement, en passant par les monnaies virtuelles), elles les ralentissent, sont facteurs d'incertitudes, et pourraient à terme soit les étouffer, soit finir de briser l'idée que la loi est au service de l'intérêt public.

[...]

Les récentes mobilisations en Europe et aux États-Unis en réaction à de tels projets politiques et législatifs (ACTA, SOPA, PIPA, neutralité du Net, etc.) démontrent le niveau d'appropriation et de consensus citoyen autour de ces questions. Il est urgent de réduire le fossé qui sépare les gouvernants des gouvernés, particulièrement palpable sur ces questions, afin de permettre un développement des cadres juridiques favorables à tous. Nous ne pouvons plus nous contenter de ne repousser que les plus dangereux de ces projets tout en assistant à la disparition progressive de nos droits fondamentaux : nous nous devons d'agir pour leur application réelle dans les pratiques numériques, d'une part à travers leur consécration législative, mais surtout par le maintien du pouvoir judiciaire au centre de ces dispositifs.

[...]

Ensemble, faisons comprendre à nos élus que nous ne laisserons pas le contrôle de la loi nous échapper d'avantage, et qu'Internet doit redevenir une « zone de droit », avec ou sans eux. »

« L'idée est ancienne (on la trouve par exemple dans le système T/TCP du RFC 1644, et dans les autres systèmes résumés en section 8) mais le problème est plus difficile à résoudre qu'il n'en a l'air, notamment si on veut garder un bon niveau de sécurité (le problème qui a tué T/TCP). L'idée est ancienne, car devoir attendre trois voyages avant de pouvoir envoyer les données contribue sérieusement à la latence d'applications comme le Web. Si le serveur est à 100 ms de distance, on attendra au moins 300 ms avant que des données ne commencent le voyage. Et, contrairement à la capacité, la latence ne s'améliore pas avec le temps et les progrès de l'électronique. Des mesures faites sur Chrome montre que la triple poignée de mains de TCP est responsable de 25 % de la latence moyenne des requêtes HTTP.

[...]

Et la sécurité ? Le TCP normal présente une vulnérabilité : les paquets SYN n'ayant aucune forme d'authentification, un attaquant peut, en trichant sur son adresse IP, envoyer des paquets SYN sans révéler son identité et ces paquets, s'ils sont assez abondants, peuvent remplir la file d'attente du serveur (attaque dite « SYN flood »). C'est encore pire avec Fast Open puisque ces requêtes en attente comprennent des données, et peuvent déclencher l'exécution de commandes complexes (GET /horrible-page-dont-la-génération-nécessite-10000-lignes-de-Java-ou-de-PHP HTTP/1.1...) Les techniques du RFC 4987 ne sont en général pas appliquables à Fast Open. C'est pour cela que Fast Open ajoute un composant essentiel : un petit gâteau (cookie) généré par le serveur et que le client devra transmettre pour bénéficier du Fast Open.

[...]

La section 3 décrit en termes généraux le protocole. À la première connexion Fast Open d'une machine vers une autre, le client envoie l'option TCP (pour les options TCP, voir la section 3.1 du RFC 793) 34 TCP Fast Open Cookie (désormais dans le registre IANA) avec un contenu vide. Si le serveur gère Fast Open, il répondra (dans le SYN + ACK) avec un gâteau (cookie), généré par lui et imprévisible. Dans les connexions TCP ultérieures, le client renverra l'option Fast Open Cookie avec le même gâteau. Le serveur le reconnaitra alors. Les requêtes SYN comportant ce gâteau pourront inclure des données, elles seront transmises tout de suite aux applications qui le demandent (et on aura alors du beau TCP Fast Open) et le premier paquet de réponse pourra inclure des données (dans les limites données par le RFC 5681). On voit donc que la première connexion entre deux machines ne bénéficiera pas de Fast Open.

[...]

La section 4 de notre RFC plonge ensuite dans les détails compliqués de TCP Fast Open. Le gâteau est un MAC généré par le serveur et est donc opaque au client. Ce dernier ne fait que le stocker et le renvoyer.

[...]

Autre point important lorsqu'on met en œuvre Fast Open : le serveur doit garder une trace en mémoire du nombre de connexions qui ont demandé Fast Open mais n'ont pas encore terminé la triple poignée de mains. Et, au delà d'une certaine limite, le serveur doit refuser de nouvelles connexions Fast Open (en ne renvoyant pas d'option Fast Open dans le SYN + ACK), n'acceptant que le TCP traditionnel. Cette précaution permet de résister à certaines attaques par déni de service.

[...]

D'abord, il peut tenter d'épuiser les ressources du serveur en utilisant des gâteaux valides. Où les obtient-il ? Cela peut être en utilisant plein de machines (un botnet). Bien sûr, vous allez me dire, on peut faire des tas d'attaques par déni de service avec un botnet mais, avec Fast Open, les zombies peuvent faire plus de dégâts pour moins cher (ils ne sont pas obligés d'écouter les réponses ni même de les attendre). [...] On ne peut pas normalement voler des gâteaux à une machine et les utiliser ensuite soi-même puisque le gâteau est (si le serveur a bien fait son boulot) lié à l'adresse IP. Mais ce vol reste possible si plusieurs machines partagent une adresse IP publique (cas du CGN par exemple). Une solution possible serait d'inclure dans le calcul du gâteau, non seulement l'adresse IP mais aussi la valeur d'une option TCP Timestamp.

[...]

Fast Open peut aussi en théorie être utilisé dans des attaques par réflexion. Par exemple (mais le RFC indique aussi d'autres méthodes), si l'attaquant contrôle une machine dans le réseau de sa victime, il peut obtenir des gâteaux valables et ensuite, lancer depuis un botnet des tas de connexions Fast Open en usurpant l'adresse IP source de sa victime. Les serveurs Fast Open vont alors renvoyer des données (potentiellement plus grosses que les requêtes, donc fournissant une amplification, chose bien utile pour une attaque par déni de service) à la victime. C'est idiot de la part de l'attaquant de s'en prendre à une machine qu'il contrôle déjà ? Non, car sa vraie victime peut être le réseau qui héberge la machine compromise. Les réponses des serveurs Fast Open arriveront peut-être à saturer la liaison utilisée par ce réseau, et cela en contrôlant juste une machine (soit par piratage, soit par location normale d'une machine chez l'hébergeur qu'on veut attaquer).

[...]

Dans le doute, une application qui ne pourrait pas gérer le cas de données dupliquées ne doit donc pas activer Fast Open (rappelez-vous qu'il ne doit pas non plus l'être par défaut). [...] Ensuite, même s'il n'a pas de conséquences néfastes, TCP Fast Open n'a pas non plus d'avantages si le temps d'établissement de la connexion est négligeable devant la durée totale de la connexion. Une requête HTTP pour un fichier de petite taille peut sans doute profiter de Fast Open, mais pas le transfert d'une énorme vidéo.

TCP Fast Open est-il utile lorsqu'on a ces connexions persistentes ? Oui, répond notre RFC. [...] Les montrent que le nombre moyens de transactions HTTP par connexion TCP n'est que de 2 à 4, alors même que ces connexions restent ouvertes plusieurs minutes, ce qui dépasse normalement le temps de réflexion d'un être humain. Les mesures effectuées sur Chrome (qui garde les connexions de 5 à 10 minutes) ne voyaient que 3,3 requêtes TCP par connexion.

Qu'est-ce qu'on doit encore étudier et mesurer pour être sûr que Fast Open marche bien ? D'abord, quel est le pourcentage exact de chemins sur l'Internet où les paquets TCP ayant des options inconnues sont jetés ? Pas mal de middleboxes stoppent stupidement tout ce qu'elles ne comprennent pas. [...] Des mesures semblent indiquer que 6 % des chemins Internet seraient dans ce cas. [...] TCP Fast Open réagit à ce problème en réessayant sans l'option (comme le font les résolveurs DNS quand ils n'optiennent pas de réponse lorsque les requêtes sont envoyées avec EDNS). »

Via http://sebsauvage.net/links/?-zjC8A

« Je vous ai déjà expliqué comment relier son Minitel comme terminal Linux, ou alors comment le relier à un Raspberry Pi. Mais s'arrêter là, ce serait oublier que le Minitel est initialement conçu pour consulter des pages Vidéotex avec son modem 1200/75 bauds intégré.

À une époque où le terme « Minitel 2.0 » est utilisé de manière péjorative et où la plupart des terminaux Minitel que l'on trouve sont sur eBay, LeBonCoin, à la déchetterie ou oubliés dans un grenier, quelle idée plus saugrenue que de mettre en place, justement, son propre serveur Minitel ? Après tout, les plus jeunes d'entre nous n'ont pas connu le Minitel. En ayant tenu un stand lors de l'événement « 3615 au revoir », j'ai pu me rendre compte que beaucoup de personnes, même plus âgées que moi, n'ont pas eu l'opportunité de voir fonctionner un Minitel, et de ce fait voir comment on faisait dans les années 80-90 pour réserver un billet de train. Outre le désir de préservation ou de fascination pour les technologies obsolètes, faire cela pour la pure prouesse technique me paraît de surcroît tout à fait justifié. »

C'pas un scoop mais c'est bien documenté et détaillé comme il faut.

« Quand on a un debian en chroot, facile de voir ses SMS sur un téléphone android : il suffit de taper dans la base de données sqlite qui va bien :) »

« En cette ère où on a toutes ces technologies de communication possible (téléphone portable, accès Internet avec la messagerie instantanée, les mails), en cette ère où l’on peut parler à n’importe qui dans le monde, en toute liberté ét gratuité, n’est-on pas seul ? Je peux parler à des milliers de personnes sur des forums, les côtoyer virtuellement tous les jours, et je ne parlerai jamais à mon voisin de pallier. Je peux parler à des tas de personnes, qui partagent les mêmes centres d’intérêts que moi, mes passions, mes gouts, qui sont si semblables et si différents.

Et pourtant, avec ces mêmes outils, bien que je puisse garder contact avec les personnes qui me sont le plus proches, à savoir mes amis, ce n’est pas le cas. Est-ce mon rapport avec ces nouvelles technologies qui est différent du leurs ? N’est-ce pas du fait que je suis geek ? C’est à travers ce long article et les points abordés/développés que je tenterai de trouver une réponse à ces questions. »

« Ce court RFC est une introduction à une entité peu connue du monde de l'Internet, l'IRTF, Internet Research Task Force. [...] L'IRTF est censée travailler sur des projets à long terme (proches de la recherche), pendant que l'IETF travaille sur des sujets bien maîtrisés techniquement, et qu'on peut normaliser relativement rapidement.

[...]

D'abord, il faut comprendre la différence entre recherche et ingéniérie. Deux citations l'illustrent, une de Fred Baker qui estime que « le résultat de la recherche, c'est la compréhension, le résultat de l'ingéniérie, c'est un produit ». Et la seconde, de Dave Clark, affirme que « si ça doit marcher à la fin du projet, ce n'est pas de la recherche, c'est de l'ingéniérie ». Le RFC résume en disant que « la recherche, c'est un voyage, l'ingéniérie, c'est une destination ». Un chercheur qui ouvre plus de questions qu'il n'en a fermé dans sa recherche peut être satisfait. Un ingénieur qui ne termine pas ne l'est pas.

[...]

Par exemple, les unités de base de l'IETF, les groupes de travail, sont très focalisés, avec une charte précise, des buts à atteindre, et un calendrier. Les unités de base de l'IRTF, les groupes de recherche, sont au contraire larges, traitant plusieurs sujets assez différents en même temps, et avec une charte bien plus large.

De même, les délais ne sont pas les mêmes. L'IRTF, travaillant sur des problèmes difficiles, voit typiquement à trois ou cinq ans, alors que les calendriers (très théoriques...) des groupes de travail IETF visent des échéances plus courtes.

Autre différence, alors que l'IETF est supposé arriver à un consensus (approximatif) entre les membres du groupe de travail (RFC 7282), l'IRTF n'a pas de telles obligations et peut parfaitement, par exemple, suivre plusieurs lièvres à la fois.

L'IRTF n'est pas non plus obligée de suivre les politiques de l'IETF relatives aux brevets (RFC 3979).

[...]

Et sur le résultat du groupe de recherche ? En quoi doit-il consister ? Un groupe de travail IETF produit des RFC, c'est son but. Mais un groupe de recherche IRTF ne le fait pas forcément. Il peut aussi publier par d'autres moyens (rapports, articles académiques...), voire se contenter d'Internet-Drafts qui ne deviendront pas de RFC. Le critère du succès, pour un groupe IRTF, c'est de faire avancer la science, pas de faire des RFC. »