1 points par GN⁺ 2025-10-25 | 1 commentaires | Partager sur WhatsApp
  • Il a été révélé que le service Wi‑Fi gratuit de messagerie à bord de British Airways autorise en réalité un accès Internet limité via un filtrage fondé sur certains domaines
  • L’auteur a réussi à accéder à des sites web ordinaires en manipulant le champ TLS SNI (Server Name Indication) pour tromper le système de la compagnie et lui faire croire qu’il s’agissait de trafic de messagerie
  • Pour cela, il a défini wa.me (le domaine de WhatsApp) comme SNI et a contourné les restrictions à l’aide d’un proxy HTTPS et de stunnel
  • Les tests ont montré que les sites essentiellement textuels (comme Hacker News) se chargeaient correctement, tandis que les images et les contenus volumineux étaient transmis lentement à cause d’une limitation de bande passante
  • Ce cas met en évidence la fragilité du filtrage basé sur le TLS SNI et la nécessité de technologies comme ECH (Encrypted Client Hello) pour y remédier

Comment fonctionne le Wi‑Fi gratuit de messagerie

  • British Airways propose un Wi‑Fi gratuit réservé à la messagerie aux membres de “The British Airways Club”
    • L’inscription est possible via le portail de bord sans vérification d’e-mail, et WhatsApp, Signal et WeChat fonctionnaient, alors que Discord était bloqué
  • L’auteur s’est demandé par quel mécanisme seules les applications de messagerie étaient autorisées
    • Il en a conclu qu’il ne s’agissait pas d’une simple limitation de trafic, mais d’une liste blanche de domaines fondée sur le champ TLS SNI
  • Une analyse avec Wireshark a montré qu’en se connectant à example.com, une réinitialisation TCP après le Client Hello se produisait
    • Cela indique un blocage des domaines non autorisés à partir de la valeur SNI exposée pendant la poignée de main TLS

Principe du filtrage basé sur le SNI

  • Le SNI TLS transmet en clair le nom de domaine ciblé avant le chiffrement
    • Cela permet aux FAI ou aux administrateurs réseau de voir à quels sites les utilisateurs tentent d’accéder
  • British Airways a mis sur liste blanche uniquement les domaines liés aux applications de messagerie, et réinitialise les autres connexions
  • L’auteur a aussi constaté qu’une connexion directe par IP sans SNI (openssl s_client -connect) était bloquée
    • En d’autres termes, l’absence de SNI elle-même est considérée comme un trafic anormal

Expérimentation sur la manipulation du SNI

  • L’auteur a tenté une connexion TLS en définissant wa.me (le domaine de WhatsApp) comme SNI
    • Le certificat serveur n’était pas prévu pour wa.me, mais la connexion restait possible si le client ignorait la non-correspondance du certificat
  • Le système de BA l’a alors pris à tort pour du trafic de messagerie, autorisant ainsi le tunnel TLS
    • L’auteur a ensuite rédigé directement des requêtes HTTP et a réussi à récupérer le contenu de son propre serveur (saxrag.com)
  • Cette expérience a démontré qu’il est possible de transmettre du trafic arbitraire en falsifiant uniquement le champ SNI

Contournement complet via un proxy HTTPS

  • L’auteur a mis en place un serveur proxy HTTPS à l’aide de tinyproxy et stunnel
    • stunnel ajoute une couche TLS pour faire croire que le client se connecte à wa.me
  • Il a utilisé l’option --resolve dans curl pour faire pointer wa.me vers l’IP de son VPS
    • Ainsi, le SNI est défini sur wa.me, mais la connexion réelle aboutit à son serveur personnel
  • Les erreurs de certificat TLS ont été ignorées avec --proxy-insecure, ce qui a permis de faire aboutir des requêtes externes via le proxy
    • Une requête vers ifconfig.co a renvoyé l’IP du VPS, confirmant le bon fonctionnement du proxy

Test en conditions réelles pendant le vol

  • Sur le vol retour, il s’est reconnecté au Wi‑Fi avec la même configuration et a reçu une réponse HTTP 200 normale via curl
    • Il a ensuite configuré un proxy HTTPS dans son navigateur (Chromium) et ajouté wa.me au fichier hosts
  • Résultat : accès réussi au site Hacker News, avec un chargement correct des pages textuelles
    • Dans Wireshark, il a confirmé le déchiffrement TLS à l’aide de SSLKEYLOGFILE
  • Les images et les contenus lourds se chargeaient très lentement, ligne par ligne, ce qui laisse penser à une limitation de bande passante
    • Cela suggère que BA combine une limitation de débit avec le filtrage par SNI

