OpenVPN zonder CA: hoe peer-fingerprint peers verifieert

Een kleine uitrol grijpt naar vingerafdrukken omdat een certificaatautoriteit aanvoelt als infrastructuur waar niemand tijd voor heeft. Het instinct is redelijk, maar de sluiproute die mensen in plaats daarvan nemen—één geheim van het datakanaal naar beide uiteinden kopiëren—is dat niet. Een peer-fingerprint-opstelling houdt de TLS-structuur intact: elke kant heeft nog steeds zijn eigen persoonlijke sleutel en certificaat, en elke kant verifieert nog steeds de andere. Wat verandert, is waar de verificatie verankerd is: van een vertrouwde uitgever naar een korte lijst vastgepinde digests. Omdat een digest het hele certificaat dekt en niet een naam, wordt vernieuwing de handeling die echt tijd kost.

Waar de vingerafdruk zich werkelijk aan verbindt

Een certificaatvingerafdruk is een digest van het volledige DER-gecodeerde certificaat, niet van de publieke sleutel en niet van de subjectnaam. Daarom hebben twee certificaten met identieke namen en dezelfde sleutel maar verschillende geldigheidsdatums verschillende vingerafdrukken. Dat maakt vastpinnen precies, en dat maakt vernieuwing ook verstorend. Een pin kan niet betekenen dat je een sleutel in het algemeen vertrouwt, omdat hij één artefact benoemt op één moment in zijn leven. Iedereen mag de digest kennen, en hem kennen bewijst op zichzelf niets.

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

Het bezit van de bijbehorende persoonlijke sleutel is wat bewijst dat de peer dat certificaat heeft, en de digest is hoe de andere kant beslist of zij dat certificaat überhaupt verwachtte. Die scheiding is de reden dat dit ontwerp niet de oude regeling met een gedeeld geheim is: een gedeelde sleutel authenticeert iedereen die dezelfde bytes kent, terwijl een pin één certificaat authenticeert. Een ander apparaat krijgt zijn eigen vermelding in plaats van een kopie van hetzelfde geheim, wat een klein verschil in bestanden en een groot in schadebereik is.

De kaart is wederkerig, niet symmetrisch

Elk eindpunt heeft twee dingen nodig: zijn eigen persoonlijke sleutel met het certificaat, en een verklaring over welke peercertificaten het accepteert. Bij de client is die verklaring de digest van het servercertificaat; bij de server is het de lijst met geregistreerde clientdigests. Een officieel voorbeeld voor kleine opstellingen voor Community 2.6 toont de regeling met peer-fingerprint, en het is de moeite waard om het te lezen voordat je dit vertrouwensmodel voor een echte uitrol kiest. De twee richtingen zijn geen omgekeerde lijst, en ze falen niet op hetzelfde moment.

Een apparaat toevoegen bewerkt een allowlist op de server, zonder privémateriaal van een bestaande client te kopiëren en zonder de serversleutel ergens heen te verplaatsen. De twee richtingen falen ook onafhankelijk, wat nuttig is bij diagnose: de kant die de handshake sluit, is de kant wiens verwachting niet is uitgekomen. Als de client de server afwijst, komt de digest niet overeen met het gepresenteerde certificaat. Als de server de client afwijst, ontbreekt de digest van die client op de lijst, of presenteert de client een ander certificaat dan het geregistreerde.

Registratie: hoe een nieuw apparaat meedoet

Genereer de sleutel en het certificaat van het nieuwe apparaat waar de persoonlijke sleutel zal leven, en verplaats daarna alleen het publieke artefact naar de partij die het moet vastpinnen. Draag de verwachte digest over via een kanaal dat je al vertrouwt, en vergelijk het volledige certificaat in plaats van een naam die bekend lijkt. Een digest die uit dezelfde ongeverifieerde download als het certificaat is gekopieerd, bewijst alleen dat de twee bestanden met elkaar overeenkomen. Dat is een consistentiecontrole en geen identiteitscontrole, en het is de stilste manier waarop dit ontwerp verzwakt.

Op de server is het toevoegen van de digest een configuratiewijziging die via de normale beheerder loopt en gevolgd wordt door opnieuw verbinden. Bevestig dat het nieuwe apparaat verbindt en dat een apparaat waarvan de digest is verwijderd dat niet meer doet. Een test die alleen het positieve geval dekt, laat de allowlist ongeverifieerd, en precies in die toestand zul je over zes maanden zijn.

Vernieuwing is het dure moment

Elk certificaat verloopt, en een nieuw certificaat heeft een nieuwe digest, zelfs wanneer de sleutel en de namen hetzelfde blijven. Onder een uitgever is vernieuwing transparant voor peers die die uitgever vertrouwen; onder vastpinnen is het een registratiegebeurtenis voor elke peer die het certificaat vastpint.

Plan de volgorde vóór de vervaldatum in plaats van erna. Verspreid de nieuwe digest naar de partijen die hem verifiëren, pas de wijziging toe, en wissel pas daarna het certificaat op het eindpunt. Die volgorde laat geen venster waarin de twee kanten het oneens zijn over welk certificaat actueel is. Houd de lijst zelf ook onder herziening, want een vastgepinde lijst verzamelt vermeldingen voor apparaten die maanden geleden zijn uitgefaseerd. Elke verouderde vermelding is een identiteit die zich nog steeds authenticeert als haar sleutel overleeft, dus er één verwijderen is een beveiligingshandeling en geen opruimen.

Wat de vertrouwenskaart niet beslist

Authenticatie is één laag, en de vastgepinde kaart zegt niets over de adrespool, de gepushte routes, de pad-MTU of het firewallbeleid. Die blijven aparte configuratie met aparte faalmodi. Een tunnel die authenticeert en geen verkeer doorlaat, is een ander onderzoek dan een die nooit omhoog komt.

De kaart schaalt ook niet onbeperkt, en een op een uitgever gebaseerde PKI is waar grotere uitrollen eindigen. Die voorkeur gaat over bedrijfsvoering en niet over cryptografie, omdat identiteiten toevoegen en uitfaseren via één autoriteit goedkoper is dan een lijst op elke peer aanpassen terwijl de vloot groeit. Waar een clientimplementatie de optie niet ondersteunt, is het antwoord een compatibel vertrouwensmodel dat die client documenteert, of een ondersteunde vervanging. De verificatiewaarschuwing onderdrukken voegt die ondersteuning niet toe, en de hele waarde van het ontwerp is dat verificatie nog steeds plaatsvindt.