British Airways का मुफ्त WiFi अनलॉक करना

 (saxrag.com)
1 पॉइंट द्वारा GN⁺ 2025-10-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • British Airways की इन-फ्लाइट मुफ्त messaging WiFi सेवा वास्तव में खास domain-based filtering के ज़रिए सीमित internet access देती है
  • लेखक ने TLS के SNI(Server Name Indication) field में हेरफेर करके airline system को यह विश्वास दिलाया कि यह messaging traffic है, और सामान्य websites तक पहुँचने में सफल रहे
  • इसके लिए wa.me (WhatsApp domain) को SNI के रूप में सेट किया गया, और HTTPS proxy तथा stunnel का उपयोग करके traffic को bypass किया गया
  • प्रयोग में text-based sites (जैसे Hacker News) सामान्य रूप से लोड हुईं, लेकिन images या बड़े content bandwidth limit के कारण धीमे ट्रांसफर हुए
  • यह मामला TLS SNI-based filtering की कमजोरी और इसे बेहतर बनाने के लिए ECH(Encrypted Client Hello) तकनीक की ज़रूरत को दिखाता है

मुफ्त messaging WiFi कैसे काम करता है

  • British Airways, “The British Airways Club” सदस्यों को messaging-only मुफ्त WiFi देता है
    • onboard portal पर email verification के बिना signup संभव था, WhatsApp·Signal·WeChat काम कर रहे थे, लेकिन Discord block था
  • लेखक को यह जानने की जिज्ञासा हुई कि यह सेवा सिर्फ messaging apps को किस तरह अनुमति देती है
    • यह साधारण traffic limit नहीं, बल्कि TLS SNI field-based domain whitelist पर आधारित लगा
  • Wireshark analysis में example.com से जुड़ने पर Client Hello के बाद TCP reset हुआ
    • इसका मतलब है कि TLS handshake के दौरान उजागर होने वाले SNI value का उपयोग करके non-allowed domains को block किया जा रहा था

SNI-based filtering का सिद्धांत

  • TLS SNI, encryption से पहले के चरण में जिस domain name से जुड़ना है उसे plain text में भेजता है
    • इससे ISP या network administrator यह देख सकते हैं कि user किस site से जुड़ रहा है
  • British Airways ने सिर्फ messaging app से जुड़े domains को whitelist किया था, बाकी connections reset कर दिए जाते थे
  • लेखक ने पुष्टि की कि SNI के बिना direct IP connection (openssl s_client -connect) भी block हो रहा था
    • यानी SNI का न होना भी abnormal traffic माना जा रहा था

SNI manipulation प्रयोग

  • लेखक ने wa.me (WhatsApp domain) को SNI के रूप में सेट करके TLS connection की कोशिश की
    • server certificate wa.me के लिए नहीं था, लेकिन client ने certificate mismatch को ignore किया तो connection संभव हुआ
  • नतीजतन BA system ने इसे messaging traffic समझ लिया, और TLS tunnel को अनुमति दे दी
    • इसके बाद HTTP requests manually बनाकर अपने server (saxrag.com) का content सफलतापूर्वक प्राप्त किया गया
  • इस प्रयोग ने साबित किया कि सिर्फ SNI field को धोखा देकर arbitrary traffic भेजा जा सकता है

HTTPS proxy से पूरा bypass

  • लेखक ने tinyproxy और stunnel का उपयोग करके HTTPS proxy server बनाया
    • stunnel ने TLS layer जोड़कर client को ऐसा दिखाया मानो वह wa.me से जुड़ रहा हो
  • curl command में --resolve option का उपयोग करके wa.me को अपने VPS IP पर map किया गया
    • इससे SNI wa.me ही रहा, लेकिन असली connection private server से हुआ
  • TLS certificate errors को --proxy-insecure से ignore किया गया, और proxy के ज़रिए external requests सफल रहीं
    • ifconfig.co request पर VPS IP वापस आया, जिससे proxy के काम करने की पुष्टि हुई

वास्तविक उड़ान में परीक्षण

  • वापसी की उड़ान में उसी setup के साथ WiFi से जुड़ने के बाद, curl के ज़रिए सामान्य HTTP 200 response मिला
    • फिर browser (Chromium) में HTTPS proxy सेट किया गया और wa.me को hosts file में दर्ज किया गया
  • नतीजतन Hacker News website खुल गई, और text-based pages सामान्य रूप से लोड हुए
    • Wireshark में SSLKEYLOGFILE का उपयोग करके TLS decryption की पुष्टि की गई
  • images या बड़े content लाइन-दर-लाइन धीमे लोड हुए, जिससे bandwidth limit होने का अनुमान लगा
    • यह संकेत देता है कि BA SNI के साथ-साथ traffic speed limiting भी कर रहा था

