Vad är en SSL/TLS-handskakning?
En SSL/TLS-handskakning är en förhandling mellan två parter i ett nätverk, t.ex. en webbläsare och en webbserver, för att fastställa detaljerna för deras anslutning. Den bestämmer vilken version av SSL/TLS som ska användas i sessionen, vilken chifferföljd som ska kryptera kommunikationen, verifierar servern (och ibland även klienten) och fastställer att en säker anslutning finns på plats innan data överförs.
Det här sker tack och lov i bakgrunden – varje gång du styr din webbläsare till en säker webbplats sker en komplex interaktion för att se till att dina data är säkra.
Det är den enkla versionen. Du kanske märker att ett dussintal beskrivningar mer eller mindre följer detta format, samtidigt som de skiljer sig åt i detalj på ett dussintal olika sätt – ibland på ett förvirrande sätt. Låt oss ta fram ett diagram som visar en bred modell för hur ett TLS-handslag fungerar, okej?
BESTÄLL NU
Obligatorisk SSL/TLS-handslagsdiagram
Alla SSL/TLS-relaterade webbplatser har sin egen version av ett handslagsdiagram – här är vårt! (Klicka för att förstora.)
Låt oss reda ut en del förvirring om vi kan
En del förvirring om hur SSL/TLS handshakes fungerar beror på att handshake bara är upptakten till den faktiska, säkrade sessionen. Låt oss försöka ta upp några vanliga punkter:
Asymmetrisk vs symmetrisk kryptering
Handskakningen i sig använder asymmetrisk kryptering – två separata nycklar används, en offentlig och en privat. Eftersom asymmetriska krypteringssystem har mycket högre overhead är de inte användbara för att ge säkerhet på heltid i den verkliga världen. Därför används den offentliga nyckeln för kryptering och den privata nyckeln för dekryptering endast under handskakningen, vilket gör det möjligt för de två parterna att konfidentiellt upprätta och utbyta en nyskapad ”delad nyckel”. Under själva sessionen används denna enda delade nyckel för att utföra symmetrisk kryptering, och det är detta som gör en säker anslutning genomförbar i praktiken (overheadkostnaden är mycket lägre). Så det fullständiga och korrekta svaret på frågan ”Är SSL/TLS-kryptering asymmetrisk eller symmetrisk?” är ”Först det ena, sedan det andra.”
Vad är en ”cipher suite”?
Själva handskakningen har flera steg, som alla hanteras enligt olika regler. Detaljerna finns här, men kärnan i det hela är att i stället för en rad separata förhandlingar fram och tillbaka (om vilka nycklar som ska användas, hur själva handslaget ska krypteras, hur handslaget ska autentiseras och så vidare) kan parterna komma överens om att använda en ”cipher suite” – ett redan befintligt urval eller kit av överenskomna komponenter. (Kom ihåg att asymmetrisk kryptering är tids- och resurskrävande – att använda chifferpaketet som en genväg snabbar upp själva handskakningen). TLS-specifikationerna tillåter ett ganska stort antal chiffersviter, och klienten och servern kommer nästan alltid att ha tillgång till en som de båda kan använda.
Basisk vs ömsesidigt autentiserad handshake
En annan förvirrande punkt är att den grundläggande modellen som vi beskrev ovan låter klienten verifiera servern, och att den stora majoriteten av sessioner som säkras med TLS endast kräver detta. Vissa chifferuppsättningar kräver dock att klienten även skickar ett certifikat och en offentlig nyckel för ömsesidig autentisering av båda parter. Denna dubbelriktade autentisering kommer naturligtvis att öka overheadkostnaden för handshake – men i vissa fall (t.ex. när två banker förhandlar om en säker anslutning för penningöverföringar) kommer chifferföljden att insistera på det, och den extra säkerheten anses vara värd det.
Olika sessioner kommer att ha olika säkerhetsparametrar
Varje nytt handshake skapar en ny session, och de inställningar som används i den ena sessionen kan skilja sig drastiskt från den andra beroende på vilken chifferföljd som valts. Detta är en av anledningarna till att det finns så många olika iterationer av det förbaskade handshake-diagrammet, och varför vi ger en ganska bred översikt här. Du ska också veta att sessioner kan ställa in parametrar som kanske inte är exakt vad du förväntar dig. Beroende på chifferföljd kan vissa steg läggas till (t.ex. kravet på tvåvägsautentisering) eller saknas. Det finns faktiskt chifferuppsättningar som förhandlar om att en session inte ska använda någon kryptering alls. (Ja, vi vet, en HTTPS-anslutning över port 443 som bestämmer sig för att skicka data i klartext är inte heller meningsfullt för oss. SSL.com rekommenderar starkt att du inte gör detta – var bara medveten om att det är möjligt.)