Ruolo della suite cipher selezionata in una connessione SSL / TLS

So from what I understand it generally works like this:

1. Client connects to the server

Per HTTPS si. Per altre applicazioni varia; alcuni fanno una nuova connessione e alcuni riutilizzano una connessione esistente.

2. Client tells server about their supported protocol (e.g. TLS 1.2) AND the cipher suite (e.g. ECDHE-RSA-AES128-GCM-SHA256)

Ciphersuite s plurale e molte altre cose nelle estensioni, entrambe mostrate nell'articolo che colleghi. (Che evidenzia SNI rilevanti per la logica IIS / http.sys descritta.)

3. Server answers and agrees on a protocol and cipher suite they both support (e.g. TLS 1.2 & ECDHE-RSA-AES128-GCM-SHA256), as well as the servers certificate (also containing their public key)

Il certificato contiene la chiave pubblica statica (a lungo termine) e, come detto in ISMSDEV, è accompagnata da qualsiasi certifica catena intermedio aka e facoltativamente il certificato radice. L'articolo non indica chiaramente, ma mostra nella traccia di rete, che i certificati sono in realtà un messaggio separato, ma probabilmente nello stesso record di SSL / TLS e quasi sempre negli stessi frame TCP. Per keyexchange effimero, come nel ciphersuite specificato ma non quello nell'articolo, la chiave temporanea del server (con parametro (s) e firma molto come ISMSDEV ha detto) è in un messaggio separato ServerKeyExchange; quindi facoltativamente un altro messaggio a "Richiedi" un certificato client, ancora una volta non indicato chiaramente e questa volta non mostrato; quindi un messaggio ServerHelloDone, non descritto affatto ma mostrato.

--- now from here on they communicate based on the chosen protocol and the role of the cipher suite becomes important ---

La versione / formato del protocollo e lo scambio di chiavi hanno già influenzato i messaggi del server sopra. Il codice simmetrico e probabilmente l'hash non hanno ancora effetto.

4. The client verifies the server's certificate against known certificate authorities and extracts the server's public key for the key exchange

Verifica il certificato catena , estrae la chiave longterm (certificata) ed estrae e verifica la chiave temporanea, se usata, che è nella ciphersuite specificata.

5. Now the cipher suite's key exchange kicks in (in this case ECDHE-RSA), which uses the server's public key - the result is the pre-master secret (as depicted in the diagram below)

Lo scambio di chiavi è già iniziato, con i messaggi del server sopra; ora è completato utilizzando la chiave del cliente. Il diagramma che copi mostra una freccia dal client al server con il segreto pre-master (crittografato) perché è per una ciphersuite che utilizza lo scambio di chiavi RSA, ma hai specificato una ciphersuite usando lo scambio di chiavi ECDHE-RSA e per quello pubblico effimero del cliente viene inviato (in chiaro) e l'algoritmo ECDH viene utilizzato, indipendentemente da entrambi i peer, per ricavare il segreto pre-master.

Inoltre, se è stato richiesto il certificato client (ovvero l'autenticazione client), il client può inviare la propria catena di certificati e la propria firma su una trascrizione tramite messaggio di scambio chiave del cliente, (entrambi) come messaggi separati , come descritto nell'articolo ma non mostrato.

6. With the pre-master secret, both the cipher and the hashing algorithm are then used (in this case AES128-GCM and SHA256) for the message encryption and digests.

Non ancora.

7. The key exchange is repeated, encrypted with the cipher, using the pre-shared secret and verified with the hashing algorithm. The result is the master secret

Nulla viene ripetuto e nulla utilizza direttamente il segreto pre-master. Invece il pre-master secret viene usato con i valori 'random' (nonce) dai messaggi Hello in un algoritmo chiamato PRF (Pseudo-Random Function) per derivare il master secret, e quindi il master secret è usato analogamente per derivare < em> varie chiavi di sessione. Come dice l'articolo:

[the server] performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret. (bullet) Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity [....]

Notare il plurale in "chiavi di sessione". Per le alcune ciphersuites in TLS1.2, incluso quello specificato, l'hash nella ciphersuite influisce sul PRF. Per altri ciphersuites e tutte le versioni di protocollo inferiori, non lo è. Vedi A cosa serve hash in ECDHE-RSA- AES-GCM-SHA? .

8. The master secret is used with the cipher and hashing algorithm, to encrypt any further communication.

Ogni endpoint invia un messaggio ChangeCipherSpec per 'attivare' la ciphersuite e quindi un messaggio Finished, che è il primo messaggio crittografato (e MACed). Come dice l'articolo:

The CLIENT & the SERVER send each other a message informing that future messages from them will be encrypted with the session key. It then sends a separate (encrypted) message indicating that its portion of the handshake is finished.

Niente utilizza direttamente la chiave master. La crittografia simmetrica (dati) utilizza due delle chiavi di sessione (una per ciascuna direzione). Per le ciphersuites che utilizzano HMAC per l'integrità (come nell'articolo), utilizza l'algoritmo hash della ciphersuite (e altre due chiavi di sessione), ma hai specificato una ciphersuite che usa la modalità GCM, che come ISMSDEV fornisce la sua autenticazione (non usando qualsiasi hash).

Penso che tu abbia le linee corrette. La mia comprensione del protocollo riguardante le suite di cifratura ha un impatto sul protocollo in quanto tale.

client ciao

Contiene la versione più alta della versione SSL / TLS supportata dal client, una nonce casuale generata dal client, un ID di sessione (l'handshake iniziale sarà zerod out), un elenco di possibili pacchetti di crittografia (vedi sotto) supportati dal client ( questi contengono l'algoritmo di autenticazione da utilizzare, l'algoritmo di crittografia da utilizzare e il protocollo dell'accordo di chiave)

Il client ora attende una risposta dal server ...

server Ciao

Contiene la versione più alta di SSL / TLS supportata dal server supportata dal client, una nonce casuale generata dal server, l'ID di sessione fornito dal client o un nuovo ID di sessione se non fornito dal client. Il server sceglie quale suite di crittografia utilizzare, ad esempio:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

che si scompone come:

- Protocollo - TLS

- Algoritmo di scambio di chiavi - ECDHE_RSA - Elliptic Curve Diffie Helman Effemerale con RSA. Come il cliente sarà d'accordo sulle chiavi simmetriche.

-Algoritmo di crittografia - AES_128_GCM - L'algoritmo utilizzato per crittografare i dati del carico utile con le chiavi concordate. AES 128 (Advanced Encryption Standard con una lunghezza della chiave di 128 bit) e utilizzando la modalità di blocco GCM (modalità Galois / Counter), che fornisce anche l'autenticazione dei messaggi ai dati crittografati.

- Funzione pseudocasuale - SHA256 - Il tipo di algoritmo utilizzato per la generazione del segreto principale, utilizzato per seminare la creazione delle chiavi di sessione. In questa suite di crittografia sta utilizzando il ben noto algoritmo di hash SHA256 per offrire livelli elevati di entropia. certificato

Questo messaggio contiene il certificato utilizzato per firmare la chiave pubblica del server e tutti i certificati intermedi nella catena di certificati X509.

scambio di chiavi del server

Utilizzando il protocollo di chiave d'accordo dalla suite di crittografia, il server invia tutti gli elementi necessari al client. Esempio, per Ephermeral Diffie Helman questo sarebbe 3 parametri più una firma su quei parametri. I parametri sono i due parametri DH globali più i server DH chiave pubblica.