▲

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

 (saxrag.com)
1P by GN⁺ 10일전 | ★ favorite | 댓글 1개
  • 브리티시 에어웨이즈의 기내 무료 메시징 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 의존형 필터링의 취약성을 인식해야 함
  • 기술적으로는 흥미로운 우회 사례이지만, 보안·윤리적 고려가 병행되어야 할 연구 사례
▲
GN⁺ 10일전  [-]
Hacker News 의견
  • 내 친구가 예전에 비슷한 터널링을 했는데, 크루즈선에서도 작동했음
    일부 항공사(아마 American Airlines)는 Fortinet 방화벽을 써서 단순히 SNI만 보는 게 아니라, 서버 인증서의 호스트명과 인증기관까지 검증함
    친구는 aa.com의 SNI를 사용하고 실제 aa.com의 TLS 1.2 핸드셰이크를 그대로 전달하는 방식으로 이를 우회했음
    이후 암호화된 데이터 단계에서는 그 핸드셰이크를 무시하고 단순히 암호화된 터널로 사용했음
    요즘은 TLS 1.3을 쓰면 인증서가 암호화되어 방화벽이 내용을 볼 수 없으므로 이런 문제를 피할 수 있음
    • 이건 사실 Xray가 하는 방식과 거의 같음
      특정 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임
    • 나도 12년 전쯤 비슷한 걸 해봤음
      DNS는 아니고 HTTP(S)를 UDP 터널링으로 돌렸는데, Stansted 공항에서 무료 Wi-Fi 30분 제한 안에 세팅 성공했을 때 꽤 뿌듯했음
  • 예전에 British Airways 사이버보안 면접을 봤는데, 꽤 이상한 경험이었음
    웹사이트의 심각한 취약점을 언급했더니 “중요하면 pentest에서 걸릴 것”이라며 대수롭지 않게 넘겼음
    서로 별로 인상적이지 않은 채로 끝났음
    • BA는 실제로 결제 페이지에 카드 스키머 스크립트가 삽입돼 털린 적이 있음
      기내 Wi-Fi 보안은 사실상 돈벌이용 장치일 뿐, 회사 보안과는 별개임
    • 어쩌면 그들의 면접 자체가 pentest였을지도 모름
    • pentest는 영국식 주택 조사처럼 쓸모없다고 느껴짐
      많은 회사가 연례 pentest만 하면 보안이 끝났다고 생각하지만, 실제로 제품을 아는 엔지니어들은 투자 승인을 받지 못함
  • 나는 불법 복제는 절도와 다르다고 생각하지만, 이건 진짜 절도에 가까움
    기술 업계는 고소득 직종인데, Wi-Fi 요금 정도는 내야 한다고 봄
  • 나는 tuningfork라는 프로젝트를 만들었음
    트래픽을 다른 노드를 통해 프록시하는 도구로, 네트워크를 이해하려고 직접 구현했음
    영국의 연령 인증 법을 우회하려는 목적도 있었음
    GitHub 링크
  • 참고로 이런 방식은 Domain Fronting이라고 부름
  • 예전에 크루즈 관련 게시물이 법적 위협을 받았던 적이 있어서, 이번 것도 얼마나 오래 버틸지 궁금함
    • 그 이야기 링크를 혹시 알고 있는지 묻고 싶음
  • 나는 비행 중에 오프라인 상태로 있는 걸 즐기는 편임
    잠시 세상과 단절되는 그 시간이 좋음. 그래서 모두가 무료 Wi-Fi를 쓰게 되는 건 반갑지 않음
    • 하지만 결국 자유 의지의 문제임
      네가 원하지 않으면 접속하지 않으면 됨. 남들이 쓴다고 해서 네게 영향은 없음
    • 그냥 이런 수고를 들여 무료 Wi-Fi를 얻지 않으면 됨
  • 지금 이 순간 British Airways 비행기 안에서 글을 쓰고 있음
    무료 메시징 플랜을 켜고 WireGuard 터널을 사용 중인데, 방화벽이 완벽히 차단하도록 설계된 것 같지는 않음
    • 혹시 그냥 51820 포트로 WireGuard를 돌린 건지 궁금함
      예전에 시도했는데 잘 안 됐던 기억이 있음
답변달기