Resumo

  • O server_name é um nome DNS fornecido pelo cliente no ClientHello para orientar uma escolha antecipada de contexto, certificado ou destino de passthrough. Ele não autentica o cliente.
  • Identidade do serviço, Host/:authority, SNI upstream, estado ECH e autorização da aplicação são decisões independentes. Repetir a mesma string não transfere autoridade entre elas.

Uma escolha correta produziu a identidade errada

O callback encontrou exatamente a configuração esperada. O certificado exibido era o do Tenant A e o handshake terminou sem erro. A falha só apareceu porque o sistema de política copiou o identificador do contexto TLS para o campo de principal.

SNI existe para resolver uma limitação de tempo: antes de enviar um certificado, o servidor precisa saber qual serviço virtual o cliente pretende alcançar. A informação vem do próprio cliente. Qualquer software capaz de montar um ClientHello pode indicar um nome sintaticamente válido.

Selecionar a credencial certa permite que o cliente autentique o servidor. Não prova que o servidor autenticou o cliente, muito menos que o cliente representa a organização nomeada. O controle falhou ao transformar seleção em pertencimento.

A extensão restringe forma, não titularidade

A RFC 6066 define server_name como uma lista no ClientHello. O tipo host_name contém nome DNS em ASCII; endereços IPv4 e IPv6 literais são proibidos, e o mesmo tipo de nome não pode aparecer duas vezes.

Nada disso prova resolução DNS, controle da zona, posse de chave ou vínculo com um tenant. Um operador pode conectar diretamente a um IP e enviar outro nome para diagnóstico. Um atacante pode fazer a mesma coisa para localizar o contexto mais valioso.

O servidor pode encerrar com unrecognized_name fatal quando rejeita um nome que entende, ou seguir uma política explícita de fallback. Por isso, a auditoria precisa testar SNI ausente, desconhecido e inválido, além do virtual host padrão. Uma tabela configurada não revela o caminho executado.

Integridade da fala não é autoridade do falante

No TLS 1.3, ClientHello faz parte do transcript autenticado por Finished. Um handshake concluído protege o SNI ordinário contra alteração silenciosa no caminho.

O resultado confirma que o servidor viu o valor que o cliente enviou nesta conexão. Não confirma que o cliente tinha direito de enviá-lo. A integridade de uma declaração não demonstra sua titularidade.

Sem autenticação do cliente, um handshake perfeito ainda pode deixar o peer anônimo para o servidor. O certificado do servidor opera no sentido oposto: é o cliente que verifica a identidade do serviço.

A telemetria deve preservar essa direção. client_requested_server_name é um fato; verified_tenant exige uma credencial e uma decisão que SNI não oferece.

Escolher certificado e validar identidade

SNI ajuda o servidor a escolher uma credencial. A RFC 9525 exige que o cliente construa seus identificadores de referência independentemente do certificado apresentado e depois os compare com os identificadores contidos nele.

Cadeia, validade, revogação e correspondência do nome pertencem ao lado verificador. O servidor ter escolhido o certificado pretendido não comprova que o cliente executou nenhuma dessas verificações.

No OpenSSL, SSL_set_tlsext_host_name() define SNI, enquanto o nome DNS esperado para validação precisa ser configurado separadamente. Uma aplicação que faz só a primeira operação pode receber o certificado ideal e ainda assim não autenticar corretamente o serviço.

Certificados com múltiplos SANs reforçam o ponto. Cobrir dois nomes criptograficamente não une os tenants nem autoriza uma origem a acessar a outra.

A autoridade HTTP chega depois

Após TLS, HTTP/1.1 apresenta Host; HTTP/2 e HTTP/3 normalmente usam :authority. A RFC 9110 trata essa informação como crítica para identificar e rotear o recurso solicitado.

Um cliente comum deriva SNI e authority da mesma URI, então os valores frequentemente coincidem. Isso não os torna o mesmo campo. Reuso de conexão, proxy, teste, erro ou ataque pode fazê-los divergir.

O serviço precisa de uma regra explícita: rejeitar, permitir uma matriz pequena e documentada, ou devolver 421 quando a conexão não serve ao origin pedido. O SNI do primeiro handshake não deve autorizar todas as requisições seguintes.

Mesmo a igualdade só indica coerência de destino. Ela continua sem dizer quem é o cliente ou quais ações ele pode executar.

O proxy reinicia a evidência

Um proxy que termina TLS possui uma conexão downstream e cria outra upstream. Cada uma tem ClientHello, SNI, certificado, identidade de referência e resultado próprios.

O SNI de saída pode ser fixo, derivado do host upstream, da authority HTTP ou de um mapa. Envoy distingue essas fontes e separa validação SAN contra o SNI enviado de validação contra a authority downstream. Registrar apenas uma chave sni elimina exatamente a distinção que a configuração oferece.

No passthrough, NGINX ssl_preread consegue extrair SNI e escolher backend sem terminar TLS. Esse equipamento testemunha uma pista e uma rota, não a validação de certificado nem a conclusão do handshake final.

A correlação legítima liga IDs de conexão e decisões. Ela não copia o êxito de uma perna para a outra.

ECH adiciona duas vistas com funções distintas

Encrypted Client Hello coloca propriedades sensíveis no ClientHelloInner. O ClientHelloOuter normalmente leva o nome público do serviço de frente, necessário para encaminhamento e retry.

Se ECH for aceito, o processamento usa o inner autenticado. Se for rejeitado, a conexão autenticada para o nome público serve apenas para obter nova configuração. A RFC 9849 diz que ela não autentica o origin e não pode ser entregue à aplicação como sucesso.

O SNI externo pode, portanto, ser correto para chegar ao frontend e deliberadamente insuficiente para representar o origin. Observabilidade precisa guardar estado ECH, papel e fonte do nome, sem misturar ordinary, outer e accepted inner.

Também deve limitar a disseminação do nome interno. Um arquivo amplo de destinos em texto claro recriaria na camada de métricas a exposição que ECH reduz no caminho.

Testar o que não deve ganhar autoridade

O primeiro caso envia o SNI do tenant privilegiado sem credencial de cliente. O certificado pode ser selecionado e TLS pode concluir; o principal deve continuar anônimo e a operação administrativa deve ser negada.

Depois vêm SNI ausente, nome desconhecido, fallback, divergência com HTTP authority e certificado válido para ambos os nomes. No proxy, usar deliberadamente outro SNI upstream e exigir duas validações. No passthrough, proibir rótulos de handshake concluído. Em ECH, testar sucesso, rejeição/retry e ausência.

Callbacks de OpenSSL e GnuTLS demonstram capacidade. A reação do código em execução a esses casos demonstra a fronteira real.