Assinaturas digitais, certificados e TLS

A lição anterior deixou uma pergunta em aberto: a encriptação assimétrica permite-lhe enviar um segredo a alguém cuja chave pública tem — mas como sabe que essa chave pública pertence mesmo a essa pessoa, e não a um atacante pelo meio? As assinaturas digitais e os certificados respondem a isso, e juntos tornam possível o TLS, o protocolo por trás de cada endereço https://.

Assinaturas digitais: prova de origem, não de sigilo

Uma assinatura digital executa a encriptação assimétrica ao contrário. Em vez de encriptar uma mensagem com a chave pública de alguém para que só essa pessoa a consiga ler, quem envia assina uma mensagem com a sua própria chave privada, e qualquer pessoa a pode verificar usando a chave pública de quem enviou. Se a verificação tiver sucesso, duas coisas são verdade: a mensagem veio de quem detém essa chave privada, e não foi alterada depois — a mesma propriedade de resistência a colisões da discussão sobre hashing na lição anterior é o que torna a adulteração detetável. Uma assinatura prova autenticidade e integridade; não mantém, por si só, a mensagem em segredo.

Certificados: uma assinatura a garantir uma chave pública

Um certificado digital resolve o problema de "de quem é mesmo esta chave pública". Como explica o Centro de Aprendizagem da Cloudflare, um certificado SSL/TLS é "um ficheiro de dados alojado no servidor de origem de um site" que contém o nome de domínio, a chave pública, uma data de expiração e — de forma crucial — "a assinatura digital da autoridade certificadora." Uma autoridade certificadora (CA) é um terceiro de confiança que verifica se um site controla o domínio para o qual está a pedir um certificado, e depois assina esse certificado com a sua própria chave privada. O seu navegador já vem com uma lista incorporada de CAs em que confia, por isso, quando recebe um certificado assinado por uma delas, pode confiar na chave pública lá dentro sem alguma vez ter conhecido o operador do site. Um certificado autoassinado — um que um site assina ele próprio em vez de o obter de uma CA — não tem esse aval externo, e é por isso que os navegadores o tratam por defeito como não fiável.

TLS: pôr as duas coisas a trabalhar

A RFC 8446, a especificação do TLS 1.3, descreve um cumprimento (handshake) em fases: troca de chaves, na qual os dois lados estabelecem material secreto partilhado; depois autenticação, em que, nas palavras da RFC, "o lado do servidor do canal é sempre autenticado; o lado do cliente é opcionalmente autenticado" — normalmente só o site prova a sua identidade, não o visitante. O servidor prova quem é usando o seu certificado e uma assinatura que só ele conseguiria produzir com a sua chave privada. Assim que ambos os lados confiam na ligação, derivam chaves simétricas rápidas (o AES da lição anterior, tipicamente) para os dados propriamente ditos. A RFC 8446 afirma claramente o que isto lhe traz: confidencialidade e integridade para os dados trocados, e autenticação do servidor. Também afirma, de forma igualmente clara, um limite: "o TLS não esconde o comprimento dos dados que transmite", e metadados como a que servidor se ligou e quando permanecem visíveis para quem estiver posicionado para observar a ligação.

O que o ícone de cadeado significa e 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 registou. É por isso que a lição anterior sobre como os ataques se desenrolam trata uma página de início de sessão falsa, cadeado incluído, como uma ameaça real, e não como uma contradição.