Planet Collab

🔒
❌ About FreshRSS
There are new available articles, click to refresh the page.
Yesterday — November 29th 2020Your RSS feeds

Le protocole Gemini, revenir à du simple et sûr pour distribuer l'information en ligne ?

By Stéphane Bortzmeyer

Comme beaucoup de gens, je trouve que le Web, tout en étant un immense succès, souffre de plusieurs défauts. Tous ne proviennent pas de la technique, mais certains peuvent quand même être reliés à des choix lors de la conception des protocoles et formats. C'est par exemple le cas des problèmes de vie privée, car HTTP et HTML fournissent trop de moyens de pister les utilisateurs, et des problèmes stratégiques autour des navigateurs : aujourd'hui, écrire un navigateur Web complet, disons l'équivalent de Firefox, est une tâche colossale, réservée à de très grosses équipes très pointues. Cela limite la concurrence : seuls trois ou quatre navigateurs vraiment différents existent et encore moins de moteurs de rendu. (Et je n'ai pas encore mentionné le désir de davantage de sobriété numérique et d'empreinte environnementale réduite.) Le projet Gemini s'attaque à ce problème en définissant un nouveau protocole et un nouveau format, délibérement très simples et non extensibles, afin de rendre plus difficile l'apparition des mêmes problèmes que dans le Web.

Gemini est donc très simple. Il utilise :

  • Un protocole à lui, qui ressemble un peu à la version 0.9 de HTTP (en mieux, quand même),
  • Un format à lui, une sorte de version simplifiée et uniformisée de Markdown,
  • Les URL que nous connaissons,
  • Le TLS que nous connaissons.
Un point important et délibéré de Gemini est son absence d'extensibilité. Le but est d'éviter ce qui est arrivé au Web, où un protocole simple et sûr du début a évolué en un gros machin compliqué et dangereux. Ainsi, Gemini n'a pas d'en-têtes de requêtes ou de réponses. Y ajouter un outil de flicage comme les cookies sera donc difficile et c'est exprès.

Si vous êtes intéressé par ce projet, consultez le site Web pour avoir une première idée. Si vous avez des questions (notamment si vous en êtes au stade « ah, les cons, pourquoi ils n'ont pas tout simplement utilisé X et/ou fait comme Y ? »), il est probable que la FAQ très détaillée y répondra. Si vous êtes d'humeur à lire l'actuelle spécification, elle est aussi sur le Web. Mais beaucoup d'autres ressources à propos de Gemini ne sont évidemment pas sur le Web, mais dans le « geminispace ».

Comme ce « geminispace » ne peut pas se visiter avec un navigateur Web classique, il va falloir un client Gemini. Il en existe beaucoup. La plupart sont assez sommaires mais les lectrices et lecteurs de mon blog sont des gens avertis et qui savent qu'il ne faut pas juger un système de publication à ses interfaces actuelles. Déjà, je vais commencer par supposer que vous ne voulez pas installer un Nième logiciel sur votre machine mais que vous voudriez quand même jeter un coup d'œil. Ça tombe bien, plusieurs clients Gemini sont disponible sur un serveur SSH public. Connectez-vous en SSH à kiosk@gemini.circumlunar.space et essayez le client de votre choix. Personnellement, j'utilise Amfora. Vous pouvez visiter les liens de la page d'accueil en tapant espace puis leur numéro. À la place d'un numéro, vous pouvez aussi indiquer un URL Gemini comme gemini://gemini.bortzmeyer.org/. Si vous voulez tester plus loin, vous pouvez installer Amfora ou bien un des autres clients. Sur Arch Linux, c'est aussi simple que de taper pacman -S amfora. Comme vous vous en doutez, il n'y a pas encore beaucoup de contenu disponible mais ça grossit tous les jours.

Et si vous voulez un serveur, pour distribuer vos idées géniales au monde entier ? Il existe plusieurs serveurs en logiciel libre, mais pas de page Web pour les présenter, il faut aller dans le geminispace en gemini://gemini.circumlunar.space/software/. J'ai choisi de commencer avec Agate. Agate est écrit en Rust donc on l'installe en général par la méthode Rust habituelle, cargo install agate. Ensuite, il nous faut un certificat car Gemini impose TLS (notez qu'il semble que pas mal de serveurs Gemini n'aient qu'un certificat auto-signé). Demandons à Let's Encrypt :

# certbot certonly -n --standalone --domain gemini.bortzmeyer.org
  
Et je copie certificat et clé privée dans un répertoire à moi, pour ne pas exécuter Agate en étant root. (Pour le renouvellement du certificat, dans trois mois, il faudra que je trouve une solution plus pérenne.) Ensuite, je lance le serveur :
% ~/.cargo/bin/agate gemini.bortzmeyer.org:1965 /var/gemini fullchain.pem privkey.pem gemini.bortzmeyer.org
  
(Pourquoi le port 1965 est-il le port par défaut ? Je vous laisse chercher un peu.)

Mais il reste à ajouter du contenu, dans le répertoire /var/gemini qu'on a indiqué au serveur. Ce contenu est dans un format spécifique à Gemini, qui ressemble à Markdown, en plus limité. Je vous le dis tout de suite : il n'y a pas d'images ! Finies, les photos de chats mignons ! Voici le source de la page d'accueil de mon serveur :

% cat index.gmi 
# First Gemini test

No actual content yet

=> https://www.afnic.fr/ AFNIC Web site
  
Vous noterez :
  • Le titre (équivalent du <h1> de HTML) s'écrit comme en Markdown.
  • Le texte s'écrit sans marques particulières.
  • Les liens sont forcément sur une ligne. On ne peut pas faire d'hypertexte. (En prime, j'ai mis un lien Web, ce qui n'est pas très géministe et ne marchera pas avec les clients Gemini non-Web.)

Voilà, je vais essayer de mettre un peu plus de contenu que ce premier exemple mais ne comptez pas sur une publication de mon blog en Gemini : l'absence d'hypertexte nécessiterait de réécrire sérieusement les articles.

Conclusion ? Ne me demandez pas si Gemini sera un succès ou pas, je suis mauvais pour les pronostics. Je dis juste que je suis content de voir que des gens ne se résignent pas à déplorer les problèmes du Web mais qu'ils essaient de les résoudre.

Autres articles en français sur Gemini :

  • November 29th 2020 at 01:00
Before yesterdayYour RSS feeds

Paris démasqué

By Stéphane Bortzmeyer

Le citadin arrogant peut imaginer que les légendes, les monstres, les histoires irrationnelles ne naissent qu'à la campagne, chez des ruraux mal dégrossis, les seuls à croire à ces récits fantastiques. Mais les villes ont aussi leurs contes fabuleux, leurs angoisses et leurs mythes. Les auteurs s'attaquent ici à quelques histoires étonnantes qui prennent place à Paris, et en profitent pour analyser l'inconscient des concentrations urbaines.

Ce livre cite vingt mythes très différents. Mythes car, quoi qu'un bon nombre parte d'évènements et de personnages réels, ce qui intéresse les auteurs, c'est ce qu'en a fait la psychologie collective. Prenons quelques exemples.

Il y a des histoires inspirées par les crimes et la répression de ces crimes, répression souvent aussi horrible que le crime lui-même. Un chapitre du livre rappelle ainsi l'histoire du gibet de Montfaucon, à l'époque où on assassinait légalement (« nous fûmes occis par justice », dit François Villon) aux quatre coins de Paris, là où on ne trouve aujourd'hui que des gentilles boulangeries bio. Montfaucon était conçu pour être visible et pour faire peur et le gibet, scène d'horreur en pleine ville, a en effet marqué les imaginations pour de nombreux siècles.

Un autre chapitre est consacré aux grands drames collectifs qui ont frappé la ville. Il y a par exemple l'angoisse des rats (vous connaissiez le terme de musophobie, qui n'est même pas dans le Wiktionnaire ?) Cette angoisse se base sur des faits réels (le rôle des rats dans des maladies comme la peste) mais a souvent dérivé vers l'irrationnel, voire le racisme. Les auteurs citent le « les rats sont coupables, les rastas ne sont pas innocents » [dans la presse de l'époque, « rasta » est un étranger oriental], du journaliste d'extrême-droite José Germain, qui rappelle que les temps d'épidémie sont propices aux délires et aux mensonges.

