Il manque un ou deux mots dans la première phrase, ce qui la rend difficile à comprendre. Si l'idée était de dire qu'Ethernet a été inventé en France, il faut me prévenir, que je renforce mon bullshitomètre pour qu'il tienne le coup.
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.
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).
Utilisant UDP, il en reprends aussi les défauts. Je pense surtout au problème pour les attaques DoS.
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).
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.
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.
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 :-)
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).
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.
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.)
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).
Importer le fichier ne semble pas marcher. "
Erreur
Aucun code QR ou 2D-DOC détecté dans le document. Essayez de recadrer le document pour que le code apparaisse clairement et dans une taille raisonnable."
En plus, je suis sûr que ça va être comme TousAntiCovid, ça ne marchera pas sur mon Fairphone 1 avec ma copie patchée de /e/ flashée à la main la nuit. Tout ça parce que Cédric O n'est même pas programmeur !
quand tu dis que ces domaines sont illégaux, tu parles bien juste de ces règles de syntaxe pour ce domaine spécifique de premier niveau (.kz)
Non, pas du tout, je parlais des règles techniques internationales, qui s'imposent à tout acteur (mais comme il n'y a pas de police de l'Internet, certains font ce qu'ils veulent).
parce que techniquement avec les Internationalized Domain Name, un registry pourrait décider d'accepter les émoticones
Certains registres le font, mais c'est une violation de la norme technique (RFC 5892), qui limite les noms (en gros) aux lettres et aux chiffres.
je ne vois pas trop de raisons pour interdire cela au niveau des normes
Les émojis ne sont pas explicitement interdits, c'est juste que la norme est conservatrice, n'autorisant que ce qui est explicitement permis. Les émojis n'étant pas autorisés sont donc interdits.
Il y a bien les problèmes de ne pas mélanger les scripts pour un nom de domaine donné (et ainsi éviter les attaques homographes)
Il aurait fait un système entièrement à lui (un nouveau réseau social centralisé, par exemple), OK. Ces adresses auraient alors peut-être été inutiles mais sans être une escroquerie. Mais, là, il les présente comme des adresses de courrier électronique, ce qu'elles ne sont pas, puisque je ne peux pas y écrire depuis ma machine Debian avec son Postfix.
[^] # Re: Naïveté et ignorance sont les 2 mamelles du renoncement
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Quel lien entre souveraineté numérique et logiciel libre ?. Évalué à 9.
Il manque un ou deux mots dans la première phrase, ce qui la rend difficile à comprendre. Si l'idée était de dire qu'Ethernet a été inventé en France, il faut me prévenir, que je renforce mon bullshitomètre pour qu'il tienne le coup.
[^] # Re: What?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse au journal Gitlab, Github & Stackoverflow sont inaccessibles simultanément. Évalué à 4.
Hélas non.
[^] # Re: What?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse au journal Gitlab, Github & Stackoverflow sont inaccessibles simultanément. Évalué à 9.
La bonne solution est plutôt de ne pas tout concentrer dans quelques gros silos/sites.
[^] # Re: "panne mondiale"
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse au journal Gitlab, Github & Stackoverflow sont inaccessibles simultanément. Évalué à 7.
Gitlab.com était touché aussi ? Le Gitlab que j'utilise (Framagit) marchait. Des tas de développeurs ont continué à bosser.
[^] # Re: "panne mondiale"
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse au journal Gitlab, Github & Stackoverflow sont inaccessibles simultanément. Évalué à 9.
Et pour cause, l'Internet marchait https://www.bortzmeyer.org/panne-fastly-presentation.html
[^] # Re: Inconvénients ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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 Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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: Transfert sur liaison haut débit haute latence
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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: "ruisseaux"
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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 Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. Évalué à 7.
Et comment on traduit "flow", très utilisé dans le RFC ?
[^] # Re: "ruisseaux"
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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: Origine du nom ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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: [Quic-Transport] Contrôle d'erreurs
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. Évalué à 5.
Attention, le lien pointe vers une vieille version du brouillon de norme. La vraie norme est le RFC 9000.
[^] # Re: Belle rédaction
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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 Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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: Chiffrement
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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: Belle rédaction
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Le protocole QUIC désormais normalisé. É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: Erreur Aucun code QR ou 2D-DOC détecté dans le document.
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Sanipasse : le déconfinement libre !. Évalué à 2.
J'ai honte, mais je ne sais pas recadrer un PDF sur Ubuntu.
# Erreur Aucun code QR ou 2D-DOC détecté dans le document.
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Sanipasse : le déconfinement libre !. Évalué à 3.
Importer le fichier ne semble pas marcher. "
Erreur
Aucun code QR ou 2D-DOC détecté dans le document. Essayez de recadrer le document pour que le code apparaisse clairement et dans une taille raisonnable."
[^] # Re: Espérons que cela reste un poisson d'avril !
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Mise en place du port du masque avec QrCode d'identification. Évalué à 2.
Clairement un complot de Beijing.
# Gouvernement d'incompétents qui ne comprend rien au numérique
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Mise en place du port du masque avec QrCode d'identification. Évalué à 10.
En plus, je suis sûr que ça va être comme TousAntiCovid, ça ne marchera pas sur mon Fairphone 1 avec ma copie patchée de /e/ flashée à la main la nuit. Tout ça parce que Cédric O n'est même pas programmeur !
[^] # Re: Héberger une page "statique" en Gemini
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 4.
Le client en question est sans doute Lagrange.
[^] # Re: Attention, escroquerie
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse au journal titre. Évalué à 6. Dernière modification le 13 mars 2021 à 11:02.
Non, pas du tout, je parlais des règles techniques internationales, qui s'imposent à tout acteur (mais comme il n'y a pas de police de l'Internet, certains font ce qu'ils veulent).
Certains registres le font, mais c'est une violation de la norme technique (RFC 5892), qui limite les noms (en gros) aux lettres et aux chiffres.
Les émojis ne sont pas explicitement interdits, c'est juste que la norme est conservatrice, n'autorisant que ce qui est explicitement permis. Les émojis n'étant pas autorisés sont donc interdits.
Ces attaques sont un argument largement pipeau.
[^] # Re: Attention, escroquerie
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse au journal titre. Évalué à 6.
Il aurait fait un système entièrement à lui (un nouveau réseau social centralisé, par exemple), OK. Ces adresses auraient alors peut-être été inutiles mais sans être une escroquerie. Mais, là, il les présente comme des adresses de courrier électronique, ce qu'elles ne sont pas, puisque je ne peux pas y écrire depuis ma machine Debian avec son Postfix.