Pokud jste někdy procházeli HTTPS URL prostřednictvím prohlížeče, setkali jste se s SSL handshake. I když si toho možná nevšimnete, prohlížeč a webová stránka vytvářejí spojení HTTPS pomocí jednosměrného předání SSL.
Hlavním účelem předání SSL je zajistit soukromí a integritu dat při komunikaci mezi serverem a klientem. Během handshake si server a klient vymění důležité informace potřebné k navázání zabezpečeného spojení.
Existují dva typy SSL handshake popsané jako jednosměrný SSL a obousměrný SSL (Mutual SSL). Rozdíl mezi nimi spočívá v tom, že při jednosměrném SSL ověřuje totožnost serveru pouze klient, zatímco při obousměrném SSL si server i klient ověřují totožnost navzájem. Při prohlížení webových stránek HTTPS se obvykle používá jednosměrný protokol SSL, kdy identitu webové stránky (serveru) ověřuje pouze náš prohlížeč (klient). Obousměrný protokol SSL se většinou používá při komunikaci mezi serverem a serverem, kdy si obě strany musí navzájem ověřit totožnost.
Při předávání protokolu SSL postupují server a klient podle níže uvedeného souboru kroků.
1. Obousměrný protokol SSL se většinou používá při komunikaci mezi serverem a serverem, kdy si obě strany musí navzájem ověřit totožnost. Client Hello
Klient odešle informace, které bude server vyžadovat pro zahájení spojení HTTPS.
V uvedeném protokolu vidíme, že klient se pozdravil pomocí protokolu TLS v1.2. Tím klient oznamuje serveru, že má podporu pro TLS verze 1.2 a nižší. Z výše uvedeného protokolu je rovněž patrný seznam šifer, které klient podporuje. Z tohoto seznamu server vybere sadu šifer, kterou podporuje. Pokud seznam obsahuje sady šifer, které server nerozpoznává, nepodporuje nebo nechce používat, bude tyto šifry ignorovat. Pokud nebyly nalezeny žádné podporované sady šifer, server odešle upozornění na selhání a ukončí spojení.
2. Server Hello
Server odpoví zpět konfigurací, kterou vybral z Client Hello, spolu s jejími informacemi pro pokračování v handshake. Server Hello bude vypadat následovně.
Server vybere verzi TLS podle nižší z verzí navržených klientem ve zprávě Client Hello a nejvyšší podporované serverem. Server také odešle zpět sadu šifer, kterou vybral ze seznamu šifer předloženého klientem.
Společně se zprávou Server Hello odešle server také certifikát serveru s řetězcem certifikátů. Řetězec certifikátů bude ověřen proti certifikátům v klientském úložišti důvěryhodnosti.
3. Zpráva o výměně klíčů serveru
Tuto zprávu odešle server klientovi s údaji potřebnými pro klienta k vygenerování předřazeného tajemství. Tato zpráva nebude odeslána, pokud je použit algoritmus výměny klíčů RSA (více o tom později) nebo jiné algoritmy výměny klíčů, které nevyžadují informace od serveru pro vygenerování předřazeného tajemství.
Při výměně klíče pomocí eliptických křivek Diffie Hellman(ECDH) se klientovi posílají následující údaje o veřejném klíči ECDH serveru.
4. Žádost o certifikát
Tady se jednosměrné SSL odklání od obousměrného SSL. Při jednosměrném SSL se neověřuje pravost klienta. Proto je tento krok v jednosměrném předávání SSL vynechán.
V tomto kroku server odešle žádost o certifikát od klienta s typem certifikátu, algoritmy podpisu certifikátu a certifikačními autoritami podporovanými serverem. Mohou nastat situace, kdy může být seznam certifikačních autorit prázdný. V takových scénářích se klient může rozhodnout, zda chce odeslat klientský certifikát, nebo zda se odeslání vyhne (závisí na implementaci klienta)
Nakonec server odešle zprávu Server Hello Done, která označuje konec Server Hello. Po odeslání této zprávy server vyčká na odpověď klienta.
5. Po odeslání této zprávy bude server čekat na odpověď klienta. Klientský certifikát
Klient předloží serveru svůj řetězec certifikátů. Certifikát musí být vhodný pro vyjednaný algoritmus výměny klíčů šifrové sady a případná vyjednaná rozšíření.
6. Client Key Exchange Message
Tuto zprávu musí klient odeslat po zprávě Client Certificate. Pokud se klientský certifikát nepředkládá (v jednosměrném protokolu SSL), měla by být zpráva o výměně klientského klíče odeslána po přijetí zprávy ServerHelloDone.
Jak všichni víme, data přenášená mezi serverem a klientem ve spojení HTTPS budou šifrována. Pro tento účel se používá symetrické šifrování, protože výpočetní náklady jsou mnohem nižší než u asymetrického šifrování. Aby bylo možné použít symetrické šifrování, musí být mezi oběma konci společný klíč. Účelem této zprávy je vygenerovat tento společný klíč mezi daným klientem a serverem, aniž by byl vystaven cizí osobě.
Ve specifikaci TLS v1.2 jsou popsány dvě metody výměny klientského klíče. Jsou to RSA a Diffie-Hellman.
Pokud je jako algoritmus výměny klíče použit RSA, klient generuje 48bajtový předřazený tajný klíč. Klient zašifruje pre-master secret veřejným klíčem certifikátu a odešle jej serveru. Pouze server bude mít odpovídající soukromý klíč k dešifrování a získání klientem vygenerovaného předřazeného tajemství.
Pokud je použit Diffie-Hellman, jsou předány parametry Diffie-Hellman, aby klient i server mohli vygenerovat stejné předřazené tajemství.
Poté obě strany vygenerují hlavní tajemství pomocí předřazeného tajemství a hlavní tajemství bude použito k vygenerování symetrického klíče pro šifrování dat relace
7. V případě, že je použit Diffie-Hellman, jsou předány parametry Diffie-Hellman. Finished
Po úspěšném ověření a vygenerování pre-master secrets/master secre bude klientem i serverem odeslána zpráva change cipher spec, ve které bude uvedeno, že zbytek komunikace bude šifrován.
Zpráva Finished bude následovat ihned po zprávě change cipher spec. Bude to první zpráva zašifrovaná vyjednanými algoritmy. Aplikační data budou přenesena až poté, co obě strany odešlou zprávu finished a ověří obsah zprávy.
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/