- Foi revelado que o serviço de WiFi gratuito para mensagens a bordo da British Airways, na prática, permite acesso limitado à internet por meio de filtragem baseada em domínios específicos
- O autor manipulou o campo TLS SNI (Server Name Indication) para enganar o sistema da companhia, fazendo-o interpretar o tráfego como sendo de mensagens, e conseguiu acessar sites comuns
- Para isso, configurou
wa.me (domínio do WhatsApp) como SNI e desviou o tráfego usando proxy HTTPS e stunnel
- Nos testes, sites baseados em texto, como o Hacker News, carregaram normalmente, mas imagens e conteúdo pesado foram transmitidos lentamente por causa de limitação de banda
- O caso mostra a fragilidade da filtragem baseada em TLS SNI e a necessidade de tecnologias como ECH (Encrypted Client Hello) para complementá-la
Como funciona o WiFi gratuito para mensagens
- A British Airways oferece WiFi gratuito apenas para mensagens aos membros do “The British Airways Club”
- O cadastro pode ser feito no portal de bordo sem verificação por e-mail; WhatsApp, Signal e WeChat funcionaram, mas o Discord foi bloqueado
- O autor quis entender como o serviço permitia apenas apps de mensagens
- A conclusão foi que não se tratava apenas de limitação de tráfego, mas de uma whitelist de domínios baseada no campo TLS SNI
- A análise com Wireshark mostrou que, ao acessar
example.com, ocorria um reset TCP logo após o Client Hello
- Ou seja, o bloqueio usava o valor do SNI, exposto durante o handshake TLS, para barrar domínios não permitidos
Como funciona a filtragem baseada em SNI
- O SNI do TLS envia em texto puro o nome do domínio que está sendo acessado antes da criptografia entrar em ação
- Isso permite que ISPs ou administradores de rede vejam quais sites o usuário está tentando acessar
- A British Airways mantinha em whitelist apenas domínios ligados a apps de mensagens, resetando as demais conexões
- O autor também confirmou que conexões diretas por IP sem SNI (
openssl s_client -connect) eram bloqueadas
- Ou seja, a ausência de SNI por si só também era tratada como tráfego anômalo
Experimento de manipulação de SNI
- O autor tentou estabelecer uma conexão TLS definindo
wa.me (domínio do WhatsApp) como SNI
- O certificado do servidor não era para
wa.me, mas a conexão funcionava se o cliente ignorasse a incompatibilidade do certificado
- Como resultado, o sistema da BA interpretou isso como tráfego de mensagens e permitiu o túnel TLS
- Depois, o autor escreveu manualmente requisições HTTP e recebeu com sucesso conteúdo do seu servidor (
saxrag.com)
- O experimento demonstrou que é possível transmitir tráfego arbitrário apenas enganando o campo SNI
Bypass completo com proxy HTTPS
- O autor montou um servidor proxy HTTPS usando
tinyproxy e stunnel
- O
stunnel adicionava a camada TLS para fazer o cliente parecer conectado a wa.me
- No comando
curl, usou a opção --resolve para mapear wa.me ao IP do próprio VPS
- Assim, o SNI era definido como
wa.me, mas a conexão real ia para o servidor pessoal
- O erro de certificado TLS foi ignorado com
--proxy-insecure, e as requisições externas via proxy funcionaram
- Ao consultar
ifconfig.co, foi retornado o IP do VPS, confirmando o funcionamento do proxy
Teste em um voo real
- No voo de volta, usando a mesma configuração após conectar ao WiFi, o autor recebeu uma resposta HTTP 200 válida via
curl
- Depois, configurou o proxy HTTPS no navegador (Chromium) e registrou
wa.me no arquivo hosts
- Como resultado, conseguiu acessar o site Hacker News, com páginas baseadas em texto carregando normalmente
- No Wireshark, confirmou a descriptografia TLS usando
SSLKEYLOGFILE
- Imagens e conteúdo pesado carregavam lentamente, linha por linha, sugerindo limitação de banda
- Isso indica que a BA provavelmente combina controle por SNI com limitação de velocidade de tráfego
Experimento com ECH (Encrypted Client Hello)
- O autor também testou diretamente a tecnologia ECH, que busca resolver a exposição do SNI no TLS
- Ele gerou um ECHConfig com
wa.me como public_name e o aplicou no Firefox
- Como resultado, o SNI externo continuava sendo
wa.me, mas o ClientHello interno incluía o domínio real (rfc5746.mywaifu.best)
- A conexão TLS foi estabelecida normalmente com um certificado da Let’s Encrypt
- Curiosamente, isso também funcionou em uma porta não padrão (7443), contornando a filtragem da British Airways
- O autor levanta a possibilidade de que o ECHConfig tenha sido transmitido por DNS-over-HTTPS (DoH)
Limites do SNI e implicações de segurança
- O SNI foi concebido originalmente apenas como uma informação de “dica” para a escolha do certificado do servidor
- Em ambientes onde cliente e servidor estão sob controle, é possível inserir valores arbitrários de SNI
- Isso significa que sistemas de censura ou soluções de detecção de ameaças podem gerar falsos positivos se dependerem demais da filtragem baseada em SNI
- Um criador de malware pode usar um SNI disfarçado de domínio inofensivo ao se conectar a um servidor de C&C
- Por isso, políticas de segurança de rede precisam de análise adicional de tráfego e validação da camada criptográfica além do SNI
Conclusão
- O WiFi gratuito da British Airways permite apenas tráfego de mensagens por meio de filtragem de domínios baseada em SNI e limitação de banda
- Porém, o experimento mostrou que, manipulando o SNI, é possível disfarçar tráfego HTTPS arbitrário como se fosse de mensagens
- O caso expõe limites estruturais do design do TLS e reforça a necessidade de adoção do ECH
- Operadores de rede e responsáveis por segurança devem reconhecer a fragilidade de filtros dependentes de SNI
- É um caso tecnicamente interessante de bypass, mas que também exige considerações de segurança e ética
1 comentários
Comentários do Hacker News
Algumas companhias aéreas (acho que a American Airlines) usam firewall da Fortinet, então não verificam só o SNI, mas também o nome do host e a autoridade certificadora do certificado do servidor
Ele contornou isso usando o SNI de aa.com e repassando o handshake TLS 1.2 real do próprio aa.com
Depois, na fase de dados criptografados, ignorava esse handshake e usava apenas como um túnel criptografado
Hoje em dia, se você usar TLS 1.3, o certificado fica criptografado e o firewall não consegue ver o conteúdo, então dá para evitar esse problema
Se chegar uma solicitação para um SNI específico sem a chave secreta, ele faz proxy de todo o handshake SSL para um site de disfarce
Caso contrário, funciona como um proxy normal disfarçado de tráfego SSL
Originalmente foi criado para contornar o GFW (Grande Firewall) da China, mas quando meu amigo configurou o Google Analytics como SNI, também funcionou no firewall de bordo da American
O Wi‑Fi e o app funcionam de graça, mas a maior parte do tráfego é bloqueada
No Wireshark, vi que só deixam passar alguns pacotes no início da conexão TCP e depois inspecionam o ClientHello para liberar apenas domínios na whitelist
O app do cruzeiro funciona porque o domínio da empresa está na whitelist
Não vale a pena abusar desse tipo de brecha e chamar atenção. Se ficar muito conhecido, vão bloquear, o que seria uma pena
Mesmo com o preço alto da antena e da assinatura, vale totalmente como uma espécie de “declaração de independência” em relação à empresa de cruzeiro
Hoje em dia, os captive portals bloqueiam quase todo o tráfego externo, mas muitos lugares ainda são vulneráveis
Recomendo o SoftEther — por causa do recurso Azure Relay, ele funciona bem até em redes com whitelist
Ainda não cheguei a usar iodine para comunicação bidirecional por DNS, mas mesmo sendo lento, provavelmente funciona na maioria dos casos
Se você iniciar o processo de pagamento repetidamente, dá para contornar por aí
O início era lento porque eu precisava testar várias portas, mas a taxa de sucesso era surpreendentemente alta
Mas hoje em dia é comum permitirem só tráfego DNS e bloquearem resolvedores arbitrários
Se alguém conseguisse fazer uma VPN TCP-over-WhatsApp, seria realmente incrível
Não era DNS, mas um túnel HTTP(S) sobre UDP, e fiquei bem satisfeito quando consegui configurar tudo dentro do limite de 30 minutos do Wi‑Fi grátis no aeroporto de Stansted
Mencionei uma vulnerabilidade séria no site, e responderam algo como “se for importante, o pentest vai encontrar”, sem dar muita importância
A conversa terminou sem impressionar ninguém
A segurança do Wi‑Fi de bordo é basicamente um mecanismo para ganhar dinheiro, separado da segurança corporativa em si
Muitas empresas acham que segurança está resolvida só porque fazem um pentest anual, enquanto os engenheiros que realmente conhecem o produto não conseguem aprovação para investimentos
O setor de tecnologia é uma área de alta renda, então acho que dá para pagar pelo menos a taxa do Wi‑Fi
É uma ferramenta para fazer proxy de tráfego por outros nós, que implementei eu mesmo para entender melhor redes
Também tinha o objetivo de contornar a lei de verificação de idade do Reino Unido
Link do GitHub
Gosto desse tempo em que fico desconectado do mundo por um instante. Então não me anima muito a ideia de todo mundo usar Wi‑Fi grátis
Se você não quiser, é só não se conectar. O fato de outras pessoas usarem não muda nada para você
Ativei o plano gratuito de mensagens e estou usando um túnel WireGuard, então o firewall não parece ter sido projetado para bloquear tudo perfeitamente
Lembro de ter tentado isso antes e não ter funcionado muito bem