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?

Solution 1

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.)

2014 UPDATE

Just force the use of https and make sure that that you are not vulnerable to session fixation or to CRIME. Do not bother to salt your auth token with any client-side information because if an attacker was able to obtain the token (provided that said token was not just trivial to guess) then whatever means were used to obtain it (e.g. cross-site scripting, or the full compromising of the client system) will also allow the attacker to easily obtain any client-side information that might have gone into the token (and replicate those on a secondary system if needed).

If the client is likely to be connecting from only a few systems, then you could generate an RSA keypair in the browser for possibly every new client system the client connects from (where the public part is submitted to your server and the private part remains in what is hopefully secure client storage) and redirect to a virtual host that uses two-way (peer/client certificate) verification in lieu of password-based authentication.

Solution 2

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

Solution 3

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