ปลดล็อก WiFi ฟรีของ British Airways

 (saxrag.com)
1 คะแนน โดย GN⁺ 2025-10-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • พบว่าบริการ WiFi ฟรีสำหรับส่งข้อความ บนเครื่องของ British Airways แท้จริงแล้วอนุญาตการเข้าถึงอินเทอร์เน็ตแบบจำกัดผ่านการกรองตามโดเมนบางรายการ
  • ผู้เขียนสามารถเข้าถึงเว็บไซต์ทั่วไปได้สำเร็จด้วยการดัดแปลงฟิลด์ TLS SNI(Server Name Indication) เพื่อหลอกให้ระบบของสายการบินมองว่าเป็นทราฟฟิกของแอปส่งข้อความ
  • โดยตั้งค่า SNI เป็น wa.me (โดเมนของ WhatsApp) และใช้ HTTPS proxy กับ stunnel เพื่ออ้อมเส้นทางทราฟฟิก
  • ผลการทดลองพบว่าเว็บไซต์ที่เน้นข้อความเป็นหลัก (เช่น Hacker News) โหลดได้ตามปกติ แต่รูปภาพหรือคอนเทนต์ขนาดใหญ่ส่งได้ช้าเนื่องจาก การจำกัดแบนด์วิดท์
  • กรณีนี้แสดงให้เห็นถึง ความเปราะบางของการกรองแบบอิง TLS SNI และความจำเป็นของเทคโนโลยี ECH(Encrypted Client Hello) เพื่อแก้ข้อจำกัดดังกล่าว

วิธีทำงานของ WiFi ฟรีสำหรับส่งข้อความ

  • British Airways ให้บริการ WiFi ฟรีเฉพาะการส่งข้อความ แก่สมาชิก “The British Airways Club”
    • สมัครได้ผ่านพอร์ทัลบนเครื่องโดยไม่ต้องยืนยันอีเมล และสามารถใช้ WhatsApp, Signal, WeChat ได้ แต่ Discord ถูกบล็อก
  • ผู้เขียนจึงตั้งคำถามว่าบริการนี้ อนุญาตเฉพาะแอปส่งข้อความด้วยวิธีใด
    • จากการสังเกตพบว่าไม่ใช่แค่การจำกัดทราฟฟิกธรรมดา แต่เป็นระบบ whitelist ของโดเมนโดยอิงจากฟิลด์ TLS SNI
  • ผลการวิเคราะห์ด้วย Wireshark พบว่าเมื่อเชื่อมต่อไปยัง example.com จะเกิด TCP reset หลัง Client Hello
    • หมายความว่าระบบใช้ค่า SNI ที่เปิดเผยระหว่าง TLS handshake เพื่อบล็อกโดเมนที่ไม่ได้รับอนุญาต

หลักการของการกรองแบบอิง SNI

  • TLS SNI จะ ส่งชื่อโดเมนปลายทางเป็นข้อความธรรมดาในขั้นตอนก่อนการเข้ารหัส
    • ทำให้ ISP หรือผู้ดูแลเครือข่ายสามารถรู้ได้ว่าผู้ใช้กำลังพยายามเข้าถึงเว็บไซต์ใด
  • British Airways ลงทะเบียน เฉพาะโดเมนที่เกี่ยวข้องกับแอปส่งข้อความไว้ใน whitelist ส่วนที่เหลือจะถูกรีเซ็ตการเชื่อมต่อ
  • ผู้เขียนยังยืนยันได้ว่าการเชื่อมต่อโดยตรงผ่าน IP โดยไม่มี SNI (openssl s_client -connect) ก็ถูกบล็อกเช่นกัน
    • นั่นคือ การไม่มี SNI เองก็ถูกมองว่าเป็นทราฟฟิกผิดปกติ

