Hvad er SSL/TLS-kryptering i en VPN?

SSL og TLS bruges ofte som fælles betegnelse for den kryptering, der skaber en sikker “kanal” mellem en klient og en server. I praksis betyder det, at parterne først gennemfører et håndtryk, hvor de aftaler kryptografiske parametre (såsom version og algoritmer) og etablerer nøgler. Når forbindelsen er etableret, bruges de aftalte nøgler til at kryptere og autentificere den efterfølgende dataudveksling, så oplysninger ikke kan læses af uvedkommende og ikke ændres ubemærket.

Det er vigtigt at skelne mellem:

  • Selve VPN’en (den måde forbindelsen bruges og styres på)
  • Krypteringslaget (TLS/SSL-håndtryk og efterfølgende kryptering)

Selvom fejlsymptomer ofte ser ens ud (fx “kan ikke oprette forbindelse”), kan årsagen ligge i krypteringslaget, i VPN-opsætningen eller i netværket imellem.

Et enkelt model: håndtryk, nøgler og “hvad der kan gå galt”

Tænk på forbindelsen som tre trin:

  1. Initial kontakt: Klienten forsøger at etablere en sikker session.
  2. Håndtryk og aftale: Parterne forhandler protokolversion og krypteringssuits (algoritmer). Samtidig præsenterer serveren typisk et certifikat, som klienten kan validere.
  3. Efterfølgende trafik: Når nøgler og parametre er aftalt, krypteres data.

Typiske fejl opstår ved et eller flere af disse trin:

  • Håndtryk fejler: Uforenelig TLS-version eller algoritmer, eller at noget i vejen ændrer trafikken.
  • Certifikatvalidering fejler: Forkert certifikat, udløbet certifikat, manglende rod-/mellemliggende certifikater eller “navn matcher ikke”.
  • Kun nogle klienter virker: Ofte forskelle i TLS-opsætning, operativsystemets certifikatlager eller browser-/klientbibliotekers standarder.
  • Virker på ét netværk, ikke et andet: Enheder som firewalls, proxyer eller sikkerheds-gateways kan påvirke håndtryk.

Vanlige problemer og hvordan du løser dem

Nedenfor er kontrolpunkter, der hjælper dig med at adskille krypteringsproblemer fra andre årsager.

1) Certifikater: kæde, gyldighed og navn

Hvis klienten ikke kan validere serverens certifikat, kan TLS-håndtrykket typisk stoppe tidligt. Almindelige problemer er:

  • Udløbet certifikat
  • Ufuldstændig certifikatkæde (manglende mellemliggende certifikater)
  • Navne-mismatch (at hostnavnet i URL/DNS ikke stemmer med certifikatets identitet)
  • Forkert rod-CA i tillid (klienten stoler ikke på udstederen)

Løsning i praksis handler ofte om at sikre, at serveren præsenterer et korrekt certifikat og en komplet kæde, samt at klienten har den rette tillid eller CA-beslutsgrundlag. Hvis der er udskiftning af certifikater, kan “midlertidige” perioder også skabe forvirring, fx når nogle klienter cached certifikater eller når flere endpoints skifter samtidig.

2) Protokolversion og cipher-/algoritmevalg

Nogle forbindelser fejler, fordi klient og server ikke kan blive enige om:

  • TLS-version (fx at serveren kun tilbyder nyere versioner, mens klienten kun understøtter ældre)
  • Krypteringssuits (algoritmekombinationer)

Løsning er typisk at justere opsætningen, så både klient og server understøtter mindst én fælles, sikker og aktiveret konfiguration. Vær opmærksom på, at “at få det til at virke” ikke bør betyde at man åbner for usikre valg; i stedet handler det om kompatibilitet med passende sikkerhedsniveau.

3) Kompatibilitetsforskelle mellem klienttyper

Forskellige klienter (desktop, mobil, indbygget software, browsere eller specialklienter) bruger ikke altid samme TLS-bibliotek og standarder. Det kan betyde:

  • at én klient accepterer en opsætning,
  • mens en anden afviser den.

Her hjælper det at sammenligne “hvilken klient der fejler”, hvornår fejlen opstår, og hvilken fejltekst/log der rapporteres. Hvis problemet er konsistent for én klienttype, er sandsynligheden større for at det handler om TLS-kompatibilitet eller certifikatlager.