Il y a bien sûr aussi un chapitre sur les récits politiques. La sainte patronne de Paris, sainte Geneviève, est un personnage historique réel. Mais elle a fait l'objet d'un gros travail de mythification. C'était une aristocrate, dirigeante politique habile dans des temps très troublés, mais on en a fait une humble bergère, avant de la considérer comme un symbole de la monarchie et de l'Église pendant la Révolution, où ses restes ont été détruits. Puis de nos jours on met davantage en avant son intelligence politique, plutôt que sa piété. Chaque époque met Geneviève à sa sauce.

En parlant de politique, le chapitre sur les « spectres et maléfices » évoque entre autres les pétroleuses. Là encore, il s'agit d'un phénomène historique réel (la participation des femmes à la Commune, pas les incendiaires se promenant avec leur bidon de pétrole) mais qui a été transformé par la presse versaillaise : les pétroleuses n'étaient pas simplement dépeintes comme des adversaires politiques mais comme des monstres inhumains. (Et c'est l'occasion de rappeler que, en deux mille et quelques années d'une histoire souvent troublée, le plus grand massacre qui ait jamais eu lieu à Paris a été commis par l'armée française.)

Paris n'est pas isolée, il y a la banlieue tout autour. Ah, la banlieue, comme objet de fantasmes et de peurs… Cela ne date pas d'aujourd'hui : la forêt de Bondy a ainsi droit à une place, car pendant longtemps, c'était le coupe-gorge qui faisait peur à tout les parisiens. Dans les mythes, le danger est toujours à l'extérieur…

Je ne vais pas résumer toutes les histoires que contient ce livre. Juste terminer en disant que j'ai été très ému, par le rappel dans le chapitre sur les épreuves collectives subies par la ville, des attentats djihadistes de janvier et novembre 2015. Le récit se termine par un message d'espoir : Paris n'a pas cédé.

  • November 28th 2020 at 01:00

My Preparation for the Wireshark WCNA Exam

By Wassim Aouadi

In this article I explain how I am preparing for the Wireshark WCNA exam. Study resources Laura Chappell’s WCNA Official Study Guide. Here. CBT Nuggets…

The post My Preparation for the Wireshark WCNA Exam appeared first on Keyboardbanger.com.