การทดลองดัดแปลง SNI

  • ผู้เขียนลองตั้งค่า SNI เป็น wa.me (โดเมนของ WhatsApp) แล้วเริ่มการเชื่อมต่อ TLS
    • แม้ใบรับรองของเซิร์ฟเวอร์จะไม่ใช่สำหรับ wa.me แต่หากไคลเอนต์มองข้ามความไม่ตรงกันของใบรับรองก็ยังเชื่อมต่อได้
  • ผลคือระบบของ BA เข้าใจผิดว่าเป็นทราฟฟิกแอปส่งข้อความ และยอมให้สร้าง TLS tunnel
    • หลังจากนั้นผู้เขียนเขียน HTTP request เองและรับคอนเทนต์จากเซิร์ฟเวอร์ของตน (saxrag.com) ได้สำเร็จ
  • การทดลองนี้พิสูจน์ว่า หากหลอกแค่ฟิลด์ SNI ก็สามารถส่งทราฟฟิกตามต้องการได้

การอ้อมแบบสมบูรณ์ด้วย HTTPS proxy

  • ผู้เขียนใช้ tinyproxy และ stunnel เพื่อสร้าง เซิร์ฟเวอร์ HTTPS proxy
    • stunnel เพิ่มชั้น TLS เพื่ออำพรางให้ดูเหมือนว่าไคลเอนต์กำลังเชื่อมต่อไปยัง wa.me
  • ในคำสั่ง curl มีการใช้ตัวเลือก --resolve เพื่อแมป wa.me ไปยัง IP ของ VPS ของตนเอง
    • ทำให้ SNI ยังเป็น wa.me แต่การเชื่อมต่อจริงเกิดขึ้นกับเซิร์ฟเวอร์ส่วนตัว
  • ข้อผิดพลาดของใบรับรอง TLS ถูกข้ามด้วย --proxy-insecure และสามารถ ส่งคำขอออกไปภายนอกผ่าน proxy ได้สำเร็จ
    • เมื่อเรียก ifconfig.co ก็ได้รับ IP ของ VPS กลับมา ยืนยันว่า proxy ทำงานจริง

การทดสอบระหว่างเที่ยวบินจริง

  • ในเที่ยวบินขากลับ ผู้เขียนเชื่อมต่อ WiFi ด้วยการตั้งค่าเดิม และได้รับ HTTP 200 response ตามปกติ ผ่าน curl
    • จากนั้นตั้งค่า HTTPS proxy ในเบราว์เซอร์ (Chromium) และเพิ่ม wa.me ลงในไฟล์ hosts
  • ผลลัพธ์คือ เข้าเว็บไซต์ Hacker News ได้สำเร็จ และหน้าเว็บที่เป็นข้อความเป็นหลักโหลดได้ตามปกติ
    • ใน Wireshark ยังยืนยันการถอดรหัส TLS ด้วย SSLKEYLOGFILE ได้ด้วย
  • อย่างไรก็ตาม รูปภาพหรือคอนเทนต์ขนาดใหญ่ โหลดช้ามากแบบทีละบรรทัด ทำให้คาดว่ามีการจำกัดแบนด์วิดท์อยู่
    • สิ่งนี้บ่งชี้ว่า BA อาจ ใช้การจำกัดความเร็วทราฟฟิกร่วมกับการกรองด้วย SNI

การทดลองกับ ECH(Encrypted Client Hello)

  • ผู้เขียนยังทดสอบ เทคโนโลยี ECH ซึ่งใช้แก้ปัญหาการเปิดเผย SNI ใน TLS โดยตรง
    • มีการสร้าง ECHConfig โดยตั้ง wa.me เป็น public_name และนำไปใช้กับ Firefox
  • ผลคือ SNI ภายนอกยังคงเป็น wa.me แต่ภายใน ClientHello จะมีโดเมนจริง (rfc5746.mywaifu.best) อยู่
    • และสามารถสร้างการเชื่อมต่อ TLS ได้ตามปกติด้วยใบรับรองจาก Let’s Encrypt
  • ที่น่าสนใจคือวิธีนี้ยังใช้ได้แม้บน พอร์ตที่ไม่ใช่มาตรฐาน (7443) และสามารถอ้อมการกรองของ British Airways ได้
  • ผู้เขียนตั้งข้อสังเกตว่า ECHConfig อาจถูกส่งผ่าน DNS-over-HTTPS(DoH)

