@Furiousnp :

Beaucoup de gens ne seront pas d'accord avec moi. Mais je vois mal comment maintenir un avis objectif sur plusieurs opérateurs.

Prenons ton opérateur actuel.

Pour moi, la note attribuée à Orange n'est pas fixe. Les critères présentés peuvent évoluer.

MilkyWAN propose un abonnement autour de 60/70€ par mois contre 25€ par mois pour Sosh. Orange propose des débits atteignant
8 Gbps symétrique contre 2 Gbps pour MilkyWAN. Je pense que l'offre MilkyWAN est efficace pour un accès professionnel. On a bien
compris que l'offre Orange Fibre résidentielle n'était pas adaptée pour faire de l'auto-hébergement. Mais les plus techniques peuvent
remplacer leur Livebox avec un peu d'effort et disposer d'une offre de services éventuellement réduite mais quasiment « pro » avec
un bon support. Tout le monde n'y arrive pas mais c'est possible. Je sais aussi qu'il y a une marge de progression pour rendre ce
processus de remplacement de boîtier Internet plus fiable et accessible. En d'autres termes, la note actuelle de 6/10 peut très bien
s'élever à 9/10. Cela rend ce classement moins pertinent.

Je ne comprends pas non plus les qualificatifs employés. Cela arrange de clamer que la méthode n'est pas « officielle » mais cela
recouvre plusieurs réalités. C'est compliqué à suivre et potentiellement contraignant mais issu des standards. C'est d'ailleurs via de
la rétro-ingénierie que cela a été rendu possible. On voit de l'ouverture également avec le support officieux d'Orange.

Normalement il n'y a pas de raison que le SSID change tout seul, mais par exemple je ne vois pas à quoi correspond la "fibre de secours".
Si jamais la Livebox a été réinitialisée à ses réglages d'usine et n'a pas restauré une sauvegarde, alors elle a pu repasser d'un SSID et mot de passe personnalisés à ceux par défaut.

En revanche, le "Type de sécurité" peut être changé par Orange : ils ont passé des Livebox de l'ancienne valeur par défaut "WPA2/WPA3 Personal" à "WPA3 Personal Compatibility".
Donc si jamais c'est la seconde valeur qui est actuellement choisie, il faudrait tester de remettre la première.

L'image est celle du TV4, celle du décodeur UHD est similaire, mais avec en haut un petit trou pour le micro et une LED.

En effet c'est consternant ! 

Et comme indiqué ici : https://www.frandroid.com/marques/sfr/3217085_red-by-sfr-victime-dune-fuite-de-donnees-les-abonnes-prevenus-seulement-7-semaines-apres-lattaque
7 semaines après ils commencent juste à prévenir les clients ... ça mérite une plainte à la CNIL rien que pour ça !

A mon avis, l'une des difficultés lors de ces fuites est de déterminer ce qui a exactement fuité, et pour quels abonnés. Il faut prévenir ceux qui ont été concernés, mais pas 20 millions de personnes si seulement 2 millions sont concernées. Sinon, on inquiète de nombreuses personnes pour rien.

Constater qu'il y a eu une fuite, et que des données sont en vente sur le dark web, c'est une chose, l’ampleur et qui est concerné exactement une autre.

- Si vous laissez la résolution DNS par notre serveur, il y a une surcouche DNS Filter qui pourra bloquer certains domaines considérés comme malveillants/malwares/etc. J’ai lu des cas de problèmes avec du DOT, je suis preneur d’exemples/traces complémentaires, si vous me confirmez par ailleurs le contexte de votre cas d’usage.

Dans les tests décrits plus haut, j'étais sur un PC Linux, et j'ai d'abord chargé le portail captif et autorisé l'accès.
Pour un utilisateur lambda le service peut être considéré comme fonctionnel (le DNS fourni par le réseau répond).

Mais comme il y avait eu des messages ici, j'ai voulu faire des tests :
 - requêtes DNS sur le port 53 (UDP / TCP) vers 1.1.1.1 / 8.8.8.8 / 9.9.9.9, et même "curl -o /dev/null https://appliwave.testdebit.info:53/1G.iso" (donc du TLS sur le port TCP 53) : aucune réponse sur aucun des serveurs
 - tests DoT avec l'outil https://github.com/natesales/q : dns.quad9.net semblait bloqué, unfiltered.joindns4.eu répondait
 - tests DoH manuels, comme par exemple "curl --insecure -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=example.com&type=A" : Cloudflare / Google / Quad9 sont interceptés par dnsfilter, avec une réponse en HTML, alors que d'autres passent
Donc clairement il y a un blocage du port 53, des blocages DoT, et des interceptions DoH.
Malheureusement j'ai manqué de temps sur la fin, et je n'ai pas sauvegardé les captures, donc je ne sais pas si côté DoT / DoH il s'agissait de DNS menteur (sur la résolution initiale via le DNS de la connexion), d'un blocage d'IP, ou d'un blocage via la reconnaissance du SNI dans le handshake TLS (Client Hello).