Wat is een SSL/TLS-handshake?

Een SSL/TLS-handshake is een onderhandeling tussen twee partijen op een netwerk – zoals een browser en een webserver – om de details van hun verbinding vast te leggen. Het bepaalt welke versie van SSL / TLS zal worden gebruikt in de sessie, welke cipher suite de communicatie zal versleutelen, verifieert de server (en soms ook de client), en stelt vast dat een beveiligde verbinding op zijn plaats is voordat gegevens worden overgedragen.

Dit gebeurt allemaal op de achtergrond, gelukkig – elke keer dat u uw browser naar een beveiligde site leidt, vindt een complexe interactie plaats om ervoor te zorgen dat uw gegevens veilig zijn.

Dat is de eenvoudige versie. U zult merken dat een dozijn beschrijvingen min of meer dit formaat volgen, terwijl ze in detail op een dozijn verschillende manieren verschillen – soms verwarrend. Zullen we een grafiek maken die een breed model laat zien van hoe een TLS-handdruk werkt?

Hebt u een certificaat nodig? SSL.com heeft het voor u. Vergelijk hier de opties om de juiste keuze voor u te vinden, van S/MIME en code signing certificaten en meer.

NU BESTELLEN

Verplichte SSL/TLS-handshake-grafiek

Alle SSL/TLS-gerelateerde sites hebben hun eigen versie van een handshake-diagram – hier is de onze! (Klik om te vergroten.)

Laten we wat verwarring wegnemen, als we kunnen

Een deel van de verwarring over hoe SSL/TLS-handshakes werken, is te wijten aan het feit dat de handshake slechts de opmaat is naar de eigenlijke, beveiligde sessie zelf. Laten we proberen enkele veel voorkomende punten te behandelen:

Asymmetrische vs symmetrische encryptie

De handshake zelf maakt gebruik van asymmetrische encryptie – er worden twee aparte sleutels gebruikt, een openbare en een privé. Omdat asymmetrische encryptie systemen veel hogere overhead hebben, zijn ze niet bruikbaar om full-time, real-world beveiliging te bieden. Daarom wordt de openbare sleutel gebruikt voor encryptie en de privé-sleutel alleen voor decryptie tijdens de handshake, waardoor de twee partijen vertrouwelijk een nieuw gecreëerde “gedeelde sleutel” kunnen opzetten en uitwisselen. De sessie zelf gebruikt deze enkele gedeelde sleutel om symmetrische encryptie uit te voeren, en dit is wat een veilige verbinding in de praktijk haalbaar maakt (de overhead is veel lager). Dus het volledige en juiste antwoord op “Is SSL/TLS encryptie asymmetrisch of symmetrisch?” is “Eerst het een, dan het ander.”

Wat is een “cipher suite”?

De handshake zelf bestaat uit meerdere fasen, die elk volgens andere regels verlopen. De details zijn hier te vinden, maar de kern van de zaak is dat in plaats van een reeks afzonderlijke heen en weer onderhandelingen (over welke sleutels te gebruiken, hoe de handdruk zelf te versleutelen, hoe de handdruk te authenticeren, enzovoort) de partijen kunnen overeenkomen een “cipher suite” te gebruiken – een reeds bestaande selectie of set van overeengekomen componenten. (Vergeet niet dat asymmetrische encryptie veel tijd en middelen kost – het gebruik van de cipher suite als een kortere weg versnelt de handshake zelf). TLS specificaties staan een behoorlijk aantal cipher suites toe, en de client en server zullen bijna altijd toegang hebben tot een die ze beiden kunnen gebruiken.

Basic vs mutually-authenticated handshake

Een ander verwarrend punt is dat het basismodel dat we hierboven beschreven de client de server laat verifiëren, en de overgrote meerderheid van sessies beveiligd door TLS heeft dit alleen nodig. Echter, sommige cipher suites vereisen dat de client ook een certificaat en publieke sleutel stuurt voor wederzijdse authenticatie van beide partijen. Deze twee-weg authenticatie voegt natuurlijk overhead toe aan de handshake – maar in sommige gevallen (bijvoorbeeld wanneer twee banken onderhandelen over een beveiligde verbinding voor geldoverdrachten) zal de cipher suite hierop aandringen, en wordt de extra veiligheid de moeite waard geacht.

Verschillende sessies zullen verschillende beveiligingsparameters hebben

Elke nieuwe handshake creëert een nieuwe sessie, en de instellingen die in de ene worden gebruikt kunnen drastisch verschillen van de andere, afhankelijk van de gekozen cipher suite. Dit is een van de redenen waarom er zoveel verschillende iteraties van die verdomde handshake tabel bestaan, en waarom we hier een vrij breed overzicht geven. Weet ook dat sessies parameters kunnen instellen die misschien niet precies zijn wat je verwacht. Afhankelijk van de cipher suite, kunnen sommige stappen toegevoegd zijn (zoals de vereiste voor twee-weg authenticatie) of afwezig. Er zijn zelfs cipher suites die onderhandelen over een sessie zonder enige vorm van encryptie. (Ja, we weten het, een HTTPS-verbinding over poort 443 die besluit om gegevens in het vrije veld te verzenden is voor ons ook niet logisch. SSL.com raadt u ten sterkste aan dit niet te doen – wees u er alleen van bewust dat het in het rijk van het mogelijke ligt.)

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.