“Skype for Business ends in July 2021. Migrate now to MS Teams!”… or not?

By LuisR
Some of my contacts and older customers have been coming to me because they were getting approached by some MS Partners that they must migrate their SfB infrastructure to Teams because ‘SfB is dead’ and ends in July 2021. I…

Continue reading

“Skype for Business ends in July 2021. Migrate now to MS Teams!”… or not?

By LuisR
Some of my contacts and older customers have been coming to me because they were getting approached by some MS Partners that they must migrate their SfB infrastructure to Teams because ‘SfB is dead’ and ends in July 2021. I will not finger-point no one here, but I want to clarify headers and speeches like […]

Genesys PureConnect

By aravindan.thambu@gmail.com

Hi All


What is Genesys Pure Connect
Genesys PureConnect is a hybrid call center solution that provides users with various tools and functionalities,
which help them to manage their business operations and communications from a single integrated platform.
The solution can be either be deployed on-premise or hosted in the cloud


What is Genesys cloud?
Genesys Cloud is a suite of cloud services for enterprise-grade communications, collaboration, and contact center management. … Genesys Cloud Communicate adds telephony features to Collaborate, making it a unified communications solution. Features include phone, voicemail, conferencing, and transfers.

https://help.mypurecloud.com/articles/genesys-cloud/

What is Genesys Pure Engage ?

PureEngage is a customer engagement suite designed for global businesses, available both on-premises and in the cloud.
PureEngage enables contact centers to provide great customer experience through every channel: voice, chat, social, email, video, web and more.


And in the coming days we will see about few components which involve in Genesys Pure connect call flow.
https://help.genesys.com/resource-center-cic.html >> you will find all documents about Pure Connect and other Genesys Products in this official link

The post Genesys PureConnect appeared first on UC Collabing.

Le service MySocket, pour donner un accès Internet à ses développements locaux

By Stéphane Bortzmeyer

Le service MySocket vient d'être lancé. À quoi ça sert ? À plusieurs choses mais le scénario d'utilisation le plus évident est le cas où vous avez un service TCP/IP sur une machine de développement et vous voudriez que des gens dans le vaste monde l'essaient. Mais, pour des raisons diverses, cette machine de développement n'est pas accessible depuis l'Internet. MySocket est un relais qui va prendre les connexions des gens extérieurs et les apporter à votre service.

