1 điểm bởi GN⁺ 2025-10-25 | 1 bình luận | Chia sẻ qua WhatsApp
  • Dịch vụ WiFi nhắn tin miễn phí trên máy bay của British Airways được phát hiện là thực chất cho phép truy cập Internet hạn chế thông qua bộ lọc dựa trên domain cụ thể
  • Tác giả đã thao túng trường TLS SNI(Server Name Indication) để đánh lừa hệ thống của hãng hàng không nhận diện đây là lưu lượng nhắn tin, từ đó truy cập được các website thông thường
  • Để làm điều này, tác giả đặt wa.me (domain của WhatsApp) làm SNI và dùng HTTPS proxy cùng stunnel để chuyển hướng lưu lượng
  • Kết quả thử nghiệm cho thấy các trang thiên về văn bản như Hacker News tải bình thường, nhưng hình ảnh hoặc nội dung dung lượng lớn truyền chậm do giới hạn băng thông
  • Trường hợp này cho thấy điểm yếu của việc lọc dựa trên TLS SNI và sự cần thiết của công nghệ ECH(Encrypted Client Hello) để khắc phục

Cách WiFi nhắn tin miễn phí hoạt động

  • British Airways cung cấp WiFi miễn phí chỉ dành cho nhắn tin cho thành viên “The British Airways Club”
    • Có thể đăng ký qua cổng trên máy bay mà không cần xác thực email; WhatsApp, Signal, WeChat hoạt động, nhưng Discord bị chặn
  • Tác giả đặt câu hỏi hệ thống này cho phép riêng các ứng dụng nhắn tin bằng cách nào
    • Đây dường như không chỉ là giới hạn loại lưu lượng đơn thuần, mà là một whitelist domain dựa trên trường TLS SNI
  • Phân tích bằng Wireshark cho thấy khi truy cập example.com, TCP reset xảy ra sau Client Hello
    • Điều này cho thấy cơ chế chặn domain không được phép bằng cách dùng giá trị SNI lộ ra trong quá trình bắt tay TLS

Nguyên lý lọc dựa trên SNI

  • TLS SNI gửi tên domain muốn kết nối dưới dạng văn bản thuần ở giai đoạn trước khi mã hóa
    • Nhờ đó ISP hoặc quản trị viên mạng có thể biết người dùng đang truy cập website nào
  • British Airways chỉ đưa các domain liên quan tới ứng dụng nhắn tin vào whitelist, còn lại thì reset kết nối
  • Tác giả cũng xác nhận rằng kết nối trực tiếp bằng IP không có SNI (openssl s_client -connect) cũng bị chặn
    • Tức là việc thiếu SNI tự nó cũng bị coi là lưu lượng bất thường

Thử nghiệm thao túng SNI

  • Tác giả thử tạo kết nối TLS với wa.me (domain của WhatsApp) làm SNI
    • Chứng chỉ máy chủ không dành cho wa.me, nhưng nếu client bỏ qua việc không khớp chứng chỉ thì vẫn có thể kết nối
  • Kết quả là hệ thống của BA nhầm đây là lưu lượng nhắn tin và cho phép đường hầm TLS
    • Sau đó tác giả tự viết HTTP request và nhận thành công nội dung từ máy chủ của mình (saxrag.com)
  • Thử nghiệm này chứng minh rằng chỉ cần đánh lừa trường SNI là có thể truyền lưu lượng tùy ý

Vượt chặn hoàn toàn bằng HTTPS proxy

  • Tác giả dựng một máy chủ HTTPS proxy bằng tinyproxystunnel
    • stunnel thêm lớp TLS để ngụy trang như thể client đang kết nối tới wa.me
  • Trong lệnh curl, tác giả dùng tùy chọn --resolve để ánh xạ wa.me tới IP VPS của mình
    • Nhờ vậy SNI vẫn là wa.me, nhưng kết nối thực tế đi tới máy chủ cá nhân
  • Lỗi chứng chỉ TLS được bỏ qua bằng --proxy-insecure, và yêu cầu ra ngoài qua proxy đã thành công
    • Khi gọi ifconfig.co, hệ thống trả về IP của VPS, xác nhận proxy hoạt động

Thử nghiệm trên chuyến bay thực tế

  • Trên chuyến bay về, tác giả kết nối WiFi với cùng cấu hình và nhận được phản hồi HTTP 200 bình thường qua curl
    • Sau đó tác giả cấu hình HTTPS proxy trong trình duyệt (Chromium) và thêm wa.me vào file hosts
  • Kết quả là truy cập thành công website Hacker News, các trang chủ yếu là văn bản tải bình thường
    • Trong Wireshark, việc giải mã TLS cũng được xác nhận bằng SSLKEYLOGFILE
  • Hình ảnh hoặc nội dung dung lượng lớn thì tải chậm từng dòng, cho thấy có tồn tại giới hạn băng thông
    • Điều này gợi ý BA không chỉ lọc theo SNI mà còn áp dụng giới hạn tốc độ lưu lượng