ข้อจำกัดของ SNI และนัยด้านความปลอดภัย

  • เดิมที SNI เป็นเพียงข้อมูลระดับ “คำใบ้” สำหรับช่วยเลือกใบรับรองของเซิร์ฟเวอร์
    • ในสภาพแวดล้อมที่ควบคุมทั้งฝั่งไคลเอนต์และเซิร์ฟเวอร์ได้ ก็สามารถใส่ค่า SNI ตามต้องการได้
  • นี่หมายความว่าหากระบบเซ็นเซอร์หรือโซลูชันตรวจจับภัยคุกคาม พึ่งพาการกรองแบบอิง SNI มากเกินไป ก็มีโอกาสเกิด false positive ได้
    • ผู้สร้างมัลแวร์อาจใช้ SNI ที่ปลอมเป็นโดเมนไม่อันตรายเมื่อติดต่อกับเซิร์ฟเวอร์ C&C
  • ดังนั้นนโยบายความปลอดภัยของเครือข่ายจึงควรมี การวิเคราะห์ทราฟฟิกเพิ่มเติมและการตรวจสอบชั้นการเข้ารหัสนอกเหนือจาก SNI

บทสรุป

  • WiFi ฟรีของ British Airways อนุญาตเฉพาะทราฟฟิกแอปส่งข้อความผ่าน การกรองโดเมนแบบอิง SNI และการจำกัดแบนด์วิดท์
  • แต่การทดลองพิสูจน์แล้วว่าสามารถ ปลอมทราฟฟิก HTTPS ใดก็ได้ให้ดูเหมือนทราฟฟิกส่งข้อความ ผ่านการดัดแปลง SNI
  • กรณีนี้สะท้อนข้อจำกัดเชิงโครงสร้างของการออกแบบ TLS และตอกย้ำ ความจำเป็นของการนำ ECH มาใช้
  • ผู้ให้บริการเครือข่ายและผู้รับผิดชอบด้านความปลอดภัยควรตระหนักถึง ความเปราะบางของการกรองที่พึ่งพา SNI
  • แม้จะเป็นกรณีศึกษาการอ้อมระบบที่น่าสนใจในเชิงเทคนิค แต่ก็เป็นงานวิจัยที่ควรพิจารณา ประเด็นด้านความปลอดภัยและจริยธรรม ควบคู่กัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-25
