Om du någonsin har surfat på en HTTPS-URL i en webbläsare har du upplevt SSL-handslaget. Även om du kanske inte märker det, skapar webbläsaren och webbplatsen en HTTPS-anslutning med hjälp av ett envägs SSL-handslag.
Det huvudsakliga syftet med ett SSL-handslag är att tillhandahålla sekretess och dataintegritet för kommunikation mellan en server och en klient. Under handskakningen utbyter server och klient viktig information som krävs för att upprätta en säker anslutning.
Det finns två typer av SSL-handskak som beskrivs som envägs-SSL och tvåvägs-SSL (Mutual SSL). Skillnaden mellan dessa två är att i envägs-SSL är det endast klienten som bekräftar serverns identitet, medan i tvåvägs-SSL bekräftar både server och klient varandras identitet. När vi surfar på en HTTPS-webbplats används vanligtvis envägs-SSL där endast vår webbläsare (klient) bekräftar webbplatsens (serverns) identitet. Tvåvägs-SSL används oftast i kommunikation mellan servrar där båda parter måste bekräfta varandras identitet.
Under ett SSL-handslag följer servern och klienten nedanstående steg.
1. Client Hello
Klienten skickar den information som krävs av servern för att starta en HTTPS-anslutning.
I loggen ovan kan vi se att klienten hälsar med TLS v1.2. Med detta meddelar klienten servern att den har stöd för TLS-versionerna 1.2 och lägre. Listan över chiffer som stöds av klienten kan också ses i loggen ovan. Ur denna lista väljer servern en chifferföljd som den stöder. Om listan innehåller chifferuppsättningar som servern inte känner igen, stöder eller vill använda, kommer servern att ignorera dessa chifferuppsättningar. Om inga cipher suites som stöds hittas kommer servern att skicka en felvarning och stänga anslutningen.
2. Server Hello
Servern kommer att svara tillbaka med den konfiguration som valts från Client Hello tillsammans med information för att fortsätta med handskakningen. Server Hello kommer att se ut på följande sätt:
Sever kommer att välja TLS-version enligt den lägsta av de versioner som föreslås av klienten i meddelandet Client Hello och den högsta som stöds av servern. Servern kommer också att skicka tillbaka den chifferföljd som den valt från listan över chiffer som presenterats av klienten.
Samman med Server Hello-meddelandet kommer servern också att skicka serverns certifikat med certifikatkedja. Certifikatkedjan kommer att valideras mot certifikaten i klientens förtroendelager.
3. Server Key Exchange Message
Detta meddelande kommer att skickas av servern till klienten med de uppgifter som krävs för att klienten ska kunna generera pre-master secret. Detta meddelande skickas inte om RSA-nyckelutbytesalgoritmen (mer om detta senare) eller andra nyckelutbytesalgoritmer används som inte kräver information från servern för att generera en pre-master secret.
För nyckelutbyte med Elliptic Curve Diffie Hellman (ECDH) skickas följande uppgifter om serverns offentliga ECDH-nyckel till klienten.
4. Certifikatbegäran
Det här är platsen där envägs-SSL skiljer sig från tvåvägs-SSL. I envägs-SSL valideras inte klientens äkthet. Därför utelämnas detta steg i envägs-SSL-handskakning.
Under detta steg skickar servern en certifikatbegäran från klienten med den certifikattyp, de certifikatsignaturalgoritmer och de certifikatmyndigheter som stöds av servern. Det kan finnas situationer där listan över certifikatmyndigheter kan vara tom. I sådana fall kan klienten välja att skicka eller undvika att skicka klientcertifikatet (beror på klientimplementationen)
Slutligt skickar servern meddelandet Server Hello Done som anger att Server Hello är avslutat. Efter att ha skickat detta meddelande väntar servern på ett klientsvar.
5. Klientcertifikat
Klienten presenterar sin certifikatkedja för servern. Certifikatet måste vara lämpligt för den förhandlade chifferföljans nyckelutbytesalgoritm och eventuella förhandlade tillägg.
6. Meddelande om nyckelutbyte för klienten
Detta meddelande måste skickas av klienten efter meddelandet om klientcertifikat. Om klientcertifikatet inte presenteras (i envägs-SSL) ska klientnyckelutbytesmeddelandet skickas efter det att klienten mottagit ServerHelloDone-meddelandet.
Som vi alla vet krypteras de data som överförs mellan servern och klienten i en HTTPS-anslutning. Symmetrisk kryptering används för detta ändamål eftersom beräkningskostnaden är mycket lägre än asymmetrisk kryptering. För att använda symmetrisk kryptering måste det finnas en gemensam nyckel mellan de två ändarna. Syftet med detta meddelande är att generera den gemensamma nyckeln mellan klienten och servern utan att exponera den för en utomstående.
Det finns två metoder för utbyte av klientnycklar som beskrivs i TLS v1.2-specifikationen. De är RSA och Diffie-Hellman.
Om RSA används som nyckelutbytesalgoritm genererar klienten en 48-byte pre-master secret. Klienten krypterar pre-master secret med certifikatets offentliga nyckel och skickar den till servern. Endast servern kommer att ha motsvarande privata nyckel för att dekryptera och få den klientgenererade pre-master secret.
Om Diffie-Hellman används överförs Diffie-Hellman-parametrarna så att både klienten och servern kan generera samma pre-master secret.
Därefter kommer båda sidor att generera en huvudhemlighet med hjälp av pre-master secret och huvudhemligheten kommer att användas för att generera den symmetriska nyckeln för att kryptera sessionsdata
7. Finished
Efter framgångsrik autentisering och generering av pre-master secrets/master secrets kommer ett change cipher spec-meddelande att skickas av både klient och server som anger att resten av kommunikationen kommer att krypteras.
Finished-meddelandet kommer att följa omedelbart efter change cipher spec-meddelandet. Detta kommer att vara det första meddelandet som krypteras med de förhandlade algoritmerna. Applikationsdata kommer att överföras först efter att båda parter har skickat det färdiga meddelandet och verifierat meddelandets innehåll.
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/