OpenVPN utan CA: hur peer-fingerprint verifierar parter

En liten utrullning griper efter fingeravtryck eftersom en certifikatmyndighet ser ut som infrastruktur som ingen har tid att driva. Instinkten är rimlig, men genvägen folk tar i stället—att kopiera en datakanalhemlighet till båda ändarna—är det inte. En peer-fingerprint-konfiguration håller TLS-strukturen intakt: varje sida har fortfarande sin egen privata nyckel och sitt certifikat, och varje sida verifierar fortfarande den andra. Det som ändras är var verifieringen är förankrad: från en betrodd utgivare till en kort lista med pinnade digester. Eftersom en digest täcker hela certifikatet och inte ett namn, blir förnyelse den operation som verkligen tar tid.

Vad fingeravtrycket faktiskt förbinder sig till

Ett certifikatfingeravtryck är en digest av hela det DER-kodade certifikatet, inte av dess publika nyckel och inte av dess subjektnamn. Därför har två certifikat med identiska namn och samma nyckel men olika giltighetsdatum olika fingeravtryck. Det är det som gör pinnning exakt, och det är också det som gör förnyelse störande. En pinn kan inte betyda att lita på en nyckel generellt, eftersom den namnger en artefakt vid en tidpunkt i dess liv. Vem som helst får känna till digesten, och att känna till den bevisar ingenting i sig själv.

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

Innehav av den matchande privata nyckeln är det som bevisar att parten har det certifikatet, och digesten är hur den andra sidan avgör om den överhuvudtaget förväntade sig det certifikatet. Den uppdelningen är anledningen till att den här designen inte är den gamla ordningen med delad hemlighet: en delad nyckel autentiserar alla som känner till samma bytes, medan en pinn autentiserar ett certifikat. En annan enhet får sin egen post i stället för en kopia av samma hemlighet, vilket är en liten skillnad i filer och en stor i skadans omfattning.

Kartan är ömsesidig, inte symmetrisk

Varje ändpunkt behöver två saker: sin egen privata nyckel med certifikatet, och ett uttalande om vilka partcertifikat den accepterar. Hos klienten är det uttalandet digesten för serverns certifikat; hos servern är det listan över registrerade klientdigester. Ett officiellt exempel för små konfigurationer för Community 2.6 visar ordningen med peer-fingerprint, och det är värt att läsa innan du väljer den här förtroendemodellen för en riktig utrullning. De två riktningarna är inte en omvänd lista, och de misslyckas inte vid samma tidpunkt.

Att lägga till en enhet redigerar en tillåtelselista på servern, utan att kopiera privat material från en befintlig klient och utan att flytta serverns nyckel någonstans. De två riktningarna misslyckas också oberoende av varandra, vilket är användbart vid felsökning: den sida som stänger handskakningen är den sida vars förväntan inte uppfylldes. Om klienten avvisar servern matchar inte digesten det certifikat som presenteras. Om servern avvisar klienten saknas den klientens digest i listan, eller så presenterar klienten ett annat certifikat än det registrerade.

Registrering: hur en ny enhet ansluter

Generera den nya enhetens nyckel och certifikat där den privata nyckeln ska bo, och flytta sedan bara den publika artefakten till den part som måste pinna den. Överför den förväntade digesten genom en kanal du redan litar på, och jämför hela certifikatet i stället för ett namn som ser bekant ut. En digest kopierad från samma overifierade nedladdning som certifikatet bevisar bara att de två filerna stämmer överens med varandra. Det är en konsekvenskontroll, inte en identitetskontroll, och det är det tystaste sättet den här designen försvagas på.

På servern är att lägga till digesten en konfigurationsändring som går genom den vanliga administratören och följs av en återanslutning. Bekräfta att den nya enheten ansluter och att en enhet vars digest togs bort inte längre gör det. Ett test som bara täcker det positiva fallet lämnar tillåtelselistan overifierad, och det är precis det tillstånd du kommer att vara i om sex månader.

Förnyelse är det dyra ögonblicket

Varje certifikat löper ut, och ett nytt certifikat har en ny digest även när nyckeln och namnen förblir desamma. Under en utgivare är förnyelse transparent för parter som litar på den utgivaren; under pinnning är det en registreringshändelse för varje part som pinnar certifikatet.

Planera ordningen före utgångsdatumet i stället för efter. Distribuera den nya digesten till de parter som verifierar den, tillämpa ändringen, och byt först därefter ut certifikatet på ändpunkten. Den ordningen lämnar inget fönster där de två sidorna är oense om vilket certifikat som är aktuellt. Håll också själva listan under granskning, eftersom en pinnad lista samlar poster för enheter som togs ur bruk för månader sedan. Varje inaktuell post är en identitet som fortfarande autentiserar om dess nyckel överlever, så att ta bort en är en säkerhetsåtgärd och inte städning.

Vad förtroendekartan inte avgör

Autentisering är ett lager, och den pinnade kartan säger ingenting om adresspoolen, de pushade rutterna, banans MTU eller brandväggspolicyn. De förblir separat konfiguration med separata fellägen. En tunnel som autentiserar och inte släpper igenom trafik är en annan undersökning än en som aldrig kommer upp.

Kartan skalar inte heller obegränsat, och en utgivarbaserad PKI är där större utrullningar hamnar. Den preferensen handlar om drift och inte kryptografi, eftersom det är billigare att lägga till och avveckla identiteter genom en myndighet än att redigera en lista på varje part när flottan växer. Där en klientimplementering inte stöder alternativet är svaret en kompatibel förtroendemodell som den klienten dokumenterar, eller en stödd ersättning. Att undertrycka verifieringsvarningen lägger inte till det stödet, och hela värdet av designen är att verifieringen fortfarande sker.