Selvsigneret VPN-certifikat: hvad det betyder, og hvad det stoler på

To overbevisninger gør det meste af skaden her: at et selvsigneret VPN-certifikat betyder, at tunnelen ikke er krypteret, og at installation af hvad VPN-klienten end bad om kun påvirker VPN'en. Ingen af dem overlever mødet med en rigtig udrulning. Et selvsigneret certifikat beskriver et signaturforhold, ikke en sikkerhedsdom, og rækkevidden af den tillid, du tilføjer, afhænger af, hvilket lager den lander i. Jeg har set en helpdesk importere en udbyderrod i en Windows-maskine for at dæmpe én advarsel og derefter bruge en eftermiddag på at forklare, hvorfor browseren holdt op med at klage over en urelateret portal. De to halvdele af dette spørgsmål hører sammen, så behandl dem som ét.

Et certifikat er ikke et tillidslager

Filen, som serveren præsenterer, bærer en offentlig nøgle, et emnenavn, et udstedernavn, gyldighedsdatoer og udvidelser. Selvsigneret betyder, at emnet og udstederen er samme enhed, og at signaturen verificeres med certifikatets egen nøgle. Intet i den definition siger, at forbindelsen er svag, og intet siger, at klienten vil acceptere den.

Accept kommer fra et andet sted: en CA-fil, som du peger klienten på, et fingeraftryk, som du sammenligner i hånden, eller en rod, der allerede ligger i et lager, som klienten læser. En udrulning kan være helt sund, mens dens certifikat ville dumpe i enhver offentlig test. openssl verify mod systembundtet rapporterer en ukendt udsteder, og den rapport er korrekt snarere end en fejl.

OpenVPN's ca-indstilling er det klareste tilfælde af app-afgrænset tillid. Den fil navngiver de ankere, som klienten vil acceptere, og den kan indeholde én privat CA eller, i en lille udrulning, serverens eget selvsignerede certifikat. Version 2.6 accepterer også --peer-fingerprint til at fastgøre et SHA-256-fingeraftryk i stedet for at distribuere en CA-fil. WireGuard ligger endnu længere ude: det har slet ingen certifikater, kun en statisk offentlig nøgle pr. peer, så spørgsmålet om selvsignering passer ikke på det.

Hvor du installerer tillid, afgør, hvem der arver den

Sæt det samme certifikat tre steder, og du får tre forskellige sprængningsradier. Et bundt, som kun VPN-klienten læser, påvirker den klient. En rod i operativsystemets lager påvirker ethvert program, der konsulterer det lager. En browser med sin egen tillidsdatabase kan ignorere begge, og derfor kan en advarsel overleve en import, der så ud til at virke.

På Debian eller Ubuntu ændrer det systembundtet at slippe en fil i /usr/local/share/ca-certificates/ og køre update-ca-certificates. På Windows skriver certutil -addstore -f Root til maskinlageret og kræver en forhøjet prompt, mens tilføjelse af -user i stedet rammer den aktuelle brugers lager; de to kan ikke udskiftes. Firefox holder sin egen NSS-database, så en import på OS-niveau vises måske aldrig der.

Omfang betyder noget på grund af, hvad en myndighed kan gøre. En udstedende CA kan signere for navne, den ikke har nogen relation til, så alt, der stoler på det lager, accepterer disse signaturer. Et enkelt fastgjort blad kan ikke gøre det; det autentificerer præcis én peer-identitet. Hvis målet er at få én VPN til at forbinde, når en app-afgrænset CA eller et fastgjort blad det, mens en maskinvid rod er en langt større indrømmelse, end symptomet kræver.

Du krypterer stadig uden en offentlig CA

TLS-håndtrykket udleder sessionsnøgler, uanset om peer-certifikatet kæder til noget, du allerede stoler på. Selvsigneret betyder ikke klartekst, og det betyder ikke, at trafikken er læsbar undervejs. Det betyder, at klienten ikke har nogen a priori grund til at tro, at nøglen tilhører den server, den bad om.

Det hul er, hvor rigtige angreb lever. En klient, der er konfigureret til at acceptere ethvert certifikat, enten gennem en deaktiveret verifikationsindstilling eller en stol-på-det-alligevel-knap, der er klikket én gang og glemt, vil kryptere glad til den, der svarer. Aflytningen sker i autentificeringstrinnet, før applikationsdata bevæger sig. Kryptering uden identitetskontrol holder en passiv observatør ude og gør lidt andet.

Tillid til udstederen springer ikke navnekontrollen over

Kædevalidering, navnematch og certifikatets formål er separate beslutninger. En kæde kan være gyldig, mens navnet er forkert, og et navn kan matche, mens certifikatet blev udstedt til en anden rolle. RFC 5280 definerer de felter, der bærer disse begrænsninger, og hvor strengt en klient håndhæver dem, er en sag for hver applikation.

OpenVPN gør opdelingen synlig. verify-x509-name fastgør det forventede emne gennem name, name-prefix eller subject-matchning. remote-cert-tls server kræver, at peer-certifikatet kan bruges som servercertifikat, hvilket afviser et klient-kun-certifikat, selv når udstederen er betroet. Ingen af indstillingerne erstattes af at sende en CA-fil.

Undersøg certifikatet, før du beslutter noget:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName viser, hvem der udstedte det, for hvilke navne og indtil hvornår.
• openssl verify -CAfile ca.crt server.crt kontrollerer, om den kæde, du planlægger at sende, faktisk validerer bladet.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error virker til TLS-endepunkter som en webportal; OpenVPN-protokollen på 1194 er ikke en almindelig TLS-strøm, så den test gælder ikke der.

Et certifikat med en udløbet dato, uden subjectAltName for det navn, du opretter forbindelse til, eller uden serverAuth-brug fejler, uanset hvor omhyggeligt ankeret blev installeret.

Fem kontroller, før du accepterer et

Sammenlign fingeraftrykket over en kanal, der ikke er den forbindelse, du forsøger at reparere: en konsol, et installationsprogram, du allerede har, en signeret konfigurationsfil. openssl x509 -in server.crt -noout -fingerprint -sha256 på serveren og den samme værdi i klientloggen er nok til at vide, at du ser på ét objekt.

Beslut derefter, hvad du installerer: ét blad eller en myndighed, der kan præge flere. Beslut så, hvor det skal hen, og navngiv de applikationer, der læser det lager. Skriv fjernelsesvejen ned, mens du stadig husker den, for stol-på-det-og-videre er, hvordan en midlertidig import bliver permanent.

Planlæg til sidst ændringen. Et fastgjort certifikat eller fingeraftryk skal opdateres gennem den samme betroede kanal, når certifikatet roterer, og en privat CA har sin egen udstedelses- og tilbagekaldelseslivscyklus. Hvis den private nøgle lækker, reparerer det intet at stole på en kopi af det samme certifikat igen; identiteten skal udskiftes.

Hvis en advarsel overlever alle fem kontroller, er det nyttige spørgsmål ikke, hvilken knap der dæmper den, men hvilket lager klienten faktisk læser, og hvor den rod kom fra. Besvar det, og den import, du er ved at foretage, bliver en beslutning i stedet for en refleks.