4

I was trying to understand the TLS handshake in depth. I set up Wireshark and captured the github.com traffic. While inspecting the Client Hello and Server Hello, I found a parameter Session ID.

According to this article session id can be used in case we want to reconnect without a big handshake. What I understand is, if we had previously connected, then the cached session id can be used again for the latest session. In that case, we are sending the session id as plain text. Can this be captured by an attacker?

enter image description here

Or, am I completely wrong here? Is this different from the symmetric key?

Anonymous Platypus
  • 1,392
  • 3
  • 18
  • 33
  • Here's a section from the book *"High Performance Browser Networking"* that covers session resumption nicely: https://hpbn.co/transport-layer-security-tls/#tls-session-resumption – StackzOfZtuff Jun 26 '18 at 19:28

2 Answers2

6

Can this be captured by an attacker?

Yes - but its not much use to them.

It's an indirect reference to the algorithms and keys previously (and securely) agreed, which are remembered by the server/client. So if the attacker asserts to your server that he wants to resume the session, your server will resume with ciphertext the attacker's client doesn't know how to decrypt.

(There may be some scope for escalating this to a DOS against a single client, but that's conjecture on my part. And if the attacker can sniff the traffic there are easier ways to subvert the connection.)

The TLS session has got nothing to with the HTTP session(s) so even if the attacker was able to decrypt the data, this is not sufficient to get control over the users session in the application.

symcbean
  • 18,278
  • 39
  • 73
  • Not even that far. Resumption skips the actual key exchange, but still does Finished, and without the master secret attacker faking client can't do valid Finished so server aborts before any data. – dave_thompson_085 Jul 28 '18 at 00:00
0

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.

Specifically, the client can include the session ID in the ClientHello message to indicate to the server that it still remembers the negotiated cipher suite and keys from previous handshake and is able to reuse them. In turn, if the server is able to find the session parameters associated with the advertised ID in its cache, then an abbreviated handshake can take place. Otherwise, a full new session negotiation is required, which will generate a new session ID.

Source: https://hpbn.co/transport-layer-security-tls/#tls-session-resumption

Anonymous Platypus
  • 1,392
  • 3
  • 18
  • 33