OpenVPN uden CA: hvordan peer-fingerprint verificerer parter

En lille udrulning griber efter fingeraftryk, fordi en certificeringsmyndighed ligner infrastruktur, som ingen har tid til at drive. Instinktet er rimeligt, men den genvej, folk i stedet tager—at kopiere én data-kanalhemmelighed til begge ender—er det ikke. En peer-fingerprint-opsætning holder TLS-strukturen intakt: hver side har stadig sin egen private nøgle og sit certifikat, og hver side verificerer stadig den anden. Det, der ændres, er hvor verifikationen er forankret: fra en betroet udsteder til en kort liste af pinmede digests. Fordi et digest dækker hele certifikatet og ikke et navn, bliver fornyelse den operation, der virkelig tager tid.

Hvad fingeraftrykket reelt forpligter sig på

Et certifikatfingeraftryk er et digest af hele det DER-kodede certifikat, ikke af dets offentlige nøgle og ikke af dets subjektnavn. Derfor har to certifikater med identiske navne og samme nøgle men forskellige gyldighedsdatoer forskellige fingeraftryk. Det er det, der gør pinning præcis, og det er også det, der gør fornyelse forstyrrende. En pin kan ikke betyde at stole på en nøgle generelt, fordi den navngiver ét artefakt på ét tidspunkt i dets liv. Enhver kan kende digestet, og at kende det beviser intet i sig selv.

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

Besiddelsen af den matchende private nøgle er det, der beviser, at modparten har det certifikat, og digestet er, hvordan den anden side afgør, om den overhovedet forventede det certifikat. Den adskillelse er grunden til, at dette design ikke er den gamle fælles-hemmelighedsordning: en fælles nøgle autentificerer enhver, der kender de samme bytes, mens en pin autentificerer ét certifikat. En anden enhed får sin egen post i stedet for en kopi af den samme hemmelighed, hvilket er en lille forskel i filer og en stor i skadesomfang.

Kortet er gensidigt, ikke symmetrisk

Hvert endepunkt har brug for to ting: sin egen private nøgle med certifikatet og en erklæring om, hvilke modpartscertifikater den vil acceptere. Hos klienten er den erklæring servercertifikatets digest; hos serveren er det listen over registrerede klientdigests. Et officielt eksempel til små opsætninger til Community 2.6 viser ordningen med peer-fingerprint, og det er værd at læse, før man vælger denne tillidsmodel til en rigtig udrulning. De to retninger er ikke én omvendt liste, og de fejler ikke på samme tidspunkt.

At tilføje en enhed redigerer en allowlist på serveren, uden at kopiere en eksisterende klients private materiale og uden at flytte servernøglen nogen steder hen. De to retninger fejler også uafhængigt, hvilket er nyttigt under fejlsøgning: den side, der lukker håndtrykket, er den side, hvis forventning ikke blev opfyldt. Hvis klienten afviser serveren, matcher digestet ikke det certifikat, der præsenteres. Hvis serveren afviser klienten, mangler den klients digest på listen, eller klienten præsenterer et andet certifikat end det, der blev registreret.

Tilmelding: hvordan en ny enhed kommer med

Generér den nye enheds nøgle og certifikat der, hvor den private nøgle skal bo, og flyt derefter kun det offentlige artefakt til den part, der skal pinne det. Overfør det forventede digest gennem en kanal, du allerede stoler på, og sammenlign hele certifikatet i stedet for et navn, der ser bekendt ud. Et digest kopieret fra samme uverificerede download som certifikatet beviser kun, at de to filer stemmer overens med hinanden. Det er en konsistenstjek, ikke et identitetstjek, og det er den mest stille måde, dette design svækkes på.

På serveren er tilføjelsen af digestet en konfigurationsændring, der går gennem den normale manager og følges af en genopkobling. Bekræft, at den nye enhed opretter forbindelse, og at en enhed, hvis digest blev fjernet, ikke længere gør det. En test, der kun dækker det positive tilfælde, efterlader allowlisten uverificeret, og det er præcis den tilstand, du vil være i om seks måneder.

Fornyelse er det dyre øjeblik

Ethvert certifikat udløber, og et nyt certifikat har et nyt digest, selv når nøglen og navnene forbliver de samme. Under en udsteder er fornyelse transparent for modparter, der stoler på den udsteder; under pinning er det en registreringshændelse for hver modpart, der pinner certifikatet.

Planlæg rækkefølgen før udløbsdatoen i stedet for efter den. Fordel det nye digest til de parter, der verificerer det, anvend ændringen, og udskift først derefter certifikatet på endepunktet. Den rækkefølge efterlader intet vindue, hvor de to sider er uenige om, hvilket certifikat der er aktuelt. Hold også selve listen under gennemsyn, fordi en pinmet liste akkumulerer poster for enheder, der blev pensioneret for måneder siden. Hver forældet post er en identitet, der stadig autentificerer, hvis dens nøgle overlever, så at fjerne én er en sikkerhedshandling og ikke rydning.

Hvad tillidskortet ikke afgør

Autentificering er ét lag, og det pinmede kort siger intet om adressepuljen, de skubbede ruter, stiens MTU eller firewallpolitikken. De forbliver separat konfiguration med separate fejltilstande. En tunnel, der autentificerer og ikke sender trafik, er en anden undersøgelse end en, der aldrig kommer op.

Kortet skalerer heller ikke ubegrænset, og en udstederbaseret PKI er der, hvor større udrulninger ender. Den præference handler om drift frem for kryptografi, fordi det er billigere at tilføje og afvikle identiteter gennem én myndighed end at redigere en liste på hver modpart, efterhånden som flåden vokser. Hvor en klientimplementering ikke understøtter muligheden, er svaret en kompatibel tillidsmodel, som den klient dokumenterer, eller en understøttet erstatning. At undertrykke verifikationsadvarslen tilføjer ikke den understøttelse, og hele værdien af designet er, at verifikation stadig sker.