4) Netværk og “middleboxes” (proxy, firewall, inspektion)

Hvis VPN-trafik passerer gennem udstyr, der inspicerer eller omformer TLS-trafik, kan håndtryk mislykkes. Symptomatisk kan det ligne certifikatsfejl eller “unexpected EOF/handshake failure”.

Løsning er at undersøge om der findes:

  • proxy-/SSL-inspektionspolitik,
  • netværksfiltrering af porte/protokoller,
  • eller krav til bestemte endepunkter.

Det kan også forklare “virker hjemme, ikke på arbejde”-scenarier.

5) Forkert VPN- og TLS-konfiguration (parameterfejl)

Nogle fejl skyldes ikke TLS i sig selv, men at VPN-konfigurationen påvirker hvordan TLS bruges. Eksempler på det kan være:

  • at den rigtige server/endpoint ikke rammes,
  • at SNI/hostheader ikke matcher forventning,
  • eller at der bruges en opsætning til “TLS-kontakt” som ikke matcher klientens forventninger.

Løsning her handler om at validere, at de konfigurérbare værdier på begge sider (endpoint, navne, port, TLS-indstillinger) stemmer overens.

Forskelle og grænser: hvornår hjælper TLS-fejlfinding ikke?

Selv om SSL/TLS ofte er årsagen, er der grænser for hvad du kan konkludere kun ud fra “TLS ser ud til at fejle”. Følgende kan gøre billedet uklart:

  • Netværksfejl efter håndtryk: Håndtryk kan lykkes, men selve tunneling/route kan fejle.
  • Ufuldgyldig logtolkning: Nogle fejltekster er generiske og dækker flere årsager.
  • Interaktion med DNS: Hvis hostnavne slår forkert, kan du ramme en anden server end forventet, hvilket igen kan give certifikatproblemer.

Derfor er den bedste strategi ofte at kombinere:

  1. certifikat-/navnevalidering,
  2. TLS-håndtrykssucces/fail,
  3. netværkskontekst (hvilket netværk og hvilke enheder der er imellem).

Praktisk: sådan kan du kontrollere årsagen trin for trin

Følgende punkter er generelle, ikke-afhængige af bestemte produkter, og kan hjælpe dig med at indsnævre problemet:

  1. Bekræft certifikatgrundlaget

    • Kontroller om certifikatet er gyldigt (ikke udløbet).
    • Kontroller at identiteten matcher det hostnavn, du bruger til at oprette forbindelse.
    • Hvis der findes en certifikatkæde, verificér at den ikke er ufuldstændig.

  2. Sammenlign fejlen på forskellige netværk

    • Prøv samme forbindelse i et andet netværk for at se om en proxy/firewall/enhed påvirker TLS.

  3. Sammenlign forskellige klienter

    • Hvis det kun rammer én klienttype, er der større sandsynlighed for TLS-kompatibilitet, certifikatlager eller klientkonfiguration.

  4. Brug loglinjer fra både klient og server

    • Se efter mønstre knyttet til “handshake”, “certificate”, “protocol/version” eller “cipher”.
    • Notér hvilket tidspunkt fejlen opstår, og om den sker før eller efter der etableres session.

  5. Hold opsætningen konsistent

    • Sørg for at serverens TLS-indstillinger og klientens TLS-understøttelse overlapper.
    • Undgå at ændre for mange ting ad gangen; så er det sværere at afgøre hvad der faktisk løste problemet.

Hvis du støder på en løsning der kræver at du slækker på sikkerhedsvalg, så stop og vurder alternativer: ofte findes der en kompatibilitetsløsning, hvor TLS stadig forbliver på et passende niveau.

Konklusion: den hurtigste måde at ramme årsagen på

Når TLS-kryptering i en VPN driller, er det typisk håndtryk og certifikatvalidering eller inkompatible TLS-indstillinger. Start derfor med certifikatets gyldighed og navnsmatch, se om der er TLS-version/cipher-uforenelighed, og test om netværksenheder påvirker forbindelsen. Hvis du kan placere fejlen i “før eller efter håndtryk”-fasen, bliver næste kontroltrin langt mere målrettet.

(Bemærk: Uden specifik fejlsætning, loguddrag eller konfiguration kan man ikke med sikkerhed afgøre den eksakte årsag i dit tilfælde; brug kontrolpunkterne til at afgrænse.)