Expérimentation avec ECH (Encrypted Client Hello)

  • L’auteur a aussi testé directement la technologie ECH, conçue pour résoudre le problème d’exposition du SNI en TLS
    • Il a généré une ECHConfig avec wa.me comme public_name, puis l’a appliquée dans Firefox
  • Au final, le SNI externe reste wa.me, mais le ClientHello interne contient le véritable domaine (rfc5746.mywaifu.best)
    • Une connexion TLS normale a alors été établie avec un certificat Let’s Encrypt
  • Fait intéressant, cela fonctionnait aussi sur un port non standard (7443), contournant le filtrage de British Airways
  • L’auteur avance l’hypothèse que l’ECHConfig a pu être transmise via DNS-over-HTTPS (DoH)

Limites du SNI et implications pour la sécurité

  • À l’origine, le SNI n’est qu’une information de type « indice » destinée à aider à sélectionner le certificat serveur
    • Dans un environnement où le client et le serveur sont tous deux contrôlés, il est possible d’insérer arbitrairement n’importe quelle valeur de SNI
  • Cela signifie que les systèmes de censure ou les solutions de détection des menaces peuvent produire des erreurs s’ils s’appuient excessivement sur un filtrage fondé sur le SNI
    • Un auteur de malware pourrait utiliser, pour joindre un serveur de C&C, un SNI déguisé en domaine inoffensif
  • Les politiques de sécurité réseau ont donc besoin, au-delà du SNI, d’une analyse supplémentaire du trafic et d’une vérification de la couche de chiffrement

Conclusion

  • Le Wi‑Fi gratuit de British Airways n’autorise le trafic de messagerie qu’au moyen d’un filtrage de domaines basé sur le SNI et d’une limitation de bande passante
  • Cependant, des expériences ont montré qu’en manipulant le SNI, il est possible de déguiser un trafic HTTPS arbitraire en trafic de messagerie
  • Ce cas illustre les limites structurelles de la conception de TLS et souligne la nécessité d’adopter ECH
  • Les opérateurs réseau comme les responsables de la sécurité doivent prendre conscience de la vulnérabilité des filtrages reposant sur le SNI
  • Techniquement, il s’agit d’un cas de contournement intéressant, mais aussi d’un sujet de recherche qui appelle des considérations de sécurité et d’éthique

