OpenVPN utan CA: korleis peer-fingerprint stadfester partar

Ei lita utrulling grip etter fingeravtrykk fordi ein sertifiseringsstyresmakt ser ut som infrastruktur ingen har tid til å driva. Instinktet er rimeleg, men snarevegen folk tek i staden—å kopiera ein data-kanalhemmelegheit til begge endar—er det ikkje. Eit peer-fingerprint-oppsett held TLS-strukturen intakt: kvar side har framleis sin eigen private nøkkel og sitt sertifikat, og kvar side stadfester framleis den andre. Det som endrar seg, er kvar stadfestinga er forankra: frå ein tiltru utgivar til ei kort liste med pinna digests. Fordi ein digest dekkjer heile sertifikatet og ikkje eit namn, blir fornying den operasjonen som verkeleg tek tid.

Kva fingeravtrykket faktisk forpliktar seg til

Eit sertifikatfingeravtrykk er ein digest av heile det DER-koda sertifikatet, ikkje av den offentlege nøkkelen og ikkje av subjektnamnet. Difor har to sertifikat med identiske namn og same nøkkel men ulike gyldigheitsdatoar ulike fingeravtrykk. Det er det som gjer pinning presist, og det er òg det som gjer fornying forstyrrande. Ein pin kan ikkje tyda å stola på ein nøkkel generelt, fordi han namngjev éin artefakt på eitt tidspunkt i livet hans. Kven som helst kan kjenna digesten, og å kjenna han beviser ingenting i seg sjølv.

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

Eige av den samsvarande private nøkkelen er det som beviser at parten har dette sertifikatet, og digesten er korleis den andre sida avgjer om ho i det heile venta dette sertifikatet. Denne delinga er grunnen til at dette designet ikkje er den gamle ordninga med delt løyndom: ein delt nøkkel autentiserer alle som kjenner dei same byta, medan ein pin autentiserer eitt sertifikat. Eininga får si eiga oppføring i staden for ein kopi av den same løyndomen, noko som er ein liten skilnad i filer og ein stor i skadeomfang.

Kartet er gjensidig, ikkje symmetrisk

Kvart endepunkt treng to ting: sin eigen private nøkkel med sertifikatet, og ei fråsegn om kva partsertifikat det vil godta. Hos klienten er den fråsegna digesten til sertifikatet til tenaren; hos tenaren er det lista over registrerte klientdigestar. Eit offisielt døme for små oppsett for Community 2.6 viser ordninga med peer-fingerprint, og det er verdt å lesa før du vel denne tillitsmodellen for ei ekte utrulling. Dei to retningane er ikkje éi omvend liste, og dei feilar ikkje på same tidspunkt.

Å leggja til eining redigerer ei tillat-liste på tenaren, utan å kopiera privat materiale frå ein eksisterande klient og utan å flytta tenarnøkkelen noko stad. Dei to retningane feilar òg uavhengig, noko som er nyttig under feilsøking: den sida som lukkar handtrykket, er den sida kvis forventning ikkje vart innfridd. Viss klienten avviser tenaren, samsvarar ikkje digesten med sertifikatet som vert presentert. Viss tenaren avviser klienten, manglar digesten til den klienten på lista, eller klienten presenterer eit anna sertifikat enn det som vart registrert.

Registrering: korleis ei ny eining blir med

Generer nøkkelen og sertifikatet til den nye eininga der den private nøkkelen skal bu, og flytt deretter berre den offentlege artefakten til parten som må pinna han. Overfør den venta digesten gjennom ein kanal du allereie stolar på, og samanlikn heile sertifikatet i staden for eit namn som ser kjent ut. Ein digest kopiert frå same uverifiserte nedlastinga som sertifikatet beviser berre at dei to filene stemmer overeins med kvarandre. Det er ein konsistenskontroll, ikkje ein identitetskontroll, og det er den stillaste måten dette designet svekkjast på.

På tenaren er det å leggja til digesten ei konfigurasjonsendring som går gjennom den vanlege administratoren og vert følgd av ei ny tilkopling. Stadfest at den nye eininga koplar til, og at ei eining kvis digest vart fjerna, ikkje lenger gjer det. Ein test som berre dekkjer det positive tilfellet, lèt tillat-lista vera uverifisert, og det er nøyaktig tilstanden du vil vera i om seks månader.

Fornying er det dyre augeblikket

Kvart sertifikat renn ut, og eit nytt sertifikat har ein ny digest sjølv når nøkkelen og namna blir dei same. Under ein utgivar er fornying gjennomsiktig for partar som stolar på den utgivaren; under pinning er det ei registreringshending for kvar part som pinnar sertifikatet.

Planlegg rekkjefølgja før utløpsdatoen i staden for etter. Fordel den nye digesten til partane som stadfester han, bruk endringa, og byt først deretter sertifikatet på endepunktet. Den rekkjefølgja lèt ikkje att noko vindauge der dei to sidene er usamde om kva sertifikat som er gjeldande. Hald sjølve lista under gjennomgang òg, fordi ei pinna liste samlar oppføringar for einingar som vart pensjonerte for månader sidan. Kvar utdatert oppføring er ein identitet som framleis autentiserer viss nøkkelen overlever, så å fjerna éin er ei tryggingshandling og ikkje rydding.

Kva tillitskartet ikkje avgjer

Autentisering er eitt lag, og det pinna kartet seier ingenting om adressepoolen, dei pusha rutene, MTU-en til banen eller brannmurpolitikken. Dei held fram som separat konfigurasjon med separate feilmodus. Ein tunnel som autentiserer og ikkje slepp gjennom trafikk, er ei anna gransking enn ein som aldri kjem opp.

Kartet skalerer heller ikkje ubegrensa, og ein utgivarbasert PKI er der større utrullingar endar opp. Den preferansen handlar om drift og ikkje kryptografi, fordi det er billegare å leggja til og avvikla identitetar gjennom éi styresmakt enn å redigera ei liste på kvar part etter kvart som flåten veks. Der ein klientimplementasjon ikkje støttar alternativet, er svaret ein kompatibel tillitsmodell som den klienten dokumenterer, eller ei støtta erstatning. Å undertrykkja stadfestingsåtvaringa legg ikkje til den støtta, og heile verdien av designet er at stadfestinga framleis skjer.