OpenVPN sense CA: com peer-fingerprint verifica els parells

Un desplegament petit recorre a les empremtes perquè una autoritat de certificació sembla una infraestructura per a la qual ningú no té temps. L'instint és raonable, però el camí curt que la gent pren en lloc seu—copiar un secret del canal de dades als dos extrems—no ho és. Una configuració peer-fingerprint manté l'estructura TLS intacta: cada costat encara té la seva clau privada i el seu certificat, i cada costat encara verifica l'altre. El que canvia és on s'ancora la verificació: d'un emissor de confiança a una llista curta de resums fixats. Com que un resum cobreix el certificat sencer i no un nom, la renovació es converteix en l'operació que realment consumeix temps.

A què es compromet realment l'empremta

L'empremta d'un certificat és un resum del certificat sencer codificat en DER, no de la seva clau pública ni del nom del subjecte. Per tant, dos certificats amb noms idèntics i la mateixa clau però dates de validesa diferents tenen empremtes diferents. Això és el que fa precisa la fixació, i també el que fa disruptiva la renovació. Una fixació no pot significar confiar en una clau en general, perquè nomena un artefacte en un moment de la seva vida. Qualsevol pot conèixer el resum, i conèixer-lo no demostra res per si sol.

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

Tenir la clau privada corresponent és el que demostra que el parell té aquell certificat, i el resum és com l'altre costat decideix si esperava aquell certificat. Aquesta separació és la raó per la qual aquest disseny no és l'antic arranjament de secret compartit: una clau compartida autentica qualsevol que conegui els mateixos bytes, mentre que una fixació autentica un certificat. Un dispositiu diferent obté la seva pròpia entrada en lloc d'una còpia del mateix secret, cosa que és una diferència petita en fitxers i gran en abast del dany.

El mapa és recíproc, no simètric

Cada extrem necessita dues coses: la seva pròpia clau privada amb el certificat, i una declaració sobre quins certificats de parell acceptarà. Al client aquesta declaració és el resum del certificat del servidor; al servidor és la llista de resums de clients inscrits. Un exemple oficial per a configuracions petites per a Community 2.6 mostra l'arranjament amb peer-fingerprint, i val la pena llegir-lo abans de triar aquest model de confiança per a un desplegament real. Les dues direccions no són una llista invertida, i no fallen al mateix moment.

Afegir un dispositiu edita una llista permesa al servidor, sense copiar el material privat d'un client existent i sense moure la clau del servidor enlloc. Les dues direccions també fallen de manera independent, cosa útil durant el diagnòstic: el costat que tanca l'apretada de mans és el costat l'expectativa del qual no s'ha complert. Si el client rebutja el servidor, el resum no coincideix amb el certificat presentat. Si el servidor rebutja el client, el resum d'aquell client falta a la llista, o el client presenta un certificat diferent del que es va inscriure.

Inscripció: com s'uneix un dispositiu nou

Genereu la clau i el certificat del dispositiu nou on viurà la clau privada, i després moveu només l'artefacte públic a la part que l'ha de fixar. Transmeteu el resum esperat per un canal en què ja confieu, i compareu el certificat complet en lloc d'un nom que sembli familiar. Un resum copiat de la mateixa baixada no verificada que el certificat només demostra que els dos fitxers concorden entre ells. És una comprovació de consistència i no d'identitat, i és la manera més silenciosa com aquest disseny s'afebleix.

Al servidor, afegir el resum és un canvi de configuració que passa pel gestor habitual i va seguit d'una reconnexió. Confirmeu que el dispositiu nou es connecta i que un dispositiu amb el resum eliminat ja no ho fa. Una prova que només cobreix el cas positiu deixa la llista permesa sense verificar, que és exactament l'estat en què estareu d'aquí a sis mesos.

La renovació és el moment car

Cada certificat caduca, i un certificat nou té un resum nou encara que la clau i els noms continuïn igual. Sota un emissor, la renovació és transparent per als parells que confien en aquell emissor; sota la fixació, és un esdeveniment d'inscripció per a cada parell que fixa el certificat.

Planifiqueu l'ordre abans de la data de caducitat i no després. Distribuïu el resum nou a les parts que el verifiquen, apliqueu el canvi i només després substituïu el certificat a l'extrem. Aquest ordre no deixa cap finestra en què les dues parts no coincideixin sobre quin certificat és vigent. Manteniu també la llista sota revisió, perquè una llista fixada acumula entrades de dispositius retirats fa mesos. Cada entrada obsoleta és una identitat que encara s'autentica si la seva clau sobreviu, així que eliminar-ne una és una acció de seguretat i no una tasca de manteniment.

Què no decideix el mapa de confiança

L'autenticació és una capa, i el mapa fixat no diu res sobre el conjunt d'adreces, les rutes empenyudes, l'MTU del camí ni la política de tallafocs. Aquests continuen sent configuració separada amb maneres de fallada separades. Un túnel que s'autentica i no passa cap trànsit és una investigació diferent d'un que no s'aixeca mai.

El mapa tampoc no escala indefinidament, i una PKI basada en emissor és on acaben els desplegaments més grans. Aquesta preferència és sobre operacions i no sobre criptografia, perquè afegir i retirar identitats a través d'una sola autoritat és més barat que editar una llista a cada parell a mesura que creix la flota. On una implementació de client no admet l'opció, la resposta és un model de confiança compatible que aquell client documenti, o un reemplaçament admès. Silenciar l'avís de verificació no afegeix aquest suport, i tot el valor del disseny és que la verificació encara passa.