TLS (Transport Layer Security) är ett kryp­te­rings­pro­to­koll som sä­ker­stäl­ler säker da­taö­ver­fö­ring på internet. Det är ef­ter­föl­ja­ren till det föråld­ra­de SSL och används nu nästan ute­slu­tan­de i versionen TLS 1.3.

Vad är TLS?

I internets barndom var da­ta­sä­ker­het inte lika viktigt som det är idag. All kom­mu­ni­ka­tion skickades öppet och okryp­te­rat från en dator till en annan. Man kan jämföra det med ett vykort: alla brev­bä­ra­re kunde läsa det.

TLS-pro­to­kol­let – även känt som SSL/TLS – in­tro­du­ce­ra­de kryp­te­ring av överfört innehåll. För att fortsätta analogin kan denna kryp­te­ring liknas vid ett förseglat kuvert som endast den rätt­mä­ti­ga mot­ta­ga­ren kan öppna.

För­kort­ning­en TLS står för Transport Layer Security. Termen avser trans­port­lag­ret i TCP/IP-modellen. TLS är en metod som krypterar da­ta­ström­mar på internet så att endast behöriga mottagare kan läsa dem.

Notis

Det tidigare namnet på kryp­te­rings­pro­to­kol­let var SSL (Secure Socket Layer). Eftersom denna för­kort­ning fort­fa­ran­de är mer känd än TLS, kallas TLS ofta för det dubbla namnet ”SSL/TLS”.

Hur fungerar TLS?

TLS krypterar data som skickas via internet och im­ple­men­te­ras normalt ovanpå TCP med hjälp av sym­met­risk kryp­to­gra­fi.

Det som låter enkelt i teorin är mer kom­pli­ce­rat i praktiken. Det grund­läg­gan­de problemet är att servern måste kom­mu­ni­ce­ra nyckeln till klienten –innan kom­mu­ni­ka­tio­nen säkras med TLS. Alla som skickar kryp­te­ra­de e-post­bi­la­gor känner till detta problem: Du krypterar en fil och måste dela det hemliga lö­senor­det med mot­ta­ga­ren, t.ex. via telefon.

TLS-pro­to­kol­let, vars nuvarande standard har varit version 1.3 sedan 2018, använder följande procedur för att lösa detta problem:

  1. Cli­ent­Hel­lo: Klienten (t.ex. en webb­lä­sa­re) skickar ett initialt med­de­lan­de till servern med in­for­ma­tion om de kryp­te­ring­ar som stöds. Detta in­klu­de­rar kryp­te­rings­s­vi­ter, pro­to­koll­ver­sio­ner, ett slump­mäs­sigt värde och dess eget Elliptic-Curve-Diffie-Hellman-nyc­kel­ut­by­tes­vär­de (ECDHE-värde). Valfritt kan det första kryp­te­ra­de da­tabloc­ket redan skickas.
  2. Ser­ver­Hel­lo: Servern väljer lämpliga pa­ra­met­rar och skickar sitt svar – inklusive sitt ECDHE-värde och sitt digitala cer­ti­fi­kat. Detta SSL-cer­ti­fi­kat bevisar att servern är autentisk och inte utger sig för att vara någon annan. Samtidigt börjar be­räk­ning­en av ses­sions­nyc­keln.
  3. Nyc­kel­be­räk­ning: Båda sidor beräknar nu oberoende av varandra samma ses­sions­nyc­kel baserat på den gemensamt över­enskom­na nyckeln.
  4. Servern slutför handskak­ning­en och påbörjar krypterad kom­mu­ni­ka­tion. Klienten gör samma sak; an­slut­ning­en är nu helt säker.
Notis

Jämfört med tidigare versioner är TLS-handskak­ning­en i TLS 1.3 betydligt smidigare och säkrare. Hela processen som beskrivs här kräver nu bara en enda rundtur (1 RTT), vilket märkbart snabbar upp an­slut­ning­en.

An­led­ning­en till att asym­met­risk kryp­te­ring med Diffie-Hellman endast används för att överföra ses­sions­nyc­keln (men inte för att kryptera själva da­ta­ström­mar­na) är has­tig­hets­för­de­len; asym­met­risk kryp­te­ring är relativt långsam och skulle fördröja da­ta­kom­mu­ni­ka­tio­nen.

För- och nackdelar med TLS

TLS är en elegant lösning för att göra webb­tra­fi­ken säkrare. Det kräver inte att de två parterna själva krypterar in­ne­hål­let, till exempel for­mu­lär­da­ta. Istället räcker det att trafiken dirigeras via TLS-pro­to­kol­let, oavsett del­ta­gar­nas ope­ra­tiv­sy­stem och pro­gram­va­ra. Alla da­ta­ström­mar krypteras då au­to­ma­tiskt under över­fö­ring­en.

