Hvad er en SSL/TLS-handshake?
En SSL/TLS-handshake er en forhandling mellem to parter på et netværk – f.eks. en browser og en webserver – om at etablere detaljerne for deres forbindelse. Den bestemmer, hvilken version af SSL/TLS der skal bruges i sessionen, hvilken cipher suite der skal kryptere kommunikationen, verificerer serveren (og nogle gange også klienten) og fastslår, at der er en sikker forbindelse, inden der overføres data.
Det hele sker heldigvis i baggrunden – hver gang du sender din browser til et sikkert websted, finder der en kompleks interaktion sted for at sikre, at dine data er sikre.
Det er den simple version. Du vil måske bemærke, at et dusin beskrivelser mere eller mindre vil følge dette format, mens de i detaljer adskiller sig fra hinanden på et dusin forskellige måder – nogle gange på forvirrende vis. Lad os smide et skema op, der viser en bred model for, hvordan et TLS-håndshake fungerer, skal vi?
BESTIL NU
Obligatorisk SSL/TLS-handshake-grafik
Alle SSL/TLS-relaterede websteder har deres egen version af et handshake-diagram – her er vores! (Klik for at forstørre.)
Lad os rydde op i noget forvirring, hvis vi kan
En vis forvirring om, hvordan SSL/TLS-håndtryk fungerer, skyldes, at håndtrykket kun er optakten til selve den sikrede session. Lad os forsøge at tage fat på nogle almindelige punkter:
Asymmetrisk vs. symmetrisk kryptering
Selve handshaken anvender asymmetrisk kryptering – der anvendes to separate nøgler, en offentlig og en privat. Da asymmetriske krypteringssystemer har et meget højere overhead, kan de ikke bruges til at give fuldtidssikkerhed i den virkelige verden. Derfor bruges den offentlige nøgle kun til kryptering og den private nøgle kun til dekryptering under handshaken, hvilket gør det muligt for de to parter at oprette og udveksle en nyoprettet “fælles nøgle” i fortrolighed. Under selve sessionen bruges denne fælles nøgle til at udføre symmetrisk kryptering, og det er det, der gør en sikker forbindelse mulig i praksis (overheadet er meget lavere). Så det fuldstændige og korrekte svar på “Er SSL/TLS-kryptering asymmetrisk eller symmetrisk?” er “Først det ene, så det andet.”
Hvad er en “cipher suite”?
Selve handshaken har flere faser, der hver især forvaltes efter forskellige regler. Detaljerne kan findes her, men kernen i det hele er, at i stedet for en række separate forhandlinger frem og tilbage (om hvilke nøgler der skal bruges, hvordan selve håndslaget skal krypteres, hvordan håndslaget skal autentificeres osv.) kan parterne aftale at bruge en “cipher suite” – et på forhånd eksisterende udvalg eller sæt af aftalte komponenter. (Husk, at asymmetrisk kryptering er tids- og ressourcemæssigt dyrt – at bruge cipher suite som en genvej fremskynder selve håndslaget). TLS-specifikationerne giver mulighed for et ret stort antal cipher suites, og klienten og serveren vil næsten altid have adgang til en, som de begge kan anvende.
Basisk vs. gensidigt autentificeret handshake
Et andet forvirrende punkt er, at den grundlæggende model, som vi beskrev ovenfor, lader klienten verificere serveren, og langt de fleste sessioner, der er sikret med TLS, kræver kun dette. Nogle cipher suites vil dog kræve, at klienten også sender et certifikat og en offentlig nøgle til gensidig autentifikation af begge parter. Denne tovejs-godkendelse vil naturligvis tilføje overhead til håndslaget – men i nogle tilfælde (f.eks. når to banker forhandler om en sikker forbindelse til pengeoverførsler) vil cipher suite insistere på det, og den ekstra sikkerhed anses for at være det værd.
Differente sessioner vil have forskellige sikkerhedsparametre
Hvert nyt håndslag skaber en ny session, og de indstillinger, der anvendes i den ene, kan afvige drastisk fra den anden, afhængigt af den valgte cipher suite. Dette er blandt årsagerne til, at der findes så mange forskellige iterationer af det forbandede handshake-diagram, og hvorfor vi giver et ret bredt overblik her. Du skal også vide, at sessioner kan indstille parametre, som måske ikke helt svarer til det, du forventer. Afhængigt af cipher suite kan nogle trin tilføjes (som f.eks. kravet om tovejs-autentifikation) eller udelades. Faktisk er der faktisk cipher suites, som forhandler en session til at bruge ingen kryptering overhovedet. (Ja, vi ved godt, at en HTTPS-forbindelse over port 443, som beslutter sig for at sende data i klartekst, heller ikke giver nogen mening for os. SSL.com anbefaler på det kraftigste, at du ikke gør dette – du skal bare være opmærksom på, at det er i det mulige.)