Assinaturas digitais, certificados e TLS

A aula anterior deixou uma pergunta em aberto: a criptografia assimétrica permite que você envie um segredo para alguém cuja chave pública você tem — mas como saber que essa chave pública realmente pertence a essa pessoa, e não a um atacante no meio do caminho? As assinaturas digitais e os certificados respondem a isso, e juntos tornam possível o TLS, o protocolo por trás de todo endereço https://.

Assinaturas digitais: prova de origem, não sigilo

Uma assinatura digital executa a criptografia assimétrica ao contrário. Em vez de criptografar uma mensagem com a chave pública de alguém para que só essa pessoa consiga lê-la, o remetente assina uma mensagem com sua própria chave privada, e qualquer pessoa pode verificá-la usando a chave pública do remetente. Se a verificação for bem-sucedida, duas coisas são verdadeiras: a mensagem veio de quem detém aquela chave privada, e ela não foi alterada depois — a mesma propriedade de resistência a colisões discutida na aula anterior sobre hashing é o que torna a adulteração detectável. Uma assinatura prova autenticidade e integridade; ela não mantém, por si só, a mensagem em sigilo.

Certificados: uma assinatura que atesta uma chave pública

Um certificado digital resolve o problema de “de quem é realmente essa chave pública”. Como explica o Learning Center da Cloudflare, um certificado SSL/TLS é “um arquivo de dados hospedado no servidor de origem de um site” contendo o nome de domínio, a chave pública, uma data de expiração e — crucialmente — “a assinatura digital da autoridade certificadora”. Uma autoridade certificadora (CA, na sigla em inglês) é um terceiro confiável que verifica se um site controla o domínio para o qual está solicitando um certificado, e então assina esse certificado com sua própria chave privada. Seu navegador já vem com uma lista integrada de CAs em que confia, então, quando recebe um certificado assinado por uma delas, ele consegue confiar na chave pública contida ali sem nunca ter tido contato com o operador do site. Um certificado autoassinado — um que o próprio site assina em vez de obter de uma CA — não tem esse aval externo, e é por isso que os navegadores tratam esse tipo de certificado como não confiável por padrão.

TLS: colocando as duas coisas para funcionar

A RFC 8446, a especificação do TLS 1.3, descreve um aperto de mão (handshake) em fases: troca de chaves, na qual os dois lados estabelecem material secreto compartilhado; depois autenticação, em que, nas palavras da RFC, “o lado do servidor do canal é sempre autenticado; o lado do cliente é autenticado opcionalmente” — normalmente só o site prova sua identidade, não o visitante. O servidor prova quem é usando seu certificado e uma assinatura que só ele conseguiria produzir com sua chave privada. Quando os dois lados confiam na conexão, eles derivam chaves simétricas rápidas (o AES da aula anterior, tipicamente) para os dados de fato. A RFC 8446 afirma claramente o que isso garante: confidencialidade e integridade para os dados trocados, e autenticação do servidor. Ela também afirma, com a mesma clareza, um limite: “o TLS não oculta o tamanho dos dados que transmite”, e metadados como a qual servidor você se conectou e quando permanecem visíveis para qualquer um posicionado para observar a conexão.

O que o ícone de cadeado significa e o que não significa

Um site de phishing construído sobre um domínio parecido pode ter um certificado perfeitamente válido: o TLS autentica o domínio, não a intenção de quem o registrou. É por isso que a aula anterior sobre como os ataques se desenrolam trata uma página de login falsa, cadeado e tudo, como uma ameaça ativa, não como uma contradição.