Como o TLS estabelece uma conexão web segura e o que o navegador verifica

Quando você abre uma página HTTPS, o navegador e o servidor precisam concordar sobre como proteger a comunicação antes de trocar os dados da aplicação. Essa negociação inicial é conhecida como handshake TLS. Não é uma senha digitada pelo usuário: é uma troca automática de mensagens e parâmetros criptográficos.

O TLS protege os dados em trânsito por meio de confidencialidade e integridade, e permite autenticar o servidor. O resultado prático é um canal no qual um observador da rede não deveria ser capaz de ler ou modificar silenciosamente o tráfego. O TLS não cifra por si só as informações armazenadas nos dispositivos ou servidores, nem decide se o conteúdo do site é honesto.

SSL é o nome do protocolo predecessor, já obsoleto; nas conexões web atuais, o protocolo pertinente é o TLS. Por costume, ainda se fala de "certificados SSL", mas o certificado é uma credencial digital e o TLS é o protocolo que estabelece e protege a conexão. Certificado e protocolo são peças distintas: ter um instalado não basta para demonstrar que a configuração TLS está bem feita.

No início, o cliente envia uma mensagem ClientHello com informações sobre as opções que suporta, como versões do TLS, algoritmos e dados para a troca de chaves. O servidor responde selecionando parâmetros compatíveis. Nenhuma combinação arbitrária é escolhida: ambas as extremidades devem concordar nas opções permitidas por suas implementações e configurações.

No TLS 1.3, o cliente pode incluir desde a primeira mensagem uma parte pública da troca efêmera de chaves. O servidor seleciona os parâmetros, apresenta seu certificado e envia sua parte correspondente; ambas as extremidades derivam independentemente segredos compartilhados e chaves de tráfego. Com ECDHE —Diffie-Hellman efêmero sobre curvas elípticas— a chave secreta de sessão não é transmitida como um dado que um terceiro possa copiar: são trocados valores públicos que permitem calcular o segredo em ambos os lados.

A criptografia simétrica protege o tráfego posterior porque é mais adequada para processar grandes quantidades de dados do que as operações de chave pública. O TLS deriva chaves de tráfego para proteger os registros da conexão; não é aconselhável descrever o processo como se o navegador simplesmente criasse uma chave de sessão e a entregasse ao servidor. O design exato depende da versão negociada e dos parâmetros acordados.

O TLS 1.3 reduziu o estabelecimento ordinário a uma viagem de ida e volta de rede (1-RTT), enquanto o TLS 1.2 geralmente precisa de duas antes de começar a troca normal de dados protegidos. A retomada de sessão com 0-RTT é uma opção distinta: pode permitir enviar dados antes de completar uma nova viagem de ida e volta, mas tem riscos de repetição e não é indiscriminadamente apropriada para operações que não toleram duplicados. Menos latência não significa que todas as requisições sejam seguras para 0-RTT.

O certificado do servidor vincula uma identidade —normalmente um nome de domínio— a uma chave pública e contém uma assinatura verificável dentro de uma cadeia de confiança. O cliente verifica que a cadeia leva a uma autoridade raiz que reconhece, que o certificado está dentro de seu período de validade e que o nome solicitado coincide com os nomes cobertos pelo certificado, habitualmente no campo SAN (Subject Alternative Name).

A validação não consiste apenas em olhar se há um cadeado. O navegador realiza verificações automáticas e pode rejeitar a conexão se o certificado estiver vencido, o nome não coincidir ou a cadeia não puder ser validada. A verificação de revogação também depende de mecanismos e políticas do cliente; não se deve supor que uma inspeção visual do ícone exponha todos os detalhes desse processo.

Um certificado válido autentica o controle de um domínio de acordo com as regras de emissão aplicáveis; não certifica que o negócio seja legítimo, que o site não seja fraudulento ou que o conteúdo seja confiável. Um site enganoso também pode servir HTTPS para seu próprio domínio. O cadeado indica uma conexão protegida com esse servidor, não uma aprovação de suas práticas ou afirmações.

A autenticação TLS web habitual verifica principalmente o servidor. A autenticação mútua, ou mTLS, é uma configuração adicional na qual o cliente também apresenta um certificado para se autenticar. Não deve ser confundida com o funcionamento normal do HTTPS, no qual o usuário não entrega necessariamente um certificado pessoal.

