Troca de chaves TLS versus certificado de cliente: qual inicia sessão?

Transportar um valor público de troca de chaves num handshake não é o mesmo evento que um cliente a iniciar sessão. Um estabelece o estado criptográfico da conexão; o outro declara quem é o cliente, e isso só acontece quando o servidor o pede e a troca o permite. Tratar o primeiro como o segundo leva a conclusões erradas sobre o que uma VPN esconde e o que não esconde. Leia as mensagens e depois decida qual das quatro propriedades realmente observou.

Dois objetos que parecem iguais numa captura

Um cliente TLS 1.3 pode contribuir com material de troca de chaves no seu primeiro voo sem apresentar qualquer certificado. Essa contribuição é pública por desenho, porque o servidor precisa dela para derivar o segredo partilhado. O certificado de cliente é outra mensagem e só é enviado depois de o servidor pedir um. Leva uma identidade que o servidor depois verifica, e a autenticação mútua é uma decisão do servidor, não uma propriedade que o conjunto de cifras implique. A identidade da aplicação é uma terceira coisa completamente diferente: um formulário de início de sessão, um token bearer, um cookie. Nada disso aparece no handshake, e tudo isso sobrevive a uma mudança de caminho de rede.

As quatro linhas são independentes. Uma conexão pode ter a primeira e a segunda linha, saltar a terceira e ainda assim transportar a quarta num cabeçalho de cookie.

Decida o que um handshake capturado pode provar

Só pelo handshake, um observador fica a saber a versão negociada, o conjunto de cifras, o certificado do servidor e os valores públicos de troca de chaves. Isso basta para obter uma impressão digital de uma implementação de cliente e para ver que servidor foi contactado. O que não fornece é o estado privado necessário para decifrar a conexão, cuja confidencialidade assenta na troca efémera e não na parte pública. Também não fornece uma identidade de conta, que nunca esteve no handshake desde o início.

Portanto a conclusão honesta é estreita: nenhum certificado de cliente foi apresentado nesta troca. Não é que o cliente não tenha enviado nada ligável, e certamente não é que a sessão não transportasse nenhum identificador.

Leia as mensagens em vez do nome da cifra

Pergunte ao servidor o que solicita, em vez de inferir do conjunto de cifras. Um handshake TLS 1.3 que inclui um pedido de certificado é visível na transcrição, e a sua ausência é igualmente visível.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

Depois repita com um certificado de cliente configurado e compare. A segunda execução deve mostrar o certificado a ser enviado e aceito; a primeira não deve mostrar nenhum, e é essa a diferença concreta de que se trata.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

Se só precisa do caso comum de navegação, a saída detalhada do cliente basta para ver a versão do protocolo, o resultado da verificação e se foi oferecido um certificado de cliente. Um servidor que nunca envia um pedido de certificado não pode ter recebido um.

Onde a retoma muda a resposta

A retoma em TLS 1.3 usa tickets associados a estado secreto, pelo que uma conexão posterior pode concluir-se sem uma troca completa de certificados. Isso reduz o que um observador vê e altera o que a transcrição prova. Não cria uma identidade onde não havia. Uma sessão retomada continua a pertencer à mesma sessão de aplicação, e qualquer cookie ou token nessa sessão continua a ser o identificador que importa.

É por isso que uma revisão de privacidade que pára em "nenhum certificado de cliente" perde a parte interessante. A pergunta a fazer é qual parte detém um identificador estável, não que mensagem faltou num handshake.

Registe quatro propriedades, não um veredicto

Registe o acordo de chaves, a verificação do servidor, a autenticação do cliente e a identidade da aplicação como quatro linhas separadas, com a evidência de cada uma. Esse inventário sobrevive a mudanças de versão do protocolo, e torna um argumento sobre privacidade verificável por outra pessoa. Depois acrescente o que o caminho de rede contribui. Uma VPN muda o endereço de origem que um serviço observa; não remove um início de sessão, um cookie ou uma impressão digital do dispositivo que a aplicação já detém.

Registe em conjunto a versão negociada da conexão e o resultado do pedido de certificado, porque é esse par que um revisor precisa para reproduzir a sua conclusão sem uma captura própria.