SSL Techniek

Dit artikel beschrijft de encryptieprotocollen SSL en TLS en de TLS Handshake die nodig zijn voor het opzetten van een HTTPS-verbinding.

SSL en TLS

De encryptieprotocollen Secure Sockets Layer (SSL) en de opvolger Transport Layer Security (TLS) beveiligen de communicatie op het internet door het versleutelen van HTTP-verkeer. SSL is oorspronkelijk ontwikkeld door Netscape, en is na een aantal verbeteringen geëvolueerd tot SSL v3, waaraan extra beveiliging tegen het afluisteren en vervalsen van berichten is toegevoegd. SSL v3 kan ook gezien worden als TLS 1.0. Alhoewel SSL de meest gebruikte term is, worden de termen SSL en TLS vaak als uitwisselbaar gebruikt. De protocollen zorgen voor:

Authenticatie van de server (bijvoorbeeld de server van een webshop) en optioneel de client (bijvoorbeeld de browser van bezoeker) met behulp van een SSL certificaat. Hierbij wordt gebruik gemaakt van asymmetrische encryptie.
Het waarborgen van privacy door het versleutelen van de uitgewisselde gegevens, op basis van een wisselende, symmetrische sleutel. De uitgewisselde gegevens zijn hierdoor niet door derden in te zien.
Het garanderen van integriteit; zodra er gegevens wijzigen wordt de verbinding verbroken.

Alle SSL protocollen zijn inmiddels verouderd en niet meer veilig, het advies is deze uit te schakelen op de webserver.

TLS Handshake Procedure

Het opzetten van een TLS-verbinding verloopt in een aantal stappen. In de meeste gevallen neemt de hele procedure niet meer dan een seconde in beslag.

Wanneer de client en server hebben besloten om de TLS-verbinding te gebruiken (vaak wordt hiervoor poort 443 voor HTTPS gebruikt) wordt de verbinding verder tot stand gebracht door middel van een 'handshake' procedure. Tijdens deze handshake gaan de client en de server akkoord met verschillende parameters om een veilige verbinding tot stand te laten komen:

Voordat de SSL verbinding opgezet wordt wisselen de client en de server gegevens uit, bijvoorbeeld het sterkste algoritme en het meest recente SSL/TLS protocol, dat zij beiden ondersteunen.
De server stuurt een bewijs van zijn identiteit in de vorm van een digitaal certificaat (de public key van het certificaat), wat de client controleert op geldigheid. Zo weet de client zeker met wie hij communiceert. In het geval van tweezijdig SSL vraagt de server op zijn beurt ook een digitaal certificaat aan de client, zodat zowel server als client weten met wie zij communiceren.
De client maakt gebruik van informatie die door de server is aangeleverd om de server te verifiëren. Als de server niet kan worden geverifieerd, dan wordt de gebruiker gewaarschuwd dat er geen versleutelde verbinding tot stand kan worden gebracht. Pas als de server met succes kan worden geverifieerd, zal de client overgaan tot de volgende stap.
De client versleutelt een willekeurig getal met de public key van het certificaat dat hij in stap 2 van de server heeft gekregen; dit wordt een zogenaamd sessie-specifiek pre-master secret. De client stuurt deze naar de server, die het pre-master secret als enige kan ontcijferen omdat hij beschikt over de private key van het gebruikte certificaat. Omdat alleen de twee genoemde partijen toegang hebben tot de gebruikte sleutels, kan misbruik door derden worden uitgesloten.
Als de server client-authenticatie heeft verzocht (in het geval van tweezijdig SSL; een optionele stap in de handshake), dan zal de client een ander uniek stuk data ondertekenen. Deze data is uniek voor deze handshake en is bekend bij zowel de client als de server. In dit geval verzendt de client de ondertekende data, het eigen certificaat van de client en het versleutelde pre-master secret aan de server.
Als de client niet kan worden geverifieerd, dan wordt de sessie afgesloten. Als de client met succes kan worden geverifieerd, dan zal de server zijn private key gebruiken voor het decoderen van het pre-master secret. Vervolgens voeren zowel de client als de server een reeks stappen uit om een master secret te genereren op basis van het pre-master secret.
Zowel de client als de server gebruiken het master secret om sessiesleutels te genereren. Dit zijn symmetrische sleutels die gebruikt worden voor het coderen en decoderen van informatie die uitgewisseld wordt tijdens de SSL-sessie en om integriteit te controleren (dat is om eventuele wijzigingen in de gegevens te detecteren tussen het verzenden en ontvangen van de data over de SSL-verbinding).
De client stuurt een bericht naar de server. Hierin wordt meegedeeld dat toekomstige berichten van de client worden versleuteld met de sessiesleutel. Vervolgens verzendt de client een apart versleuteld bericht dat aangeeft dat het client-onderdeel van de handshake is voltooid.
De server stuurt een bericht naar de client. Hierin wordt meegedeeld dat toekomstige berichten van de server worden versleuteld met de sessiesleutel. Vervolgens verzendt de server een apart versleuteld bericht dat aangeeft dat het serveronderdeel van de handshake is voltooid.

