Definition og formål
SSL og TLS bruges om kryptering af data under transport, så oplysninger ikke kan læses eller ændres undervejs mellem fx en webbrowser og en server. I dag omtales det typisk som TLS; “SSL” bruges ofte som en praktisk betegnelse, selvom selve SSL er historisk.
Et enkelt model: tillid først, så kryptering
En TLS-forbindelse kan forstås som tre overordnede trin:
- Forhandling (handshake): Klient og server aftaler hvilke kryptografiske algoritmer de vil bruge, og forbereder nøgler til selve krypteringen.
- Tillid via certifikat: Serverens identitet knyttes til et certifikat. Klienten kontrollerer certifikatet (fx at det er gyldigt og passer til serverens navn), så den ikke “forbinder til den forkerte”.
- Sessionnøgle og krypteret trafik: Når handshake er færdig, bruges en sessionnøgle til at kryptere og beskytte selve dataudvekslingen.
Resultatet er, at indholdet sendes som krypteret trafik. Modtagere uden den rigtige nøgle kan typisk ikke læse data. Hvor “sikker” løsningen er i praksis afhænger af, om forhandlingen og valgte algoritmer er tilstrækkeligt stærke, og om certifikater håndteres korrekt.
Hvad der sker i praksis: certifikater, nøgler og integritet
TLS handler ikke kun om fortrolighed (hemmeligholdelse). Den giver også integritet: mekanismer i protokollen skal sikre, at data ikke kan ændres uden at det opdages. Dertil kan TLS give autentificering gennem certifikatet, så klienten kan vurdere, at serveren er den, den udgiver sig for.
Nøgleudvekslingen (hvordan de fælles sessionnøgler skabes) er protokollens tekniske kerne. Den konkrete proces kan variere afhængigt af TLS-version og den valgte nøgleudvekslingsmetode. Derfor er det klogt at undgå at tænke i ét “magisk” trin; der er flere varianter, og nogle er mere robuste end andre.
Forskelle, begrænsninger og undtagelser
SSL vs. TLS: TLS er en videreudvikling af SSL med ændringer i sikkerhed og protokoladfærd. Hvis et system reelt bruger ældre SSL-varianter eller tillader svage krypteringsindstillinger, kan beskyttelsen være lavere end forventet.
Styrken afhænger af konfiguration: Selv når TLS bruges, kan sikkerheden påvirkes af valg som algoritmer, protokolversioner og certifikatstatus. Fx kan et forkert eller udløbet certifikat få klienten til at reagere (typisk ved advarsler eller afvisning), men detaljer varierer.
Ingen “absolut” sikkerhed: TLS beskytter data på transportniveau, men det løser ikke alt. Hvis den ene part allerede er kompromitteret, eller hvis der er fejl i applikationslogik, kan TLS alene ikke garantere, at alt bliver korrekt. Derudover kan metadatapåvirkninger som hvem der kommunikerer med hvem afhænge af systemdesign, selv om selve indholdet er krypteret.
Hvis du vil vurdere, om en konkret forbindelse faktisk bruger stærk TLS, bør du undersøge den faktiske forhandlingsopsætning og certifikatforhold i den kontekst, du kontrollerer.
Hvad du kan tjekke selv
- Brug af HTTPS/TLS i praksis: Se om forbindelsen viser et TLS-setup (typisk via browserens sikkerhedssignaler), og om der er tydelige advarsler.
- Certifikatgyldighed og navn: Kontroller at certifikatet er gyldigt og matcher serverens navn, du forsøger at nå.
- Protokol og kryptografiske valg: Verificér hvilke TLS-versioner og krypteringspakker der forhandles i din specifikke situation.
Hvis du matcher disse kontrolpunkter, kan du placere TLS-kryptering korrekt i forhold til din egen trusselsmodel: den beskytter især data under transport, men den erstatter ikke behovet for korrekt drift og sikre konfigurationer.