1 commentaires

 
GN⁺ 2025-10-25
Commentaires Hacker News
  • Un ami à moi avait déjà fait un tunneling similaire, et ça fonctionnait aussi sur un bateau de croisière
    Certaines compagnies aériennes (probablement American Airlines) utilisent des pare-feu Fortinet, donc elles ne regardent pas seulement le SNI, mais vérifient aussi le nom d’hôte et l’autorité de certification du certificat serveur
    Mon ami contournait cela en utilisant le SNI de aa.com et en relayant tel quel le handshake TLS 1.2 réel de aa.com
    Ensuite, au stade des données chiffrées, il ignorait ce handshake et utilisait simplement le tout comme un tunnel chiffré
    Aujourd’hui, avec TLS 1.3, le certificat est chiffré et le pare-feu ne peut plus en voir le contenu, ce qui permet d’éviter ce problème
    • En réalité, c’est presque exactement ainsi que fonctionne Xray
      Si une requête correspondant à un SNI donné arrive sans clé secrète, il proxyfie l’intégralité du handshake SSL vers un site web de couverture
      Sinon, il agit comme un proxy classique déguisé en trafic SSL
      À l’origine, il a été conçu pour contourner le GFW (Grand Firewall) de la Chine, mais quand mon ami a mis Google Analytics comme SNI, cela a aussi fonctionné avec le pare-feu embarqué d’American Airlines
    • J’ai moi aussi fait récemment une croisière de 3 semaines, et Internet coûtait l’absurde somme de 50 dollars par jour
      Le Wi-Fi et l’application fonctionnent gratuitement, mais la majeure partie du trafic est bloquée
      Avec Wireshark, j’ai vu que seuls quelques paquets au début de la connexion TCP étaient autorisés, puis le ClientHello était inspecté pour ne laisser passer que les domaines en liste blanche
      L’application de croisière fonctionne parce que le domaine de l’entreprise est en liste blanche
      Il ne faut pas abuser de ce genre de faille et il vaut mieux rester discret. Si ça devient trop connu, ce sera bloqué, ce qui serait dommage
    • De nos jours, la vraie solution sur les bateaux de croisière, c’est d’emporter un Starlink Mini
      Même si l’antenne et l’abonnement coûtent cher, c’est largement rentable comme sorte de « déclaration d’indépendance » face aux compagnies de croisière
  • J’ai souvent contourné les Wi-Fi publics (y compris en vol) avec un serveur VPN sur le port UDP 53
    Aujourd’hui, les portails captifs bloquent presque tout le trafic externe, mais beaucoup restent encore vulnérables
    Je recommande SoftEther — grâce à sa fonction Azure Relay, il marche bien même sur des réseaux en liste blanche
    Je n’ai pas encore essayé d’aller jusqu’à une communication DNS bidirectionnelle avec iodine, mais même si c’est lent, ça devrait fonctionner dans la plupart des cas
    • Il existe des portails qui autorisent temporairement tout le trafic pour afficher le widget de paiement
      Il suffit de relancer sans cesse le processus de paiement pour contourner la restriction
    • À une époque, j’avais un serveur Hetzner avec 8 IP, dont une configurée pour autoriser OpenVPN sur tous les ports
      Le démarrage était lent à force d’essayer plusieurs ports, mais le taux de réussite était étonnamment élevé
    • Moi aussi, je fais tourner WireGuard et OpenVPN sur le port 53, chacun sur un VPS différent
      Mais aujourd’hui, il est fréquent que seul le trafic DNS soit autorisé et que les résolveurs arbitraires soient bloqués
    • Certains Wi-Fi de compagnies aériennes n’autorisent que la messagerie gratuite (WhatsApp, Messenger)
      Si quelqu’un arrivait à créer un VPN TCP-over-WhatsApp, ce serait vraiment formidable
  • La méthode évoquée par quelqu’un consistant à « envoyer la charge utile de la requête dans un sous-domaine et recevoir la réponse via des enregistrements TXT », c’est précisément iodine
    • J’ai moi aussi fait quelque chose de similaire il y a environ 12 ans
      Ce n’était pas du DNS, mais je faisais passer HTTP(S) dans un tunnel UDP, et j’étais assez fier d’avoir réussi à tout configurer dans la limite des 30 minutes de Wi-Fi gratuit à l’aéroport de Stansted
  • J’ai passé autrefois un entretien de cybersécurité chez British Airways, et c’était une expérience assez étrange
    J’ai mentionné une grave vulnérabilité du site web, et on m’a répondu que « si c’est important, le pentest le verra », en balayant ça d’un revers de main
    On s’est quittés sans vraiment s’impressionner mutuellement
    • BA a effectivement déjà été compromise via l’injection d’un script skimmer de carte dans sa page de paiement
      La sécurité du Wi-Fi en vol n’est en fait qu’un mécanisme de monétisation, sans grand rapport avec la sécurité globale de l’entreprise
    • Peut-être que leur entretien était lui-même un pentest
    • J’ai l’impression que les pentests sont aussi utiles qu’un diagnostic immobilier au Royaume-Uni
      Beaucoup d’entreprises pensent qu’un pentest annuel suffit à régler la sécurité, tandis que les ingénieurs qui connaissent réellement le produit n’arrivent pas à faire approuver les investissements nécessaires
  • Je pense que le piratage n’est pas du vol, mais ici on s’en approche vraiment
    Le secteur tech est bien rémunéré, donc payer le prix du Wi-Fi ne me semble pas déraisonnable
  • J’ai créé un projet appelé tuningfork
    C’est un outil qui proxyfie le trafic via d’autres nœuds, que j’ai implémenté moi-même pour mieux comprendre les réseaux
    Il visait aussi à contourner la loi britannique de vérification de l’âge
    Lien GitHub
  • Pour info, cette technique s’appelle Domain Fronting
  • Il y a déjà eu un billet sur les croisières qui avait reçu des menaces juridiques, donc je me demande combien de temps celui-ci restera en ligne
    • J’aimerais bien savoir si quelqu’un a le lien vers cette histoire
  • En vol, j’aime bien être hors ligne
    J’apprécie ce moment de déconnexion temporaire du monde. Donc l’idée que tout le monde finisse avec un Wi-Fi gratuit ne m’enchante pas
    • Mais au final, c’est une question de libre arbitre
      Si tu n’en veux pas, il te suffit de ne pas te connecter. Le fait que d’autres l’utilisent n’a aucun impact sur toi
    • Il suffit de ne pas faire tous ces efforts pour obtenir du Wi-Fi gratuit
  • J’écris ce message en ce moment même depuis un avion British Airways
    J’ai activé le forfait de messagerie gratuite et j’utilise un tunnel WireGuard, donc le pare-feu ne semble pas avoir été conçu pour tout bloquer parfaitement
    • Je me demande si c’est simplement du WireGuard sur le port 51820
      J’avais essayé autrefois, et dans mon souvenir, ça ne fonctionnait pas très bien