Il y a beaucoup de cas où la machine sur laquelle vous êtes en train de travailler ne peut pas être contactée par des clients situés sur l'Internet. Le plus évident est celui où vous êtes coincé sur un réseau attardé qui n'a pas IPv6 (ou bien que vos clients n'ont pas IPv6) et que le NAT empêche ces connexions entrantes. (Ou, encore pire, le service est dans un conteneur Docker double-NATé…) MySocket va agir comme un mini-Cloudflare, il va fournir une prise réseau à laquelle vos clients se connecteront et, derrière, cela viendra chez vous. C'est très pratique pour des essais, du développement, etc.

MySocket a été présenté dans cet article. Mais vous avez une documentation complète en ligne. Pratiquer est un bon moyen de voir en quoi ce service consiste concrètement, donc allons-y.

MySocket se pilote via son API. Il ne semble pas y avoir d'interface Web pour les utilisateurs en ce moment. Pour parler à l'API, vous pouvez écrire votre propre programme ou, plus simple, utiliser le client mysocketctl développé par MySocket. (Son source est disponible.) C'est un script Python donc on l'installe de manière pythonienne :

%   pip3 install --user mysocketctl 
...
Successfully installed mysocketctl-0.3
  

La connexion entre MySocket et votre service se fera forcément en SSH. Donc, il faut une clé SSH. Ici, je vais en créer une dédiée à ce service MySocket :

% ssh-keygen -t ed25519 -f ~/.ssh/id_mysocket
...
Your public key has been saved in /home/stephane/.ssh/id_mysocket.pub.

%  ssh-add ~/.ssh/id_mysocket
  

On peut maintenant se créer un compte sur le service MySocket (je me répète mais il n'y a pas d'interface Web pour cela) :

% mysocketctl account create \
    --name "Stéphane Bortzmeyer" \
    --email "foobar@example.com" \
    --password "Plein de caractères" \
    --sshkey "$(cat ~/.ssh/id_mysocket.pub)"
Congratulation! your account has been created. A confirmation email has been sent to foobar@example.com
Please complete the account registration by following the confirmation link in your email.
...
  
Une fois reçu le message de confirmation envoyé par courrier, vous suivez le lien et votre adresse est confirmée. Note amusante : la réponse du serveur Web sera en JSON (oui, oui, avec le type application/json), et composée de la chaîne "You have confirmed your account. Thanks!".

Les opérations de gestion des prises réseau nécessiteront un jeton d'authentification que l'on crée avec la commande login, et qui est valable quelques heures (après, vous aurez un Login failed) :

% mysocketctl login \
    --email "foobar@example.com" \
    --password "Plein de caractères" 

Logged in! Token stored in /home/stephane/.mysocketio_token
(À l'heure actuelle, ce fichier .mysocketio_token est créé avec les permissions par défaut. Vous aurez peut-être besoin de durcir ses permissions.)

Voilà, à ce stade, vous avez un compte, vous avez un jeton d'authentification, on peut créer une prise. mysocketctl permet de le faire de manière simple, ou de manière plus compliquée mais permettant davantage de choses. Commençons par la manière simple :

% mysocketctl connect \
    --port 8080 \
    --name "Youpi"

+--------------------------------------+--------------------------------+-------+
|              socket_id               |            dns_name            |  name |
+--------------------------------------+--------------------------------+-------+
| 3d66b504-677f-4e68-85a7-bb63da251007 | shy-bush-6765.edge.mysocket.io | Youpi |
+--------------------------------------+--------------------------------+-------+

Connecting to Server: ssh.mysocket.io
...
Youpi - https://shy-bush-6765.edge.mysocket.io 
...
(Si vous récupérez un Permission denied (publickey), vérifier que la clé SSH a bien été chargée dans l'agent avec ssh-add.) Et voilà, une prise a été créée et elle est accessible du monde extérieur via le nom shy-bush-6765.edge.mysocket.io. Par défaut, c'est une prise HTTPS et les clients sont donc censés s'y connecter avec l'URL indiqué https://shy-bush-6765.edge.mysocket.io. Notez bien que vous ne choisissez pas le nom de domaine, il est attribué par MySocket et vous êtes donc dépendant d'eux, y compris dans le nom publié. On l'a déjà dit : MySocket est surtout conçu pour du développement, du temporaire, pas pour le site e-commerce de votre entreprise.

Maintenant, un client, par exemple un navigateur Web, va essayer de se connecter à cet URL. Et paf, on a un 502 Bad Gateway. Qu'est-ce que cela veut dire ? Tout simplement qu'on a créé la prise, qu'on l'a connectée au port 8080 de notre machine mais que rien n'écoute sur ce port (d'où l'erreur 502, RFC 7231, section 6.6.3). Il nous faut développer un petit service. Ici, on va utiliser le module http.server de Python :

#!/usr/bin/env python3

import http.server

server_address = ('', 8080)
httpd = http.server.HTTPServer(server_address,
                               http.server.SimpleHTTPRequestHandler)
httpd.serve_forever()
  
Simple, non ? Cela crée un serveur HTTP (rappelez-vous que par défaut mysocketctl crée une prise HTTP), écoutant sur le port 8080 et traitant les requêtes avec la classe SimpleHTTPRequestHandler. Cette classe contient du code pour les méthodes HTTP comme GET et, par défaut, elle crée un petit serveur de fichier qui sert les fichiers locaux. Exécutons ce serveur :
% ./test-mysocket.py    
...
127.0.0.1 - - [25/Nov/2020 18:13:06] "GET / HTTP/1.0" 200 -
  
Ça marche, le client HTTP reçoit cette fois le code de retour 200 indiquant que tout va bien, et il voit la liste des fichiers locaux. La ligne commençant par 127.0.0.1 est le journal qu'affiche par défaut le module http.server. Le premier champ est l'adresse IP du client, ici 127.0.0.1, l'adresse de la machine locale, car c'est le client MySocket, lancé par mysocketctl qui s'est connecté à ce service. Si on veut voir la vraie adresse du client, il faut regarder le journal de mysocketctl :
192.0.2.106 - - [25/Nov/2020:17:13:06 +0000] "GET / HTTP/1.1" 200 432 "-" "curl/7.64.0" response_time="0.032 secs"
  
C'est pratique, on a la vraie adresse IP du client. Elle est également disponible dans les en-têtes de la requête HTTP, champs X-Real-IP: et X-Forwarded-For: (mais hélas pas avec l'en-tête standard du RFC 7239).

Pendant que tout marche et que le bonheur coule à flot, regardons d'un peu plus près le service que fournit MySocket. Je crée une prise, et on m'obtient le nom purple-surf-7070.edge.mysocket.io. Ce nom a une adresse IP (IPv4 seul, hélas) :

% dig A purple-surf-7070.edge.mysocket.io
...
;; ANSWER SECTION:
purple-surf-7070.edge.mysocket.io. 300 IN A 75.2.104.207
  
Mais cette adresse IP ne correspond pas à une seule machine : MySocket utilise l'anycast pour que cette adresse IP soit toujours proche de vous. (Évidemment, seul MySocket est anycasté, votre service ne tourne toujours que sur une seule machine.) Pour réaliser cela, MySocket tourne sur un service d'AWS (Global Accelerator) qui n'a hélas pas IPv6. Testons l'adresse IP avec les sondes RIPE Atlas :
% blaeu-reach -r 200 75.2.104.207
197 probes reported
Test #28277168 done at 2020-11-25T17:23:21Z
Tests: 584 successful tests (98.8 %), 0 errors (0.0 %), 7 timeouts (1.2 %), average RTT: 19 ms
  
On voit un RTT moyen très court, montrant bien l'intérêt de l'anycast.

Je n'ai pas utilisé cette possibilité, mais notez que MySocket permet également de créer des prises protégées (avec l'option --protected). Pour HTTP, ce sera avec l'authentification simple du RFC 7235. mysocketctl connect --help si vous voulez des détails, je n'ai personnellement pas testé.

J'ai dit qu'il y avait deux manières de gérer les prises, une simple et une plus compliquée. On vient de tester la simple, avec mysocketctl connect qui crée la prise, y connecte votre service, et nettoie lorsqu'il se termine. Maintenant, on va procéder en deux temps, d'abord en créant la prise, sans y connecter notre service :

% mysocketctl socket create --name "Youpi" 
+--------------------------------------+-----------------------------------+---------+------+-------+
|              socket_id               |              dns_name             | port(s) | type |  name |
+--------------------------------------+-----------------------------------+---------+------+-------+
| c5d771fe-1ae8-4254-a8bd-fb8b1f4c293e | lively-rain-9509.edge.mysocket.io |  80 443 | http | Youpi |
+--------------------------------------+-----------------------------------+---------+------+-------+
  
On dispose désormais d'une prise « permanente » (qui ne disparait pas quand on a cessé de se connecter). mysocketctl socket ls me donnera la liste de ces prises. Pour utiliser la prise, il faut créer un tunnel :
% mysocketctl tunnel create --socket_id c5d771fe-1ae8-4254-a8bd-fb8b1f4c293e 
+--------------------------------------+--------------------------------------+---------------+------------+
| socket_id                            | tunnel_id                            | tunnel_server | relay_port |
+--------------------------------------+--------------------------------------+---------------+------------+
| c5d771fe-1ae8-4254-a8bd-fb8b1f4c293e | ace4b7bf-78f5-4373-992c-e7854b917b45 |               | 6150       |
+--------------------------------------+--------------------------------------+---------------+------------+
  
Puis on se connecte à MySocket :
% mysocketctl tunnel connect \
    --socket_id c5d771fe-1ae8-4254-a8bd-fb8b1f4c293e \
    --tunnel_id ace4b7bf-78f5-4373-992c-e7854b917b45     --port 8080
                                                    
Connecting to Server: ssh.mysocket.io
...
Youpi - https://lively-rain-9509.edge.mysocket.io 
  
Et on peut s'en servir, à l'URL indiqué.

Quelques petits points divers, avant de montrer deux services actuellements disponibles via MySocket :

  • Je n'ai pas creusé la question du modèle d'affaires de MySocket. Pour l'instant, tout est gratuit, fonctionnant au mieux (sans garantie). Je suppose qu'il y aura un service payant avec davantage de possibilités et de garanties, mais je n'en sais rien. Notez que le créateur de MySocket est Andree Tonk, créateur de BGPmon, donc a priori, c'est sérieux.
  • Ceci dit, MySocket est une solution cloud, c'est-à-dire tournant sur d'autres ordinateurs que le vôtre. Si la communication entre votre service et MySocket est chiffrée avec SSH, et que celle entre le client et MySocket l'est en général avec TLS, le trafic est en clair sur les serveurs de MySocket (qui sont des machines Amazon). Donc, attention si vous manipulez des données importantes.
  • Pensez aussi à la sécurité de votre service. MySocket permet à tout l'Internet (sauf si vous utilisez le mode protégé, avec --protected) d'appeler un service qui tourne sur votre machine. Un serveur mal écrit et des tas de choses ennuyeuses peuvent se passer. Il est recommandé d'utiliser un langage de programmation sûr (Python plutôt que C…) et de faire tourner le service dans un bac à sable, par exemple un conteneur.
  • Un des avantages de MySocket est que votre service apparaitra aux yeux du monde comme sécurisé avec TLS, sans que vous ayiez le moindre effort de programmation ou de configuration à faire, ce qui est très sympa. (Le certificat de MySocket est un Let's Encrypt.)

Et pour finir, voici deux services qui tournent actuellement via MySocket. Tous les deux sont hébergés sur un Raspberry Pi 1 (oui, le premier modèle). Ces deux services sont évidemment sans garantie de fiabilité ou de pérennité, c'est juste pour vous montrer et que vous puissiez tester. Le premier utilise une prise de type HTTPS, comme dans les exemples plus haut. Il indique la température du Raspberry Pi et le nombre de paquets et d'octets passés sur son interface Ethernet. Il est accessible en https://frosty-butterfly-737.edge.mysocket.io/. Le source du service est disponible.

Le second utilise un autre type de prise, TLS, ce qui permet de faire tourner des protocoles non-HTTP. Pour créer une telle prise, on utilise l'option --type TLS. À noter qu'un port est alloué pour ce service, pensez à le noter, les clients devront utiliser ce port. Ce service compte simplement le nombre d'octets dans la chaîne de caractères que vous lui envoyer. Il est en misty-violet-3591.edge.mysocket.io:41106. Comme c'est du TLS, on ne peut pas utiliser telnet ou netcat comme client, donc on va se servir de gnutls-cli :

 % gnutls-cli -p 41106 misty-violet-3591.edge.mysocket.io
 ...
 - Status: The certificate is trusted. 
- Description: (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
...
- Simple Client Mode:

toto
4 bytes
Et mysocketctl va montrer la connexion :
192.0.2.106 [25/Nov/2020:19:19:50 +0000] TCP 200 bytes_sent:8 bytes_received:5 session_time: 1.899 
Le source du service est disponible.

Comme la demande pour un tel service est forte, il y a d'autres solutions possibles (je ne les ai pas testées) :

  • November 25th 2020 at 01:00

RFC 8961: Requirements for Time-Based Loss Detection

By Stéphane Bortzmeyer

Vous savez certainement que l'Internet fait circuler les données sous forme de paquets indépendants, et qu'un paquet peut toujours être perdu, par exemple parce qu'un rayon cosmique agressif est passé à ce moment-là ou, moins spectaculaire, parce que les files d'un routeur étaient pleines et qu'il a dû se résigner à laisser tomber le paquet. Des protocoles existent donc pour gérer ces pertes de paquets, ce qui implique de les détecter. Et comment sait-on qu'un paquet a été perdu ? C'est plus complexe que ça n'en a l'air, et ce RFC tente d'établir un cadre générique pour la détection de pertes.

Ne tournons pas autour du pot : la seule façon fiable de savoir si un paquet a été perdu, c'est d'attendre qu'il arrive (ce que le RFC nomme, dans son titre, time-based loss detection) et, s'il n'arrive pas, de le déclarer perdu. Plus précisément, pour l'émetteur (car le récepteur ne sait pas forcément qu'on lui a envoyé un paquet), on émet un paquet et on attend une confirmation qu'il a été reçu (avec TCP, cette confirmation sera le ACK, avec le DNS sur UDP, ce sera la réponse DNS). Si la confirmation n'a pas été reçue, s'il y a timeout, c'est qu'un paquet (la demande, ou bien l'accusé de réception) n'est pas arrivé. Mais attendre combien de temps ? Si on attend peu de temps (mettons 100 millisecondes), on risque de considérer le paquet comme perdu, alors que le voyage était simplement un peu long (en 100 ms, vous ne pouvez même pas faire un aller-retour entre la France et les Philippines, ne serait-ce qu'à cause de la limite de la vitesse de la lumière). Et si on attend longtemps (mettons 5 secondes), on ne pourra pas réagir rapidement aux pertes, et la latence perçue par l'utilisateur sera insupportable (la sensation de « vitesse » pour l'utilisateur dépend davantage de la latence que de la capacité). Il faut donc faire un compromis entre réactivité et justesse.

Il existe d'autres méthodes que l'attente pour détecter des pertes, par exemple TCP et SCTP utilisent aussi les accusés de réception sélectifs (RFC 2018, RFC 4960 dans sa section 3.3.4 et RFC 6675) mais aucune de ces autres méthodes ne détecte toutes les pertes, et la détection par absence de réponse reste donc indispensable.

L'Internet, vous le savez, est un ensemble compliqué de réseaux, reliés par des câbles très variés (et quelques liens radio), avec des débits bien différents et changeant d'un moment à l'autre. Tout chemin d'une machine à l'autre va avoir un certain nombre de propriétés (qui varient dans le temps) telles que la latence ou la capacité. Et le taux de perte de paquets, qui nous intéresse ici. (Voir aussi le RFC 7680.)

Notre RFC suppose que la perte de paquets est une indication de congestion (RFC 5681). Ce n'est pas vrai à 100 %, surtout sur les liens radio, où des paquets peuvent être détruits par des perturbations électro-magnétiques sans qu'il y ait congestion, mais c'est quand même proche de la vérité.

Et, au fait, pourquoi détecter la perte de paquets ? Pourquoi ne pas tout simplement ignorer le problème ? Deux raisons :

  • Pour pouvoir envoyer des données de manière fiable, il faut détecter les paquets manquants, afin de pouvoir demander leur retransmission. C'est ce que fait TCP, par exemple, sans quoi on ne pourrait pas transmettre un fichier en étant sûr qu'il arrive complet.
  • Puisque la perte de paquets signale en général qu'il y a congestion, détecter cette perte permet de ralentir l'envoi de données et donc de lutter contre la congestion.
Résultat, beaucoup de protocoles ont un mécanisme de détection de pertes : TCP (RFC 6298), bien sûr, mais aussi SCTP (RFC 4960), SIP (RFC 3261), etc.

Le RFC cite souvent l'article de Allman, M. et Paxson V, « On Estimating End-to-End Network Path Properties » donc vous avez le droit d'interrompre votre lecture ici pour lire cet article avant de continuer.

Reprenons, avec la section 2 du RFC, qui explique les buts et non-buts de ce RFC :

  • Ce RFC ne change aucun protocole existant, les RFC restent les mêmes, vous n'avez pas à réapprendre TCP,
  • Ce RFC vise surtout les RFC futurs, qui auraient intérêt à se conformer aux principes énoncés ici (c'est par exemple le cas si vous développez un nouveau protocole au-dessus d'UDP et que vous devez donc mettre en œuvre la détection de pertes),
  • Ce RFC n'impose pas des règles absolues, il donne des principes qui marchent dans la plupart des cas, c'est tout.

Nous arrivons maintenant à la section 4 du RFC, qui liste les exigences auxquelles doivent obéir les mécanismes de détection de pertes. (En pratique, les mécanismes existants collent déjà à ces exigences mais elles n'avaient pas été formalisées.) Un petit retour sur la notion de latence, d'abord. On veut savoir combien de temps attendre avant de déclarer un paquet perdu. Cette durée se nomme RTO (Retransmission TimeOut). Les latences dans l'Internet étant extrêmement variables, il serait intéressant de faire dépendre le RTO de la latence. Mais quelle latence ? Le temps d'aller-retour entre deux machines est le temps qu'il faut à un paquet IP pour aller de la machine A à la machine B plus le temps qu'il faut à un paquet IP pour aller de B à A. On ne peut pas mesurer directement ce temps, car le temps de traitement dans la machine B n'est pas forcément connu. Dans le cas de l'ICMP Echo utilisé par ping, ce temps est considéré comme négligeable, ce qui est assez correct si l'amer est une machine Unix dont le noyau traite l'ICMP Echo. Cela l'est moins si l'amer est un routeur qui traite les réponses ICMP à sa plus basse priorité. Et cela l'est encore moins si un client DNS essaie d'estimer la latence vers un résolveur. Si le résolveur avait la réponse dans sa mémoire, le temps de traitement est faible. S'il devait demander aux serveurs faisant autorité, ce temps peut être bien supérieur à la latence. Le RFC distingue donc RTT (Round-Trip Time), la vraie latence, et FT (Feedback Time) qui est ce qu'affichent ping, dig et autres outils. La machine qui veut savoir combien de temps attendre une réaction de la machine en face, avant de déclarer qu'un paquet est perdu, a tout intérêt à avoir une idée du FT.

Certaines des exigences du RFC sont quantitatives. Ainsi, tant qu'on n'a pas mesuré le FT (au début de la session), le RFC requiert que le RTO soit d'au moins une seconde, pour ne pas surcharger le réseau avec des réémissions, et parce que la perte étant interprétée comme un signe de congestion, un RTO trop faible amènerait à réduire la quantité de données qu'on peut envoyer, diminuant ainsi la capacité effective. Sans compter le problème de l'ambiguïté. Si on a réémis un paquet, et qu'une réponse revient, était-elle pour le paquet initial ou pour la réémission ? Dans le doute, il ne faut pas utiliser le temps mesuré pour changer son estimation du RTO. Et c'est une des raisons pour lesquelles il faut prendre son temps pour les premières mesures. Ah, au fait, pourquoi une seconde et pas 0,75 ou 1,25 ? Cela vient d'une analyse quantitative des RTT typiques de l'Internet, exposée dans l'annexe A du RFC 6298.

Après plusieurs mesures, on connait mieux le FT et on peut abaisser le RTO. Il n'y a pas de durée minimale, donc on peut s'approcher de zéro tant qu'on veut.

Le RFC dit aussi que le RTO (Retransmission TimeOut, le délai d'attente) doit se mesurer à partir de plusieurs observations du FT, pour éviter une mesure faussée par un cas extrême. Et il faut refaire ces observations souvent car le réseau change ; les vieilles mesures n'ont pas d'intérêt. C'est ce que fait TCP avec son smoothed RTT, utilisant la moyenne mobile exponentielle (RFC 6298).

L'Internet étant ce qu'il est, il est recommandé de s'assurer qu'un méchant ne puisse pas facilement fausser cette mesure en injectant des faux paquets. Pour TCP, cette assurance est donnée par le caractère imprévisible du numéro de séquence initial, si l'attaquant n'est pas sur le chemin (RFC 5961). Si on veut une protection contre un attaquant situé sur le chemin, il faut de la cryptographie.

Le RFC recommande de refaire l'évaluation du RTO au moins une fois par RTT et, de préference, aussi souvent que des données sont échangées. TCP le fait une fois par RTT et, si on utilise le RFC 7323, à chaque accusé de réception.

Le RFC rappelle qu'en l'absence d'indication du contraire, une perte de paquets doit être considérée comme un indicateur de congestion, et qu'il faut donc ralentir (RFC 5681, pour le cas de TCP).

Et, dernière exigence, en cas de perte de paquets, le RTO doit croitre exponentiellement, pour s'ajuster rapidement à la charge du réseau. On pourra réduire le RTO lorsqu'on aura la preuve que les paquets passent et qu'on reçoit des accusés de réception et/ou des réponses. Dans tous les cas, le RFC limite le RTO à 60 secondes, ce qui est déjà énorme (je n'ai jamais vu une réponse revenir après une durée aussi longue).

Enfin, la section 5 discute des exigences posées et de leurs limites. La tension entre le désir de réactivité (un RTO faible) et celui de mesures correctes (un RTO plus important, pour être raisonnablement sûr de ne pas conclure à tort qu'il y a eu une perte) est une tension fondamentale : on n'aura jamais de solution parfaite, juste des compromis. Il existe des techniques qui permettent de mieux détecter les pertes (l'algorithme Eifel - RFC 3522, le F-RTO du RFC 5682, DSACK - RFC 2883 et RFC 3708…) mais elles ne sont pas complètes et l'attente bornée par le RTO reste donc nécessaire en dernier recours.

Le noyau Linux a mis en œuvre plusieurs techniques non normalisées (par exemple des modifications du RFC 6298) sans que cela ne crée apparemment de problèmes. D'une manière générale, les algorithmes de détection de pertes de TCP, SCTP ou QUIC sont largement compatibles avec les exigences de ce RFC.

  • November 24th 2020 at 01:00

Introduction to Python Network Automation – The First Journey (Author: Brendan Choi)

By italchemy

I am happy to share this news on my latest book release update. I have been working with Apress Publishing for the last 10 months and finally the book cover has been released officially.

I have completed the draft of my second book and technical review has been also completed. The book cover is not online for public to preview the general content of my book. If you are interested to learn Python, Virtualization, Networking, Linux Administration, Regular Expressions for the purpose of Network Automation using Python., this would be the book for you. Please check it out.

https://www.apress.com/gp/book/9781484268056

Introduction to Python Network Automation – The First Journey (Author: Brendan Choi)

By italchemy

I am happy to share this news on my latest book release update. I have been working with Apress Publishing for the last 10 months and finally the book cover has been released officially.

I have completed the draft of my second book and technical review has been also completed. The book cover is not online for public to preview the general content of my book. If you are interested to learn Python, Virtualization, Networking, Linux Administration, Regular Expressions for the purpose of Network Automation using Python., this would be the book for you. Please check it out.

https://www.apress.com/gp/book/9781484268056

How to create Teams Live Events in Switzerland (and other regions)

By LuisR
About 3 weeks ago I posted the explanation why you could not schedule Teams live events in some regions like Switzerland and the options that you have to still use the Live Events: Can I make Teams Live Events in…

Continue reading

Teams meeting recording button became unavailable

By LuisR
ISSUE Some day ago, users started reporting that they could not record a meeting. The record option was unavailable: The meeting policy for the users allow them to record meetings: CAUSE Sooooo… what happened?Time to investigate what has MS changed…

Continue reading

Teams ‘Busy on Busy’ causes missed call storm notifications

By LuisR
Recently in my company we decided to rollout the ‘Busy on Busy’ feature for all users, to suppress the annoying ring sound that comes on your headsets when you are on a call (or a meeting) and this makes it…

Continue reading

How to create Teams Live Events in Switzerland (and other regions)

By LuisR
About 3 weeks ago I posted the explanation why you could not schedule Teams live events in some regions like Switzerland and the options that you have to still use the Live Events: Can I make Teams Live Events in my country? Now it’s time to show ‘option #3’: Unlock and schedule a Teams Live Event […]

RFC 8943: Concise Binary Object Representation (CBOR) Tags for Date

By Stéphane Bortzmeyer

Le format de données CBOR, normalisé dans le RFC 7049, possède un certain nombre de types de données de base, et un mécanisme d'extensions, les étiquettes (tags). Ce RFC spécifie deux nouvelles étiquettes, pour indiquer des dates.

Le RFC 7049 déclarait déjà deux types pour les estampilles temporelles, l'étiquette 0 pour une chaîne de caractères dont le contenu est une estampille au format du RFC 3339 (avec la date et l'heure), et l'étiquette 1 pour une estampille sous la forme d'un nombre de secondes depuis l'epoch. Dans ce nouveau RFC sont ajoutées deux étiquettes, 100 pour un entier qui va stocker le nombre de jours depuis l'epoch, et 1004 pour une date seule (sans heure) au format du RFC 3339. L'epoch est celle de la norme Posix 1 / IEEE Standard 1003.1, le 1 janvier 1970. Dans les deux cas, comme on ne stocke pas l'heure, des considérations comme le fuseau horaire ou les secondes intercalaires sont inutiles. Quant au calendrier utilisé, c'est le grégorien.

Dans ce calendrier, John Lennon (je reprends l'exemple du RFC…) est né le 9 octobre 1940 et mort le 8 décembre 1980. (Les dates utilisées dans ce RFC n'incluent pas l'heure.) Pour la première étiquette, 100, qui indique le nombre de jours depuis l'epoch, l'auteur d'I Am the Walrus est né le -10676. C'est un nombre négatif puisque l'epoch utilisée est le 1 janvier 1970, après sa naissance. Lennon est mort le 3994. Pour le cas de la deuxième étiquette, 1004, il est né le 1940-10-09 et mort le 1980-12-08, suivant le format du RFC 3339. Le jour (lundi, mardi, mercredi…) est explicitement non mentionné, si on en a besoin, il faut le recalculer.

Les deux formats, en nombre de jours depuis l'epoch, et en RFC 3339 ont l'avantage que les comparaisons de date sont triviales, une simple comparaison d'entiers dans le premier cas, de chaînes de caractères dans le suivant, suffit.

Petit piège des dates indiquées sans l'heure, un même événement peut survenir à deux dates différentes selon le fuseau horaire. Ainsi, une vidéoconférence qui a lieu, à Tokyo, le 12 octobre à 10h00 sera considérée par les habitants d'Honolulu comme se tenant le 11 octobre à 15h00.

Les deux étiquettes ont été enregistrées à l'IANA. La valeur 100 pour la première a été choisie car 100 est le code ASCII de 'd' (pour date).

Si vous voulez un fichier CBOR utilisant ces deux étiquettes, vous pouvez appeler le service https://www.bortzmeyer.org/apps/date-in-cbor qui vous renvoie un tableau avec les quatre façons de servir une date en CBOR, les deux standards du RFC 7049, et les deux de notre RFC. Ici, on utilise le programmme read-cbor pour afficher plus joliment :

% wget -q -O - https://www.bortzmeyer.org/apps/date-in-cbor | ./read-cbor -
Array of 5 items
...
        Tag 0
                String of length 20: 2020-11-21T06:44:33Z
        Tag 1
                Unsigned integer 1605941073
        Tag 100
                Unsigned integer 18587
        Tag 1004
                String of length 10: 2020-11-21
  
  • November 21st 2020 at 01:00
❌