OpenVPN sem CA: como o peer-fingerprint verifica os pares

Uma implantação pequena recorre às impressões digitais porque uma autoridade de certificação parece uma infraestrutura para a qual ninguém tem tempo. O instinto é razoável, mas o atalho que as pessoas tomam em vez disso—copiar um segredo do canal de dados para as duas pontas—não é. Uma configuração peer-fingerprint mantém a estrutura TLS intacta: cada lado ainda tem sua própria chave privada e seu certificado, e cada lado ainda verifica o outro. O que muda é onde a verificação está ancorada: de um emissor confiável para uma lista curta de resumos fixados. Como um resumo cobre o certificado inteiro e não um nome, a renovação vira a operação que realmente consome tempo.

Aquilo a que a impressão realmente se compromete

A impressão digital de um certificado é um resumo do certificado inteiro codificado em DER, não da sua chave pública e não do nome do seu sujeito. Por isso dois certificados com nomes idênticos e a mesma chave mas datas de validade diferentes têm impressões diferentes. Isso é o que torna a fixação precisa, e também o que torna a renovação disruptiva. Uma fixação não pode significar confiar numa chave em geral, porque nomeia um artefato num momento da sua vida. Qualquer um pode conhecer o resumo, e conhecê-lo não prova nada por si só.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

Possuir a chave privada correspondente é o que prova que o par tem esse certificado, e o resumo é como o outro lado decide se esperava esse certificado. Essa separação é a razão pela qual este desenho não é o antigo arranjo de segredo compartilhado: uma chave compartilhada autentica qualquer um que conheça os mesmos bytes, enquanto uma fixação autentica um certificado. Um dispositivo diferente ganha a sua própria entrada em vez de uma cópia do mesmo segredo, o que é uma diferença pequena em arquivos e grande no alcance do dano.

O mapa é recíproco, não simétrico

Cada extremidade precisa de duas coisas: a sua própria chave privada com o certificado, e uma declaração sobre quais certificados de pares aceitará. No cliente essa declaração é o resumo do certificado do servidor; no servidor é a lista de resumos de clientes inscritos. Um exemplo oficial para configurações pequenas de Community 2.6 mostra o arranjo com peer-fingerprint, e vale a pena lê-lo antes de escolher este modelo de confiança para uma implantação real. As duas direções não são uma lista invertida, e não falham no mesmo momento.

Adicionar um dispositivo edita uma lista de permitidos no servidor, sem copiar o material privado de um cliente existente e sem mover a chave do servidor para lugar nenhum. As duas direções também falham de forma independente, o que é útil durante o diagnóstico: o lado que fecha o handshake é o lado cuja expectativa não foi atendida. Se o cliente rejeita o servidor, o resumo não corresponde ao certificado apresentado. Se o servidor rejeita o cliente, falta o resumo desse cliente na lista, ou o cliente apresenta um certificado diferente do que foi inscrito.

Inscrição: como um novo dispositivo entra

Gere a chave e o certificado do novo dispositivo onde a chave privada viverá, e depois mova apenas o artefato público para a parte que precisa fixá-lo. Transfira o resumo esperado por um canal em que você já confia, e compare o certificado completo em vez de um nome que pareça familiar. Um resumo copiado do mesmo download não verificado do certificado prova apenas que os dois arquivos concordam entre si. É uma verificação de consistência e não de identidade, e é a forma mais silenciosa de este desenho enfraquecer.

No servidor, adicionar o resumo é uma mudança de configuração que passa pelo gestor habitual e é seguida de uma reconexão. Confirme que o dispositivo novo se conecta e que um dispositivo cujo resumo foi removido já não o faz. Um teste que cobre apenas o caso positivo deixa a lista de permitidos sem verificação, e é exatamente o estado em que você estará daqui a seis meses.

A renovação é o momento caro

Todo certificado expira, e um certificado novo tem um resumo novo mesmo quando a chave e os nomes continuam iguais. Sob um emissor, a renovação é transparente para os pares que confiam nesse emissor; sob a fixação, é um evento de inscrição para cada par que fixa o certificado.

Planeie a ordem antes da data de expiração e não depois. Distribua o resumo novo às partes que o verificam, aplique a mudança e só então substitua o certificado na extremidade. Essa ordem não deixa nenhuma janela em que os dois lados discordem sobre qual certificado é o atual. Mantenha também a própria lista em revisão, porque uma lista fixada acumula entradas de dispositivos retirados há meses. Cada entrada obsoleta é uma identidade que ainda se autentica se a sua chave sobreviver, então remover uma é uma ação de segurança e não uma tarefa de manutenção.

O que o mapa de confiança não decide

A autenticação é uma camada, e o mapa fixado não diz nada sobre o conjunto de endereços, as rotas empurradas, a MTU do caminho ou a política do firewall. Eles continuam a ser configuração separada com modos de falha separados. Um túnel que se autentica e não passa tráfego é uma investigação diferente de um que nunca sobe.

O mapa também não escala indefinidamente, e uma PKI baseada num emissor é onde acabam as implantações maiores. Essa preferência é sobre operações e não sobre criptografia, porque adicionar e retirar identidades através de uma só autoridade é mais barato do que editar uma lista em cada par à medida que a frota cresce. Onde uma implementação de cliente não suporta a opção, a resposta é um modelo de confiança compatível que esse cliente documente, ou um substituto suportado. Silenciar o aviso de verificação não acrescenta esse suporte, e todo o valor do desenho é que a verificação continua a acontecer.