OpenVPN uten CA: hvordan peer-fingerprint verifiserer parter

En liten utrulling griper etter fingeravtrykk fordi en sertifiseringsmyndighet ser ut som infrastruktur ingen har tid til å drive. Instinktet er rimelig, men snarveien folk tar i stedet—å kopiere én data-kanalhemmelighet til begge ender—er det ikke. En peer-fingerprint-oppsett holder TLS-strukturen intakt: hver side har fortsatt sin egen private nøkkel og sitt sertifikat, og hver side verifiserer fortsatt den andre. Det som endres, er hvor verifiseringen er forankret: fra en betrodd utsteder til en kort liste med pinnede digester. Fordi en digest dekker hele sertifikatet og ikke et navn, blir fornyelse den operasjonen som virkelig tar tid.

Hva fingeravtrykket faktisk forplikter seg til

Et sertifikatfingeravtrykk er en digest av hele det DER-kodede sertifikatet, ikke av den offentlige nøkkelen og ikke av subjektnavnet. Derfor har to sertifikater med identiske navn og samme nøkkel men ulike gyldighetsdatoer ulike fingeravtrykk. Det er det som gjør pinning presist, og det er også det som gjør fornyelse forstyrrende. En pin kan ikke bety å stole på en nøkkel generelt, fordi den navngir én artefakt på ett tidspunkt i livet dens. Hvem som helst kan kjenne digesten, og å kjenne den beviser ingenting i seg selv.

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

Besittelse av den matchende private nøkkelen er det som beviser at parten har dette sertifikatet, og digesten er hvordan den andre siden avgjør om den i det hele tatt forventet dette sertifikatet. Denne delingen er grunnen til at dette designet ikke er den gamle ordningen med delt hemmelighet: en delt nøkkel autentiserer alle som kjenner de samme bytene, mens en pin autentiserer ett sertifikat. En annen enhet får sin egen oppføring i stedet for en kopi av den samme hemmeligheten, noe som er en liten forskjell i filer og en stor i skadeomfang.

Kartet er gjensidig, ikke symmetrisk

Hvert endepunkt trenger to ting: sin egen private nøkkel med sertifikatet, og en erklæring om hvilke partsertifikater det vil godta. Hos klienten er den erklæringen digesten til serverens sertifikat; hos serveren er det listen over registrerte klientdigester. Et offisielt eksempel for små oppsett for Community 2.6 viser ordningen med peer-fingerprint, og det er verdt å lese før du velger denne tillitsmodellen for en ekte utrulling. De to retningene er ikke én omvendt liste, og de feiler ikke på samme tidspunkt.

Å legge til en enhet redigerer en tillatt-liste på serveren, uten å kopiere privat materiale fra en eksisterende klient og uten å flytte servernøkkelen noe sted. De to retningene feiler også uavhengig, noe som er nyttig under feilsøking: den siden som lukker håndtrykket, er den siden hvis forventning ikke ble innfridd. Hvis klienten avviser serveren, samsvarer ikke digesten med sertifikatet som presenteres. Hvis serveren avviser klienten, mangler klientens digest på listen, eller klienten presenterer et annet sertifikat enn det som ble registrert.

Registrering: hvordan en ny enhet blir med

Generer den nye enhetens nøkkel og sertifikat der den private nøkkelen skal bo, og flytt deretter bare den offentlige artefakten til parten som må pinne den. Overfør den forventede digesten gjennom en kanal du allerede stoler på, og sammenlign hele sertifikatet i stedet for et navn som ser kjent ut. En digest kopiert fra samme uverifiserte nedlasting som sertifikatet beviser bare at de to filene stemmer overens med hverandre. Det er en konsistenskontroll, ikke en identitetskontroll, og det er den stilleste måten dette designet svekkes på.

På serveren er det å legge til digesten en konfigurasjonsendring som går gjennom den vanlige administratoren og følges av en gjenoppkobling. Bekreft at den nye enheten kobler til, og at en enhet hvis digest ble fjernet, ikke lenger gjør det. En test som bare dekker det positive tilfellet, lar tillatt-listen være uverifisert, og det er nøyaktig tilstanden du vil være i om seks måneder.

Fornyelse er det dyre øyeblikket

Hvert sertifikat utløper, og et nytt sertifikat har en ny digest selv når nøkkelen og navnene forblir de samme. Under en utsteder er fornyelse gjennomsiktig for parter som stoler på den utstederen; under pinning er det en registreringshendelse for hver part som pinner sertifikatet.

Planlegg rekkefølgen før utløpsdatoen i stedet for etter. Distribuer den nye digesten til partene som verifiserer den, bruk endringen, og bytt først deretter sertifikatet på endepunktet. Den rekkefølgen etterlater ikke noe vindu der de to sidene er uenige om hvilket sertifikat som er gjeldende. Hold selve listen under gjennomgang også, fordi en pinnet liste akkumulerer oppføringer for enheter som ble pensjonert for måneder siden. Hver utdatert oppføring er en identitet som fortsatt autentiserer hvis nøkkelen overlever, så å fjerne én er en sikkerhetshandling og ikke rydding.

Hva tillitskartet ikke avgjør

Autentisering er ett lag, og det pinnede kartet sier ingenting om adressepoolen, de pusha rutene, banens MTU eller brannmurpolitikken. De forblir separat konfigurasjon med separate feilmoduser. En tunnel som autentiserer og ikke slipper gjennom trafikk, er en annen undersøkelse enn en som aldri kommer opp.

Kartet skalerer heller ikke ubegrenset, og en utstederbasert PKI er der større utrullinger ender opp. Den preferansen handler om drift og ikke kryptografi, fordi det er billigere å legge til og avvikle identiteter gjennom én myndighet enn å redigere en liste på hver part etter hvert som flåten vokser. Der en klientimplementasjon ikke støtter alternativet, er svaret en kompatibel tillitsmodell som den klienten dokumenterer, eller en støttet erstatning. Å undertrykke verifiseringsadvarselen legger ikke til den støtten, og hele verdien av designet er at verifiseringen fortsatt skjer.