Durante uma conexão TLS, a criptografia dificulta que terceiros na rota leiam o conteúdo protegido e a integridade permite detectar modificações dos dados em trânsito. A autenticação do servidor ajuda a reduzir o risco de que o cliente estabeleça a conexão com um impostor que não controla a identidade certificada. Essas proteções se aplicam ao trajeto da conexão, não a todos os pontos pelos quais passam os dados.

O TLS não oculta necessariamente todas as informações de contexto. Por exemplo, o endereço IP do servidor e outros metadados de rede podem continuar visíveis; além disso, o nome do servidor pode ser exposto durante o estabelecimento em configurações que não empregam mecanismos de proteção do nome. Também não impede que o próprio site, uma extensão maliciosa ou um equipamento comprometido acessem os dados uma vez que são decifrados na extremidade.

Uma conexão HTTPS também não garante criptografia de ponta a ponta entre duas pessoas. O servidor termina a conexão TLS e pode ler os dados que recebe para prestar o serviço. Transporte cifrado não equivale a conteúdo inacessível para o provedor: para esse último objetivo, faz falta um design de criptografia de ponta a ponta no qual o serviço não controle as chaves de decifragem.

openssl s_client permite abrir uma conexão TLS a um servidor e observar informações da negociação, como o protocolo selecionado, o conjunto de cifras e os certificados que apresenta. Para um domínio de teste, uma verificação básica é:

openssl s_client -connect example.com:443 -servername example.com -showcerts

A opção -servername envia o nome via SNI, necessário quando vários sites compartilham o mesmo endereço IP. Sem SNI, o servidor poderia responder com um certificado padrão que não corresponde ao domínio que se queria revisar. Substitua example.com pelo nome que você administra ou tem permissão para verificar.

A saída não é um veredito completo de segurança. Examine o protocolo e a cifra negociados, a cadeia que o servidor apresenta e o código de verificação. A verificação pode depender do armazenamento de autoridades de confiança da instalação local do OpenSSL; um resultado correto em uma máquina não prova como todos os navegadores ou dispositivos se comportarão.

Para solicitar uma conexão específica com TLS 1.3, se a versão local do OpenSSL o admite, adicione -tls1_3; para TLS 1.2, use -tls1_2. Essas opções servem para verificar compatibilidade com uma versão, mas uma conexão falha pode dever-se à política do servidor, à rede ou à implementação local. Não mude a configuração de produção com base em um único teste.

No navegador, o painel de informações do site permite revisar a conexão e os dados do certificado, embora o caminho exato dependa do navegador e sua versão. Para uma revisão prática, verifique pelo menos o nome coberto, o emissor, a vigência e se a página foi carregada via HTTPS. As ferramentas de desenvolvimento podem mostrar também informações de segurança e de requisições, mas não substituem uma revisão de configuração do servidor.

Falhas de handshake são sintomas, não diagnósticos: podem aparecer quando cliente e servidor não compartilham uma versão ou um conjunto de cifras, quando o certificado não é válido para o nome solicitado, quando falta um certificado intermediário ou quando há problemas de SNI. Um relógio incorreto também pode fazer com que um certificado pareça ainda não vigente ou já vencido. Identificar a causa evita "correções" que removem proteções.

Em um serviço web, o administrador deveria manter protocolos e algoritmos compatíveis com os clientes que realmente precisa, e remover opções obsoletas de acordo com sua política de segurança. O TLS 1.3 reduz as opções criptográficas herdadas; o TLS 1.2 ainda pode ser necessário para compatibilidade, mas sua segurança depende da seleção concreta de parâmetros. Não basta ativar uma versão sem revisar o conjunto completo de configuração.

Uma lista útil para uma primeira revisão é:

• Confirmar que o domínio solicitado aparece no certificado e que este está vigente.
• Revisar se se envia a cadeia de certificados necessária e se o servidor usa o certificado correto via SNI.
• Verificar qual versão TLS e conjunto de cifras se negociam com clientes representativos.
• Investigar os registros do servidor e a saída do OpenSSL antes de modificar políticas.
• Evitar desativar a validação do certificado ou reativar protocolos obsoletos como solução rápida.

Não desative a validação para fazer desaparecer um aviso. Se o problema é uma cadeia incompleta, um nome incorreto ou um certificado vencido, ignorar a verificação converte um erro visível em uma conexão menos confiável. A decisão prática é corrigir a causa no servidor ou no cliente, não aceitar às cegas uma identidade que não pôde ser verificada.