Pode partilhar uma chave pública VPN? Verifique três coisas

Pode entregar a sua chave pública VPN a um par, a um fornecedor ou a um fórum, e o túnel continua a funcionar. A chave privada já não pode entregar, nem ao pessoal de apoio, sem entregar a identidade que essa chave comprova. A decisão raramente fica assim tão limpa, porque as pessoas confundem qual metade do par estão a ver, e porque algumas implementações tratam o valor público como um nome. Três verificações resolvem-na: qual metade tem, a que a implementação a liga, e quanto custa a substituição.

Verificação um: qual metade do par está na sua área de transferência

As chaves assimétricas vêm em pares, e o sentido da derivação é todo o ponto. No WireGuard a chave privada tem 32 bytes aleatórios e a chave pública é calculada a partir dela; no sentido inverso não é possível. wg genkey escreve o valor privado, wg pubkey deriva o público, e só o segundo pertence a uma mensagem para um par.

wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt

O mundo dos certificados usa a mesma divisão com mais peças móveis. Um certificado de servidor transporta uma chave pública e nomes, e é assinado por uma chave privada da CA que nunca sai da CA. Um cliente que verifica esse servidor precisa do certificado da CA, que é público, e não tem qualquer uso para a chave de assinatura privada da CA.

Se não tiver a certeza de qual valor tem, procure o marcador em vez do nome do ficheiro. Um bloco PEM que começa com -----BEGIN PRIVATE KEY-----, ou a forma mais antiga BEGIN RSA PRIVATE KEY, é a metade secreta. Um valor que pode colar sem esse marcador é candidato a partilha, sujeito às duas verificações seguintes.

Verificação dois: a que a implementação liga esse valor público

Segurança criptográfica e anonimato são propriedades diferentes. A chave pública de um par WireGuard é um identificador estável dentro da implementação: a configuração do servidor lista-a, o handshake nomeia-a, e um administrador que lê registos vê a mesma cadeia sempre que esse par se liga. Se publicar a chave ao lado de uma pergunta sobre a sua configuração, ligou essa cadeia a tudo o resto na publicação.

Os certificados revelam identidade por desenho. Subject e subject alternative name são legíveis, e para certificados TLS publicamente fidedignos o próprio certificado é publicado em registos Certificate Transparency, que são pesquisáveis. Nada disso expõe uma chave privada, e tudo isso expõe uma relação.

É aqui que as implementações divergem, e isso decide a resposta. Um par de teste descartável num servidor de laboratório é um objeto diferente da chave que identifica o endpoint site-to-site de uma empresa, embora os bytes pareçam idênticos.

Verificação três: o que pode revogar, e com que rapidez

A terceira verificação separa as duas metades por completo. Uma chave pública publicada pode ser substituída ao seu ritmo. Uma chave privada publicada não pode ser recuperada: apagar a sua cópia não toca nas cópias já tiradas, e cada par que confiava nela confia agora em algo que um estranho tem.

A revogação é uma ação de configuração, não criptográfica. O WireGuard não fornece qualquer lista de revogação, por isso remove o par:

wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart

OpenVPN implementações baseadas em certificados revogam o certificado e publicam uma CRL que o servidor verifica realmente através de crl-verify. Sem essa diretiva a lista de revogação é decoração. De qualquer forma a sequência é a mesma: emitir uma substituição, distribuí-la pelo canal suportado e depois retirar a identidade antiga.

Os erros que vêm de juntar as três verificações

A maioria das fugas reais não é uma pessoa a decidir publicar uma chave privada. É um perfil inteiro colado num fórum: um .conf WireGuard com uma linha PrivateKey, um pacote .ovpn com um bloco de chave inline, ou uma captura de ecrã de uma janela de cliente que inclui por acaso o campo da chave. O valor público provavelmente estava bem; viajou com a parte que não estava.

Os fluxos de apoio são a segunda fonte. Nenhum passo de verificação legítimo precisa da sua chave privada, porque o outro lado deriva o que precisa da metade pública. Quando um formulário ou uma pessoa pede o valor privado, a resposta correta é o valor público mais o comando local que o produz.

Registos e capturas de ecrã pertencem à mesma categoria. A saída de diagnóstico pode transportar material de chave, identificadores de sessão e endereços internos, e publicar tudo isso para obter resposta a uma pergunta troca uma pequena conveniência por uma exposição maior.

Depois de uma fuga de valor privado, retire a identidade

Se um valor privado saiu mesmo, trate essa identidade como retirada. Gere um novo par, instale a metade pública onde os pares a esperam, remova o par antigo ou revogue o certificado antigo, e verifique os locais onde a publicou. Não pode apagar cópias que não controla, por isso a remoção é sobre o futuro, não sobre o passado.

Depois escreva a distribuição: que chave pertence a que dispositivo, quem guarda uma cópia, como é entregue uma substituição, e quem remove um par retirado. São as partes de que as pessoas se esquecem, e decidem durante quanto tempo uma fuga continua útil.