sachant que a l'epoque avec ESNI ca fonctionnait et que ech semble pas actif sur rsf (https://rsf.org/cdn-cgi/trace donne cleartext sni)
Il n'y a pas d'ECH pour rsf.org (cf about:networking#dnslookuptool dans Firefox, pas de "echConfig").
Mais Chrome envoie quand même l'extension (Wireshark indique "Unknown type 65037").
Il s'agit de GREASE ECH :
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-15#name-grease-ech.
Je suppose que ça a deux rôles :
- faire comme GREASE (qui est aussi utilisé) : s'assurer que les différents serveurs et intermédiaires (proxy, ...) n'ont pas de bugs quand ils voient des extensions qu'ils ne connaissent pas
- noyer le trafic ECH dans le reste
Ici, même avec le SNI rsf.org, ça semble permettre de contourner le blocage.
Pour Firefox, il y a :
- security.tls.ech.grease_probability (pourcentage des connexions TLS qui ont GREASE ECH activé) : 0 par défaut, 50 sur Nightly
- security.tls.ech.grease_http3 (activation de GREASE ECH en HTTP/3) : false par défaut
Avec security.tls.ech.grease_probability=100, le comportement serait similaire à Chrome, ça peut permettre de contourner les blocages aussi.
Autre chose m'interpelle : l'utilisation de TLS 1.2 alors que https://rsf.org gère TLS 1.3 (et les navigateurs aussi). Comment expliquer que TLS 1.2 soit utilisé ?
Le Client Hello a pour version TLS 1.2, mais l'extension supported_versions indique TLS 1.2, TLS 1.3 (et GREASE pour Chrome).
C'est normal, puisque les navigateurs supportent le deux versions, le serveur répond avec la plus récente qu'il supporte.
Wireshark renseigne probablement la colonne protocole à partir de la version vue dans l'extension supported_versions du Server Hello.
Protocoles réseaux sécurisés (https)