Resumo

  • O SNI levou o nome DNS pretendido para o ClientHello, permitindo que um ponto TLS compartilhado escolhesse certificado e serviço antes de receber o HTTP criptografado.
  • O campo seleciona contexto, mas não comprova identidade ou autorização. Como aparece antes da criptografia, ficou observável; o ECH passou a separar um nome externo público do nome interno protegido.

Um hotel com uma chave só para a portaria

Imagine um hotel dividido em várias alas independentes, todas atrás da mesma entrada. Antes de abrir a correspondência lacrada do hóspede, a portaria precisa apresentar a credencial da ala correta. O nome da ala está dentro da correspondência. A ordem impede a decisão.

Foi esse o problema entre hospedagem virtual e TLS. A RFC 2246 estabelecia autenticação e chaves antes dos dados de aplicação protegidos. O Host do HTTP só chegaria depois do handshake, tarde demais para escolher o certificado que participava dele.

Em 2003, a RFC 3546 definiu Server Name Indication. O cliente incluiu o nome do servidor no ClientHello, dando ao front-end a informação necessária para selecionar certificado, parâmetros e serviço.

A mudança essencial foi temporal. O protocolo não inventou o nome do site; retirou uma cópia mínima dele da mensagem futura e a colocou antes da decisão criptográfica.

O endereço deixou de determinar sozinho a identidade

Hospedagem HTTP por nome já permitia compartilhar endereços. O front-end lia a autoridade do pedido e encaminhava o conteúdo. TLS exigia apresentar uma identidade antes dessa leitura.

Sem SNI, havia alternativas caras ou rígidas: um endereço por identidade, certificados com muitos nomes ou um certificado padrão que nem sempre correspondia ao destino. Endereçamento, renovação de certificados e topologia ficavam acoplados.

SNI acrescentou um segundo seletor. DNS e roteamento ainda levam a conexão até o endereço. O nome no ClientHello diz qual contexto TLS deve responder. Essa distinção sustentou hospedagem compartilhada segura, redes de distribuição, proxies reversos e gateways de nuvem.

Não foi o fim do IP, mas o fim da suposição de que um IP bastava para identificar um único serviço HTTPS.

Selecionar não é autorizar

A RFC 6066 consolidou server_name e o formato DNS host_name. Se o servidor entende a extensão, mas não reconhece o nome, pode abortar com unrecognized_name ou prosseguir conforme a política local.

O campo não prova que o cliente tem direito ao serviço. Também não autentica DNS nem torna o certificado selecionado automaticamente válido. O cliente continua responsável por validar o certificado, e a aplicação continua responsável por permissões e pela autoridade do pedido.

SNI funciona como o nome escrito no lado de fora de uma encomenda: ajuda a entregá-la ao balcão certo. Não é a assinatura, não é o conteúdo e não é autorização para abrir portas. Essa separação deve permanecer inclusive quando o mesmo front-end controla vários locatários.

A informação chegou antes da proteção

O primeiro ClientHello precede as chaves produzidas pelo handshake. Se o nome fosse cifrado com essas chaves, o servidor teria de escolher o contexto sem conhecer o dado que orienta a escolha. O SNI original resolveu a circularidade deixando o nome visível.

Um observador no caminho podia não ver URL, texto ou resposta HTTP, mas ainda aprender o domínio. A RFC 8744 descreveu a perda de privacidade e os usos operacionais formados em torno do SNI em claro.

A RFC 8446 trouxe TLS 1.3 e criptografou mais mensagens após o ServerHello. Ainda assim, o ClientHello inicial precisa chegar antes. A exposição não sumiu com a modernização da cifra porque vinha da ordem do protocolo.

Quando uma pista vira dependência

CDNs roteiam pelo nome; sistemas de observabilidade agrupam eventos; controles de rede filtram; equipes de suporte diagnosticam. O que começou como solução para seleção virou uma interface consumida por muitos atores.

Isso torna a privacidade uma mudança de arquitetura e de incentivos. O serviço de entrada precisa de informação pública suficiente para alcançar quem pode decifrar o destino. Intermediários, ao mesmo tempo, podem tratar a visibilidade histórica como requisito permanente.

O risco é confundir necessidade com hábito. Nem todo consumidor do SNI em claro precisa conhecer o nome exato; alguns apenas se acostumaram a tê-lo.

ECH cria um nome de fachada e outro de destino

A RFC 9849 especifica Encrypted ClientHello. O cliente monta um ClientHello interno com as informações sensíveis e o cifra dentro de um ClientHello externo. O nome público externo encaminha a conexão até o serviço compatível; o nome real do site permanece no interior.

ECH não apaga todos os metadados. O endereço e o nome público continuam observáveis. A diferença é que eles podem representar uma fachada compartilhada, sem identificar diretamente cada origem hospedada atrás dela.

O cliente confirma pelo handshake protegido se ECH foi aceito. Se o servidor não puder decifrar, pode fornecer configurações para nova tentativa. O protocolo evita tratar o nome externo como destino real por acidente.

Assim, o problema antigo recebe uma resposta menos reveladora: publique apenas o nome necessário para chegar à fronteira que protege o nome preciso.

O legado de uma decisão de ordem

SNI tornou compatíveis a economia da hospedagem por nome e a sequência de autenticação do TLS. Viabilizou muitos serviços seguros em um endereço e diminuiu a dependência de certificados e IPs rigidamente pareados.

Nunca foi prova de identidade, permissão ou sigilo. Sua força e sua fragilidade nasceram do mesmo lugar: antes da criptografia. ECH não promete invisibilidade completa; procura reduzir quem conhece o destino específico.

Campos de protocolo distribuem poder conforme o momento em que aparecem. Quem vê o nome antes da proteção pode usá-lo. Redesenhar essa fronteira exige uma rota pública mínima e a disciplina de não transformá-la em autoridade privada.

Fontes e limites das evidências

O registro normativo inclui as RFC 2246, RFC 3546, RFC 6066, RFC 8446, RFC 8744 e RFC 9849. As conclusões sobre custo de hospedagem e dependência operacional são inferências da ordem e visibilidade das mensagens, não medições de um provedor específico.