Strângerea de mână TLS 1.3 funcționează după cum urmează:
Clientul va trimite o structură de date „ClientHello” către server. În această etapă, clientul nu știe încă ce „Grupuri” suportă serverul. Pentru a evita o călătorie suplimentară dus-întors la server, poate conține în mod speculativ un „element de grup” pentru grupul pe care ar prefera să-l folosească. În cazul întrebat, elementul de grup este o cheie publică de 32 de octeți pentru utilizare cu „Grupul 29” (29 == hex 0x1d), care este un identificator TLS pentru ceea ce este cunoscut în mod obișnuit ca X25519. O listă a numerotărilor pentru toate grupurile acceptate TLS este aici: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
X25519 înseamnă un schimb Diffie-Hellman folosind un punct de bază bine-cunoscut G pe curba eliptică Curve25519, unde elementele grupului sunt în subgrupul ciclic mare care conține G în această curbă. Punctul G nu trebuie transmis, deoarece este definit ca parte a X25519 standard și este același pentru toate invocările lui X25519.
Cheia publică efemeră a clientului este „elementul de grup” care a fost trimis în mod speculativ. Pentru X25519, are o lungime de 32 de octeți (64 de caractere hexadecimale sau 256 de biți). Acest element de grup este listat ca valoare „schimb de chei” în secțiunea „parte de cheie” a structurii de date ClientHello.
Serverul va răspunde cu un mesaj „ServerHello” dacă este de acord să utilizeze grupul inclus în mod speculativ al clientului, aici Grupul 29. Acesta include elementul de grup al serverului în valoarea „schimb de chei” din secțiunea „Partajare cheie”.Acest element de grup este cheia publică efemeră a serverului.
Cu aceste informații, atât clientul, cât și serverul vor putea calcula fiecare același secret partajat numit „secretul pre-master”. Acesta este apoi combinat cu datele ClientHello și ServerHello pentru a obține chei de criptare simetrice (consultați https://datatracker.ietf.org/doc/html/rfc8446#section-7.1). Acestea permit serverului și clientului să comunice în siguranță unul cu celălalt folosind criptare autentificată, cum ar fi AES-GCM.
Dacă serverul nu este de acord cu grupul propus de client sau clientul a optat să nu propună niciun grup, dar serverul este de acord cu un (alt) grup clientul listat în „grupuri acceptate”, acesta trimite în schimb HelloRetryRequest care îi spune client să reîncerce ClientHello folosind un grup specificat, pe care serverul îl acceptă apoi ca mai sus. Dacă serverul nu este de acord orice grupul pe care clientul îl acceptă, trimite o alertă de eroare și strângerea de mână eșuează -- cu excepția cazului în care clientul a propus și un PSK disponibil, dar de obicei asta se întâmplă doar pentru reluare, iar dacă strângerea de mână inițială eșuează, reluarea nu este posibilă.
TLS 1.0-1.2 gestionează ECDHE în mod diferit -- dacă este deloc, pentru că acolo este opțional. În aceste protocoale, ciphersuite specifică schimbul de chei și autentificarea, precum și cifrul de date și hash pentru HMAC (dacă nu AEAD) și PRF (dacă 1.2). Clientul trimite ClientHello listarea suitelor de criptare pe care le acceptă, oricare, unele sau toate pot utiliza ECDHE în combinație cu autentificarea RSA sau ECDSA (adică certificat), și o extensie de grupuri suportate (sau curbe suportate înainte de RFC7919) care specifică curbele pe care le suportă. Dacă serverul este de acord cu un pachet de criptare ECDHE oferit și o curbă oferită, trimite ServerHello specificând pachetul de criptare, apoi lanțul său de certificate, apoi ServerKeyExchange care conține id-ul curbei și cheia publică efemeră.Clientul (dacă acceptă certificatul) trimite ClientKeyExchange care conține cheia sa publică efemeră, după care calculul secret partajat procedează în mod similar, deși detaliile despre modul în care sunt derivate cheile de lucru diferă de 1.3 și, de asemenea, între 1.2 și mai devreme.
