(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:
PVK
PVK
*) PFS: Perfect Forward Secrecy; acord de claus independent de l'autenticació
PVK
PVK
TLS é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
, 3DES
Valors 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)
?