Thử nghiệm ECH(Encrypted Client Hello)

  • Tác giả trực tiếp thử công nghệ ECH để giải quyết vấn đề lộ SNI trong TLS
    • Một ECHConfig được tạo với wa.me làm public_name và áp dụng trong Firefox
  • Kết quả là SNI bên ngoài vẫn giữ là wa.me, nhưng bên trong ClientHello chứa domain thật (rfc5746.mywaifu.best)
    • Kết nối TLS bình thường được thiết lập bằng chứng chỉ Let’s Encrypt
  • Đáng chú ý là cách này cũng hoạt động trên cổng không chuẩn (7443), vượt qua được bộ lọc của British Airways
  • Tác giả cho rằng ECHConfig có thể đã được truyền qua DNS-over-HTTPS(DoH)

Giới hạn của SNI và hàm ý bảo mật

  • SNI vốn chỉ là thông tin ở mức “gợi ý” để máy chủ chọn chứng chỉ phù hợp
    • Trong môi trường mà cả client và server đều có thể kiểm soát, có thể chèn giá trị SNI tùy ý
  • Điều này có nghĩa là nếu hệ thống kiểm duyệt hoặc giải pháp phát hiện mối đe dọa phụ thuộc quá nhiều vào lọc dựa trên SNI, khả năng phát hiện sai là có thật
    • Tác giả phần mềm độc hại có thể dùng SNI ngụy trang thành domain vô hại khi kết nối tới máy chủ C&C
  • Vì vậy, chính sách bảo mật mạng cần phân tích lưu lượng bổ sung ngoài SNI và kiểm tra lớp mã hóa

Kết luận

  • WiFi miễn phí của British Airways chỉ cho phép lưu lượng nhắn tin thông qua lọc domain dựa trên SNI và giới hạn băng thông
  • Tuy nhiên, thử nghiệm đã chứng minh rằng có thể ngụy trang lưu lượng HTTPS tùy ý thành lưu lượng nhắn tin bằng cách thao túng SNI
  • Trường hợp này cho thấy giới hạn mang tính cấu trúc trong thiết kế TLS và nhấn mạnh sự cần thiết của việc triển khai ECH
  • Các nhà mạng và người phụ trách bảo mật cần nhận thức được điểm yếu của lọc phụ thuộc vào SNI
  • Đây là một trường hợp vượt chặn thú vị về mặt kỹ thuật, nhưng cũng là một nghiên cứu cần đi kèm cân nhắc về bảo mật và đạo đức

