Als u ooit via een browser een HTTPS-URL hebt bezocht, hebt u de SSL-handshake ervaren. Ook al merkt u het misschien niet, de browser en de website maken een HTTPS-verbinding met behulp van een eenrichtings-SSL-handshake.
Het belangrijkste doel van een SSL-handshake is om privacy en gegevensintegriteit te bieden voor de communicatie tussen een server en een client. Tijdens de handshake wisselen server en client belangrijke informatie uit die nodig is om een beveiligde verbinding tot stand te brengen.
Er zijn twee soorten SSL-handshakes beschreven als eenrichtings-SSL en tweerichtings-SSL (Mutual SSL). Het verschil tussen deze twee is dat in eenrichtingsservices SSL alleen de client de identiteit van de server valideert, terwijl in tweerichtingsservices SSL zowel de server als de client de identiteit van elkaar valideren. Gewoonlijk, wanneer we een HTTPS website bezoeken, wordt eenrichtings SSL gebruikt waar enkel onze browser (client) de identiteit van de website (server) valideert. Tweeweg-SSL wordt meestal gebruikt in server-naar-server-communicatie waarbij beide partijen de identiteit van elkaar moeten valideren.
Tijdens een SSL-handshake volgen de server en de client de onderstaande reeks stappen.
1. Client Hello
De client stuurt de informatie die de server nodig heeft om een HTTPS-verbinding op te starten.
In het bovenstaande logboek kunnen we zien dat de client hello met TLS v1.2. Hiermee laat de client aan de server weten dat hij ondersteuning heeft voor TLS versies 1.2 en lager. De lijst van ciphers die door de client worden ondersteund kan ook worden gezien in het bovenstaande log. Uit deze lijst zal de server een cipher suite kiezen die hij ondersteunt. Indien de lijst cijfersuites bevat die de server niet herkent, ondersteunt of wenst te gebruiken, zal de server deze cijfers negeren. Indien geen ondersteunde cipher suites zijn gevonden zal de server een failure alert sturen en de verbinding sluiten.
2. Server Hello
De server zal terug antwoorden met de configuratie die hij geselecteerd heeft van de Client Hello samen met de informatie om verder te gaan met de handshake. Server Hello ziet er als volgt uit.
De server selecteert de TLS-versie op basis van de laagste van de door de client in het Client Hello-bericht voorgestelde versie en de hoogste die door de server wordt ondersteund. De server stuurt ook de cipher suite terug die hij heeft geselecteerd uit de lijst met ciphers die door de client zijn voorgesteld.
Gelijktijdig met het Server Hello-bericht stuurt de server ook het certificaat van de server met de certificaatketen. De certificaatketen wordt gevalideerd aan de hand van de certificaten in de vertrouwensopslag van de client.
3. Bericht van de server over uitwisseling van sleutels
Dit bericht wordt door de server naar de client gezonden en bevat de vereiste gegevens voor de client om het pre-master secret te genereren. Dit bericht wordt niet verzonden als het RSA sleuteluitwisselingsalgoritme (waarover later meer) of een ander sleuteluitwisselingsalgoritme wordt gebruikt dat geen informatie van de server nodig heeft om een pre-master secret te genereren.
Voor Elliptic Curve Diffie Hellman(ECDH)-sleuteluitwisseling worden de volgende gegevens over de openbare ECDH-sleutel van de server naar de client verzonden.
4. Certificaataanvraag
Dit is de plaats waar eenrichtings-SSL afwijkt van tweerichtings-SSL. In eenrichtings-SSL wordt de authenticiteit van de klant niet gevalideerd. Daarom wordt deze stap weggelaten in eenrichtings-SSL-handshake.
Tijdens deze stap stuurt de server een certificaatverzoek van de client met het certificaattype, de certificaatondertekeningsalgoritmen en de certificaatautoriteiten die door de server worden ondersteund. Er kunnen zich situaties voordoen waarin de lijst met certificaatautoriteiten leeg is. In dergelijke scenario’s kan de client ervoor kiezen het clientcertificaat wel of niet te verzenden (hangt af van de clientimplementatie)
Tot slot stuurt de server het bericht Server Hello Done, waarmee het einde van Server Hello wordt aangegeven. Na verzending van dit bericht wacht de server op een reactie van de client.
5. Client Certificate
De client presenteert zijn certificaatketen aan de server. Het certificaat moet geschikt zijn voor het sleuteluitwisselingsalgoritme van de overeengekomen cipher suite en eventuele overeengekomen uitbreidingen.
6. Client Key Exchange Message
Dit bericht moet door de client worden verzonden na het Client Certificate-bericht. Als het cliëntcertificaat niet wordt gepresenteerd (bij eenrichtings-SL), moet het bericht over de uitwisseling van cliëntsleutels worden verzonden nadat de cliënt het bericht ServerHelloDone heeft ontvangen.
Zoals bekend worden de gegevens die in een HTTPS-verbinding tussen de server en de cliënt worden overgedragen, versleuteld. Hiervoor wordt symmetrische versleuteling gebruikt, omdat de rekenkosten veel lager zijn dan bij asymmetrische versleuteling. Om symmetrische versleuteling te gebruiken, moet er een gemeenschappelijke sleutel zijn tussen de twee uiteinden. Het doel van dit bericht is om die gemeenschappelijke sleutel tussen die cliënt en de server te genereren zonder deze aan een buitenstaander bloot te stellen.
Er zijn twee cliënt-sleuteluitwisselingsmethoden beschreven in de TLS v1.2 spec. Het zijn RSA en Diffie-Hellman.
Als RSA wordt gebruikt als het sleuteluitwisselingsalgoritme, genereert de client een 48-byte pre-master secret. De client versleutelt het pre-master secret met de openbare sleutel van het certificaat en zendt het naar de server. Alleen de server heeft de corresponderende privé-sleutel om het door de client gegenereerde pre-master secret te ontcijferen en te verkrijgen.
Als Diffie-Hellman wordt gebruikt, worden de Diffie-Hellman parameters doorgegeven om zowel client als server in staat te stellen hetzelfde pre-master secret te genereren.
Daarna genereren beide zijden een master secret met behulp van het pre-master secret en het master secret wordt gebruikt om de symmetrische sleutel te genereren voor het versleutelen van de sessiegegevens
7. Voltooid
Na succesvolle authenticatie en het genereren van de pre-master geheimen/master geheimen, zal een change cipher spec bericht worden verzonden door zowel client als server dat aangeeft dat de rest van de communicatie zal worden versleuteld.
Het Voltooid bericht zal onmiddellijk volgen op het change cipher spec bericht. Dit zal het eerste bericht zijn dat met de overeengekomen algoritmen wordt versleuteld. Toepassingsgegevens worden pas overgedragen nadat beide partijen het bericht Voltooid hebben verzonden en de inhoud van het bericht hebben geverifieerd.
https://tools.ietf.org/html/rfc5246
https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel
https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https
https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
https://www.globalsign.com/en/ssl-information-center/what-are-certification-authorities-trust-hierarchies/
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/