Kort svar
En TLS handshake er den indledende forhandling der etablerer en krypteret forbindelse. Klienten foreslår protokolversioner og cipher suites (Client Hello), serveren vælger og sender sit certifikat (Server Hello), de to udfører en key exchange der giver dem en fælles hemmelighed uden at sende den over nettet, og ud af den udleder begge sider de symmetriske session keys der krypterer resten af samtalen. I TLS 1.2 tager det to round-trips; i TLS 1.3 ét.
Hvorfor en handshake overhovedet?
Symmetrisk kryptering er hurtig, men kræver at begge parter har den samme nøgle. Problemet er at blive enige om den nøgle over et netværk hvor enhver kan lytte med. Handshaken løser præcis det: den bruger asymmetrisk kryptografi og en key-exchange-algoritme til at aftale en delt hemmelighed, og verificerer samtidig at serveren er den den udgiver sig for via dens certifikat. Resultatet er en kanal der er både fortrolig og autentificeret. Forskellen på selve protokollerne dækker vi i SSL vs TLS.
Beskedsekvensen i TLS 1.2
Den klassiske handshake er en udveksling i to round-trips. Forenklet ser rækkefølgen sådan ud:
Klient Server | ---- ClientHello ----------------> | versioner, cipher suites, random, SNI | <--- ServerHello ----------------- | valgt version + cipher, random | <--- Certificate ----------------- | serverens certifikat-kæde | <--- ServerKeyExchange ----------- | (ECDHE) servers efemere public key | <--- ServerHelloDone ------------- | | ---- ClientKeyExchange -----------> | klients efemere public key | ---- ChangeCipherSpec ------------> | "fra nu krypterer jeg" | ---- Finished --------------------> | verificér handshake-integritet | <--- ChangeCipherSpec ------------ | | <--- Finished -------------------- | | ==== krypteret applikationsdata == |
Bemærk at Finished-beskederne indeholder en hash af hele den hidtidige handshake. Hvis en angriber havde pillet ved en enkelt besked undervejs (fx forsøgt at nedgradere protokollen), ville hasherne ikke matche, og forbindelsen afbrydes.
Trin 1 — Client Hello
Klienten åbner med en liste over hvad den understøtter: TLS-versioner, en prioriteret liste af cipher suites, et tilfældigt tal (client random) og en række extensions. Den vigtigste extension er SNI (Server Name Indication), der fortæller serveren hvilket domæne klienten vil til — afgørende når mange sites deler én IP. Mere om det i SNI forklaret.
Trin 2 — Server Hello og certifikat
Serveren vælger den højeste fælles protokolversion og én cipher suite fra klientens liste, sender sit eget tilfældige tal (server random) og leverer sin certifikat-kæde. Klienten validerer kæden op til en betroet root, tjekker udløbsdato, at navnet matcher SNI, og — afhængigt af konfiguration — revokeringsstatus. Sender serveren ikke hele kæden, fejler valideringen i mange klienter; det er den hyppigste praktiske handshake-fejl.
Trin 3 — Key exchange
Her aftales den fælles hemmelighed. Moderne TLS bruger ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): hver side genererer et efemert nøglepar, udveksler de offentlige dele, og begge kan nu uafhængigt beregne den samme delte hemmelighed — uden at den hemmelighed nogensinde sendes. Fordi nøgleparret er efemert (kasseres efter forbindelsen), opnår man Perfect Forward Secrecy: selv hvis serverens private nøgle lækker senere, kan gammel trafik ikke dekrypteres.
Trin 4 — Session keys og Finished
Ud fra den delte hemmelighed plus de to random-værdier udleder begge sider de samme symmetriske session keys via en key-derivation-funktion. Fra dette punkt skifter de til symmetrisk kryptering (hurtig), og Finished-beskederne bekræfter at ingen har manipuleret handshaken. Den valgte cipher suite bestemmer præcis hvilke algoritmer der bruges til key exchange, autentificering, kryptering og integritet.
TLS 1.3: ét round-trip
TLS 1.3 omdesignede handshaken. Klienten gætter kvalificeret på key-exchange-parametrene og sender allerede sin efemere public key i Client Hello. Serveren kan derfor svare med alt det nødvendige på én gang, og applikationsdata kan flyde efter blot ét round-trip (1-RTT) i stedet for to:
Klient Server | ---- ClientHello + key_share ----> | | <--- ServerHello + key_share ----- | + Certificate + Finished (krypteret) | ---- Finished -------------------> | | ==== krypteret applikationsdata == |
For genbesøg tilbyder TLS 1.3 endda 0-RTT, hvor klienten sender data allerede i sin første pakke. Samtidig fjernede TLS 1.3 statiske RSA-key-exchange og en række svage algoritmer — derfor giver alle TLS 1.3-forbindelser forward secrecy. Sammenligningen i detaljer: TLS 1.2 vs TLS 1.3.
| Aspekt | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Round-trips | 2 (1 ved resumption) | 1 (0 ved resumption) |
| Forward secrecy | Kun med ECDHE | Altid |
| Statisk RSA key exchange | Tilladt | Fjernet |
Se din egen handshake
Du kan inspicere en handshake live. Outputtet viser den fremforhandlede protokol og cipher:
openssl s_client -connect example.com:443 -servername example.com
Kig efter Protocol : TLSv1.3 og Cipher : TLS_AES_256_GCM_SHA384. Hvis du i stedet vil teste hvorfor en handshake fejler, har vi en dedikeret guide: "SSL handshake failed".
Hvordan CertControl holder øje med handshaken
En handshake fejler typisk af forudsigelige grunde: serveren tilbyder forældede protokoller (TLS 1.0/1.1), mangler en intermediate i kæden, eller serverer et certifikat tæt på udløb. CertControl scanner jeres endpoints udefra, fremforhandler en rigtig handshake mod hver enkelt, og rapporterer den valgte protokol og cipher, kædens fuldstændighed og dage til udløb — så I ser problemerne før jeres brugere rammer dem.
Ofte stillede spørgsmål
Hvor lang tid tager en TLS handshake?
Typisk nogle få millisekunder oven i netværkets round-trip-tid. TLS 1.2 kræver to round-trips før data kan flyde, TLS 1.3 kun ét — derfor føles TLS 1.3-forbindelser mærkbart hurtigere, især på mobile netværk med høj latens.
Hvad er forskellen på handshaken og selve krypteringen?
Handshaken er den indledende forhandling der aftaler nøgler og verificerer identitet med asymmetrisk kryptografi. Når den er færdig, krypteres selve applikationsdataen symmetrisk med de fremforhandlede session keys, hvilket er langt hurtigere.
Hvad er en session key?
En midlertidig symmetrisk nøgle der udledes under handshaken og bruges til at kryptere alt applikationsdata i forbindelsen. Den eksisterer kun for den ene session og kasseres bagefter.
Hvorfor sendes serverens certifikat i handshaken?
For at klienten kan verificere serverens identitet og hente dens offentlige nøgle. Klienten validerer certifikat-kæden op til en betroet root og tjekker at navnet matcher det domæne den forbinder til.
Hvad betyder 1-RTT i TLS 1.3?
1-RTT (one round-trip time) betyder at klient og server kun behøver én frem-og-tilbage-udveksling før krypteret applikationsdata kan sendes. TLS 1.2 krævede to. Ved genoptagne forbindelser kan TLS 1.3 endda klare 0-RTT.
Kan en handshake nedgraderes af en angriber?
Handshaken er beskyttet mod nedgraderingsangreb: Finished-beskederne indeholder en hash af hele forløbet, så enhver manipulation undervejs får hasherne til ikke at matche, og forbindelsen afbrydes.