SSL session persistence and secure cookies

Question

I currently have a roll-your-own application security service that runs in my enterprise and is - for the most part - meeting business needs.

The issue that I currently face is that the service has traditionally (naively) relied on the user's source IP remaining constant as a hedge against session hijacking - the web applications in the enterprise are not directly available to the public and it was in the past perfectly acceptable for me to require that a users' address remain constant throughout a given session.

Unfortunately this is no longer the case and I am therefore forced to switch to a solution that does not rely on the source IP. I would much prefer to implement a solution that actually accomplishes the original designer's intent (i.e. preventing session hijacking).

My research so far has turned up this, which essentially says "salt your authentication token hash with the SSL session key."

On the face of it, this seems like a perfect solution, however I am left with a nagging suspicion that real-world implementation of this scheme is impractical due to the possibility that the client and server can at any time - effectively arbitrarily - opt to re-negotiate the SSL session and therefore change the key.

this is the scenario I am envisioning:

1. SSL session established and key agreed upon.
2. Client authenticates to server at the application level (i.e. via username and password).
3. Server writes a secure cookie that includes SSL session key.
4. Something occurs that causes a session re-negotiation. For example, I think IE does this on a timer with or without a reason.
5. Client submits a request to the server containing the old session key (since there was no application level knowledge of the re-negotiation there was no opportunity for a new, updated hash to be written to the client).
6. Server rejects client's credential due to hash match failure, etc.

Is this a real issue or is this a misapprehension on my part due to a (to say the least) less-than-perfect understanding of how SSL works?

Answer 1

Yes, but there are several things you can do about it. The easiest it to simply cache the session key(s) you use as salt (per user), and accept any of them. Even if the session is renegotiated you'll still have it in your cache. There are details--expiration policy, etc.--but nothing insurmountable unless you are running something that needs to be milspec hardened, in which case you shouldn't be doing it this way in the first place.

-- MarkusQ

Answer 2

See all topics related to SSL persistence. This is a well-researched issue in the load-balancer world.

The short answer is: you cannot rely on the SSLID -- most browsers renegotiate, and you still have to use the source IP. If the IP address is likely to change mid-session then you can force a soft-reauthentication, or use the SSLID as a bridge between the two IP changes (and vice-versa, i.e. only assume hijacking if both IP address and SSLID change at the same time, as seen by the server.)

You may be able to hedge your bets, from a security perspective, by also hashing other attributes that may be, if not unique, then somewhat more selective of the machine used to authenticate (e.g. grab the UserAgent, or any other identifying information you may obtain, say through JavaScript, from the client PC during authentication) and that a hijacker cannot easily reproduce on another machine, effectively making the hijacker's life much much more complicated.

Please let me know what your ultimate decision is, I am faced with the same issue and, what's worse, I am facing it over potentially unencrypted communication channels.

Cheers, V.

Answer 3

I am wondering why it would not be just enough to simply

1. require ssl in your transport
2. encode inputs (html/url/attribute) to prevent cross-site scripting
3. require only POSTs for all requests that change information and
4. prevent CSRF as best you can (depending on what your platform supports).
5. Set your cookies to HTTPOnly