Certificado VPN autoassinado: o que significa e em que confia

Aqui fazem mais dano duas crenças: que um certificado VPN autoassinado significa que o túnel não está cifrado, e que instalar o que o cliente VPN pediu afeta apenas a VPN. Nenhuma sobrevive ao contacto com uma implementação real. Um certificado autoassinado descreve uma relação de assinatura, não um veredicto de segurança, e o alcance da confiança que acrescenta depende do armazém onde aterrissa. Vi um serviço de assistência importar uma raiz de fornecedor numa máquina Windows para silenciar um aviso e depois passar uma tarde a explicar por que o navegador deixara de se queixar de um portal sem relação. As duas metades desta pergunta andam juntas, por isso trate-as como uma só.

Um certificado não é um armazém de confiança

O ficheiro que o servidor apresenta transporta uma chave pública, um nome de sujeito, um nome de emitente, datas de validade e extensões. Autoassinado significa que o sujeito e o emitente são a mesma entidade e a assinatura é verificada com a própria chave do certificado. Nada nessa definição diz que a ligação é fraca, nem nada diz que o cliente a aceitará.

A aceitação vem de outro lugar: um ficheiro CA para o qual aponta o cliente, uma impressão digital que compara à mão ou uma raiz que já está num armazém que o cliente lê. Uma implementação pode ser perfeitamente sólida enquanto o seu certificado falharia todos os testes públicos. openssl verify contra o pacote do sistema reportará um emitente desconhecido, e esse relatório está correto, não é uma falha.

A opção ca do OpenVPN é o caso mais claro de confiança limitada à aplicação. Esse ficheiro nomeia as âncoras que o cliente aceitará, e pode conter uma CA privada ou, numa implementação pequena, o próprio certificado autoassinado do servidor. A versão 2.6 também aceita --peer-fingerprint para fixar uma impressão digital SHA-256 em vez de distribuir um ficheiro CA. O WireGuard fica ainda mais longe: não tem certificados nenhuns, apenas uma chave pública estática por par, pelo que a questão do autoassinado não se lhe aplica.

Onde instala a confiança decide quem a herda

Coloque o mesmo certificado em três locais e obtém três raios de explosão diferentes. Um pacote lido apenas pelo cliente VPN afeta esse cliente. Uma raiz no armazém do sistema operativo afeta todos os programas que consultam esse armazém. Um navegador com a sua própria base de dados de confiança pode ignorar ambos, e é por isso que um aviso pode sobreviver a uma importação que parecia funcionar.

No Debian ou Ubuntu, deixar um ficheiro em /usr/local/share/ca-certificates/ e executar update-ca-certificates altera o pacote de todo o sistema. No Windows, certutil -addstore -f Root escreve no armazém da máquina e exige uma linha de comandos elevada, enquanto acrescentar -user aponta para o armazém do utilizador atual; os dois não são intercambiáveis. O Firefox mantém a sua própria base de dados NSS, pelo que uma importação ao nível do sistema operativo pode nunca aparecer lá.

O alcance importa por causa do que uma autoridade pode fazer. Uma CA emitente pode assinar nomes com os quais não tem qualquer relação, pelo que tudo o que confia nesse armazém aceitará essas assinaturas. Uma única folha fixada não pode fazê-lo; autentica exatamente uma identidade de par. Se o objetivo é fazer uma VPN ligar, uma CA limitada à aplicação ou uma folha fixada conseguem-no, enquanto uma raiz para toda a máquina é uma concessão muito maior do que o sintoma exige.

Continua a cifrar sem uma CA pública

O aperto de mão TLS deriva chaves de sessão independentemente de o certificado do par encadear em algo em que já confia. Autoassinado não significa texto simples, nem significa que o tráfego seja legível em voo. Significa que o cliente não tem qualquer razão a priori para acreditar que a chave pertence ao servidor que pediu.

É nessa lacuna que vivem os ataques reais. Um cliente configurado para aceitar qualquer certificado, seja através de uma definição de verificação desativada, seja através de um botão de confiar-mesmo-assim clicado uma vez e esquecido, cifrará alegremente para quem responder. A interceção ocorre no passo de autenticação, antes de os dados da aplicação se moverem. A cifra sem verificação de identidade mantém um observador passivo de fora e faz pouco mais.

Confiar no emitente não salta a verificação do nome

A validação da cadeia, a correspondência do nome e a finalidade do certificado são decisões separadas. Uma cadeia pode ser válida enquanto o nome está errado, e um nome pode corresponder enquanto o certificado foi emitido para outra função. O RFC 5280 define os campos que transportam essas restrições, e até que ponto um cliente as aplica é matéria de cada aplicação.

O OpenVPN torna a separação visível. verify-x509-name fixa o sujeito esperado através da correspondência de name, name-prefix ou subject. remote-cert-tls server exige que o certificado do par seja utilizável como certificado de servidor, o que rejeita um certificado só de cliente mesmo quando o emitente é de confiança. Nenhuma das definições é substituída pelo envio de um ficheiro CA.

Inspecione o certificado antes de decidir qualquer coisa:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName mostra quem o emitiu, para que nomes e até quando.
• openssl verify -CAfile ca.crt server.crt verifica se a cadeia que pretende enviar valida realmente a folha.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error funciona para pontos finais TLS como um portal web; o protocolo OpenVPN na porta 1194 não é um fluxo TLS simples, pelo que esse teste não se aplica ali.

Um certificado com data expirada, sem subjectAltName para o nome a que se liga ou sem utilização serverAuth falha independentemente do cuidado com que a âncora foi instalada.

Cinco verificações antes de aceitar um

Compare a impressão digital por um canal que não seja a ligação que tenta reparar: uma consola, um instalador que já tem, um ficheiro de configuração assinado. openssl x509 -in server.crt -noout -fingerprint -sha256 no servidor e o mesmo valor no registo do cliente bastam para saber que está a olhar para um único objeto.

Depois, decida o que está a instalar: uma folha ou uma autoridade que pode cunhar mais. Em seguida decida para onde vai e nomeie as aplicações que leem esse armazém. Anote o caminho de remoção enquanto ainda se lembra dele, porque confiar-e-seguir é como uma importação temporária se torna permanente.

Por fim, planeie a mudança. Um certificado ou impressão digital fixados têm de ser atualizados pelo mesmo canal de confiança quando o certificado roda, e uma CA privada tem o seu próprio ciclo de vida de emissão e revogação. Se a chave privada vazar, voltar a confiar numa cópia do mesmo certificado não repara nada; a identidade tem de ser substituída.

Se um aviso sobreviver às cinco verificações, a pergunta útil não é que botão o silencia, mas que armazém o cliente lê realmente e de onde veio essa raiz. Responda a isso, e a importação que está prestes a fazer torna-se uma decisão em vez de um reflexo.