Le protocole de transport QUIC (couche 4 du modèle OSI) vient d’être normalisé, sous la forme de plusieurs RFC. QUIC, déjà largement déployé, peut changer pas mal de choses sur le fonctionnement de l’Internet, en remplaçant, au moins partiellement, TCP. C’est quoi, QUIC, et à quoi ça sert ? 
Sommaire
- Couche transport
- QUIC en deux mots
- Les détails de mise en œuvre
- Les normes
- Le passé
- Et pour aller encore plus loin
Couche transport
QUIC n’est pas un protocole d’application (couche 7) comme peuvent l’être HTTP ou SSH. Les utilisateurs ordinaires ne verront pas la différence, ils se serviront des mêmes applications, via les mêmes protocoles applicatifs. QUIC est un protocole de transport (couche 4 du traditionnel modèle en couches OSI), donc un concurrent de TCP, dont il vise à résoudre certaines limites, notamment dans le contexte du Web.
Quelles limites ? Pour comprendre, il faut revenir à ce à quoi sert la couche de transport.
Placée entre les paquets d’IP, qui peuvent arriver ou pas, dans l’ordre ou pas, et les applications, qui comptent en général sur un flux d’octets ordonnés, où rien ne manque, la couche transport est chargée de surveiller l’arrivée des paquets, de signaler à l’émetteur qu’il en manque pour qu’il puisse réémettre, et de mettre dans le bon ordre les données. Dit comme ça, cela semble simple, mais cela soulève beaucoup de problèmes intéressants. Par exemple, il ne faut pas envoyer toutes les données sans réfléchir : le réseau n’est peut-être pas capable de les traiter, et un envoi trop brutal pourrait mener à la congestion du réseau. De même, en cas de pertes de paquet, il faut certes ré-émettre, mais aussi diminuer le rythme d’envoi, la perte pouvant être le signal que le réseau est saturé. C’est à la couche transport de gérer cette congestion, en essayant de ne pas la déclencher ou en tout cas de ne pas l’aggraver. En pratique, la couche transport est donc très complexe, comme le montre le nombre de RFC sur TCP.
Maintenant que nous avons révisé les tâches de la couche transport, quelles sont ces limites de TCP dont je parlais, et qui justifient le développement de QUIC ?
Notez d’abord qu’elles ont surtout été mentionnées dans le contexte du Web. Celui-ci pose en effet des problèmes particuliers, notamment le désir d’une faible latence (quand on clique, on veut une réponse tout de suite) et le fait que l’affichage d’une seule page nécessite le chargement de plusieurs ressources (images, vidéos, code JavaScript, CSS, etc). La combinaison de TCP et de TLS n’est pas satisfaisante question latence, puisqu’il faut d’abord établir la connexion TCP, avant de pouvoir commencer la négociation qui mènera à l’établissement de la session TLS. Ensuite, TCP souffre du manque de parallélisme : quand on veut récupérer plusieurs ressources, il faut soit ouvrir plusieurs connexions TCP, qui ne partageront alors plus d’information (délai aller-retour, taux de perte, etc) ou de calculs (cryptographie…), soit multiplexer à l’intérieur d’une connexion TCP, ce que fait HTTP/2 mais, alors, on risque le head-of-line blocking, où la récupération d’une ressource bloque les suivantes, et le fait que la perte d’un seul paquet va faire ralentir tous les téléchargements.
QUIC en deux mots
Quels sont les concepts de base de QUIC ? QUIC gère des connexions entre machines, comme TCP. Par contre, contrairement à TCP, ces connexions portent ensuite des ruisseaux (streams) séparés, ayant leur propre contrôle de congestion, en plus du contrôle global à la connexion. Les ruisseaux peuvent être facilement et rapidement créés. Ce n’est pas par hasard que le concept ressemble à celui des ruisseaux de HTTP/2, dans les deux cas, le but était de s’adapter au désir des navigateurs Web de charger toutes les ressources d’une page en parallèle, sans pour autant « payer » l’établissement d’une connexion pour chaque ressource.
Avec QUIC, le chiffrement est obligatoire. Il n’y a pas de version de QUIC en clair. Non seulement les données applicatives sont chiffrées, comme avec TLS ou SSH mais une bonne partie de la couche transport l’est également. Pourquoi ?
- En raison de la prévalence de la surveillance massive sur l’Internet ; moins on expose de données, moins il y a de risques.
- Afin d’éviter que les middleboxes (les boitiers intermédiaires qui regardent au-dessus de la couche 3) ne se croient capables d’analyser le fonctionnement de la couche transport, et ne se croient autorisées à y intervenir, ce qui mènerait à une ossification de l’Internet. Si tout est chiffré, on pourra faire évoluer le protocole sans craindre l’intervention de ces fichus intermédiaires.
- Certains FAI (Fournisseur d’accès à l’Internet) ont déjà exploité le caractère visible de TCP pour des attaques, par exemple en envoyant des paquets RST (ReSeT) pour couper le trafic BitTorrent. TLS et SSH ne protègent pas contre ce genre d’attaques.
- L’observation de la couche transport peut permettre d’identifier les services utilisés et d’en dé-prioritiser certains. Le chiffrement du transport peut donc aider à préserver la neutralité du réseau.
On peut prévoir que les habituels adversaires du chiffrement protesteront d’ailleurs contre QUIC, en l’accusant de gêner la visibilité (ce qui est bien le but).
QUIC utilise le classique protocole TLS pour le chiffrement mais pas de la manière habituelle. Normalement, TLS fait la poignée de main initiale, l’échange des clés et le chiffrement des données. Avec QUIC, TLS ne fait que la poignée de main initiale et l’échange des clés. Une fois les clés obtenues, QUIC chiffrera tout seul comme un grand, en utilisant les clés fournies par TLS.
Les détails de mise en œuvre
Puisqu’on a parlé des middleboxes : déployer un nouveau protocole de transport dans l’Internet d’aujourd’hui est très difficile, en raison du nombre d’équipements qui interfèrent avec le trafic (les routeurs NAT, par exemple). Conceptuellement, QUIC aurait pu tourner directement sur IP. Mais il aurait alors été bloqué dans beaucoup de réseaux. D’où le choix de ses concepteurs de le faire passer sur UDP. QUIC utilise UDP comme il utiliserait IP. On lit parfois que QUIC, ce serait « HTTP au-dessus d’UDP », mais c’est une grosse incompréhension. QUIC est une couche de transport complète, concurrente de TCP, dont le fonctionnement sur UDP n’est qu’un détail nécessaire au déploiement. QUIC n’a aucune des propriétés d’UDP. Par exemple, comme TCP, mais contrairement à UDP, QUIC teste la réversibilité du trafic, ce qui empêche l’usurpation d’adresses IP et toutes les attaques UDP qui reposent dessus.
QUIC est parfois présenté comme « tournant en mode utilisateur et pas dans le noyau du système d’exploitation ». En fait, ce n’est pas spécifique à QUIC. Tout protocole de transport peut être mis en œuvre en mode utilisateur ou noyau (et il existe des mises en œuvre de TCP qui fonctionnent en dehors du noyau). Mais il est exact qu’en pratique la plupart des mises en œuvre de QUIC ne sont pas dans le noyau du système, l’expérience prouvant que les mises à jour du système sont souvent trop lentes, par rapport au désir de faire évoluer en permanence la couche transport. Et puis, sur Microsoft Windows, Google, premier promoteur de QUIC, n’aime pas dépendre de Microsoft pour les performances de son navigateur Chrome.
Les normes
Les RFC normalisant QUIC sont :
- RFC 9000 est la norme principale, décrivant le socle de base de QUIC ;
- RFC 9001 normalise l’utilisation de TLS avec QUIC ;
- RFC 9002 spécifie les mécanismes de récupération de QUIC, quand des paquets sont perdus et qu’il faut ré-émettre, sans pour autant écrouler le réseau ;
- RFC 8999 est consacré aux invariants de QUIC, aux points qui ne changeront pas dans les nouvelles versions de QUIC.
J’ai dit que QUIC, comme TCP, est un protocole de transport généraliste, et qu’on peut faire tourner plusieurs applications différentes dessus. En pratique, QUIC a été conçu essentiellement en pensant à HTTP mais dans le futur, d’autres protocoles pourront profiter de QUIC, notamment s’ils ont des problèmes qui ressemblent à ceux du Web (désir de faible latence, et de multiplexage).
Pour HTTP, la version de HTTP qui tourne sur QUIC se nomme HTTP/3 et sera normalisée dans un futur RFC. Comme HTTP/2, HTTP/3 a un encodage binaire, mais il ne fait plus de multiplexage, celui-ci étant désormais assuré par QUIC.
Le passé
QUIC a eu une histoire longue et compliquée. À l’origine, vers 2012, QUIC était un projet Google. Si les motivations étaient les mêmes que celles du QUIC actuel, et que certains concepts étaient identiques, il y avait quand même deux importantes différences techniques : le QUIC de Google utilisait un protocole de cryptographie spécifique, au lieu de TLS, et il était beaucoup plus marqué pour son utilisation par HTTP uniquement. Et il y a aussi bien sûr une différence politique, QUIC était un protocole privé d’une entreprise particulière, il est maintenant une norme IETF (Internet Engineering Task Force).
Et pour aller encore plus loin
- La norme de base sur TCP, le RFC 793
- Une liste commentée des RFC à lire sur TCP
- Le RFC sur HTTP/2
- Le RFC sur la surveillance massive, et l’engagement de l’IETF à lutter contre cette attaque
- Sur la notion d’« image montrée au réseau », le RFC 8546
- Un ancien article de LinuxFr.org sur QUIC
Aller plus loin
- La norme de base de QUIC, le RFC 9000 (255 clics)
- La norme d'interaction entre QUIC et TLS, le RFC 9001 (25 clics)
- La norme sur les invariants de QUIC, le RFC 8999 (26 clics)
- Le livre libre et gratuit de Daniel Stenberg, qui couvre HTTP/3 mais aussi QUIC (60 clics)
- Sa version en français (143 clics)
- Une liste bien gérée des nombreuses mises en œuvre de QUIC (50 clics)
- La norme sur la récupération en cas de perte de paquets, le RFC 9002 (17 clics)
- L'arrivée de QUIC dans Firefox (79 clics)
# Belle rédaction
Posté par Glandos . Évalué à 10.
Et bien si avec tout ce travail de documentation sur QUIC (la version sur le blog est bien longue et multiple), il y a fort à parier que QUIC est populaire.
Après, va falloir que ça s'installe… Déjà, ce n'est pas facilement disponible en tant que serveur. Heureusement, les clients populaires le supporte.
Et enfin… Faut que le pare-feu de ma boîte accepte de faire passer l'UDP. C'est pas gagné.
[^] # Re: Belle rédaction
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8.
Pour les serveurs, ça se fera au fur et à mesure. Il y a de très nombreuses mises en œuvre qualité production, il reste à en faire de belles bibliothèques facilement disponibles sur le système d'exploitation de votre choix, puis à intégrer cela dans les logiciels serveurs (si on a déjà du HTTP/2, ce n'est pas trop difficile).
Pour les pare-feux àlakon, oui, c'est une plaie classique de l'Internet (et une des raisons pour lesquelles on fait tout tourner sur HTTP).
[^] # Re: Belle rédaction
Posté par nolio . Évalué à 4.
Ça me fait penser à la migration vers IPv6 (sans vouloir troller), et du coup, je me demande si le passage de HTTP à QUIC sera utile et généraliser à tous ce qui est Web.
J'ai en tête plusieurs exemples :
- les interfaces Web d'administration d'équipements
- des sites avec peu d'utilisateurs
Et est-ce que ça ne serait même intéressant que pour les gros site des GAFAM ?
[^] # Re: Belle rédaction
Posté par barmic 🦦 . Évalué à 5.
C'est intéressant pour les sites web en général, c'est juste que les interfaces de boxes d'une part utilisent de vieux logiciels d'autre part ont des contraintes de déploiement (et encore).
C'est intéressant dès que le multiplexage est intéressant, donc pour les webservices ça va dépendre de tes usages (si tu as plusieurs appels parallèles ou pas).
Après on peut en imaginer des choses :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Belle rédaction
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
La grosse différence avec IPv6 est que la couche 3 affecte tous les routeurs sur le trajet alors que la couche 4 est de bout en bout. Il suffit que client et serveur le fassent.
[^] # Re: Belle rédaction
Posté par tisaac (Mastodon) . Évalué à 4.
J'ai peut-être mal compris mais QUIC semble aussi intéressant pour avoir des flux cryptés et donc moins sensibles à différents désagréments au niveau des intermédiaires.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Belle rédaction
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 9.
En effet QUIC chiffre (et ne crypte pas) en partie pour éviter que les intermédiaires ne se permettent de regarder et de se croire capable d'intervenir. C'est mentionné dans la dépêche (paragraphe sur la neutralité du réseau).
[^] # Re: Belle rédaction
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Clair, les DSI bloquent UDP. C'est déjà galère pour la visio… Les DSI n'aime pas UDP en général ! Au final, on se retrouve souvent à faire des tunnels SSH donc TCP dans TCP pour bosser ;-)
Bref, ce n'est pas gagné… On voit que TCP et le web (80/443) ont tué tous les autres protocoles / ports !
[^] # Re: Belle rédaction
Posté par lagou . Évalué à 4.
… RTP dans TCP…
# Chiffrement
Posté par barmic 🦦 . Évalué à 6.
Merci pour la dépêche.
Je me demandais à quel point ce serait contraignant. Par exemple pour étudier tcp et udp (en TP), c'est assez facile. Ajouter l'utilisation de certificats (pour ceux qui se demandent on peut créer des certificats pour des adresses ip) va complexifier un peu (ne pas présumer des difficultés que peuvent rencontrer des étudiants…).
Je présume qu'ils vont contraindre http/3 à fonctionner sur quic, ce qui va poser pas mal de question coté load balancer et terminaison tls. Je ne doute pas que google s'est posé la question, mais je n'ai rien trouvé dessus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chiffrement
Posté par abriotde (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 30 mai 2021 à 05:48.
Un load balancer est agnostique. L'IP destination ne sera pas chiffré sinon comment expédier un paquet.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Chiffrement
Posté par barmic 🦦 . Évalué à 3.
S'il is très bien tout ça, mais s'il déchiffre (s'il est la terminaison tls), il doit passer à tcp ou udp de l'autre côté. Soit il reimplemente les différences, soit on s'aligne sur tcp avec http…
J'ai pas de doute que l'IETF a eu le concours de personnes dont c'est la problématique. Je pense surtout à haproxy parce qu'il ne fait que ça (et que je m'en sert), mais il y a aussi varnish dont l'un des dev avait beaucoup parlé lors des travaux sur http2.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chiffrement
Posté par Sytoka Modon (site web personnel) . Évalué à 3. Dernière modification le 30 mai 2021 à 08:57.
Et d'ailleurs, c'est un des soucis, c'est compliqué de faire du haproxy avec SSH et je n'ai pas encore trouvé comment, avec du logiciel libre, faire un répartiteur de charge SSH avec gestion de la session (envoyer la personne toujours sur le même nœud s'il avait une connexion pas trop ancienne précédemment…).
Si le répartiteur de charge voit tout, c'est pas forcément terrible. S'il ne voit rien, c'est pas terrible du tout.
Bref, sujet complexe.
[^] # Re: Chiffrement
Posté par rnash . Évalué à 3. Dernière modification le 30 mai 2021 à 19:51.
Le probleme avec un loadbalancer pour du ssh, c'est les clés ssh des serveurs cibles ( les "real servers" en vocabulaire Kemp).
exemple :
ssh.toto.com => Load Balancer
-> Noeud1.internal
-> Noeud2.internal
Une fois on va se connecter via le load balancer a Noeud1.internal et recevoir sa clé, un autre jour pour une nouvelle session, on sera dispatché sur Noeud2.internal et le client ssh qui avait associé la clé de Noeud1.internal à ssh.toto.com va se prendre la clé de Noeud2.internal et demander confirmation puisque la clé à changé voire refuser la connexion.
J'ai le probleme au boulot avec un Kemp Loadmaster (basé sur du Linux avec du haproxy il me semble mais avec interface web et payant) qui repartit la charge sur 2 bastions pour accéder à tous mes serveurs Linux.
Avec certains clients ssh on peut ignorer la signature mais c'est dommage.
Probleme absent pour HTTPS puisque le Loadbalancer peut gérer le chiffrement/dechiffrement (exemple publication sur internet il porte un certificat payant ou let's encrypt et les serveurs internes portent des certificat privés donc non soumis à la limite de validité de 13 mois : si public non let's encrypt, moins de serveurs à traiter lors du deploiement du certificat à chaque renouvellement).
[^] # Re: Chiffrement
Posté par barmic 🦦 . Évalué à 4.
Tu peux utiliser la même clef sur tes nœuds ssh.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chiffrement
Posté par Anonyme . Évalué à 7.
Ou tu peux utiliser l’équivalent de DANE pour SSH, à savoir SSHFP.
[^] # Re: Chiffrement
Posté par barmic 🦦 . Évalué à 3.
Je ne connaissais pas, c'est bien plus propre. Il faut avoir dnssec, mais c'est cool. Merci
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chiffrement
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
Je n'ai pas compris en quoi ça permet de résoudre le problème ?
[^] # Re: Chiffrement
Posté par barmic 🦦 . Évalué à 5.
Tu utilise un nom de domaine avec une entrée pour indiquer l’empreinte de leur clef et un domaine principale qui sera un alias des autres (avec CNAME).
A moins que je ne me trompe.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chiffrement
Posté par Anonyme . Évalué à 7.
Le commentaire de barmic résume bien, mais je veux juste ajouter quelques détails.
Le fonctionnement est le suivant : quand tu te connectes à un serveur (
ssh root@server.example.com), SSH récupère une les clefs que présente le serveur, mais au lieu suivre le fonctionnement TOFU où tu dois valider manuellement que l’empreinte de la clef est correcte (si elle n’est pas déjà dans le fichierknown_hosts), SSH va faire requête DNS pourSSHFP? server.example.com, vérifier que les données sont valides grâce à DNSSEC et comparer l’empreinte de la clef du serveur avec ce qui est configuré dans le DNS.L’avantage c’est que tu contourne complètement TOFU donc tu évites à l’utilisateur de devoir bêtement accepter une clef qu’il ne vérifiera jamais, tu n’as plus besoin de maintenir un
known_hostset tu peux facilement remplacer les clefs d’hôtes au besoin.[^] # Re: Chiffrement
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3. Dernière modification le 01 juin 2021 à 05:33.
En quoi est-ce que cela permet d'avoir des clés différentes sur plusieurs noeuds d'un load balancer ?
[^] # Re: Chiffrement
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 01 juin 2021 à 07:14.
Tu fais ta répartition au niveau dns et pas par routage tcp.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chiffrement
Posté par Anonyme . Évalué à 3.
Tu mets autant d’enregistrement SSHFP qu’il y a de serveurs et de clefs sur ces serveurs. Si tu rajoutes un serveur, tu rajoutes des enregistrements.
[^] # Re: Chiffrement
Posté par gouttegd . Évalué à 10.
Ou bien des certificats SSH : des clefs différentes sur chaque machine mais signées par une même clef de confiance, qui est la seule que le client a besoin d’accepter dans son
known_hosts.[^] # Re: Chiffrement
Posté par Anonyme . Évalué à 2.
Je savais pas que les CA fonctionnaient dans ce sens également (je pensais que c’était seulement pour authentifier le client).
[^] # Re: Chiffrement
Posté par NeoX . Évalué à 2.
y avait un webinar sur le sujet y a quelques temps fait par les gars d'haproxy
de memoire, j'ai pas implémenté, et j'ai pas eu acces au replay.
tu fais du tcp-inspect sur le port 22 pour detecter le domaine (un peu comme le SNI)
et apres tu utilises les stick-tables sur la source
[^] # Re: Chiffrement
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 9.
Il est certain que le chiffrement ajoute de la complexité (dans le contexte des TP, utiliser Wireshark devient plus compliqué, il faut demander une écriture des clés dans un fichier, qu'on fera relire par Wireshark pour qu'il déchiffre le contenu). Mais c'est inévitable de nos jours, les connexions en clair sont vraiment trop vulnérables.
Philosophons un peu : c'est le sort de toutes les techniques. Au début du 20e siècle, un bricoleur pouvait construire un avion acceptable en assemblant un moteur, des ailes et hop. Aujourd'hui, ce n'est pas envisageable, et les TP pour les étudiants sont donc bien plus difficiles. Même l'ultra-simple Gemini impose TLS :-)
Et, oui, HTTP/3 ne fonctionne que sur QUIC, dont il utilise toutes les fonctions (vrai parallélisme, QPACK).
Si le répartiteur de charge termine TLS, pas de problème, il peut relayer comme il veut derrière (nouvelle session QUIC, HTTP/1 ou 2). Sinon, il peut utiliser le Connection ID de QUIC, qui est en clair, pour envoyer tous les paquets d'une même connexion au même dorsal. (Petit piège toutefois car le Connection ID n'est pas forcément constant.)
[^] # Re: Chiffrement
Posté par barmic 🦦 . Évalué à 6.
Oui oui je suis d'accord, mais dans la pratique je pense que la plupart des étudiants ne verront jamais quic sauf s'il supplente ces prédécesseurs. Je m'occupe uniquement des tp et je fais pas les programmes, mais quand je vois les difficultés pour tcp/udp avec un peu de routage (aussi à cause de la mauvaise image que les gens ont du réseau), je ne les vois pas découvrir tls et quic dans la foulée.
Oui la traduction de protocole est possible, mais on voit que ça n'a pas été un travail anodin pour y passer avec http2.
Le coût du connexion id, c'est super cool par contre :) Si ssh y passe n'est là fin de mosh.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chiffrement
Posté par gUI (Mastodon) . Évalué à 10.
Oui et justement, peut-être que ce sera une charnière définitive dans l'éducation des informaticiens : "chiffrement first". Je suis de la vieille école qui code d'abord et ajoute la sécurité après. C'est mauvais, très mauvais, mais c'est comme ça : je n'ai jamais parlé de chiffrement lors de mes études, d'aucune manière que ce soit.
Un élève qui a toujours appris à mettre un certificat de chiffrement dans Wireshark sera déjà bcp plus enclin à changer de paradigme et réellement mettre la sécurité au coeur de son développement.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Chiffrement
Posté par barmic 🦦 . Évalué à 6.
Je suis plus pessimiste que toi amha ça va juste réduire ta compréhension initiale. C'est déjà le cas, en soit même pour du réseau simple, peu de gens s'y intéressent.
Je lui souhaite sincèrement plus de succès qu'ipv6, mais je doute qu'il ai entre dans la majorité des formations (tls n'y figurent pas par exemple).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chiffrement
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 01 juillet 2021 à 13:36.
Pour le routage propre, tu n'as besoin que de IP (et du port ?), tu te fout de ce qu'il y a dedans. Voir tu n'as besoin que du fqdn.
j'ai l'impression que les problèmes commencent quand des boiboites essayent de comprendre ce qu'il y a dans le paquet.
"La première sécurité est la liberté"
# Origine du nom ?
Posté par Christophe Duparquet (site web personnel) . Évalué à 5.
J'ai trouvé bizarre que l'origine du nom QUIC ne soit pas précisée dans la dépêche (intéressante au demeurant) mais je ne l'ai pas trouvée ailleurs non plus.
Quelqu'un sait ?
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Origine du nom ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10. Dernière modification le 30 mai 2021 à 09:57.
https://en.wikipedia.org/wiki/QUIC Although its name was initially proposed as the acronym for "Quick UDP Internet Connections", IETF's use of the word QUIC is not an acronym; it is simply the name of the protocol. Donc c'était un acronyme, puis on a gardé le nom, mais avec les majuscules, parce que les autres qui sont des acronymes étaient comme ça ?
La version acronyme était présente dans les documents de 2012 / 2013 de Jim Roskind de Google. Et elle disparaît de la version IETF ensuite.
https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34#section-1 (janvier 2021)
« QUIC: The transport protocol described by this document. QUIC is a name, not an acronym. »
QUIC est donc rapide et FORT.
[^] # Re: Origine du nom ?
Posté par Christophe Duparquet (site web personnel) . Évalué à 4.
Thanks. J'aurais pas dû m'arrêter à la page WP française.
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Origine du nom ?
Posté par porki . Évalué à 5.
J'ai l'impression que QUIC (quick) est dans la continuité de SPDY (speedy), c'est-à-dire des travaux de Google visant l'amélioration des communications. SPDY est devenu http/2 et QUIC devrait être le support de http3. Un simple hasard ou c'est le même communiquant qui a choisi les noms des projets chez Google ?
[^] # Re: Origine du nom ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 6.
Oui, QUIC et HTTP/3 empruntent pas mal d'idées à HTTP/2, notamment celles des ruisseaux parallèles à l'intérieur d'une même connexion. Et le champ lexical de la vitesse n'a sans doute pas été choisi par hasard :-)
[^] # Re: Origine du nom ?
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
Tu veux dire, les travaux de Google visant à 1) réduire leurs frais généraux, 2) éliminer toute concurrence dans l'exploitation des données de leurs utilisateurs.
Dans le cas du Michoulin.e Moyen.ne, l'overhead TCP/TLS est une question négligeable. Les lenteurs proviennent surtout des couches basses (connexion pourris, infras saturées) ou applicatives (site pourris). Il me semble.
[^] # Re: Origine du nom ?
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 30 juin 2021 à 12:17.
En quoi http 2 et 3 éliminent toute concurrence dans l'exploitation des données utilisateurs ?1
Je sais pas ce que tu entends par "Michoulin.e Moyen.ne" (utilisateur ou ceux qui proposent du contenu), mais c'est tu n'a pas besoin d'être un GAFAM pour que ça soit une contrainte et des entreprises comme F5 ne vivent que de ça. Ça permet aussi de faire autant avec moins.
Les gains de quick ont un impact positif sur les connexions pourris et infras saturées. Réduire les aller retours et permettre de survivre à des changements d'IP sont intéressant pour ça.
Je ne dis pas que Google c'est le bien, mais là je vois pas d'où viennent les reproches.
sachant que l'arrivée de ses nouveautés sont entrain de tuer à petit feux AMP techno purement propriétaire de Google ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Origine du nom ?
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
C'est expliqué dans l'article.
_ Il n’y a pas de version de QUIC en clair. Non seulement les données applicatives sont chiffrées, comme avec TLS ou SSH mais une bonne partie de la couche transport l’est également_
On a donc moins de metadonnées exploitables notamment par les FAI.
Je parles de l'utilisateur moyen. je ne dis pas qu'il n'y a pas d'impact.
A mon échelle, pour la 10aine de millier de sites dont j'assure l'hébergement, ni le déploiement d'HTTP/2.0, ni la mise en place d'une nouvelle interco avec Orange qui divise par 4 la latence avec cet opérateur n'ont eu d'impact notable sur le ressentie utilisateur.
La lourdeur de la page, la qualité des infrastructures opérateur comptent infiniment plus dans le ressenti utilisateur que les optimisations de cet ordre. C'est mon sentiment en tout cas.
Survivre aux changements d'IP c'est intéressant effectivement.
Je suis peut-être excessif mais quand on aspire le web toutes les nuits, il est évident que ce genre de travaux a un intérêt économique démesuré. Le discours marketing sur le bien des utilisateurs me sort par les yeux. S'ils veulent le bien des utilisateurs qu'ils arrêtent la pub.
[^] # Re: Origine du nom ?
Posté par barmic 🦦 . Évalué à 3.
T'es entre de dire qu'il faut arrêter chercher à avoir de la sécurité parce que si on se protège mieux de nos FAI que des sites distants, google peut faire plus de choses que ton FAI ? Je comprends ton point de vu (et je ne suis pas d'accord), comprends tout de même que ce n'est pas si évident que ce que tu présentais au début.
Maintenant pourquoi je ne suis pas d'accord. Ça ne change rien du point de vu que tu donne. Les FAI ont un peu moins de données et Google a déjà énormément plus de données et d'une précision infiniment supérieure. Tu as déjà déjà ce que tu redoute.
Et ben moi, avec un site, j'ai dû loué des F5 pour ça. Ça dépend du profile de tes connexions, mais globalement si ton infra prends un pique de connexion instantanées important. Ça arrive quand tu as des évènements temporel, par exemple pour une billetterie, les retransmissions sportives ou autres.
Ah non ils font ça en continue, ils vont pas s'arrêter parce qu'il y a du soleil ou non.
Où as-tu lu ça de leur part ? Tu ne confondrais pas avec des observateurs qui expliquent l'intérêt du truc ?
Google a l'avantage que ça lui simplifie l'indexation (qu'on est tous bien content d'avoir que ce soit celui de google, bing ou qwant par exemple), mais aussi parce que google ne faisant du business qu'à travers le web il est toujours bon pour lui de pousser les gens à utiliser le web autant que possible.
Les routes servent à des entreprises que je ne portent pas non plus dans mon cœur, je ne me plains pas pour autant que le maintiens des routes aide ses entreprises.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# [Quic-Transport] Contrôle d'erreurs
Posté par lagou . Évalué à 2.
https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-29#section-13.3
Donc pour tout ce qui s'appuie sur RTP, par exemple, QUIC pourrait faire office d'un udp chiffré. En plus de remplacer TCP pour les tunnels http.
[^] # Re: [Quic-Transport] Contrôle d'erreurs
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Attention, le lien pointe vers une vieille version du brouillon de norme. La vraie norme est le RFC 9000.
[^] # Re: [Quic-Transport] Contrôle d'erreurs
Posté par lagou . Évalué à 2.
En effet, j'ai fait au plus court (et n'ai pas pensé regarder quicwg.org) et ai présumé que ça n'avait pas changé.
Le bon lien est https://www.rfc-editor.org/rfc/rfc9000.html#name-retransmission-of-informati
# "ruisseaux"
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Qui utilise le mot "ruisseau" pour traduire "stream"? Est-ce que "flux" ne serait pas plus usité en français?
Je veux bien qu'on essaie d'éviter les anglicismes, mais les traductions littérales approximatives, c'est pas toujours mieux pour rendre les choses lisibles et compréhensibles…
[^] # Re: "ruisseaux"
Posté par orfenor . Évalué à 7.
Moi j'ai bien aimé. Ça nous changeait un peu. Ce ruisseau m'évoquait un printemps sans orages de grêle.
[^] # Re: "ruisseaux"
Posté par Eric P. . Évalué à 10. Dernière modification le 31 mai 2021 à 06:02.
Je ne doute pas que cette traduction ait été choisie volontairement, mais ça reste une faute de traduction qui fait très 'traduction automatique'.
Les dictionnaires donnent les traductions suivantes pour stream:
Ruisseau: (small river)
A stream flows behind their house.
Il y a un ruisseau derrière leur maison.
Flot: (current flowing steadily)
There was a stream of good news.
Il y eut un flot de bonnes nouvelles.
Flux: (data: real-time audio or video)
The audio stream from the web radio station was cut after 20 minutes.
Le flux audio de la station de radio Internet a été interrompu après 20 minutes.
La traduction correcte dans ce cas est clairement flux.
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
[^] # Re: "ruisseaux"
Posté par Philippe F (site web personnel) . Évalué à 7.
Je trouve que ruisseau est bien approprié, au contraire. Avec cette image, je visualise bien la rivière (la connexion principale) et les ruisseaux (des connexions plus petites et rapides) qui en découlent. C'était très élégant comme analogie.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: "ruisseaux"
Posté par aiolos . Évalué à 10. Dernière modification le 31 mai 2021 à 10:11.
Pour ma part, j'avais cru qu'il s'agissait d'un nouveau vocabulaire, référant à une nouvelle logique. J'ai donc été voire la RFC pour voir de quoi il s'agissait et me rendre compte que c'était simplement un "stream" et rien de nouveau :(
edit : je n'avais pas vu/lu la parenthèse
[^] # Re: "ruisseaux"
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
Oui, les petits ruisseaux font une grande rivière.
En fait, c'est la faute d'Abba "I cross the stream \ I have a dream », ce qui est mieux que « Je traverse la rue \ Je trouve un boulot ».
[^] # Re: "ruisseaux"
Posté par orfenor . Évalué à 3.
Une «traduction automatique» venant de Monsieur Bortzmeyer ça m'étonnerait :-)
[^] # Re: "ruisseaux"
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7.
Et comment on traduit "flow", très utilisé dans le RFC ?
[^] # Re: "ruisseaux"
Posté par blobmaster . Évalué à 7.
flot ?
[^] # Re: "ruisseaux"
Posté par gouttegd . Évalué à 7.
Stéphane Bortzmeyer.
[^] # Re: "ruisseaux"
Posté par barmic 🦦 . Évalué à 6.
Mais c'est l'auteur des 2 sources…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: "ruisseaux"
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8.
Flux désigne autre chose. « À l'intérieur d'un ruisseau circule un flux ordonné d'octets. » Le gros problème de flot ou flux, c'est qu'ils sont utilisés pour des tas de choses différentes en réseau.
[^] # Re: "ruisseaux"
Posté par cg . Évalué à 2.
Le coup de la rivière et des ruisseaux, c'est évocateur, mais pas tant que ça. Le fait que l'eau s'écoule permet au cerveau de se représenter la transmission des données, mais c'est à peut près tout. En plus, ça oriente la visualisation sur un flux unidirectionnel.
Une analogie avec des torons qui forment une corde me semble pas mal pour parler de la connexion et du multiplexage.
# QoS
Posté par nlgranger . Évalué à 3.
Il y a quelque-chose de prévu pour faire de la qualité de service? Par exemple pour différencier un paquet qui peut partir à la poubelle ou pour indiquer le besoin en latence?
[^] # Re: QoS
Posté par xryl669 . Évalué à 3.
Non
[^] # Re: QoS
Posté par fredezic . Évalué à 1.
diffserv est au niveau de la couche 3 (IP), donc quic devrait pouvoir en bénéficier
# Transfert sur liaison haut débit haute latence
Posté par cg . Évalué à 4.
Je suis curieux de voir si ça peut concurrencer UDT/UDR, HPN-SSH ou Aspera pour le cas des transferts sur des grosses liaisons intercontinentales (10Gbps ou plus, 100ms de ping).
[^] # Re: Transfert sur liaison haut débit haute latence
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Déjà, FASP (le protocole derrière Aspera) est un truc privé, fermé et breveté.
Ensuite, faire passer davantage d'octets par seconde est facile si on ne tient pas compte des autres. Un protocole égoïste va toujours pouvoir faire mieux. Ce n'est pas grave si on a des liens dédiés mais QUIC est fait pour l'Internet ouvert.
UDT est abandonné, non ?
HPN-SSH utilise TCP, donc hérite des avantages et inconvénients de TCP. https://linuxfr.org/users/obsider/journaux/high-performance-ssh
[^] # Re: Transfert sur liaison haut débit haute latence
Posté par cg . Évalué à 3.
Je me suis mal exprimé je crois. Je vais donner des exemples pour clarifier ma question.
Cas d'usage 1 : J'utilise UDT au quotidien via le wrapper UDR (rsync+udt), ça m'a permis de passer de 6-10 heures de temps de synchro à 30-45 minutes, sur une ligne 1Gbps avec 90ms de RTT. Donc je dirais que l'outil est peut-être abandonné, mais en tout cas il marche d'enfer !
Cas d'usage 2 : J'ai un serveur de fichiers (genre NextCloud File Drop, donc https) sur Internet en France, mes clients sont à Los Angeles et doivent récupérer 500Go de fichiers (RTT=140ms). En faisant des downloads en parallèle on peut accélérer le transfert, mais ce n'est pas toujours supporté côté client ou pas pratique.
Ma question donc : dans ce genre de cas, est-ce qu'un protocole comme QUIC me permet d'aller presque à la vitesse du lien sans bricoler ? Genre avec un "bête" curl, et surtout sans truc compliqué et cher comme FASP.
[^] # Re: Transfert sur liaison haut débit haute latence
Posté par cg . Évalué à 5.
À relire la chouette dépêche, je crois que la réponse est partiellement dedans :
« En pratique, QUIC a été conçu essentiellement en pensant à HTTP mais dans le futur, d’autres protocoles pourront profiter de QUIC, notamment s’ils ont des problèmes qui ressemblent à ceux du Web (désir de faible latence, et de multiplexage). »
# Inconvénients ?
Posté par pamputt . Évalué à 6.
Bonjour, en tant que béotien, quand je lis cette dépêche, je retiens que QUIC est très bien car il résout beaucoup de problème de TCP. J'ai également noté qu'il est surtout pensé pour les applications qui nécessite une faible latence (HTTP par exemple).
Du coup, est ce que ce protocole n'a aucun défaut ? Est ce qu'il offre de moins bonnes performances (lesquelles ?) pour les applications qui se foutent de la latence ?
[^] # Re: Inconvénients ?
Posté par barmic 🦦 . Évalué à 5.
Par rapport à ses 2 grands frères (c'est à prendre comme un point de vu) :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Inconvénients ?
Posté par KiKouN . Évalué à 9.
Utilisant UDP, il en reprends aussi les défauts. Je pense surtout au problème pour les attaques DoS.
QUIC peut déjà être utilisé comme amplification d'attaque DoS. L'entête de première réponse du serveur contient le certificat du serveur pour ouvrir la session TLS au plus tôt. L'effet est limité en demandant au client d'envoyer un gros premier paquet d'ouverture de session.
Le port QUIC peut-être simplement flooder aussi comme le ferai une attaque de type TCP-SYNFLOOD. Je suppose que les serveurs auront un moyen de se protéger (limitation par ip, SNI ou autre) mais il va être difficile de faire grands chose au niveau d'un firewall avant un serveur. Avec TCP, on peut faire un proxy tcp-syn avec iptables par exemple qui vérifie la véracité d'une connexion TCP avant de la donner au serveur. Avec QUIC, je ne sais pas si cela est possible sans avoir recours à un vrai proxy logiciel qui devra avoir au moins les certificats pour chaques SNI. Les premiers paquets des sessions QUIC devant être plus gros pour limiter l'amplification en cas d'attaque par rebond, une attaque DoS de type TCP-SYNFLOOD utilisant QUIC pourra viser la saturation du serveur et la saturation des liens réseaux.
Je ne doute pas que les gros vont avoir des solutions pour cela. Mais en tant que petit, quel seront les solutions pour se protéger de ces attaques ?
[^] # Re: Inconvénients ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
Non, c'est faux. Beaucoup de gens ne connaissent de QUIC que le « il tourne sur UDP » et se disent « ah mon Dieu, ça va servir pour des attaques par réflexion ». Ce serait comme de dire de TCP qu'il permet des attaques par réflexion car il tourne sur IP, qui permet ces attaques.
QUIC, comme TCP, teste la réversibilité ("returnability") et ne peut donc pas servir pour des attaques par réflexion.
Pour le premier datagramme (pour lequel on n'a pas encore pu tester la réversibilité), QUIC limite le BAF (Bandwith Amplification Factor) à trois. C'est pour cela que le premier datagramme du client est souvent si gros (le RFC recommande 1 200 octets), afin d'être sûr que les certificats tiendront dans la réponse. Rappelons que TCP, sur Linux, a un PAF (Packet Amplification Factor) de 5 (oui, 5 datagrammes TCP sont envoyés en réponse au premier datagramme, pour lequel la réversibilité n'a pas été testée).
[^] # Re: Inconvénients ?
Posté par Pol' uX (site web personnel) . Évalué à 6.
A vue de nez, ça se paie au moins en complexité d'implantation. Pas dit qu'on fasse du quick avec un petit micro contrôleur pour lequel la gestion de tcp est déjà parfois un exploit technique.
Adhérer à l'April, ça vous tente ?
[^] # Re: Inconvénients ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Oui, pour l'instant, QUIC n'est prévu que pour des ordinateurs classiques, pas pour des objets connectés (qui n'auraient de toute façon sans doute rien à faire des avantages de QUIC comme le parallélisme).
[^] # Re: Inconvénients ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Est-ce que quick a un truc comme le header http "authentication", pour avoir des tokens jwt ou autre et avoir de la securité entre machine sans http ?
"La première sécurité est la liberté"
[^] # Re: Inconvénients ?
Posté par barmic 🦦 . Évalué à 4.
Tu peux faire de l'auth dans les 2 sens avec TLS, donc faut un certif coté client aussi.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Inconvénients ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Gérer des certificats des 2 cotés, c'est autrement plus complexe que d'en avoir un seul dont la signature est vérifié d'un coté. De plus, on peut ajouter des trucs dedans comme les rôles, etc…
"La première sécurité est la liberté"
[^] # Re: Inconvénients ?
Posté par barmic 🦦 . Évalué à 4.
C'est plus compliqué qu'un basic auth, mais par rapport à jwt c'est discutable. jwt demande de gérer le renouvellement etc. Mettre en place un certificat coté client n'est pas si compliqué que ce que l'on imagine.
On peut ajouter un tas de trucs dans un token jwt comme dans un certificat X509. Je pense que les 2 ont la même expressivité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Inconvénients ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
Une partie des défauts ne seront découverts qu'avec le temps (comme cela a été le cas pour TCP). Le retour d'expérience existe mais ne doutons pas qu'on verra des problèmes à l'usage quand il sera plus massif et plus distribué.
Un défaut possible, mais pas encore exploré, est la facilité de suivre un utilisateur donné au cours du temps, puisque les sessions peuvent être longues (et survivent aux changements d'adresses IP). QUIC protège mieux contre un surveillant extérieur mais moins bien contre l'extrémité (le serveur). En pratique, ce n'est sans doute pas un vrai problème car HTTP, notamment grâce aux cookies, transmet déjà largement assez pour le suivi de l'utilisateur (suivi qui, contrairement à QUIC, s'étend au-delà d'un seul serveur, grâce à Google Analytics et aux boutons de partage des GAFA). Par contre, si on développe un système tout nouveau et orienté vie privée, le client devra veiller à ne pas laisser les sessions QUIC durer trop longtemps et survivre aux changements d'adresses IP. Bref, QUIC sur Tor ne serait sans doute pas pertinent.
[^] # Re: Inconvénients ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
J'ai détaillé cette analyse dans un article.
[^] # Re: Inconvénients ?
Posté par barmic 🦦 . Évalué à 3.
Je ne comprends pas très bien l'implémentation est au courante de du changement d'adresse puisqu'elle doit changer d'identifiant, non ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Inconvénients ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 6.
Le client QUIC n'est pas forcément au courant du changement d'adresse IP (qui peut se produire loin de lui, par exemple dans un routeur NAT). Et, justement, le principe du "Connection ID" de QUIC est qu'il sert à identifier une connexion (qui, en TCP, est identifiée par l'adresse IP), ce qui est bon pour les performances et la robustesse, mais mauvais pour la vie privée.
[^] # Re: Inconvénients ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
On peut imaginer que Firefox ouvre une nouvelle socket Quick pour chaque site de base en suivant les règles habituelles d’étanchéité des URL. Cela évitera d'avoir une socket ouverte en permanence chez akamai, netlify ou autre.
"La première sécurité est la liberté"
# Et SCTP
Posté par Sébastien Koechlin . Évalué à 4.
Je n'ai pas vu mentionné SCTP en fr qui semble prometteur sur le papier. Multiplexage, échange de messages de taille arbitraire, répartition vers plusieurs serveurs cibles… Ça semble bien adapté pour un serveur web.
J'imagine qu'il souffre méchamment du filtrage à outrance. J'ai l'impression que ça stagne depuis des années.
[^] # Re: Et SCTP
Posté par claudex . Évalué à 4.
Il me semble que c'est le cas d'école qui montre qu'il est impossible de se passer de tcp/udp pour pouvoir joindre des machines hors de réseaux entièrement maîtrisé.
« 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: Et SCTP
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
Le fait de gérer les frontières de message n'a pas en pratique convaincu tellement de monde. Sinon, SCTP n'a pas d'avantage suffisamment écrasant sur TCP. Mais il est dans le noyau Linux depuis un certain temps, donc vous pouvez l'utiliser.
Victime du filtrage massif fait par les opérateurs, il a en effet du mal à passer partout. Aujourd'hui, il est en général employé sur UDP (RFC 6951).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.