- Es wurde aufgedeckt, dass der kostenlose Messaging-WiFi-Dienst an Bord von British Airways tatsächlich über eine domänenbasierte Filterung begrenzten Internetzugang erlaubt
- Der Autor manipulierte das TLS-Feld SNI (Server Name Indication), um das System der Fluggesellschaft glauben zu lassen, es handle sich um Messaging-Traffic, und konnte so erfolgreich normale Websites aufrufen
- Dafür setzte er
wa.me (die WhatsApp-Domain) als SNI und leitete den Traffic mit HTTPS-Proxy und stunnel um
- Im Experiment luden textbasierte Websites (wie Hacker News) normal, während Bilder oder große Inhalte wegen Bandbreitenbegrenzung nur langsam übertragen wurden
- Dieser Fall zeigt die Schwäche von TLS-SNI-basierter Filterung und die Notwendigkeit der Technologie ECH (Encrypted Client Hello), um sie zu ergänzen
Wie kostenloses Messaging-WiFi funktioniert
- British Airways bietet Mitgliedern von „The British Airways Club“ kostenloses WiFi nur für Messaging an
- Die Anmeldung war im Bordportal ohne E-Mail-Bestätigung möglich; WhatsApp, Signal und WeChat funktionierten, Discord war jedoch blockiert
- Der Autor fragte sich, wie dieser Dienst nur Messaging-Apps zulässt
- Es handelte sich offenbar nicht um eine einfache Traffic-Beschränkung, sondern um eine Whitelist von Domains auf Basis des TLS-SNI-Feldes
- Eine Wireshark-Analyse zeigte, dass beim Zugriff auf
example.com nach dem Client Hello ein TCP-Reset erfolgte
- Das bedeutet, dass nicht erlaubte Domains über den während des TLS-Handshakes sichtbaren SNI-Wert blockiert werden
Prinzip der SNI-basierten Filterung
- TLS-SNI überträgt den Namen der Ziel-Domain im Klartext vor der Verschlüsselung
- Dadurch können ISPs oder Netzwerkadministratoren sehen, welche Website ein Nutzer aufruft
- British Airways führte nur Domains von Messaging-Apps auf einer Whitelist, alle anderen Verbindungen wurden zurückgesetzt
- Der Autor bestätigte außerdem, dass auch direkte IP-Verbindungen ohne SNI (
openssl s_client -connect) blockiert wurden
- Das heißt, auch ein fehlendes SNI selbst gilt als anomaler Traffic
Experiment zur SNI-Manipulation
- Der Autor versuchte eine TLS-Verbindung mit
wa.me (WhatsApp-Domain) als SNI
- Das Serverzertifikat war zwar nicht für
wa.me, aber die Verbindung funktionierte, wenn der Client die Zertifikatsabweichung ignorierte
- Das BA-System hielt dies letztlich fälschlich für Messaging-Traffic und ließ den TLS-Tunnel zu
- Anschließend formulierte der Autor HTTP-Anfragen direkt und erhielt erfolgreich Inhalte von seinem eigenen Server (
saxrag.com)
- Das Experiment bewies, dass sich beliebiger Traffic übertragen lässt, solange nur das SNI-Feld täuscht
Vollständige Umgehung mit einem HTTPS-Proxy
- Der Autor richtete mit
tinyproxy und stunnel einen HTTPS-Proxy-Server ein
stunnel fügte eine TLS-Schicht hinzu, damit es so aussah, als verbinde sich der Client mit wa.me
- Mit der Option
--resolve im curl-Befehl wurde wa.me auf die IP seines eigenen VPS abgebildet
- So blieb das SNI auf
wa.me gesetzt, während die tatsächliche Verbindung zu seinem privaten Server ging
- TLS-Zertifikatsfehler wurden mit
--proxy-insecure ignoriert, und externe Anfragen über den Proxy waren erfolgreich
- Eine Anfrage an
ifconfig.co lieferte die VPS-IP zurück und bestätigte damit die Funktion des Proxys
Test während des tatsächlichen Flugs
- Auf dem Rückflug erhielt der Autor mit derselben Konfiguration nach der WiFi-Verbindung per
curl eine normale HTTP-200-Antwort
- Danach konfigurierte er im Browser (Chromium) den HTTPS-Proxy und trug
wa.me in die Hosts-Datei ein
- Dadurch gelang der Zugriff auf die Website von Hacker News, textbasierte Seiten wurden normal geladen
- In Wireshark wurde die TLS-Entschlüsselung mithilfe von
SSLKEYLOGFILE bestätigt
- Bilder oder große Inhalte luden zeilenweise sehr langsam, was auf eine Bandbreitenbegrenzung schließen lässt
- Das deutet darauf hin, dass BA zusätzlich zum SNI auch Traffic-Drosselung einsetzt
Experiment mit ECH (Encrypted Client Hello)
- Der Autor testete direkt die ECH-Technologie, die das Problem des offengelegten TLS-SNI lösen soll
- Er erzeugte eine ECHConfig mit
wa.me als public_name und setzte sie in Firefox ein
- Dadurch blieb das externe SNI zwar
wa.me, im internen ClientHello stand jedoch die tatsächliche Domain (rfc5746.mywaifu.best)
- Mit einem Let’s-Encrypt-Zertifikat kam eine normale TLS-Verbindung zustande
- Interessanterweise funktionierte dies auch auf einem nicht standardmäßigen Port (7443) und umging die Filterung von British Airways
- Der Autor vermutet, dass die ECHConfig über DNS-over-HTTPS (DoH) übertragen wurde
Grenzen von SNI und sicherheitstechnische Implikationen
- SNI ist ursprünglich nur ein Hinweis zur Auswahl des passenden Serverzertifikats
- In Umgebungen, in denen sowohl Client als auch Server kontrolliert werden, kann ein beliebiger SNI-Wert eingefügt werden
- Das bedeutet, dass Zensursysteme oder Threat-Detection-Lösungen bei zu starker Abhängigkeit von SNI-basierter Filterung Fehlklassifikationen riskieren
- Malware-Autoren könnten beim Zugriff auf C&C-Server ein als harmlos getarntes SNI einer unverdächtigen Domain verwenden
- Daher benötigen Netzwerksicherheitsrichtlinien zusätzliche Traffic-Analysen und Prüfungen der Verschlüsselungsschicht über SNI hinaus
Fazit
- Das kostenlose WiFi von British Airways erlaubt Messaging-Traffic nur über SNI-basierte Domain-Filterung und Bandbreitenbegrenzung
- Das Experiment zeigte jedoch, dass sich durch SNI-Manipulation beliebiger HTTPS-Traffic als Messaging tarnen lässt
- Dieser Fall macht die strukturellen Grenzen des TLS-Designs sichtbar und unterstreicht die Notwendigkeit der Einführung von ECH
- Netzbetreiber und Sicherheitsverantwortliche sollten die Schwächen SNI-abhängiger Filterung erkennen
- Technisch ist dies ein interessanter Fall einer Umgehung, zugleich aber ein Forschungsbeispiel, das Sicherheits- und ethische Überlegungen mit einbeziehen sollte
1 Kommentare
Hacker-News-Kommentare
Einige Fluggesellschaften (vermutlich American Airlines) verwenden Fortinet-Firewalls und prüfen nicht nur einfach das SNI, sondern validieren sogar Hostnamen und Zertifizierungsstelle des Serverzertifikats
Mein Freund hat das umgangen, indem er das SNI von aa.com verwendet und den eigentlichen TLS-1.2-Handshake von aa.com unverändert weitergeleitet hat
In der anschließenden Phase der verschlüsselten Daten hat er diesen Handshake ignoriert und es einfach als verschlüsselten Tunnel genutzt
Wenn man heute TLS 1.3 verwendet, sind die Zertifikate verschlüsselt, sodass die Firewall den Inhalt nicht sehen kann und man dieses Problem vermeiden kann
Wenn eine Anfrage mit passendem SNI ohne den geheimen Schlüssel hereinkommt, wird der komplette SSL-Handshake an eine Tarn-Website weitergeleitet
Andernfalls arbeitet es als normaler Proxy, getarnt als SSL-Traffic
Ursprünglich wurde es entwickelt, um die chinesische GFW (Great Firewall) zu umgehen, aber als mein Freund Google Analytics als SNI gesetzt hat, funktionierte es auch mit der Bord-Firewall von American Airlines
Wi-Fi und die App funktionieren kostenlos, aber der meiste Traffic wird blockiert
In Wireshark konnte ich sehen, dass zu Beginn einer TCP-Verbindung nur ein paar Pakete erlaubt werden und danach das ClientHello geprüft wird, sodass nur Domains auf der Whitelist durchkommen
Die Kreuzfahrt-App funktioniert, weil die Domain des Unternehmens auf der Whitelist steht
Solche Lücken sollte man nicht ausnutzen, sondern still und leise verwenden. Es wäre schade, wenn das zu bekannt wird und dann geschlossen wird
Auch wenn Schüssel und Tarif teuer sind, ist das als eine Art „Freiheitserklärung“ gegenüber der Kreuzfahrtgesellschaft absolut lohnend
Heutzutage blockieren Captive Portals externen Traffic fast vollständig, aber viele sind immer noch anfällig
Ich empfehle SoftEther — dank der Funktion Azure Relay funktioniert es auch in Netzwerken mit Whitelist gut
iodine habe ich noch nicht für bidirektionale DNS-Kommunikation ausprobiert, aber auch wenn es langsam ist, dürfte es in den meisten Fällen funktionieren
Wenn man den Bezahlvorgang immer wieder neu startet, kann man das zum Umgehen nutzen
Der Start war langsam, weil ich viele Ports ausprobieren musste, aber die Erfolgsquote war überraschend hoch
Aber heutzutage wird oft nur DNS-Traffic erlaubt, während beliebige Resolver blockiert werden
Wenn man ein TCP-over-WhatsApp-VPN bauen könnte, wäre das wirklich großartig
Nicht über DNS, sondern mit HTTP(S) über UDP-Tunneling, und ich war ziemlich stolz, als ich das innerhalb des 30-Minuten-Limits des kostenlosen Wi-Fis am Flughafen Stansted eingerichtet bekam
Als ich eine schwerwiegende Schwachstelle auf der Website erwähnte, wurde das mit „Wenn es wichtig ist, wird es im Pentest auffallen“ abgetan
Am Ende waren wir wohl beide nicht sonderlich beeindruckt voneinander
Die Sicherheit des Bord-Wi-Fis ist in Wirklichkeit nur ein Instrument zum Geldverdienen und hat mit der Unternehmenssicherheit wenig zu tun
Viele Unternehmen glauben, dass ihre Sicherheit erledigt ist, wenn sie nur einen jährlichen Pentest machen, während Ingenieure, die das Produkt wirklich kennen, keine Investitionsfreigabe bekommen
Die Tech-Branche ist ein Berufsfeld mit hohen Einkommen, daher finde ich, man sollte die Wi-Fi-Gebühren einfach bezahlen
Es ist ein Tool, das Traffic über andere Nodes proxyt, und ich habe es selbst implementiert, um Netzwerke besser zu verstehen
Es diente auch dazu, das britische Altersverifizierungsgesetz zu umgehen
GitHub-Link
Ich mag diese kurze Zeit, in der man von der Welt abgeschnitten ist. Deshalb freue ich mich nicht darüber, wenn am Ende alle kostenloses Wi-Fi nutzen
Wenn du es nicht willst, musst du dich einfach nicht verbinden. Dass andere es nutzen, hat keine Auswirkung auf dich
Ich habe den kostenlosen Messaging-Tarif aktiviert und nutze einen WireGuard-Tunnel, aber die Firewall scheint nicht so gebaut zu sein, dass sie alles perfekt blockiert
Ich habe das früher einmal versucht und erinnere mich, dass es nicht gut funktioniert hat