Numero sequenza TLS

Per la risposta esatta , fai riferimento a lo standard .

Per un breve riassunto: il numero di sequenza è implicito e non viene trasmesso. Sia il mittente che il ricevitore tengono traccia di quanti record hanno inviato e ricevuto, quindi non ne hanno bisogno per essere ripetuto nel record stesso (e se fosse lì, quindi dovrebbero verificarlo, perché il punto della sequenza numero è quello di rilevare duplicati, record abbandonati e record fuori-ordine).

Tuttavia, i record TLS 1.1 e 1.2 hanno IV esplicito , per le modalità di cifratura a blocco che li richiedono (in SSL 3.0 e TLS 1.0, l'IV per un record era una copia dell'ultimo blocco crittografato di il record precedente, che consentiva attacchi selected-plaintext , resi popolari nel caso di TLS con il nome "BEAST" ). Per le suite di crittografia che richiedono la modalità CBC di crittografia, l'IV dovrebbe essere generato casualmente e dai tuoi occhi wirehark questi IV appariranno "casuali". TLS 1.2, tuttavia, supporta anche le modalità di crittografia AEAD , che sono modalità di cifratura a blocchi avanzate che combinano non solo la crittografia e il MAC (mentre le suite di crittografia basate su CBC necessitano di un HMAC extra per l'integrità), ma sono anche meno esigenti riguardo al loro IV.

Considera in particolare le GCM suite di crittografia, specificate in RFC 5288 . GCM ha bisogno di un IV da 12 byte, che non deve essere casuale; l'unico vincolo è che nessun valore IV deve essere usato per più di un record, per una data chiave simmetrica. Quando GCM viene utilizzato in TLS, i primi 4 byte di IV vengono calcolati come parte della derivazione della chiave di handshake e tutti i record in una determinata connessione usano gli stessi valori per questi quattro byte; i restanti 8 byte vengono trasmessi con il record stesso e spetta al mittente garantire che nessun valore di 8 byte venga riutilizzato all'interno di una connessione specifica. Come dice RFC 5288:

Each value of the nonce_explicit MUST be distinct for each distinct
invocation of the GCM encrypt function for any fixed key.  Failure to
meet this uniqueness requirement can significantly degrade security.
The nonce_explicit MAY be the 64-bit sequence number.

Vedi in particolare questa ultima frase: l'uso di un contatore va bene, e il numero della sequenza di registrazione è un tale contatore. Questo è ciò che osservi: l'implementazione TLS specifica che stai studiando sembra utilizzare una copia del numero di sequenza come (parte della) IV per ogni record. Questo è permesso, e va bene (ripeto: questo va bene per le suite di cifratura GCM ; per le suite di crittografia CBC, questo sarebbe debole).

Attenzione ai dettagli, però: è non obbligatorio usare il numero di sequenza per questo campo; in realtà non è obbligatorio utilizzare un contatore. L'estremità ricevente di un record TLS non deve presumere che il campo nonce_explicit sarà uguale al numero di sequenza; invece, deve utilizzare il valore del campo come ricevuto. Inoltre, sia il mittente che il destinatario devono comunque tenere traccia del numero di sequenza, poiché il numero di sequenza è parte dei "dati autenticati" nel calcolo di AEAD. È conveniente e intelligente utilizzare il numero di sequenza come nonce_explicit e RFC 5288, prevedendo la domanda, afferma esplicitamente che va bene.

(Lo standard TLS sarebbe stato leggermente meno complesso se avessero specificato che l'IV per GCM era il numero di sequenza, senza la necessità di inviarlo sul filo, ma RFC 5246 cerca di essere generico per ospitare altri future modalità AEAD che potrebbero avere altri requisiti sulla IV.)

Per studiare in modo efficace questi dettagli , una buona strategia è implementare la tua libreria SSL / TLS, non per uso di produzione, ma per il valore pedagogico. Quando il codice del client (rispettivamente del server) riesce a comunicare con un'implementazione del server esistente (rispettivamente client), avrai imparato molto. Assumerò anche, per esperienza, che non esiste un metodo migliore per imparare TLS.

Sì, la visibilità dei numeri di sequenza dipende dalla suite di crittografia: in un codice AEAD, il numero di sequenza è incluso nei dati aggiuntivi (RFC5246, 6.2.3.3):

additional_data = seq_num + TLSCompressed.type +
                            TLSCompressed.version + 
                            TLSCompressed.length;

I dati aggiuntivi sono autenticati, ma non crittografati . Quindi puoi vedere il suo contenuto usando Wireshark.

Negli altri cifrari supportati da TLS 1.2, ovvero la codifica a flusso e la modalità di cifratura a blocchi CBC, il numero di sequenza è implicitamente nel MAC (RFC5246, 6.2.3.1):

MAC = HMAC(MAC_write_key, seq_num +
                          TLSCompressed.type +
                          TLSCompressed.version +
                          TLSCompressed.length +
                          TLSCompressed.fragment);

Quindi non è visibile lì.