(Transport Layer Security/rfc5246)
(abans de TLS 1.0 $\rightarrow$ SSL, Secure Sockets Layer)
Ubicació de TLS dins la pila TCP/IP en aplicacions HTTPS
Funcionalment equivalent a un socket TCP aportant-hi:
PVKPVK*) PFS: Perfect Forward Secrecy; acord de claus independent de l'autenticació
PVKPVKTLS és el successor de l'SSL i ha anat evolucionant per diferents versions en resposta als diferents atacs teòrics i pràctics que han anat sortint
els clients quan es connecten acorden fer servir la versió més moderna que suportin ambdós extrems:
ClientHello $\longrightarrow$
conté un random, cipher-suites suportats, versió
$\longleftarrow$ ServerHello
conté un random, session-ID, i la versió de TLS i el cipher-suite usat
$\longleftarrow$ Certificate
cadena de certificats incloent el del servidor
$\longleftarrow$ ServerKeyExchange
(si DHE) paràmetres DH i la seva clau pública (efímera: InputSecret)
$\longleftarrow$ CertificateRequest$\dagger$
(si el servidor requereix autenticació de client) DN's de les CA acceptades
$\longleftarrow$ CertificateVerify
signatura dels missatges anteriors
Certificate $\longrightarrow$
(si el servidor requereix autenticació de client) cadena de certificats incloent la del client
ClientKeyExchange $\longrightarrow$
(si DHE) clau pública DH (efímera: InputSecret)
CertificateVerify$\dagger$
$\longrightarrow$
(si el servidor requereix autenticació de client) signatura dels missatges anteriors
a partir dels dos InputSecret es genera el MasterSecret
del MasterSecret se'n deriven 4 claus i 2 IV:
les dades es fragmenten en blocs de fins 16 kB
cada bloc està protegit pels algorismes simètrics acordats durant la inicialització i les claus i IV's
derivats de la MasterKey...
i per un nombre de seqüència
S'identifiquen (aprox) amb la cadena KEA_SIGN_WITH_CIPHER_HASH
| Component | Contingut |
| KEA | algorisme d'acord de claus |
| SIGN | algorisme de signatura |
| CIPHER | algorisme de xifrat simètric |
| HASH | algorisme de hash |
els següents cipher-suites són d'obligatòria implementació (MUST):
{DHE|ECDHE}_ECDSA_WITH_AES_128_GCM_SHA256
{DHE|ECDHE}_RSA_WITH_AES_128_GCM_SHA256
i es recomana l'implementació d'aquests (SHOULD):
{DHE|ECDHE}_ECDSA_WITH_AES_256_GCM_SHA384
{DHE|ECDHE}_ECDSA_WITH_CHACHA20_POLY1305_SHA256
{DHE|ECDHE}_RSA_WITH_AES_256_GCM_SHA384
{DHE|ECDHE}_RSA_WITH_CHACHA20_POLY1305_SHA256
Notes:
RSA-2048, ECDSA-224, ECDH-224: longituds mínimes;DSA, SHA-1, SHA-224, 3DESValors previstos per a cada camp de KEA_SIGN_WITH_CIPHER_HASH
encara que poden canviar
| Component | Contingut |
| KEA | DHE, ECDHE
$\quad \Rightarrow$ només variants efímeres DH |
| SIGN | RSA, ECDSA
$\quad \Rightarrow$ desapareix DSA |
| CIPHER | AES-128, AES-256, ChaCha20
$\quad \Rightarrow$ desapareixen 3DES, RC4, |
| HASH | SHA-2, Poly1305
$\quad \Rightarrow$ desapareixen MD5, SHA-1, SHA-2/224 |
les dades es protegeixen amb CIPHER_HASH
$\downarrow$
derivades amb KEA
$\downarrow$
autenticats (els secrets) amb SIGN
$\downarrow$
Claus públiques de servidor i client (opcionalment)
?