- 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
Commentaires Hacker News
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
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
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
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
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 suffit de relancer sans cesse le processus de paiement pour contourner la restriction
Le démarrage était lent à force d’essayer plusieurs ports, mais le taux de réussite était étonnamment élevé
Mais aujourd’hui, il est fréquent que seul le trafic DNS soit autorisé et que les résolveurs arbitraires soient bloqués
Si quelqu’un arrivait à créer un VPN TCP-over-WhatsApp, ce serait vraiment formidable
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 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
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
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
Le secteur tech est bien rémunéré, donc payer le prix du Wi-Fi ne me semble pas déraisonnable
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
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
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
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
J’avais essayé autrefois, et dans mon souvenir, ça ne fonctionnait pas très bien