브리티시 에어웨이즈 무료 WiFi 잠금 해제하기

• 브리티시 에어웨이즈의 기내 무료 메시징 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 의존형 필터링의 취약성을 인식해야 함
• 기술적으로는 흥미로운 우회 사례이지만, 보안·윤리적 고려가 병행되어야 할 연구 사례