tls-auth mot tls-crypt: hva hver av dem beskytter i OpenVPN

Begge alternativene bruker en delt nøkkelfil, og begge gjør håndtrykkstrafikk vanskeligere å forfalske, og derfor behandles de som to navn på samme funksjon. Det er de ikke. Den ene signerer kontrollpakker, den andre krypterer dem også, og ingen av dem har noe med sifferen som beskytter nyttelasten din å gjøre.

Den forskjellen betyr noe når en profil ikke får kontakt, når en sikkerhetsgjennomgang spør hva nøkkelen beskytter, og når noen antar at den ekstra filen gjør tunnelen kryptert på en eller annen udefinert måte.

Hva den delte nøkkelen faktisk beskytter

Nøkkelen som disse alternativene bruker, hører til kontrollkanalen: utvekslingen som forhandler parametere, beviser identiteter og utleder datanøklene. Det er en forhåndsdelt hemmelighet som begge ender må ha før håndtrykket kan fortsette. Fordi den ligger før identitetskontrollene, stopper en feil nøkkel samtalen tidligere enn et feil passord ville gjort. Den rekkefølgen forklarer hvorfor feilmodusen er så stille.

tls-auth bruker den hemmeligheten til å beregne en HMAC over kontrollpakker. En pakke uten gyldig signatur forkastes før den når den dyrere TLS-behandlingen, og derfor beskrives alternativet ofte som et første filter snarere enn en erstatning for TLS.

tls-crypt går lenger ved å kryptere den beskyttede kontrolltrafikken i tillegg til å autentisere den. Sertifikatinnhold, forhandlede siffernavn og andre håndtrykksdetaljer er ikke lenger synlige på nettet, og en observatør uten nøkkelen kan ikke engang se hvilken TLS-versjon som forsøkes. For en utrulling som frykter å avsløre VPN-fingeravtrykket sitt, er den egenskapen hovedgrunnen til å velge den. Den er fortsatt en gruppehemmelighet, ikke en legitimasjon per bruker.

Ingen av mekanismene utsteder identiteter. Den delte nøkkelen er en gruppehemmelighet, og alle som har den, kan oppfylle det laget av kontrollen.

Hvor de to alternativene skiller seg

Forskjellen man kan se, er hva en observatør ser. Med tls-auth er håndtrykket synlig, men ikke verifiserbart uten nøkkelen. Med tls-crypt er håndtrykket ugjennomsiktig for alle som ikke har nøkkelen.

Konfigurasjonen er også forskjellig. tls-auth brukes med en retningsverdi, så den ene siden bruker den ene halvdelen av nøkkelmaterialet og den andre siden den andre halvdelen. tls-crypt bruker én nøkkel i begge retninger, så retningsdirektivet er ikke en del av oppsettet.

De to alternativene utelukker hverandre i moderne utgivelser. En profil bør inneholde ett av dem, ikke begge, og serveren og klienten må bli enige om hvilket, med samsvarende nøkkelmateriale. Å beholde et gammelt direktiv ved siden av et nytt er en vanlig migreringsrest. Fjern det inaktive slik at neste leser vet hvilket lag som faktisk gjelder.

En nyere variant, tls-crypt-v2, binder hver klient til sin egen innpakkede nøkkel, slik at tilbakekalling av én klient ikke krever at gruppenøkkelen utstedes på nytt. Det er verdt å kjenne til, men det er et annet alternativ og ikke et synonym for noen av de to her.

Hvorfor en uoverensstemmelse ser ut som om ingenting skjer

Når det delte materialet ikke stemmer, forkaster motparten pakkene uten å fortelle avsenderen hvorfor. Det finnes ingen autentiseringsfeil å lese, fordi pakken aldri nådde laget som ville produsert en.

Klienten prøver på nytt, serveren sier ingenting, og symptomet ser ut som et nettverksproblem. Så starter folk tjenesten på nytt, skriver inn kontopassordet igjen eller fjerner beskyttelsesdirektivet for å «teste» det, noe som endrer utrullingen i stedet for å diagnostisere den.

Les serverloggen for den første klagen på pakkenivå i stedet for den siste nytt-forsøk-linjen. Bekreft at begge sider har samme alternativ med identisk nøkkelmateriale, og at nøkkelfilen ikke ble generert på nytt på bare én side.

Å fjerne direktivet er ikke en trygg reparasjon. Det deaktiverer et beskyttelseslag for hver klient, og en tunnel som virker etterpå beviser bare at laget var uoverensstemmelsen.

Hva som fortsatt må konfigureres separat

Disse alternativene bekrefter ikke hvem motparten er. Sertifikatvalidering, tillitsankeret og det forventede servernavnet forblir separate krav, og ingen av dem blir valgfrie fordi det finnes en delt nøkkel.

De velger heller ikke datasifferen. Det er en separat forhandling som styres av datakanalens innstillinger på begge parter, og en tunnel beskyttet av tls-crypt kan fortsatt bruke en siffer du ikke hadde tenkt deg.

Til slutt trenger den delte nøkkelen selv håndtering. Behandle den som en hemmelighet, distribuer den via en godkjent kanal, og bytt den ut når noen som hadde den, slutter. Fordi den deles, er dens eksponering eksponeringen til hver ende som bruker den.