ECH(Encrypted Client Hello) प्रयोग

  • लेखक ने TLS SNI exposure की समस्या को हल करने वाली ECH तकनीक का सीधे परीक्षण किया
    • wa.me को public_name बनाकर ECHConfig तैयार किया गया और Firefox में लागू किया गया
  • नतीजतन बाहरी SNI wa.me ही रहा, लेकिन आंतरिक ClientHello में वास्तविक domain (rfc5746.mywaifu.best) शामिल था
    • Let’s Encrypt certificate के साथ सामान्य TLS connection स्थापित हुआ
  • दिलचस्प बात यह रही कि यह non-standard port (7443) पर भी काम किया, और British Airways filtering को bypass कर गया
  • लेखक ने यह संभावना जताई कि ECHConfig DNS-over-HTTPS(DoH) के ज़रिए भेजा गया होगा

SNI की सीमाएँ और security implications

  • SNI मूल रूप से server certificate चुनने के लिए सिर्फ एक “hint” स्तर की जानकारी है
    • जहाँ client और server दोनों नियंत्रित हों, वहाँ मनचाहा SNI value डाला जा सकता है
  • इसका मतलब है कि यदि censorship systems या threat detection solutions SNI-based filtering पर ज़रूरत से ज़्यादा निर्भर हों, तो false positives संभव हैं
    • malware बनाने वाले C&C server से जुड़ते समय निर्दोष दिखने वाले domain के रूप में छिपा SNI इस्तेमाल कर सकते हैं
  • इसलिए network security policies में SNI के अलावा अतिरिक्त traffic analysis और encryption-layer verification की आवश्यकता है

निष्कर्ष

  • British Airways का मुफ्त WiFi SNI-based domain filtering और bandwidth limiting के ज़रिए सिर्फ messaging traffic को अनुमति देता है
  • लेकिन SNI manipulation के माध्यम से arbitrary HTTPS traffic को messaging की तरह छिपाया जा सकता है, यह प्रयोग से सिद्ध हुआ
  • यह मामला TLS design की संरचनात्मक सीमाओं को दिखाता है और ECH अपनाने की ज़रूरत पर ज़ोर देता है
  • network operators और security जिम्मेदार लोगों को SNI-dependent filtering की कमजोरी समझनी चाहिए
  • तकनीकी रूप से यह एक दिलचस्प bypass case है, लेकिन security और ethical considerations के साथ देखा जाने वाला शोध उदाहरण भी है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-25
