Selvsignert VPN-sertifikat: hva det betyr og hva det stoler på

To overbevisninger gjør mest skade her: at et selvsignert VPN-sertifikat betyr at tunnelen ikke er kryptert, og at installasjon av hva VPN-klienten enn ba om bare påvirker VPN-en. Ingen av dem overlever møtet med en ekte utrulling. Et selvsignert sertifikat beskriver et signaturforhold, ikke en sikkerhetsdom, og rekkevidden til tilliten du legger til, avhenger av hvilket lager den lander i. Jeg har sett en helpdesk importere en leverandørrot i en Windows-maskin for å dempe én advarsel, og deretter bruke en ettermiddag på å forklare hvorfor nettleseren sluttet å klage på en urelatert portal. De to halvdelene av dette spørsmålet hører sammen, så behandle dem som ett.

Et sertifikat er ikke et tillitslager

Filen serveren presenterer, bærer en offentlig nøkkel, et subjektnavn, et utstedernavn, gyldighetsdatoer og utvidelser. Selvsignert betyr at subjektet og utstederen er samme enhet, og signaturen verifiseres med sertifikatets egen nøkkel. Ingenting i den definisjonen sier at forbindelsen er svak, og ingenting sier at klienten vil godta den.

Godtakelse kommer fra et annet sted: en CA-fil du peker klienten mot, et fingeravtrykk du sammenligner for hånd, eller en rot som allerede ligger i et lager klienten leser. En utrulling kan være helt sunn mens sertifikatet ville stryke på enhver offentlig test. openssl verify mot systembunten vil rapportere en ukjent utsteder, og den rapporten er korrekt, ikke en feil.

OpenVPNs ca-valg er det klareste tilfellet av app-avgrenset tillit. Den filen navngir ankerne klienten vil godta, og den kan inneholde én privat CA eller, i en liten utrulling, serverens eget selvsignerte sertifikat. Versjon 2.6 godtar også --peer-fingerprint for å feste et SHA-256-fingeravtrykk i stedet for å distribuere en CA-fil. WireGuard ligger enda lenger ute: det har ingen sertifikater i det hele tatt, bare en statisk offentlig nøkkel per peer, så spørsmålet om selvsignering passer ikke på det.

Hvor du installerer tillit, avgjør hvem som arver den

Sett det samme sertifikatet tre steder, og du får tre forskjellige eksplosjonsradier. En bunt som bare VPN-klienten leser, påvirker den klienten. En rot i operativsystemets lager påvirker hvert program som konsulterer det lageret. En nettleser med sin egen tillitsdatabase kan ignorere begge, og derfor kan en advarsel overleve en import som så ut til å virke.

På Debian eller Ubuntu endrer det systembunten å slippe en fil i /usr/local/share/ca-certificates/ og kjøre update-ca-certificates. På Windows skriver certutil -addstore -f Root til maskinlageret og krever en forhøyet ledetekst, mens å legge til -user i stedet retter seg mot den gjeldende brukerens lager; de to er ikke utskiftbare. Firefox holder sin egen NSS-database, så en import på OS-nivå vises kanskje aldri der.

Omfang betyr noe på grunn av hva en myndighet kan gjøre. En utstedende CA kan signere for navn den ikke har noen relasjon til, så alt som stoler på det lageret, godtar disse signaturene. Et enkelt festet blad kan ikke gjøre det; det autentiserer nøyaktig én peer-identitet. Hvis målet er å få én VPN til å koble til, når en app-avgrenset CA eller et festet blad det, mens en maskinvid rot er en langt større innrømmelse enn symptomet krever.

Du krypterer fortsatt uten en offentlig CA

TLS-håndtrykket utleder sesjonsnøkler uansett om peer-sertifikatet kjeder til noe du allerede stoler på. Selvsignert betyr ikke klartekst, og det betyr ikke at trafikken er lesbar underveis. Det betyr at klienten ikke har noen a priori grunn til å tro at nøkkelen tilhører serveren den ba om.

Det er i det gapet ekte angrep lever. En klient som er konfigurert til å godta ethvert sertifikat, enten gjennom en deaktivert verifiseringsinnstilling eller en stol-på-det-likevel-knapp som er klikket én gang og glemt, vil krypte gladelig til den som svarer. Avlyttingen skjer i autentiseringstrinnet, før applikasjonsdata beveger seg. Kryptering uten identitetskontroll holder en passiv observatør ute og gjør lite annet.

Tillit til utstederen hopper ikke over navnekontrollen

Kjedevalidering, navnematching og sertifikatets formål er separate beslutninger. En kjede kan være gyldig mens navnet er feil, og et navn kan matche mens sertifikatet ble utstedt for en annen rolle. RFC 5280 definerer feltene som bærer disse begrensningene, og hvor strengt en klient håndhever dem, er en sak for hver applikasjon.

OpenVPN gjør oppdelingen synlig. verify-x509-name fester det forventede subjektet gjennom name, name-prefix eller subject-matching. remote-cert-tls server krever at peer-sertifikatet kan brukes som server-sertifikat, noe som avviser et klient-bare-sertifikat selv når utstederen er klarert. Ingen av innstillingene erstattes av å sende en CA-fil.

Undersøk sertifikatet før du bestemmer noe:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName viser hvem som utstedte det, for hvilke navn og til når.
• openssl verify -CAfile ca.crt server.crt sjekker om kjeden du planlegger å sende faktisk validerer bladet.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error virker for TLS-endepunkter som en nettportal; OpenVPN-protokollen på 1194 er ikke en vanlig TLS-strøm, så den testen gjelder ikke der.

Et sertifikat med utløpt dato, uten subjectAltName for navnet du kobler til, eller uten serverAuth-bruk, feiler uansett hvor nøye ankeret ble installert.

Fem kontroller før du godtar ett

Sammenlign fingeravtrykket over en kanal som ikke er forbindelsen du prøver å reparere: en konsoll, et installasjonsprogram du allerede har, en signert konfigurasjonsfil. openssl x509 -in server.crt -noout -fingerprint -sha256 på serveren og samme verdi i klientloggen er nok til å vite at du ser på ett objekt.

Deretter bestemmer du hva du installerer: ett blad eller en myndighet som kan prege flere. Så bestemmer du hvor det skal hen, og navngir applikasjonene som leser det lageret. Skriv ned fjerningsveien mens du fortsatt husker den, for stol-på-det-og-gå-videre er hvordan en midlertidig import blir permanent.

Til slutt, planlegg endringen. Et festet sertifikat eller fingeravtrykk må oppdateres gjennom samme klarerte kanal når sertifikatet roterer, og en privat CA har sin egen livssyklus for utstedelse og tilbakekalling. Hvis den private nøkkelen lekker, reparerer det ingenting å stole på en kopi av samme sertifikat igjen; identiteten må erstattes.

Hvis en advarsel overlever alle fem kontroller, er det nyttige spørsmålet ikke hvilken knapp som demper den, men hvilket lager klienten faktisk leser, og hvor den roten kom fra. Svar på det, og importen du er i ferd med å gjøre, blir en beslutning i stedet for en refleks.