Nätverk och protokoll

TLS

Kryptografiskt protokoll som säkrar klientservertrafik mot avlyssning och manipulering.

Var du ser detta: Syns i paketfångster, nätverksdiagram, brandväggsregler samt system- och nätverksloggar.

Vad det är

TLS (Transport Layer Security) är standardsättet för att säkra trafik mellan två slutpunkter på Internet. Den tillhandahåller konfidentialitet (kryptering), integritet (manipulationsdetektering) och slutpunktsautentisering, oftast autentisera servern till klienten.

Nyckelpunkter
  • Handskakning förhandlar versioner, chiffer och nycklar, sedan skyddar postlagret data.
  • Serverautentisering bygger på certifikatkedjor och verifiering av värdnamn.
  • TLS 1.3 minskar handskakning tur och retur och tar bort många äldre funktioner.

Hur det fungerar i stora drag

  1. Klienten ansluter till servern och skickar ett ClientHello med stödda protokollversioner, chiffersviter och slumpmässiga värden.
  2. Servern svarar med ServerHello, väljer parametrar och tillhandahåller nyckelutbytesmaterial. I TLS 1.3 etablerar detta handskakningsnycklar snabbt.
  3. Servern skickar sin certifikatkedja och bevisar innehav av den privata nyckeln, och klienten verifierar kedjan och värdnamnet.
  4. Båda sidor hämtar delade hemligheter och byter till krypterade poster för resten av sessionen.
  5. Applikationsdata delas upp i poster som är krypterade och integritetsskyddade.
  6. Funktioner som återupptagande av session tillåter senare anslutningar att hoppa över delar av handskakningen för snabbhet.
  7. När anslutningen avslutas kasseras nycklar. Bra implementeringar roterar också nycklar och tvingar fram moderna versioner.

Konkret exempel

När du besöker en bankwebbplats utför din webbläsare en TLS-handskakning, verifierar att certifikatet matchar bankens domän och krypterar sedan all HTTP-trafik så att WiFi-angripare inte kan läsa dina referenser eller ändra sidan.

Varför det är viktigt

Utan TLS kan vem som helst på vägen läsa eller ändra trafik. TLS finns så att applikationer säkert kan använda det offentliga Internet och fortfarande ha privat, pålitlig kommunikation.

Säkerhetsperspektiv

  • TLS säkerhet beror på korrekt certifikatvalidering och betrodda rotlager.
  • Modern vägledning är att föredra TLS 1.3 och starka chiffersviter och att inaktivera äldre omförhandling och äldre versioner.
  • Hantera certifikat som autentiseringsuppgifter operativt: spåra utgångsdatum, automatisera förnyelse och övervaka för felaktiga utfärdande.

Vanliga fallgropar

  • Hoppa över värdnamnsverifiering. Ett giltigt certifikat för fel namn är inte säkert.
  • Tillåter föråldrade protokoll eller svaga chiffer för kompatibilitet.
  • Att glömma att TLS inte säkrar själva slutpunkten. Kompromissade klienter kan fortfarande läcka hemligheter.
  • TLS avslutande proxyservrar kan bryta antaganden från början och ändra vad nätverksövervakning kan se.
  • Missförstånd av certifikatfel som valfritt. De är vanligtvis din enda varning för avlyssning.

FÖRDJUPNING

▾

Vad TLS ger och var den sitter

TLS sitter ovanför en transport som TCP och under applikationsprotokoll som HTTP. Transporten levererar bytes. TLS förvandlar dessa bytes till en skyddad kanal med konfidentialitet, integritet och valfri klientautentisering. Den gör detta genom att komma överens om nycklar och algoritmer och sedan slå in applikationsdata i krypterade poster.

TLS är inte bara kryptering. Integritet är lika viktigt. Varje post är autentiserad, så en passiv angripare kan inte ändra trafik utan upptäckt. Det är därför HTTPS skyddar dig från manipulering även på fientlig WiFi, inte bara från avlyssning.

Eftersom TLS är lager kan du ofta resonera om problem genom att separera lager. Om TCP är instabil ser du återsändningar och återställningar. Om TLS misslyckas ser du handskakningsvarningar, certifikatfel eller protokollförväntningar som inte matchar även när TCP-anslutning finns.

TLS 1.3 handslag i verkligheten

En typisk TLS 1.3-anslutning börjar med en ClientHello. Klienten erbjuder protokollversioner som stöds, chiffersviter och nyckelresurser för den tillfälliga Diffie Hellman. Det kan också inkludera SNI för att tala om för servern vilket värdnamn den vill ha, och ALPN för att förhandla fram applikationsprotokoll som HTTP/2.

Servern svarar med ServerHello som väljer parametrar och tillhandahåller sin egen nyckeldelning. Från den punkten kan båda sidor härleda handskakningsnycklar och kryptera mycket av den återstående handskakningen. Servern skickar sitt certifikat och bevis på innehav, sedan utbyter båda sidor Färdiga meddelanden som bekräftar att de såg samma utskrift och hämtade samma nycklar.

Efter avslutad flyter applikationsdataposter, skyddade av AEAD-chiffer. TLS 1.3 är utformad för att nå denna punkt med en tur och retur i det vanliga fallet, vilket är anledningen till att moderna HTTPS känns snabbare än äldre TLS-versioner på nätverk med hög latens.

Certifikat, identitet och varför validering är viktigt

Certifikatet är hur klienten vet att den pratar med rätt server, inte en bedragare. Servern presenterar en certifikatkedja som länkar tillbaka till en betrodd rot i klientens förtroendearkiv. Klienten validerar kedjesignaturerna, kontrollerar utgången och verifierar att certifikatet matchar värdnamnet som den avsåg att nå.

Om valideringen misslyckas får du de välbekanta webbläsarvarningarna. Ett vanligt fel är ett värdnamnsfel, vilket kan inträffa om SNI saknas eller om en lastbalanserare levererar fel certifikat. En annan är en ofullständig kedja där ett mellancertifikat inte serverades korrekt.

I företagsmiljöer ger TLS avlyssning ytterligare en twist. En proxy kan avsluta TLS och presentera ett annat certifikat signerat av en intern CA. Det fungerar bara om klienten litar på den CA. Om inte, ser det ut som en attack, vilket är korrekt från klientens synvinkel.

Efter handskakningen: poster, återupptagande och viktiga uppdateringar

När den väl har upprättats skickar TLS data som en sekvens av poster. Varje post har sin egen autentiseringstagg, och sekvensnummer förhindrar uppspelning och omordningstrick. Om du fångar trafik kommer du fortfarande att se paketstorlekar och timing, men innehållet är ogenomskinligt.

För att minska latensen vid upprepade besök kan servrar aktivera återupptagande. Kunden kan uppvisa en sessionsbiljett och återuppta med färre tur- och returresor. TLS 1.3 definierar också 0 RTT-data, men den funktionen kan tillåta uppspelning av tidiga data, så den är vanligtvis begränsad till idempotenta förfrågningar.

TLS stöder också nyckeluppdateringar under en lång anslutning. Regelbunden uppdatering av nycklar minskar mängden data som skyddas under en enskild nyckel och begränsar skador om en nyckel på något sätt komprometteras. I praktiken är de flesta sessioner tillräckligt korta för att du sällan märker detta, men mekanismen är en del av det som gör TLS robust i skala.