# 브리티시 에어웨이즈 무료 WiFi 잠금 해제하기 > Clean Markdown view of GeekNews topic #23908. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=23908](https://news.hada.io/topic?id=23908) - GeekNews Markdown: [https://news.hada.io/topic/23908.md](https://news.hada.io/topic/23908.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-25T21:33:52+09:00 - Updated: 2025-10-25T21:33:52+09:00 - Original source: [saxrag.com](https://www.saxrag.com/tech/reversing/2025/06/01/BAWiFi.html) - Points: 1 - Comments: 1 ## Topic Body - 브리티시 에어웨이즈의 기내 **무료 메시징 WiFi 서비스**가 실제로는 특정 도메인 기반 필터링을 통해 제한된 인터넷 접근을 허용함이 밝혀짐 - 작성자는 TLS **SNI(Server Name Indication)** 필드를 조작해, 항공사 시스템이 메시징 트래픽으로 인식하도록 속여 일반 웹사이트 접속에 성공 - 이를 위해 `wa.me`(WhatsApp 도메인)를 SNI로 설정하고, **HTTPS 프록시와 stunnel**을 이용해 트래픽을 우회 - 실험 결과, 텍스트 기반 사이트(Hacker News 등)는 정상적으로 로드되었으나, 이미지나 대용량 콘텐츠는 **대역폭 제한**으로 느리게 전송됨 - 이 사례는 **TLS SNI 기반 필터링의 취약성**과, 이를 보완하기 위한 **ECH(Encrypted Client Hello)** 기술의 필요성을 보여줌 --- ### 무료 메시징 WiFi의 작동 방식 - 브리티시 에어웨이즈는 “The British Airways Club” 회원에게 **메시징 전용 무료 WiFi**를 제공 - 가입은 기내 포털에서 이메일 인증 없이 가능, WhatsApp·Signal·WeChat은 작동했으나 Discord는 차단됨 - 작성자는 이 서비스가 **어떤 방식으로 메시징 앱만 허용하는지** 의문을 가짐 - 단순한 트래픽 제한이 아닌, TLS **SNI 필드 기반 도메인 화이트리스트**로 판단됨 - Wireshark 분석 결과, `example.com` 접속 시 **Client Hello 이후 TCP 리셋**이 발생 - 이는 TLS 핸드셰이크 중 노출되는 **SNI 값**을 이용해 비허용 도메인을 차단하는 방식임 ### SNI 기반 필터링의 원리 - TLS SNI는 암호화 이전 단계에서 **접속하려는 도메인 이름을 평문으로 전송** - 이를 통해 ISP나 네트워크 관리자는 사용자가 어떤 사이트에 접속하는지 확인 가능 - 브리티시 에어웨이즈는 **메시징 앱 관련 도메인만 화이트리스트**로 등록, 나머지는 연결을 리셋 - 작성자는 SNI가 없는 직접 IP 연결(`openssl s_client -connect`)도 차단됨을 확인 - 즉, **SNI 누락 자체도 비정상 트래픽으로 간주**됨 ### SNI 조작 실험 - 작성자는 `wa.me`(WhatsApp 도메인)를 SNI로 설정해 TLS 연결을 시도 - 서버 인증서는 `wa.me`용이 아니었지만, 클라이언트가 인증서 불일치를 무시하면 연결 가능 - 결과적으로 BA 시스템은 이를 **메시징 트래픽으로 오인**, TLS 터널을 허용 - 이후 HTTP 요청을 직접 작성해 자신의 서버(`saxrag.com`) 콘텐츠를 성공적으로 수신 - 이 실험으로 **SNI 필드만 속이면 임의의 트래픽 전송이 가능함**이 입증됨 ### HTTPS 프록시를 이용한 완전한 우회 - 작성자는 `tinyproxy`와 `stunnel`을 이용해 **HTTPS 프록시 서버**를 구성 - `stunnel`은 TLS 계층을 추가해, 클라이언트가 `wa.me`로 연결하는 것처럼 위장 - `curl` 명령어에서 `--resolve` 옵션을 사용해 `wa.me`를 자신의 VPS IP로 매핑 - 이로써 SNI는 `wa.me`로 설정되지만 실제 연결은 개인 서버로 이루어짐 - TLS 인증서 오류는 `--proxy-insecure`로 무시, **프록시를 통한 외부 요청 성공** - `ifconfig.co` 요청 시 VPS IP가 반환되어, 프록시 동작이 확인됨 ### 실제 비행 중 테스트 - 귀국편에서 동일한 설정으로 WiFi 접속 후, `curl`을 통해 **정상적인 HTTP 200 응답**을 수신 - 이후 브라우저(Chromium)에 HTTPS 프록시를 설정하고, `wa.me`를 hosts 파일에 등록 - 결과적으로 **Hacker News 웹사이트 접속 성공**, 텍스트 기반 페이지는 정상 로드 - Wireshark에서 SSLKEYLOGFILE을 이용해 TLS 복호화 확인 - 이미지나 대용량 콘텐츠는 **라인 단위로 느리게 로드**, 대역폭 제한 존재 추정 - 이는 BA가 **SNI 외에도 트래픽 속도 제한을 병행**함을 시사 ### ECH(Encrypted Client Hello) 실험 - 작성자는 TLS SNI 노출 문제를 해결하는 **ECH 기술**을 직접 테스트 - `wa.me`를 public_name으로 설정한 ECHConfig를 생성, Firefox에서 적용 - 결과적으로 외부 SNI는 `wa.me`로 유지되지만, 내부 ClientHello에는 실제 도메인(`rfc5746.mywaifu.best`)이 포함 - Let’s Encrypt 인증서로 정상적인 TLS 연결 성립 - 흥미롭게도 **비표준 포트(7443)** 에서도 작동, 브리티시 에어웨이즈 필터링을 우회 - 작성자는 ECHConfig가 **DNS-over-HTTPS(DoH)** 로 전송되었을 가능성을 제기 ### SNI의 한계와 보안적 시사점 - SNI는 본래 서버 인증서 선택을 위한 **“힌트” 수준의 정보**에 불과 - 클라이언트·서버 모두 제어 가능한 환경에서는 **임의의 SNI 값 삽입 가능** - 이는 검열 시스템이나 위협 탐지 솔루션이 **SNI 기반 필터링에 과도하게 의존할 경우 오탐 가능성**을 의미 - 악성코드 제작자는 C&C 서버 접속 시 **무해한 도메인으로 위장된 SNI**를 사용할 수 있음 - 따라서 네트워크 보안 정책은 **SNI 외 추가적인 트래픽 분석 및 암호화 계층 검증**이 필요 ### 결론 - 브리티시 에어웨이즈의 무료 WiFi는 **SNI 기반 도메인 필터링과 대역폭 제한**으로 메시징 트래픽만 허용 - 그러나 SNI 조작을 통해 **임의의 HTTPS 트래픽을 메시징으로 위장**할 수 있음이 실험으로 입증 - 이 사례는 TLS 설계의 구조적 한계를 보여주며, **ECH 도입의 필요성**을 강조 - 네트워크 사업자와 보안 담당자는 **SNI 의존형 필터링의 취약성**을 인식해야 함 - 기술적으로는 흥미로운 우회 사례이지만, **보안·윤리적 고려**가 병행되어야 할 연구 사례 ## Comments ### Comment 45457 - Author: neo - Created: 2025-10-25T21:33:53+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45695134) - 내 친구가 예전에 비슷한 **터널링**을 했는데, 크루즈선에서도 작동했음 일부 항공사(아마 American Airlines)는 Fortinet 방화벽을 써서 단순히 SNI만 보는 게 아니라, 서버 인증서의 **호스트명과 인증기관**까지 검증함 친구는 aa.com의 SNI를 사용하고 실제 aa.com의 TLS 1.2 핸드셰이크를 그대로 전달하는 방식으로 이를 우회했음 이후 암호화된 데이터 단계에서는 그 핸드셰이크를 무시하고 단순히 암호화된 터널로 사용했음 요즘은 **TLS 1.3**을 쓰면 인증서가 암호화되어 방화벽이 내용을 볼 수 없으므로 이런 문제를 피할 수 있음 - 이건 사실 [**Xray**](https://github.com/XTLS/Xray-core)가 하는 방식과 거의 같음 특정 SNI에 맞는 요청이 비밀키 없이 들어오면 SSL 핸드셰이크 전체를 위장용 웹사이트로 프록시함 그렇지 않으면 SSL 트래픽으로 위장한 일반 프록시로 동작함 원래는 중국의 **GFW(만리방화벽)** 을 우회하기 위해 만들어졌지만, 친구가 Google Analytics를 SNI로 설정하자 American 항공의 기내 방화벽에서도 작동했다고 함 - 나도 최근 3주짜리 크루즈 여행을 다녀왔는데, 인터넷이 하루에 50달러로 터무니없이 비쌌음 Wi-Fi와 앱은 무료로 작동하지만 대부분의 트래픽은 차단됨 Wireshark로 보니 TCP 연결 초기에 몇 개의 패킷만 허용하고, 이후 **ClientHello**를 검사해 화이트리스트 도메인만 통과시킴 크루즈 앱은 회사 도메인이 화이트리스트에 있어서 작동함 이런 허점을 악용하지 말고 조용히 써야 함. 너무 알려지면 막힐 테니까 아쉬움 - 요즘 크루즈선의 진짜 해결책은 **Starlink Mini**를 들고 가는 것임 접시값과 요금이 비싸도, 크루즈 회사에 대한 일종의 ‘자유 선언’으로 충분히 가치 있음 - 나는 공공 Wi-Fi(기내 포함)를 **UDP 53 포트 VPN 서버**로 우회한 적이 많음 요즘은 캡티브 포털이 외부 트래픽을 거의 막지만, 여전히 많은 곳이 취약함 SoftEther를 추천함 — **Azure Relay** 기능 덕분에 화이트리스트 네트워크에서도 잘 작동함 아직 **iodine**을 써서 DNS 양방향 통신까지는 안 해봤지만, 느리더라도 대부분의 경우 통할 듯함 - 결제 위젯을 띄우기 위해 일시적으로 모든 트래픽을 허용하는 포털이 있음 결제 과정을 반복해서 시작하면 그걸로 우회 가능함 - 예전에 Hetzner 서버에 8개의 IP를 두고, 하나는 모든 포트에서 OpenVPN을 허용하도록 설정했음 여러 포트를 시도하느라 시작은 느렸지만, 성공률이 놀라울 정도로 높았음 - 나도 WireGuard와 OpenVPN을 각각 다른 VPS에서 53포트로 돌림 하지만 요즘은 DNS 트래픽만 허용하고, 임의의 리졸버는 막는 경우가 많음 - 일부 항공사 Wi-Fi는 **무료 메시징(WhatsApp, Messenger)** 만 허용함 만약 **TCP-over-WhatsApp VPN**을 만들 수 있다면 정말 멋질 것 같음 - 누군가가 말한 “요청 페이로드를 서브도메인으로 보내고, TXT 레코드로 응답을 받는” 방식은 바로 [**iodine**](https://github.com/yarrick/iodine)임 - 나도 12년 전쯤 비슷한 걸 해봤음 DNS는 아니고 HTTP(S)를 UDP 터널링으로 돌렸는데, Stansted 공항에서 무료 Wi-Fi 30분 제한 안에 세팅 성공했을 때 꽤 뿌듯했음 - 예전에 **British Airways** 사이버보안 면접을 봤는데, 꽤 이상한 경험이었음 웹사이트의 심각한 취약점을 언급했더니 “중요하면 **pentest**에서 걸릴 것”이라며 대수롭지 않게 넘겼음 서로 별로 인상적이지 않은 채로 끝났음 - BA는 실제로 결제 페이지에 **카드 스키머 스크립트**가 삽입돼 털린 적이 있음 기내 Wi-Fi 보안은 사실상 돈벌이용 장치일 뿐, 회사 보안과는 별개임 - 어쩌면 그들의 면접 자체가 pentest였을지도 모름 - pentest는 영국식 주택 조사처럼 쓸모없다고 느껴짐 많은 회사가 연례 pentest만 하면 보안이 끝났다고 생각하지만, 실제로 제품을 아는 엔지니어들은 투자 승인을 받지 못함 - 나는 **불법 복제는 절도와 다르다**고 생각하지만, 이건 진짜 절도에 가까움 기술 업계는 고소득 직종인데, Wi-Fi 요금 정도는 내야 한다고 봄 - 나는 **tuningfork**라는 프로젝트를 만들었음 트래픽을 다른 노드를 통해 프록시하는 도구로, 네트워크를 이해하려고 직접 구현했음 영국의 **연령 인증 법**을 우회하려는 목적도 있었음 [GitHub 링크](https://github.com/mutn3ja/tuningfork) - 참고로 이런 방식은 [**Domain Fronting**](https://en.wikipedia.org/wiki/Domain_fronting)이라고 부름 - 예전에 크루즈 관련 게시물이 **법적 위협**을 받았던 적이 있어서, 이번 것도 얼마나 오래 버틸지 궁금함 - 그 이야기 링크를 혹시 알고 있는지 묻고 싶음 - 나는 비행 중에 **오프라인 상태**로 있는 걸 즐기는 편임 잠시 세상과 단절되는 그 시간이 좋음. 그래서 모두가 무료 Wi-Fi를 쓰게 되는 건 반갑지 않음 - 하지만 결국 **자유 의지**의 문제임 네가 원하지 않으면 접속하지 않으면 됨. 남들이 쓴다고 해서 네게 영향은 없음 - 그냥 이런 수고를 들여 무료 Wi-Fi를 얻지 않으면 됨 - 지금 이 순간 **British Airways** 비행기 안에서 글을 쓰고 있음 무료 메시징 플랜을 켜고 **WireGuard 터널**을 사용 중인데, 방화벽이 완벽히 차단하도록 설계된 것 같지는 않음 - 혹시 그냥 51820 포트로 WireGuard를 돌린 건지 궁금함 예전에 시도했는데 잘 안 됐던 기억이 있음