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?
The encrypted communication typically works more or less like this:
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.