OpenVPN sonder ’n CA: hoe peer-fingerprint eweknieë verifieer

’n Klein ontplooiing gryp na vingerafdrukke omdat ’n sertifikaatowerheid lyk soos infrastruktuur waarvoor niemand tyd het nie. Die instink is redelik, maar die kortpad wat mense eerder neem—om een datakanaalgeheim na albei kante te kopieer—is dit nie. ’n peer-fingerprint-opstelling hou die TLS-struktuur ongeskonde: elke kant hou steeds sy eie private sleutel en sertifikaat, en elke kant verifieer steeds die ander. Wat verander, is waar die verifikasie geanker is: van ’n vertroude uitreiker na ’n kort lys vasgepen digest-waardes. Omdat ’n digest die hele sertifikaat dek eerder as ’n naam, word hernuwing die operasie wat werklik tyd kos.

Waartoe die vingerafdruk werklik verbind

’n Sertifikaatvingerafdruk is ’n digest van die hele DER-gekodeerde sertifikaat, nie van sy publieke sleutel nie en nie van sy onderwerpnaam nie. Twee sertifikate met identiese name en dieselfde sleutel maar verskillende geldigheidsdatums het dus verskillende vingerafdrukke. Dit is wat vaspen presies maak, en dit is ook wat hernuwing ontwrigtend maak. Vaspenning kan nie beteken om ’n sleutel in die algemeen te vertrou nie, want dit noem een artefak op een oomblik in sy lewe. Enigiemand mag die digest ken, en om dit te ken bewys op sigself niks.

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

Die besit van die ooreenstemmende private sleutel is wat bewys die eweknie hou daardie sertifikaat, en die digest is hoe die ander kant besluit of hy daardie sertifikaat hoegenaamd verwag het. Daardie skeiding is waarom hierdie ontwerp nie die ou gedeelde-geheim-reëling is nie: ’n gedeelde sleutel verifieer enigiemand wat dieselfde grepe ken, terwyl ’n vaspenning een sertifikaat verifieer. ’n Ander toestel kry sy eie inskrywing eerder as ’n kopie van dieselfde geheim, wat ’n klein verskil in lêers en ’n groot een in die omvang van skade is.

Die kaart is wederkerig, nie simmetries nie

Elke eindpunt het twee dinge nodig: sy eie private sleutel saam met sy sertifikaat, en ’n verklaring oor watter eweknie-sertifikate hy sal aanvaar. Op die kliënt is daardie verklaring die bediener-sertifikaat se digest; op die bediener is dit die lys ingeskrewe kliënt-digests. ’n Amptelike voorbeeld vir klein opstellings vir Community 2.6 wys die reëling met peer-fingerprint, en dit is die moeite werd om dit te lees voordat jy hierdie vertrouensmodel vir ’n werklike ontplooiing kies. Die twee rigtings is nie een lys wat omgekeer is nie, en hulle misluk nie op dieselfde oomblik nie.

Om ’n toestel by te voeg wysig ’n toelaatlys op die bediener, sonder om ’n bestaande kliënt se private materiaal te kopieer en sonder om die bediener-sleutel êrens heen te skuif. Die twee rigtings misluk ook onafhanklik, wat nuttig is tydens diagnose: watter kant ook al die TLS-handskud sluit, is die kant wie se verwagting nie nagekom is nie. As die kliënt die bediener verwerp, stem die digest nie ooreen met die sertifikaat wat aangebied word nie. As die bediener die kliënt verwerp, ontbreek daardie kliënt se digest op die lys, of die kliënt bied ’n ander sertifikaat aan as die een wat ingeskryf is.

Inskrywing: hoe ’n nuwe toestel aansluit

Genereer die nuwe toestel se sleutel en sertifikaat waar die private sleutel sal woon, en skuif dan net die publieke artefak na die party wat dit moet vaspen. Dra die verwagte digest oor deur ’n kanaal wat jy reeds vertrou, en vergelyk die volledige sertifikaat eerder as ’n naam wat bekend lyk. ’n Digest wat uit dieselfde ongeverifieerde aflaai as die sertifikaat gekopieer is, bewys net dat die twee lêers met mekaar ooreenstem. Dit is ’n konsekwentheidstoets eerder as ’n identiteitstoets, en dit is die stilste manier waarop hierdie ontwerp verswak word.

Op die bediener is die byvoeging van die digest ’n konfigurasiewysiging wat deur die normale bestuurder gaan en deur ’n herverbinding gevolg word. Bevestig dat die nuwe toestel konnekteer en dat ’n toestel wie se digest verwyder is, nie meer doen nie. ’n Toets wat net die positiewe geval dek, laat die toelaatlys ongeverifieer, wat presies die toestand is waarin jy oor ses maande sal wees.

Hernuwing is die duur oomblik

Elke sertifikaat verstryk, en ’n nuwe sertifikaat het ’n nuwe digest selfs wanneer die sleutel en die name dieselfde bly. Onder ’n uitreiker is hernuwing deursigtig vir eweknieë wat daardie uitreiker vertrou; onder vaspenning is dit ’n inskrywingsgebeurtenis vir elke eweknie wat die sertifikaat vaspen.

Beplan die volgorde voor die vervaldatum eerder as daarna. Versprei die nuwe digest aan die partye wat dit verifieer, pas die wysiging toe, en ruil eers dan die sertifikaat op die eindpunt om. Daardie volgorde laat geen venster waarin die twee kante dit oneens is oor watter sertifikaat tans geldig is nie. Hou die lys self ook onder hersiening, want ’n vasgepen lys versamel inskrywings vir toestelle wat maande gelede onttrek is. Elke verouderde inskrywing is ’n identiteit wat steeds verifieer as sy sleutel oorleef, so om een te verwyder is ’n sekuriteitsaksie eerder as huiswerk.

Wat die vertrouenskaart nie besluit nie

Verifikasie is een laag, en die vasgepen kaart sê niks oor die adrespoel, die gestuurde roetes, die pad-MTU of die firewall-beleid nie. Dit bly aparte konfigurasie met aparte foutmodusse. ’n Tonnel wat verifieer en geen verkeer deurlaat nie, is ’n ander ondersoek as een wat nooit opkom nie.

Die kaart skaal ook nie onbeperk nie, en ’n uitreiker-gebaseerde PKI is waar groter ontplooiings beland. Daardie voorkeur gaan oor bedryf eerder as kriptografie, want om identiteite deur een owerheid by te voeg en af te lê is goedkoper as om ’n lys op elke eweknie te wysig namate die vloot groei. Waar ’n kliëntimplementering die opsie nie ondersteun nie, is die antwoord ’n versoenbare vertrouensmodel wat daardie kliënt dokumenteer, of ’n ondersteunde plaasvervanger. Om die verifikasiewaarskuwing te onderdruk voeg nie daardie ondersteuning by nie, en die hele waarde van die ontwerp is dat verifikasie steeds plaasvind.