De SSL handshake is nu voltooid en de sessie begint. De client en de server gebruiken nu de sessiesleutels om gegevens te versleutelen, ontsleutelen en de integriteit te controleren. Voor iedere sessie (zoals het bezoeken van website) wordt het handshake proces opnieuw uitgevoerd en worden er nieuwe sleutels gebruikt.

Historie

Bij het opzetten van een veilige verbinding onderhandelen de client en server tijdens de handshake over een gemeenschappelijk protocol ter beveiliging van het kanaal. Er zijn verschillende versies van SSL en TLS ontwikkeld; de meest recente versie is TLS 1.3.

SSL 1.0, 2.0 en 3.0

De eerste SSL 1.0 technologie is ontwikkeld door Netscape in 1994. Door ernstige beveiligingsproblemen is deze versie echter nooit gepubliceerd. In 1995 heeft Netscape SSL 2.0 gepubliceerd. De kwetsbaarheden van de vorige versie zijn hierin verbeterd, maar SSL 2.0 had nog steeds een aantal cryptografische zwakheden. Wederom door Netscape is in 1996 SSL 3.0 gepubliceerd, ontwikkeld door Paul Kocher. In deze versie werd het protocol volledig herschreven en alle beveiligingszwakheden hersteld. In 2014 is in SSL 3.0 wederom een ernstige zwakheid ontdekt.

PCT 1.0

Private Communications Technology (PCT) 1.0 is een protocol ontwikkeld door Microsoft in de jaren '90. PCT is ontworpen om beveiligingsfouten in Netscape's SSL 2.0 aan te pakken en Netscape te dwingen het eigendomsrecht en controle van het SSL protocol om te zetten naar een open standaard. PCT is inmiddels een achterhaald protocol en vervangen door SSLv3 en TLS. PCT werd tijdelijk nog ondersteund door Internet Explorer, maar de nieuwste versies ondersteunen PCT niet meer. Het PCT protocol staat nog steeds in IIS en de system library van Windows operating systems maar is standaard uitgeschakeld.

TLS 1.0

TLS 1.0 is in januari 1999 ontwikkeld als een upgrade van SSL 3.0 (beschreven in RFC 2246). Ondanks dat er geen grote verschillen zijn tussen TLS 1.0 en SSL 3.0, konden de protocollen niet samenwerken. Daarnaast was het met TLS 1.0 mogelijk een SSL 3.0 verbinding op te zetten, wat de beveiliging verzwakte. In 2011 is deze versie door Thai Duong en Juliano Rizzo gekraakt waarmee deze versie als veilig protocol onbruikbaar is geworden.

TLS 1.1

TLS 1.1 is in april 2006 gepubliceerd (beschreven in RFC4346). TLS 1.1 is een update en doorontwikkeling op versie 1.0. Deze versie biedt verschillende verbeteringen, zoals verbeterde beveiliging en afhandeling van errors. Ondanks de verbeterde functionaliteit wordt deze versie nog nauwelijks gebruikt.

TLS 1.2

TLS 1.2 is in augustus 2008 gepubliceerd (beschreven in RFC5246). TLS 1.2 is een doorontwikkeling van versie 1.1 met een aantal aanzienlijke verbeteringen waaronder:

Gebruikte cryptografische hashes, die onveilig zijn gebleken, zijn vervangen door SHA-256.
Verbeterde ondersteuning voor modernere encryptiemethoden uit de Advanced Encryption Standard.
Fallback compatibiliteit met het onveilige SSL 2.0 verwijderd.

TLS 1.3

De ontwikkeling van TLS 1.3 is in maart 2018 voltooid en op 10 augustus 2018 is de Request for Change gepubliceerd. De browsers Chrome en Firefox ondersteunen het protocol vanaf respectievelijk versie 56 en 52. In januari 2021 heeft het Nationaal Cyber Security Centrum haar advies aangepast naar 1.3, waarbij de status van 1.2 naar beneden is bijgesteld van goed naar voldoende. TLS 1.3 is beter bestand tegen (toekomstige) aanvalstechnieken en is bovendien gemakkelijker veilig te configureren dan haar voorganger TLS 1.2, en de meeste softwarebibliotheken ondersteunen het protocol inmiddels.

TLS 1.3 is een doorontwikkeling van versie 1.2 met een aantal belangrijke verbeteringen, waaronder:

Verhoogde snelheid, vergeleken met de vorige versie is er alleen één round-trip vereist.
Verbeterde beveiliging, verouderde en onveilige functies zoals SHA1 en MD5 zijn verwijderd.