O que é SNI (Server Name Indication)

Server Name Indication (SNI) é um campo no TLS handshake. Quando seu navegador conecta a um site sobre HTTPS, manda um valor SNI não criptografado na primeira mensagem: "quero falar com www.example.com." O servidor usa isso pra escolher o certificado certo (vários sites frequentemente compartilham um IP via virtual hosting), aí os dois lados configuram criptografia pra tudo que segue.

A pegadinha: SNI é texto puro. Qualquer um observando o cabo (seu provedor, o Wi-Fi do café, uma caixa DPI) vê o hostname. Mesmo cada byte de página depois do handshake estar criptografado, o domínio destino está em texto claro no momento da conexão.

Por que SNI existe

Antes do SNI, todo site HTTPS precisava do próprio endereço IP. O servidor recebia um handshake criptografado e não tinha como dizer qual certificado apresentar. SNI consertou isso adicionando o hostname à parte não criptografada do handshake. Agora centenas de sites podem compartilhar um IP: o servidor lê o SNI, pega o cert correspondente, o handshake completa.

É como shared hosting e tráfego de CDN funcionam em escala. Cloudflare, Fastly, Akamai todos servem milhões de domínios de um conjunto pequeno de IPs. SNI é o que faz isso possível.

O que SNI revela

Mesmo com HTTPS completo:

• Seu provedor sabe todo domínio que você visita.
• A rede do seu empregador sabe.
• Equipamento de vigilância governamental sabe.
• Qualquer um rodando DPI no caminho sabe.

Conteúdo de página é criptografado. Destino não. Pra privacidade da rede, esse é o canal lateral que derrota o raciocínio "mas HTTPS me protege".

Encrypted SNI: rollout lento

Encrypted Client Hello (ECH) e o mais antigo Encrypted SNI (ESNI) tentam criptografar o hostname pra que a rede não consiga ler. Ambos funcionam criptografando o SNI com uma chave que o destino publica via DNS.

Adoção é parcial:

• Cloudflare suporta ECH.
• Firefox suporta ECH (off por default em algumas regiões).
• Chrome tem suporte experimental.
• A maioria dos CDNs e sites grandes não deployaram.

Até ECH ser ubíquo, SNI vaza. E em redes fazendo DPI agressivo, mesmo navegadores usando ECH são filtrados ou downgraded; o censor pode detectar a tentativa de ECH e bloquear.

Como VLESS Reality usa SNI pra desaparecer

VLESS Reality pega SNI e transforma em camuflagem. O SNI do handshake é o SNI de um site público real tipo microsoft.com. O certificado servido de volta é o certificado real do microsoft.com, assinado pelo CA real. Pro DPI observando o cabo, essa conexão é indistinguível de qualquer outra sessão HTTPS pra microsoft.com: mesmo SNI, mesmo cert, mesmo timing de handshake.

Pra bloquear, o censor teria que bloquear microsoft.com: o que geralmente não vão fazer, porque tráfego demais depende dele. Essa é a diferença estrutural entre Reality e VPNs "obfuscated" que tentam fingir um TLS handshake. Reality usa reais.

Leia Deep packet inspection, explicado pra como isso se encaixa no quadro mais amplo de censura, ou a página do protocolo VLESS Reality pra detalhes de implementação.

Experimente o Fexyn grátis por 7 dias. Stealth usa SNI real pra hosts públicos pra que DPI veja HTTPS normal, não VPN.