1 bình luận

 
GN⁺ 2025-10-25
Ý kiến Hacker News
  • Bạn tôi trước đây từng làm kiểu tunneling tương tự, và nó cũng hoạt động trên tàu du lịch
    Một số hãng hàng không, có lẽ là American Airlines, dùng tường lửa Fortinet nên không chỉ nhìn SNI đơn thuần mà còn kiểm tra cả hostname và tổ chức cấp chứng chỉ của chứng chỉ máy chủ
    Anh ấy đã vượt qua bằng cách dùng SNI của aa.com rồi chuyển tiếp nguyên vẹn bắt tay TLS 1.2 thật của aa.com
    Sau đó, ở giai đoạn dữ liệu đã được mã hóa, anh ấy bỏ qua phần bắt tay đó và chỉ dùng nó như một đường hầm được mã hóa
    Ngày nay nếu dùng TLS 1.3 thì chứng chỉ được mã hóa nên tường lửa không thể thấy nội dung, nhờ vậy tránh được vấn đề này
    • Thực ra cách này gần như giống hệt những gì Xray làm
      Nếu có yêu cầu khớp với một SNI cụ thể đi vào mà không có khóa bí mật, nó sẽ proxy toàn bộ bắt tay SSL sang website ngụy trang
      Nếu không thì nó hoạt động như một proxy thông thường được ngụy trang thành lưu lượng SSL
      Ban đầu nó được tạo ra để vượt qua GFW (Vạn lý Tường lửa) của Trung Quốc, nhưng khi bạn tôi đặt Google Analytics làm SNI thì nó cũng hoạt động với tường lửa trên chuyến bay của American
    • Tôi cũng vừa đi một chuyến du thuyền 3 tuần, và Internet đắt vô lý, tới 50 đô một ngày
      Wi‑Fi và ứng dụng thì dùng miễn phí, nhưng phần lớn lưu lượng đều bị chặn
      Xem bằng Wireshark thì thấy chỉ vài gói đầu của kết nối TCP được cho phép, sau đó họ kiểm tra ClientHello và chỉ cho qua các domain trong whitelist
      Ứng dụng của tàu du lịch hoạt động vì domain của công ty có trong whitelist
      Nên cứ âm thầm dùng thôi, đừng khai thác lỗ hổng này quá lộ liễu. Nếu bị lan truyền rộng thì họ sẽ vá mất, khá tiếc
    • Giải pháp thực sự cho tàu du lịch ngày nay là mang theo Starlink Mini
      Dù giá thiết bị và cước phí đắt đỏ, nó vẫn hoàn toàn xứng đáng như một kiểu “tuyên ngôn tự do” trước các hãng tàu
  • Tôi đã nhiều lần vượt qua Wi‑Fi công cộng, kể cả trên máy bay, bằng máy chủ VPN cổng UDP 53
    Giờ đây captive portal chặn gần như toàn bộ lưu lượng ra ngoài, nhưng vẫn còn nhiều nơi sơ hở
    Tôi khuyên dùng SoftEther — nhờ tính năng Azure Relay mà nó hoạt động tốt cả trên các mạng có whitelist
    Tôi vẫn chưa thử dùng iodine để làm truyền thông hai chiều qua DNS, nhưng dù chậm thì có lẽ trong đa số trường hợp vẫn dùng được
    • Có những portal tạm thời cho phép toàn bộ lưu lượng để hiện widget thanh toán
      Nếu cứ lặp đi lặp lại việc bắt đầu quy trình thanh toán thì có thể vượt qua bằng cách đó
    • Trước đây tôi có một server Hetzner với 8 IP, trong đó một IP được cấu hình cho phép OpenVPN trên mọi cổng
      Khởi đầu hơi chậm vì phải thử nhiều cổng, nhưng tỷ lệ thành công cao đến ngạc nhiên
    • Tôi cũng chạy WireGuard và OpenVPN trên cổng 53 ở hai VPS khác nhau
      Nhưng dạo này nhiều nơi chỉ cho phép lưu lượng DNS và chặn các resolver tùy ý
    • Một số Wi‑Fi trên máy bay chỉ cho phép nhắn tin miễn phí (WhatsApp, Messenger)
      Nếu có thể làm một TCP-over-WhatsApp VPN thì sẽ thật tuyệt
  • Cách mà ai đó nói là “gửi payload yêu cầu qua subdomain và nhận phản hồi bằng bản ghi TXT” chính là iodine
    • Tôi cũng từng làm thứ tương tự khoảng 12 năm trước
      Không phải DNS, mà là chạy HTTP(S) qua UDP tunneling, và tôi khá tự hào khi thiết lập xong trong giới hạn 30 phút Wi‑Fi miễn phí ở sân bay Stansted
  • Trước đây tôi từng phỏng vấn an ninh mạng với British Airways, và đó là một trải nghiệm khá kỳ quặc
    Tôi nhắc tới một lỗ hổng nghiêm trọng trên website của họ, nhưng họ gạt đi kiểu “nếu quan trọng thì pentest sẽ phát hiện ra”
    Kết thúc mà hai bên đều chẳng ấn tượng gì về nhau
    • BA thực sự từng bị cài script skimmer thẻ vào trang thanh toán và bị tấn công
      Bảo mật Wi‑Fi trên máy bay thực chất chỉ là công cụ kiếm tiền, tách biệt với an ninh của công ty
    • Biết đâu chính buổi phỏng vấn của họ mới là pentest
    • Tôi thấy pentest vô dụng kiểu như khảo sát nhà ở theo phong cách Anh
      Nhiều công ty nghĩ chỉ cần làm pentest hằng năm là xong chuyện bảo mật, trong khi các kỹ sư thực sự hiểu sản phẩm lại không được duyệt đầu tư
  • Tôi nghĩ sao chép lậu không giống ăn cắp, nhưng cái này thì thật sự gần với ăn cắp hơn
    Ngành công nghệ là lĩnh vực thu nhập cao, nên tôi cho rằng tiền Wi‑Fi thì nên trả
  • Tôi đã tạo ra một dự án tên là tuningfork
    Đây là công cụ proxy lưu lượng qua các node khác, tôi tự viết để hiểu rõ mạng hoạt động thế nào
    Nó cũng nhằm mục đích vượt qua luật xác minh độ tuổi ở Anh
    Liên kết GitHub
  • Nhân tiện, kiểu này được gọi là Domain Fronting
  • Trước đây từng có bài viết về tàu du lịch bị đe dọa pháp lý, nên tôi tò mò không biết bài này sẽ tồn tại được bao lâu
    • Tôi muốn hỏi liệu bạn có biết link của câu chuyện đó không
  • Tôi là kiểu người thích ở trạng thái offline khi đang bay
    Tôi thích khoảng thời gian tạm thời tách khỏi thế giới đó. Vì vậy việc mọi người đều dùng Wi‑Fi miễn phí không khiến tôi vui lắm
    • Nhưng rốt cuộc đây là vấn đề của ý chí tự do
      Nếu bạn không muốn thì đừng kết nối. Người khác dùng cũng không ảnh hưởng gì đến bạn
    • Cứ đơn giản là đừng bỏ công sức như vậy chỉ để có Wi‑Fi miễn phí
  • Tôi đang viết dòng này ngay lúc này trên một chuyến bay của British Airways
    Tôi đã bật gói nhắn tin miễn phí và đang dùng WireGuard tunnel, có vẻ tường lửa không được thiết kế để chặn hoàn toàn
    • Không biết có phải bạn chỉ đơn giản chạy WireGuard trên cổng 51820 không
      Tôi nhớ là trước đây đã thử nhưng không thành công