Priset för sä­ker­he­ten är en något lång­sam­ma­re an­slut­nings­upp­kopp­ling, eftersom de ovan nämnda pro­cess­ste­gen – cer­ti­fi­kat, slumptal, nyc­kel­ut­byte – är be­räk­nings­in­ten­si­va.

An­vänd­nings­om­rå­den för TLS

Som nämnts kan TLS användas uni­ver­sellt eftersom det är oberoende av ap­pli­ka­tio­ner och ope­ra­tiv­sy­stem. Följakt­li­gen finns det en TLS-säker version för en mängd olika ap­pli­ka­tions­pro­to­koll. Namn­giv­nings­sche­mat är i de flesta fall ganska enkelt: bokstaven “S” läggs till pro­to­kol­lets namn när pro­to­kol­let kom­mu­ni­ce­rar via TLS.

Det vik­ti­gas­te an­vänd­nings­om­rå­det för TLS är World Wide Web, särskilt HTTP-pro­to­kol­let. Dess kryp­te­ra­de version kallas HTTPS.

Utöver dessa bör följande vanliga an­vänd­nings­fall nämnas:

  • POP3S: Hämta e-post­med­de­lan­den från servern med hjälp av POP3-pro­to­kol­let
  • IMAPS: Syn­kro­ni­se­ra inkorg med servern med hjälp av IMAP-pro­to­kol­let
  • SMTPS: Skicka e-post­med­de­lan­den
  • FTPS: Filö­ver­fö­ring via FTP-protokoll
  • SIPS: IP-telefoni via SIP-pro­to­kol­let
  • IRCS: Kryp­te­ra­de chattar
  • QUIC: Googles trans­port­pro­to­koll som direkt in­te­gre­rar TLS 1.3; ett al­ter­na­tiv till TCP för snabbare och säkrare web­ban­slut­ning­ar (t.ex. med HTTP/3)

OpenVPN, ett gratis program för att upprätta ett virtuellt privat nätverk (VPN), använder också TLS-pro­to­kol­let.

Viktiga TLS-im­ple­men­te­ring­ar

Några av de mest använda im­ple­men­te­ring­ar­na av TLS är:

  • OpenSSL – den över­läg­set van­li­gas­te im­ple­men­te­ring­en som används av de flesta HTTPS-webb­plat­ser
  • GnuTLS (Free Software Founda­tion)
  • LibreSSL (OpenBSD)
  • NSS (Network Security Services)
  • BoringSSL (Google)
  • Rustls (Joe Birr-Pixton, Dirkjan Ochtman, Daniel McCarney, Josh Aas och Open-Source Community)
  • Botan (BSD-licens, Jack Lloyd)
  • JSSE (Java Secure Socket Extension, Oracle)
  • S2n (Amazon)

Denna lista är inte ut­töm­man­de. De­tal­je­rad in­for­ma­tion om TLS-im­ple­men­te­ring­ar finns på Wikipedia.

Välkända TLS-attacker

Även om TLS är utformat för säker kom­mu­ni­ka­tion har det fort­fa­ran­de kända svagheter. Dessa in­klu­de­rar:

  • Pro­gram­me­rings­fel: He­art­bleed Bug blev känt som ett kritiskt pro­gram­me­rings­fel i tidigare versioner av OpenSSL. Det åt­gär­da­des 2014.
  • Svaga kryp­te­ring­ar: Som ett resultat av ame­ri­kans­ka ex­port­re­strik­tio­ner för kryp­to­gra­fi ut­veck­la­des ”ex­port­ver­sio­ner” som var lättare att knäcka än ori­gi­na­len.
  • Kom­pri­me­ring­s­at­tac­ker: När HTTP-kom­pri­me­ring används istället för TLS-kom­pri­me­ring blir det möjligt för hackare att gissa TLS-krypterat innehåll genom vissa metoder.
  • BEAST-attacken påverkade TLS version 1.0 och beskrevs redan 2014. Nuvarande TLS-versioner är säkra mot den.
  • Padding Oracle-attacken upp­täck­tes 2002 och var möjlig upp till SSL version 3.0. Den nuvarande TLS version 1.3 påverkas inte.
  • ALPACA-attacken från 2021 visar hur TLS-cer­ti­fi­kat på fel­kon­fi­gu­re­ra­de servrar kan utnyttjas för att omdi­ri­ge­ra användare till andra tjänster och avlyssna eller ma­ni­pu­le­ra data.

Det har också gjorts försök att förhindra helt säker TLS-kryp­te­ring för att myn­dig­he­ter ska kunna få tillgång till krypterad kom­mu­ni­ka­tion, till exempel i samband med fi­nan­si­el­la trans­ak­tio­ner och brottslig verk­sam­het. En av de or­ga­ni­sa­tio­ner som fö­re­språ­ka­de en sådan ”avsiktlig sårbarhet” i TLS var ETSI (Eu­ro­pe­is­ka in­sti­tu­tet för te­le­kom­mu­ni­ka­tions­stan­dar­der).

Gå till huvudmeny