-1

I've been reading from (how do https prevent session hijacking) where it says that the hijacker will only see encrypted data and not the plain text hence it is not possible for them to hijack session.

But given the actual user is also sending encrypted data, isnt that all that is needed by hijacker and hence the fact that the hijacker can see the encrypted data is still problematic and enough to really hijack the session and imitate as a different user?

I am not sure how TLS/SSL prevent this.

Assume, client sends cookie value "ABC" that was generated by the server on successful auth. Now the client wont send ABC rather "XYZ" (After encryption). Now hijacker will see XYZ and it can also send XYZ, and then server will decrypt it and assume that the hijacker is the actual client.

What am i doing wrong here?

Kraken
  • 23,393
  • 37
  • 102
  • 162

1 Answers1

0

The encrypted communication typically works more or less like this:

  1. Client and server agree on the initial state S.
  2. Client sends message M1 encrypted with respect to state S.
  3. Client derives new state S2, via some fancy formula, specifically designed to work well.
  4. Client sends message M2 encrypted with respect to state S2, ... and so on

On the other side the server of course mirrors this. This way we prevent replays. You cannot just pick a message M1 encrypted with respect to state S and send it again, because the server already expects next message to be encrypted with respect to state S2. And of course the whole point is to construct the protocol in such a way that a man-in-the-middle won't be able to derive S2 just by looking at the encrypted messages.

Not to mention that just by looking at the encrypted stream, you wouldn't even be able to tell which piece is the cookie.

freakish
  • 54,167
  • 9
  • 132
  • 169
  • 1
    This is wrong. All data ciphers in SSL/TLS use both a key and IV or nonce, and vary per record _only_ the IV/nonce. The oldest, now-broken versions (SSLv3 and TLSv1.0) for CBC ciphersuites (then all but RC4) did use the last block of ciphertext as IV for records after the first; this allowed the 'BEAST' attack and those versions are now prohibited. The initial key setup (usually but not always DH agreement) creates at least 2 keys, often more. But different sessions (including resumption of a previous session) always have different keys due to the handshake nonces (as explained in the dupe). – dave_thompson_085 Aug 26 '23 at 09:44
  • 1
    ... What you describe is more like an IM protocol such as Signal's 'ratchet' scheme -- but not correct for that either. – dave_thompson_085 Aug 26 '23 at 09:45
  • @dave_thompson_085 ok, I've changed the word "key" to "state" and fixed wording here and there. This is just semantics anyway. I'm only briefly explaining tls, I'm deliberately not diving into complicated details. For example 3/4 of your comment are implementation details, that I don't find relevant here. – freakish Aug 26 '23 at 13:42