Hacker News राय
  • मेरे एक दोस्त ने पहले इसी तरह की tunneling की थी, और यह cruise ship पर भी काम करती थी
    कुछ airlines (शायद American Airlines) Fortinet firewall इस्तेमाल करती हैं, इसलिए वे सिर्फ SNI नहीं देखते, बल्कि server certificate के hostname और certificate authority तक verify करते हैं
    मेरे दोस्त ने aa.com का SNI इस्तेमाल किया और असली aa.com का TLS 1.2 handshake ज्यों का त्यों pass through किया
    उसके बाद encrypted data stage में उस handshake को ignore किया और उसे बस एक encrypted tunnel की तरह इस्तेमाल किया
    आजकल अगर TLS 1.3 इस्तेमाल करें, तो certificate encrypted होता है, इसलिए firewall उसकी सामग्री नहीं देख सकता और इस तरह की समस्या से बचा जा सकता है
    • असल में यह लगभग वही तरीका है जो Xray अपनाता है
      अगर किसी खास SNI के लिए request बिना secret key के आए, तो वह पूरे SSL handshake को disguise website की ओर proxy कर देता है
      नहीं तो वह SSL traffic के रूप में छिपे एक सामान्य proxy की तरह काम करता है
      यह मूल रूप से चीन के GFW(ग्रेट फ़ायरवॉल) को bypass करने के लिए बनाया गया था, लेकिन मेरे दोस्त ने जब Google Analytics को SNI के रूप में सेट किया, तो यह American Airlines के in-flight firewall पर भी काम कर गया
    • मैं भी हाल ही में 3 हफ़्ते की cruise trip से लौटा हूँ, और वहाँ internet का दाम 50 डॉलर प्रतिदिन था, जो बेहूदा महँगा था
      Wi-Fi और app मुफ़्त चलते हैं, लेकिन ज़्यादातर traffic block कर दिया जाता है
      Wireshark में देखा कि TCP connection की शुरुआत में कुछ packets ही allow होते हैं, और उसके बाद ClientHello inspect करके सिर्फ whitelist किए गए domains को pass किया जाता है
      cruise app काम करती है क्योंकि company domain whitelist में है
      ऐसे loopholes का दुरुपयोग नहीं करना चाहिए, बस चुपचाप इस्तेमाल करना चाहिए। बहुत फैल गया तो इसे बंद कर देंगे, यही अफ़सोस है
    • आजकल cruise ship के लिए असली समाधान Starlink Mini साथ ले जाना है
      dish और plan दोनों महँगे हों, फिर भी cruise company के खिलाफ एक तरह की ‘आज़ादी की घोषणा’ के रूप में इसकी काफ़ी कीमत है
  • मैंने public Wi-Fi (in-flight सहित) को UDP 53 port VPN server के ज़रिए कई बार bypass किया है
    आजकल captive portals बाहरी traffic को लगभग पूरी तरह block कर देते हैं, लेकिन अब भी कई जगहों पर कमज़ोरी है
    मैं SoftEther की सिफारिश करूँगा — इसकी Azure Relay feature की वजह से यह whitelist network पर भी अच्छी तरह काम करता है
    मैंने अभी तक iodine से DNS bidirectional communication नहीं चलाया है, लेकिन धीमा होने पर भी ज़्यादातर मामलों में यह शायद काम कर जाएगा
    • कुछ portals payment widget दिखाने के लिए थोड़ी देर के लिए सारा traffic allow कर देते हैं
      अगर payment process बार-बार शुरू करें, तो उससे bypass किया जा सकता है
    • पहले मैंने Hetzner server पर 8 IP रखे थे, जिनमें से एक को इस तरह सेट किया था कि सभी ports पर OpenVPN allow हो
      कई ports आज़माने में शुरुआत धीमी थी, लेकिन success rate हैरान कर देने वाली थी
    • मैं भी WireGuard और OpenVPN को अलग-अलग VPS पर 53 port पर चलाता हूँ
      लेकिन अब कई जगह सिर्फ DNS traffic allow होता है, और arbitrary resolvers को block कर दिया जाता है
    • कुछ airline Wi-Fi में free messaging(WhatsApp, Messenger) ही allow होता है
      अगर TCP-over-WhatsApp VPN बनाया जा सके, तो वह वाकई कमाल का होगा
  • किसी ने जो “request payload को subdomain के रूप में भेजना और TXT record से response लेना” कहा, वह दरअसल iodine ही है
    • मैंने भी करीब 12 साल पहले कुछ ऐसा ही किया था
      DNS नहीं, बल्कि HTTP(S) को UDP tunneling के ऊपर चलाया था, और Stansted airport में free Wi-Fi की 30 मिनट सीमा के भीतर setup कर लेने पर काफ़ी गर्व महसूस हुआ था
  • मैंने पहले British Airways में cybersecurity interview दिया था, और वह काफ़ी अजीब अनुभव था
    मैंने website की एक गंभीर vulnerability का ज़िक्र किया, तो उन्होंने कहा “अगर यह महत्वपूर्ण होगा तो pentest में पकड़ में आ जाएगा,” और बात को हल्के में टाल दिया
    बातचीत इस तरह खत्म हुई कि कोई भी दूसरे से प्रभावित नहीं हुआ
    • BA वास्तव में एक बार payment page में card skimmer script inject होने के कारण compromise हो चुकी है
      in-flight Wi-Fi security असल में बस पैसा कमाने का एक साधन है, company security से उसका अलग मामला है
    • हो सकता है उनका interview ही pentest रहा हो
    • pentest मुझे UK के housing survey की तरह बेकार लगता है
      कई companies मान लेती हैं कि सालाना pentest हो गया तो security पूरी हो गई, लेकिन जो engineers वास्तव में product को जानते हैं उन्हें investment approval ही नहीं मिलता
  • मेरा मानना है कि piracy theft से अलग है, लेकिन यह मामला सचमुच theft के क़रीब है
    tech industry high-income पेशा है, इसलिए Wi-Fi fee जैसी चीज़ का भुगतान करना चाहिए
  • मैंने tuningfork नाम का एक project बनाया है
    यह traffic को दूसरे nodes के ज़रिए proxy करने वाला एक tool है, जिसे मैंने network को समझने के लिए खुद implement किया
    इसका एक मकसद UK के age verification law को bypass करना भी था
    GitHub लिंक
  • जानकारी के लिए, इस तरह के तरीके को Domain Fronting कहा जाता है
  • पहले cruise से जुड़ी एक post को legal threats मिले थे, इसलिए सोच रहा हूँ यह वाली कितने समय तक टिकेगी
    • क्या किसी को उस कहानी का लिंक पता है?
  • मुझे flight के दौरान offline रहना पसंद है
    दुनिया से थोड़ी देर कटा रहने का वह समय अच्छा लगता है। इसलिए सबके लिए free Wi-Fi उपलब्ध होना मुझे खास अच्छा नहीं लगता
    • लेकिन आखिरकार यह free will का मामला है
      अगर तुम नहीं चाहते, तो connect मत करो। दूसरे लोग इस्तेमाल करें, उससे तुम पर कोई असर नहीं पड़ता
    • या फिर free Wi-Fi पाने के लिए इतनी मेहनत ही मत करो
  • मैं यह अभी इसी वक्त British Airways की flight के अंदर से लिख रहा हूँ
    मैंने free messaging plan चालू किया है और WireGuard tunnel इस्तेमाल कर रहा हूँ, लेकिन firewall ऐसा नहीं लगता कि उसे पूरी तरह block करने के लिए डिज़ाइन किया गया हो
    • क्या तुमने WireGuard बस 51820 port पर ही चलाया था?
      मुझे याद है मैंने पहले कोशिश की थी, लेकिन ठीक से काम नहीं किया था