Qual è il parametro ID sessione indicato nei messaggi Client Hello e Server Hello

Can this be captured by an attacker?

Sì, ma non è molto utile per loro.

È un riferimento indiretto agli algoritmi e alle chiavi precedentemente (e in modo sicuro) concordati, che vengono ricordati dal server / client. Quindi se l'attaccante dichiara al proprio server che desidera riprendere la sessione, il server riprenderà con testo cifrato il client dell'attaccante non sa come decrittografarlo.

(Ci può avere qualche possibilità di inoltrarlo a un DOS contro un singolo client, ma questa è una congettura da parte mia e se l'utente malintenzionato può intercettare il traffico ci sono modi più semplici per sovvertire la connessione .)

La sessione TLS non ha ottenuto nulla con le sessioni HTTP, quindi anche se l'autore dell'attacco è stato in grado di decrittografare i dati, questo non è sufficiente per ottenere il controllo sulla sessione degli utenti nell'applicazione.

The first Session Identifiers (RFC 5246) resumption mechanism was introduced in SSL 2.0, which allowed the server to create and send a 32-byte session identifier as part of its ServerHello message during the full TLS negotiation we saw earlier. With the session ID in place, both the client and server can store the previously negotiated session parameters—keyed by session ID—and reuse them for a subsequent session.

In particolare, il client può includere l'ID di sessione nel messaggio ClientHello per indicare al server che ricorda ancora la suite di cifratura negoziata e le chiavi dall'handshake precedente ed è in grado di riutilizzarle. A sua volta, se il server è in grado di trovare i parametri di sessione associati all'ID pubblicizzato nella sua cache, può avvenire una stretta di mano abbreviata. In caso contrario, è necessaria una negoziazione di sessione completamente nuova, che genererà un nuovo ID di sessione.

Fonte: link