Hacker News Reader

Comment by neftaly | Hacker News Reader

I wonder if it's feasible to reference the TLS/SSL session against the session cookie? While the HTTPS session itself is probably transient, you can tell something is up if the same session cookie is being used with two different HTTPS keys.

View on HN

You're describing the concept behind channel bound cookies. https://tools.ietf.org/html/rfc5929

As far as I know, it's not supported by any current browser (I welcome feedback to the contrary) but is included in SChannel. Given that we've only recently (arguably) gotten away from SSLv3, I don't have high hopes that it will be viable to require channel binding in the very near term.

Chrome v24+ does support all you need for channel-bound cookies: it supports TLS Channel IDs (previously known as Origin-Bound Certificates). To actually bind cookies, it is the server's responsibility to extract the channel ID from the TLS/SSL handshake, and bind the cookies to it.

Do any cloud SSL terminators like Amazon ELB support forwarding the channel IDs on to the application servers (i.e. in a custom header)? For that matter, is there a configuration setting for i.e. Nginx if you want to roll your own SSL terminator to do this? Having trouble finding good documentation about how to handle this from the server side.

Cool – hadn't heard of that before. I was thinking more along the lines of a purely server-side approach:

  $_REQUEST["salted_SHA_hash_of_symmetric_TLS_key"]

You'd save the current key to a DB, and manually check it in future requests.

Well, if you can intercept the request to the server to can also change that parameter of the TLS certificate hash.

Is that actually true, though (especially w.r.t. Forward Secrecy)? Don't both parties generate separate halves of a symmetric key independently, preventing any one party from forcing the use of a particular key on a new session?

Reply on news.ycombinator.com