Ha valaha is böngészett már egy HTTPS URL-címet a böngészőn keresztül, akkor már megtapasztalta az SSL handshake-et. Még ha talán észre sem veszi, a böngésző és a webhely egyirányú SSL-kézfogással hoz létre HTTPS-kapcsolatot.
Az SSL-kézfogás fő célja, hogy a kiszolgáló és az ügyfél közötti kommunikáció során adatvédelmet és adatintegritást biztosítson. A kézfogás során a kiszolgáló és az ügyfél kicseréli a biztonságos kapcsolat létrehozásához szükséges fontos információkat.
Az SSL kézfogásnak két típusa van, amelyeket egyirányú SSL és kétirányú SSL (Mutual SSL) néven írnak le. A különbség a kettő között az, hogy az egyirányú SSL-ben csak az ügyfél érvényesíti a kiszolgáló személyazonosságát, míg a kétirányú SSL-ben a kiszolgáló és az ügyfél is érvényesíti egymás személyazonosságát. Általában, amikor egy HTTPS weboldalon böngészünk, egyirányú SSL-t használunk, ahol csak a böngészőnk (ügyfél) érvényesíti a weboldal (kiszolgáló) személyazonosságát. A kétirányú SSL-t leginkább a szerver-kiszolgáló kommunikációban használják, ahol mindkét félnek igazolnia kell egymás személyazonosságát.
Az SSL kézfogás során a szerver és az ügyfél az alábbi lépéseket követi.
1. Client Hello
A kliens elküldi azokat az információkat, amelyekre a kiszolgálónak szüksége van a HTTPS-kapcsolat elindításához.
A fenti naplóban láthatjuk, hogy a kliens TLS v1.2-vel üdvözli a klienst. Ezzel a kliens értesíti a kiszolgálót, hogy támogatja a TLS 1.2-es és az alatti verziókat. Az ügyfél által támogatott titkosítások listája szintén látható a fenti naplóból. Ebből a listából a kiszolgáló kiválasztja az általa támogatott titkosírási csomagot. Ha a lista olyan titkosírási készleteket tartalmaz, amelyeket a kiszolgáló nem ismer, nem támogat, vagy nem kíván használni, akkor a kiszolgáló figyelmen kívül hagyja ezeket a titkosírási készleteket. Ha nem talált támogatott titkosírási készletet, a kiszolgáló hibajelzést küld, és lezárja a kapcsolatot.
2. Server Hello
A kiszolgáló a Client Hello során kiválasztott konfigurációval és a kézfogás folytatásához szükséges információkkal együtt válaszol vissza. A Server Hello a következőképpen alakul.
A kliens által a Client Hello üzenetben javasolt és a kiszolgáló által támogatott legmagasabb TLS-verzió közül az alacsonyabbiknak megfelelően választja ki a TLS-verziót. A kiszolgáló szintén visszaküldi az általa az ügyfél által bemutatott kódkészlet listájából kiválasztott kódkészletet.
A Server Hello üzenettel együtt a kiszolgáló elküldi a kiszolgáló tanúsítványát is a tanúsítványlánccal együtt. A tanúsítványláncot az ügyfél bizalmi tárolójában lévő tanúsítványokkal összevetve ellenőrzi.
3. Szerver kulcscsere üzenet
Ezt az üzenetet a kiszolgáló küldi el az ügyfélnek, amely tartalmazza a szükséges adatokat az ügyfél számára az előzetes mestertitok létrehozásához. Ez az üzenet nem kerül elküldésre, ha RSA kulcscsere-algoritmust (erről később) vagy bármely más olyan kulcscsere-algoritmust használnak, amely nem igényel információt a kiszolgálótól az előmester-titok létrehozásához.
Elliptic Curve Diffie Hellman(ECDH) kulcscsere esetén a szerver ECDH nyilvános kulcsának következő adatait küldi az ügyfélnek.
4. Tanúsítványkérés
Ez az a hely, ahol az egyirányú SSL eltér a kétirányú SSL-től. Az egyirányú SSL-ben az ügyfél hitelességét nem ellenőrzik. Ezért ez a lépés az egyirányú SSL kézfogásnál elmarad.
Ez a lépés során a kiszolgáló tanúsítványkérést küld az ügyféltől a kiszolgáló által támogatott tanúsítványtípussal, tanúsítvány-aláírási algoritmusokkal és tanúsító hatóságokkal. Előfordulhatnak olyan helyzetek, amikor a tanúsítványhivatalok listája üres lehet. Ilyen esetekben az ügyfél eldöntheti, hogy elküldi vagy nem küldi el az ügyféltanúsítványt (az ügyfél implementációjától függ)
Végül a kiszolgáló elküldi a Server Hello Done üzenetet, amely a Server Hello befejezését jelzi. Ezen üzenet elküldése után a kiszolgáló megvárja az ügyfél válaszát.
5. Ügyféltanúsítvány
A kliens bemutatja a tanúsítványláncát a kiszolgálónak. A tanúsítványnak megfelelőnek kell lennie a kialkudott titkosítási csomag kulcscsere-algoritmusához és az esetleges kialkudott kiterjesztésekhez.
6. Client Key Exchange Message
Ezt az üzenetet a kliensnek a Client Certificate üzenetet követően kell elküldenie. Ha az ügyféltanúsítványt nem mutatják be (egyirányú SSL esetén), az ügyfélkulcscsere-üzenetet azt követően kell elküldeni, hogy az ügyfél megkapta a ServerHelloDone üzenetet.
Mint tudjuk, a HTTPS-kapcsolatban a szerver és az ügyfél között átadott adatok titkosítva lesznek. Erre a célra szimmetrikus titkosítást használnak, mivel a számítási költsége sokkal alacsonyabb, mint az aszimmetrikus titkosításé. A szimmetrikus titkosítás használatához a két végpont között közös kulcsra van szükség. Ennek az üzenetnek az a célja, hogy létrehozza ezt a közös kulcsot az adott ügyfél és a kiszolgáló között anélkül, hogy egy kívülálló számára felfedné.
A TLS v1.2 specifikációban két ügyfélkulcscsere-módszer van leírva. Ezek az RSA és a Diffie-Hellman.
Ha kulcscsere algoritmusként az RSA-t használják, az ügyfél egy 48 bájtos pre-master titkot generál. Az ügyfél a tanúsítvány nyilvános kulcsával titkosítja az előmester-titkot, és elküldi a kiszolgálónak. Csak a kiszolgáló rendelkezik a megfelelő magánkulccsal, hogy visszafejtse és megkapja az ügyfél által generált pre-mastertitkot.
Diffie-Hellman használata esetén a Diffie-Hellman paraméterek továbbításra kerülnek, hogy az ügyfél és a kiszolgáló ugyanazt a pre-mastertitkot tudja generálni.
Ezután mindkét fél az pre-mastertitok felhasználásával létrehoz egy master-titkot, és a master-titkot használják a munkamenetadatok titkosításához szükséges szimmetrikus kulcs generálására
7. Finished
A sikeres hitelesítés és a pre-mastertitkok/mastertitkok generálása után mind az ügyfél, mind a kiszolgáló elküld egy change cipher spec üzenetet, amely jelzi, hogy a kommunikáció további része titkosítva lesz.
A Finished üzenet közvetlenül a change cipher spec üzenetet követi. Ez lesz az első olyan üzenet, amelyet a kialkudott algoritmusokkal titkosítottak. Az alkalmazási adatok csak azután kerülnek átvitelre, hogy mindkét fél elküldte a kész üzenetet és ellenőrizte az üzenet tartalmát.
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/