Hvis du nogensinde har surfet på en HTTPS-URL via en browser, har du oplevet SSL-handshake. Selv om du måske ikke bemærker det, opretter browseren og webstedet en HTTPS-forbindelse ved hjælp af envejs SSL-håndshake.
Det vigtigste formål med et SSL-håndshake er at sikre privatlivets fred og dataintegritet for kommunikation mellem en server og en klient. Under håndslaget udveksler server og klient vigtige oplysninger, der er nødvendige for at etablere en sikker forbindelse.
Der findes to typer SSL-håndslag, der beskrives som envejs SSL og tovejs SSL (Mutual SSL). Forskellen mellem de to er, at i envejs-SSL er det kun klienten, der validerer serverens identitet, mens det i tovejs-SSL er både server og klient, der validerer hinandens identitet. Når vi surfer på et HTTPS-websted, anvendes der normalt envejs-SSL, hvor kun vores browser (klient) validerer webstedets (serverens) identitet. Tovejs-SSL bruges mest i server til server-kommunikation, hvor begge parter skal validere hinandens identitet.
Ved et SSL-håndshake følger serveren og klienten nedenstående trin.
1. Client Hello
Klienten sender de oplysninger, som serveren skal bruge for at starte en HTTPS-forbindelse.
I ovenstående log kan vi se, at klienten hello med TLS v1.2. Hermed meddeler klienten serveren, at den har understøttelse af TLS-versioner 1.2 og lavere. Listen over ciphers, der understøttes af klienten, kan også ses af ovenstående log. Ud fra denne liste vil serveren vælge en cipher suite, som den understøtter. Hvis listen indeholder cipher suites, som serveren ikke genkender, understøtter eller ønsker at bruge, vil serveren ignorere disse ciphers. Hvis der ikke findes nogen understøttede cipher suites, sender serveren en fejlmeddelelse og lukker forbindelsen.
2. Server Hello
Serveren svarer tilbage med den konfiguration, den har valgt fra Client Hello, sammen med sine oplysninger for at fortsætte med håndslaget. Server Hello vil være som følger:
Sever vil vælge TLS-versionen i henhold til den laveste af den, der er foreslået af klienten i Client Hello-meddelelsen, og den højeste, der understøttes af serveren. Serveren sender også den cipher suite tilbage, som den har valgt fra den liste over ciphers, som klienten har præsenteret.
Sammen med Server Hello-meddelelsen sender serveren også serverens certifikat med certifikatkæden. Certifikatkæden vil blive valideret i forhold til certifikaterne i klientens truststore.
3. Server Key Exchange Message
Denne meddelelse sendes af serveren til klienten med de nødvendige oplysninger, så klienten kan generere pre-master secret. Denne meddelelse sendes ikke, hvis der anvendes RSA-nøgleudvekslingsalgoritme (mere herom senere) eller andre nøgleudvekslingsalgoritmer, som ikke kræver oplysninger fra serveren til at generere en pre-masterhemmelighed.
For Elliptic Curve Diffie Hellman(ECDH)-nøgleudveksling sendes følgende oplysninger om serverens offentlige ECDH-nøgle til klienten.
4. Certifikatanmodning
Dette er det sted, hvor envejs-SSL afviger fra tovejs-SSL. I envejs-SSL bliver klientens autenticitet ikke valideret. Derfor udelades dette trin i envejs SSL-håndtryk.
I dette trin sender serveren en certifikatanmodning fra klienten med den certifikattype, certifikatsignaturalgoritmer og certifikatmyndigheder, der understøttes af serveren. Der kan være situationer, hvor listen over certifikatmyndigheder kan være tom. I sådanne scenarier kan klienten vælge, om den vil sende eller undgå at sende klientcertifikatet (afhænger af klientimplementeringen)
Sidst sender serveren Server Hello Done-meddelelsen, der angiver, at Server Hello er afsluttet. Når denne meddelelse er sendt, venter serveren på et klientsvar.
5. Klientcertifikat
Klienten præsenterer sin certifikatkæde for serveren. Certifikatet skal være passende for den forhandlede cipher-suites nøgleudvekslingsalgoritme og eventuelle forhandlede udvidelser.
6. Client Key Exchange Message
Denne meddelelse skal sendes af klienten efter Client Certificate-meddelelsen. Hvis klientcertifikatet ikke præsenteres (i envejs-SSL), skal klientnøgleudvekslingsmeddelelsen sendes, efter at klienten har modtaget ServerHelloDone-meddelelsen.
Som vi alle ved, vil de data, der overføres mellem serveren og klienten i en HTTPS-forbindelse, blive krypteret. Der anvendes symmetrisk kryptering til dette formål, da beregningsomkostningerne er meget lavere end asymmetrisk kryptering. For at kunne anvende symmetrisk kryptering skal der være en fælles nøgle mellem de to ender. Formålet med denne meddelelse er at generere denne fælles nøgle mellem klienten og serveren uden at eksponere den for en udenforstående.
Der er to metoder til udveksling af klientnøgler, der er beskrevet i TLS v1.2-specifikationen. De er RSA og Diffie-Hellman.
Hvis RSA anvendes som nøgleudvekslingsalgoritme, genererer klienten en 48-byte pre-master secret. Klienten krypterer præ-masterhemmeligheden med den offentlige nøgle i certifikatet og sender den til serveren. Kun serveren vil have den tilsvarende private nøgle til at dekryptere og få den klientgenererede pre-master secret.
Hvis Diffie-Hellman anvendes, overføres Diffie-Hellman-parametrene for at give både klient og server mulighed for at generere den samme pre-master secret.
Dernæst vil begge sider generere en master secret ved hjælp af pre-master secret, og master secret vil blive anvendt til at generere den symmetriske nøgle til kryptering af sessionsdataene
7. Færdig
Efter vellykket autentifikation og generering af pre-master secrets/master secrets sendes en change cipher spec-meddelelse af både klient og server, der angiver, at resten af kommunikationen vil blive krypteret.
Den færdige meddelelse følger umiddelbart efter change cipher spec-meddelelsen. Dette vil være den første meddelelse, der krypteres med de forhandlede algoritmer. Applikationsdata vil kun blive overført, efter at begge parter har sendt den færdige meddelelse og verificeret indholdet af meddelelsen.
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/