OpenVPN sen CA: como peer-fingerprint verifica os pares

Un despregamento pequeno recorre ás pegadas porque unha autoridade de certificación parece unha infraestrutura para a que ninguén ten tempo. O instinto é razoable, pero o atallo que a xente toma no seu lugar—copiar un segredo do canal de datos a ambos extremos—non o é. Unha configuración peer-fingerprint mantén intacta a estrutura TLS: cada lado aínda ten a súa propia clave privada e o seu certificado, e cada lado aínda verifica o outro. O que cambia é onde se ancora a verificación: dun emisor de confianza a unha lista curta de resumos fixados. Como un resumo cobre o certificado completo e non un nome, a renovación convértese na operación que realmente consume tempo.

A que se compromete realmente a pegada

A pegada dun certificado é un resumo do certificado completo codificado en DER, non da súa clave pública nin do nome do seu suxeito. Por iso dous certificados con nomes idénticos e a mesma clave pero datas de validez distintas teñen pegadas distintas. Eso é o que fai precisa a fixación, e tamén o que fai disruptiva a renovación. Unha fixación non pode significar confiar nunha clave en xeral, porque nomea un artefacto nun momento da súa vida. Calquera pode coñecer o resumo, e coñecelo non demostra nada por si mesmo.

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

Posuír a clave privada correspondente é o que demostra que o par ten ese certificado, e o resumo é como o outro lado decide se esperaba ese certificado. Esa separación é a razón pola que este deseño non é o antigo arranxo de segredo compartido: unha clave compartida autentica a calquera que coñeza os mesmos bytes, mentres que unha fixación autentica un certificado. Un dispositivo distinto obtén a súa propia entrada en lugar dunha copia do mesmo segredo, o que é unha diferenza pequena en ficheiros e grande no alcance do dano.

O mapa é recíproco, non simétrico

Cada extremo necesita dúas cousas: a súa propia clave privada co certificado, e unha declaración sobre que certificados de pares aceptará. No cliente esa declaración é o resumo do certificado do servidor; no servidor é a lista de resumos de clientes inscritos. Un exemplo oficial para configuracións pequenas de Community 2.6 mostra o arranxo con peer-fingerprint, e paga a pena lelo antes de escoller este modelo de confianza para un despregamento real. As dúas direccións non son unha lista invertida, e non fallan no mesmo momento.

Engadir un dispositivo edita unha lista de permitidos no servidor, sen copiar o material privado dun cliente existente e sen mover a clave do servidor a ningures. As dúas direccións tamén fallan de forma independente, o que resulta útil durante o diagnóstico: o lado que pecha o handshake é o lado cuxa expectativa non se cumpriu. Se o cliente rexeita o servidor, o resumo non coincide co certificado presentado. Se o servidor rexeita o cliente, falta o resumo dese cliente na lista, ou o cliente presenta un certificado distinto do que se inscribiu.

Inscrición: como se une un dispositivo novo

Xere a clave e o certificado do dispositivo novo onde vivirá a clave privada, e logo move só o artefacto público á parte que debe fixalo. Transfira o resumo esperado por unha canle na que xa confíe, e compare o certificado completo en lugar dun nome que pareza familiar. Un resumo copiado da mesma descarga non verificada que o certificado só demostra que os dous ficheiros concordan entre si. É unha comprobación de consistencia e non de identidade, e é a forma máis silenciosa en que este deseño se debilita.

No servidor, engadir o resumo é un cambio de configuración que pasa polo xestor habitual e vai seguido dunha reconexión. Confirme que o dispositivo novo se conecta e que un dispositivo cuxo resumo se eliminou xa non o fai. Unha proba que só cobre o caso positivo deixa a lista de permitidos sen verificar, que é exactamente o estado no que estará dentro de seis meses.

A renovación é o momento caro

Cada certificado caduca, e un certificado novo ten un resumo novo incluso cando a clave e os nomes seguen igual. Baixo un emisor, a renovación é transparente para os pares que confían nese emisor; baixo a fixación, é un evento de inscrición para cada par que fixa o certificado.

Planifique a orde antes da data de caducidade e non despois. Distribúa o resumo novo ás partes que o verifican, aplique o cambio e só entón substitúa o certificado no extremo. Esa orde non deixa ningunha xanela na que os dous lados discrepen sobre que certificado é o actual. Manteña tamén a propia lista en revisión, porque unha lista fixada acumula entradas de dispositivos retirados hai meses. Cada entrada obsoleta é unha identidade que aínda se autentica se a súa clave sobrevive, así que eliminar unha é unha acción de seguridade e non unha tarefa de mantemento.

Que non decide o mapa de confianza

A autenticación é unha capa, e o mapa fixado non di nada sobre o conxunto de enderezos, as rutas empurradas, a MTU da ruta nin a política do firewall. Seguen sendo configuración separada con modos de fallo separados. Un túnel que se autentica e non pasa tráfico é unha investigación distinta dun que nunca se levanta.

O mapa tampouco escala indefinidamente, e unha PKI baseada en emisor é onde acaban os despregamentos máis grandes. Esa preferencia ten que ver coas operacións e non coa criptografía, porque engadir e retirar identidades a través dunha soa autoridade é máis barato que editar unha lista en cada par a medida que a frota medra. Onde unha implementación de cliente non admite a opción, a resposta é un modelo de confianza compatible que ese cliente documente, ou un substituto admitido. Silenciar o aviso de verificación non engade ese soporte, e todo o valor do deseño é que a verificación segue a ocorrer.