title: SSL session persistence and secure cookies
body: <p>I currently have a roll-your-own application security service that runs in my enterprise and is - for the most part - meeting business needs.</p>
  
  <p>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.</p>
  
  <p>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).</p>
  
  <p>My research so far has turned up <a href="http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf" rel="noreferrer">this</a>, which essentially says "salt your authentication token hash with the SSL session key."</p>
  
  <p>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. </p>
  
  <p>this is the scenario I am envisioning:</p>
  
  <ol>
  <li>SSL session established and key agreed upon.</li>
  <li>Client authenticates to server at the application level (i.e. via username and password).</li>
  <li>Server writes a secure cookie that includes SSL session key.</li>
  <li><em>Something</em> occurs that causes a session re-negotiation. For example, I think IE does this on a timer with or without a reason.</li>
  <li>Client submits a request to the server containing the <em>old</em> 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).</li>
  <li>Server rejects client's credential due to hash match failure, etc.</li>
  </ol>
  
  <p>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?</p>