ความคิดเห็นจาก Hacker News
  • เพื่อนของฉันเคยทำ tunneling คล้าย ๆ แบบนี้มาก่อน และมันใช้ได้บนเรือสำราญด้วย
    สายการบินบางแห่ง (น่าจะเป็น American Airlines) ใช้ไฟร์วอลล์ Fortinet เลยไม่ได้ดูแค่ SNI อย่างเดียว แต่ตรวจสอบทั้ง hostname และผู้ออกใบรับรอง ในเซิร์ฟเวอร์เซอร์ติฟิเคตด้วย
    เพื่อนฉันหลบเลี่ยงได้โดยใช้ SNI ของ aa.com แล้วส่งต่อ TLS 1.2 handshake ของ aa.com จริงไปตามเดิม
    หลังจากนั้นในขั้นตอนข้อมูลที่เข้ารหัสแล้ว ก็จะไม่สนใจ handshake นั้นและใช้มันเป็นเพียง tunnel ที่เข้ารหัสเท่านั้น
    ทุกวันนี้ถ้าใช้ TLS 1.3 ใบรับรองจะถูกเข้ารหัส ทำให้ไฟร์วอลล์มองไม่เห็นเนื้อหา จึงหลีกเลี่ยงปัญหาแบบนี้ได้
    • ที่จริงแล้วนี่แทบจะเหมือนวิธีที่ Xray ใช้เลย
      ถ้ามีคำขอที่ตรงกับ SNI เฉพาะเข้ามาโดยไม่มีคีย์ลับ ก็จะพร็อกซี SSL handshake ทั้งหมดไปยังเว็บไซต์ลวงตา
      ถ้าไม่ใช่ ก็จะทำงานเป็นพร็อกซีปกติที่ปลอมตัวเป็นทราฟฟิก SSL
      เดิมทีสร้างขึ้นมาเพื่อหลบเลี่ยง GFW (Great Firewall) ของจีน แต่เพื่อนฉันบอกว่าพอตั้ง Google Analytics เป็น SNI แล้ว มันก็ใช้ได้กับไฟร์วอลล์บนเครื่องบินของ American เช่นกัน
    • ฉันเพิ่งกลับมาจากทริปเรือสำราญ 3 สัปดาห์เหมือนกัน และอินเทอร์เน็ตแพงแบบเหลือเชื่อ วันละ 50 ดอลลาร์
      Wi-Fi กับแอปใช้งานได้ฟรี แต่ทราฟฟิกส่วนใหญ่ถูกบล็อก
      พอดูด้วย Wireshark ก็พบว่าเขาอนุญาตแค่ไม่กี่แพ็กเก็ตช่วงต้นของการเชื่อมต่อ TCP แล้วหลังจากนั้นจะตรวจ ClientHello เพื่อให้ผ่านเฉพาะโดเมนใน whitelist
      แอปของเรือสำราญทำงานได้เพราะโดเมนของบริษัทอยู่ใน whitelist
      ช่องโหว่แบบนี้ไม่ควรถูกเอาไปใช้แบบโจ่งแจ้ง ควรใช้เงียบ ๆ ดีกว่า ไม่งั้นเดี๋ยวก็โดนปิด ช่องนี้เลยน่าเสียดาย
    • ทุกวันนี้ทางออกที่แท้จริงบนเรือสำราญคือพก Starlink Mini ไปเอง
      ต่อให้ค่าจานกับค่าบริการแพง มันก็คุ้มในฐานะการ ‘ประกาศอิสรภาพ’ จากบริษัทเรือสำราญ
  • ฉันเคยหลบ public Wi-Fi (รวมถึงบนเครื่องบิน) หลายครั้งด้วย เซิร์ฟเวอร์ VPN บนพอร์ต UDP 53
    ทุกวันนี้ captive portal มักจะบล็อกทราฟฟิกภายนอกแทบทั้งหมด แต่หลายแห่งก็ยังอ่อนแออยู่
    แนะนำ SoftEther — ฟีเจอร์ Azure Relay ของมันทำงานได้ดีแม้ในเครือข่ายที่ใช้ whitelist
    ยังไม่เคยลองใช้ iodine จนถึงขั้นสื่อสาร DNS แบบสองทาง แต่ถึงจะช้าก็น่าจะใช้ได้ในหลายกรณี
    • มีพอร์ทัลบางแห่งที่อนุญาตทราฟฟิกทั้งหมดชั่วคราวเพื่อแสดงวิดเจ็ตชำระเงิน
      ถ้าเริ่มกระบวนการจ่ายเงินซ้ำ ๆ ก็สามารถใช้มันหลบได้
    • เมื่อก่อนฉันมีเซิร์ฟเวอร์ Hetzner ที่มี 8 IP แล้วตั้งค่าให้หนึ่งในนั้นยอมรับ OpenVPN ทุกพอร์ต
      ตอนเริ่มจะช้าเพราะต้องลองหลายพอร์ต แต่ความสำเร็จสูงอย่างน่าทึ่ง
    • ฉันก็รันทั้ง WireGuard และ OpenVPN บนพอร์ต 53 แยกกันคนละ VPS
      แต่เดี๋ยวนี้หลายที่อนุญาตเฉพาะทราฟฟิก DNS และบล็อก resolver อื่นที่ไม่ได้กำหนดไว้
    • Wi-Fi ของบางสายการบินอนุญาตแค่ ส่งข้อความฟรี (WhatsApp, Messenger)
      ถ้าสร้าง TCP-over-WhatsApp VPN ได้คงเจ๋งมาก
  • วิธีที่มีคนพูดถึงว่า “ส่ง payload ของคำขอไปเป็น subdomain แล้วรับคำตอบกลับผ่าน TXT record” นั่นก็คือ iodine นั่นเอง
    • ฉันก็เคยทำอะไรคล้าย ๆ กันเมื่อราว 12 ปีก่อน
      ไม่ใช่ DNS แต่เป็นการทำ HTTP(S) ผ่าน UDP tunneling และตอนที่ตั้งค่าเสร็จทันภายในช่วง Wi-Fi ฟรี 30 นาทีที่สนามบิน Stansted นั้นก็รู้สึกภูมิใจไม่น้อย
  • ฉันเคยไปสัมภาษณ์งานด้านไซเบอร์ซีเคียวริตีกับ British Airways และมันเป็นประสบการณ์ที่แปลกพอสมควร
    ตอนฉันพูดถึงช่องโหว่ร้ายแรงในเว็บไซต์ พวกเขากลับตอบประมาณว่า “ถ้าสำคัญจริง เดี๋ยวมันก็จะโผล่ใน pentest เอง” แล้วก็ไม่ใส่ใจเท่าไร
    สุดท้ายก็จบลงแบบที่ต่างฝ่ายต่างไม่ได้ประทับใจกันนัก
    • BA เคยโดนฝัง สคริปต์ดักข้อมูลบัตร ไว้ในหน้าชำระเงินจริง ๆ
      ความปลอดภัยของ Wi-Fi บนเครื่องจึงแทบเป็นแค่อุปกรณ์หารายได้ ไม่ได้เกี่ยวอะไรกับความปลอดภัยของบริษัทโดยรวม
    • บางทีการสัมภาษณ์ของพวกเขาอาจเป็น pentest เสียเองก็ได้
    • ฉันรู้สึกว่า pentest ก็มีประโยชน์พอ ๆ กับการสำรวจบ้านแบบอังกฤษ
      หลายบริษัทคิดว่าแค่ทำ pentest ประจำปีก็ถือว่าจบเรื่องความปลอดภัยแล้ว ทั้งที่วิศวกรที่รู้จักผลิตภัณฑ์จริงกลับไม่ได้รับอนุมัติงบลงทุน
  • ฉันคิดว่า การละเมิดลิขสิทธิ์ไม่เหมือนการขโมย แต่กรณีนี้ใกล้เคียงการขโมยจริง ๆ
    วงการเทคเป็นอาชีพรายได้สูง ดังนั้นค่า Wi-Fi แค่นี้ก็ควรจ่าย
  • ฉันสร้างโปรเจกต์ชื่อ tuningfork
    เป็นเครื่องมือที่พร็อกซีทราฟฟิกผ่านโหนดอื่น โดยฉันทำขึ้นเองเพื่อเรียนรู้ความเข้าใจเรื่องเครือข่าย
    มันมีจุดประสงค์เพื่อหลบเลี่ยง กฎหมายยืนยันอายุ ของสหราชอาณาจักรด้วย
    ลิงก์ GitHub
  • เพื่ออ้างอิง วิธีแบบนี้เรียกว่า Domain Fronting
  • ก่อนหน้านี้เคยมีโพสต์เกี่ยวกับเรือสำราญที่โดน ขู่ทางกฎหมาย มาแล้ว เลยสงสัยว่าโพสต์นี้จะอยู่ได้นานแค่ไหน
    • อยากถามว่าคุณพอมีลิงก์ของเรื่องนั้นไหม
  • ฉันชอบการอยู่ ออฟไลน์ ระหว่างบิน
    ฉันชอบช่วงเวลาที่ได้ตัดขาดจากโลกไปชั่วคราว เพราะงั้นการที่ทุกคนจะมี Wi-Fi ฟรีใช้ก็ไม่ใช่เรื่องน่ายินดีสำหรับฉัน
    • แต่มันก็เป็นเรื่องของ เจตจำนงเสรี อยู่ดี
      ถ้าคุณไม่อยากใช้ ก็แค่ไม่ต้องเชื่อมต่อ คนอื่นใช้ก็ไม่ได้ส่งผลอะไรกับคุณ
    • ก็แค่อย่าอุตส่าห์พยายามหาวิธีเอา Wi-Fi ฟรีก็พอ
  • ฉันกำลังพิมพ์ข้อความนี้จากบนเครื่องบินของ British Airways ในตอนนี้เลย
    ฉันเปิดแพ็กเกจส่งข้อความฟรีไว้และกำลังใช้ WireGuard tunnel อยู่ ดูเหมือนไฟร์วอลล์ไม่ได้ถูกออกแบบมาให้บล็อกได้สมบูรณ์แบบนัก
    • อยากรู้ว่าคุณแค่รัน WireGuard บนพอร์ต 51820 หรือเปล่า
      ฉันเคยลองมาก่อนและจำได้ว่ามันไม่ค่อยเวิร์ก