Repository navigation
Removing newSession/resumeSession #1462
Description
SSL session ids are so outdated, let's remove them. TLS tickets is a modern age and they are very widely deployed!
I'd like to remove it to get rid of the ClientHelloParser. SSL_set_cert_cb is a new OpenSSL-1.0.2 API that we are going to use instead.
The list of the modules that will no longer work:
Please comment if you have a use case for this API, or know a module that does depend on it.
cc @iojs/collaborators @iojs/community-members @iojs/crypto
Activity
silverwind commentedon Apr 18, 2015
I'm using id resumption, but meant to switch over to tickets eventually.
Could you provide a bit of info on where the ticket keys are stored and if there is a user-exposed API to manage the invalidation? I think if we want to do the switch to tickets, the user should have control over this important aspect.
Also, how is the client support on tickets? Such data seems hard to find. Does IE support them yet?
indutny commentedon Apr 18, 2015
@silverwind tickets are stored on client-side, the client should provide them when attempting to do a new connection. There is a validity timeout, but it is not configurable in io.js yet. Please file a bug for it ;)
The client-side session API in io.js remains the same even when using TLS tickets. You could call
.getSession()and supply it as asessionoption to thetls.connect().silverwind commentedon Apr 18, 2015
But the server uses a key to encrypt the ticket, and I think best practice dictates this key to be rotated, no?
indutny commentedon Apr 18, 2015
@silverwind that's true. We do not provide the API to change the the ticket key in runtime.
Speaking of, I just figured that
sessionTimeoutcontrols TLS ticket lifetime, but it is only an advisory. So technically the TLS tickets are valid until the key is rotated.silverwind commentedon Apr 18, 2015
On the server, I could see forcing a ticket key refresh by instantiating a new server with a provided
ticketKeys(The docs to that option seem confusing, it's called keys but says it only takes a single key). I think there should probably be a better api to this.indutny commentedon Apr 18, 2015
@silverwind well, this is some OpenSSL weirdness :) It takes one buffer and splits it into 3 parts, each used for a different kind of key for TLS tickets. That's why it is called that way.
There is an API for changing it in runtime. I'd really appreciate if you'll open a ticket for it and mention me there.
silverwind commentedon Apr 18, 2015
Will do.
My primary concern is we're deprecating a important performance functionality to which there is no universally supported alternative to. Could you provide some data on browser support?
indutny commentedon Apr 18, 2015
I think @pquerna has some insights on this: https://journal.paul.querna.org/articles/2012/09/07/adoption-of-tls-extensions/ . Though the situation might have been changed much since 2012 ;)
I believe that chrome/firefox/opera/... support this, while old IE versions most likely do not. The command line utilities do not support TLS tickets in their majority, but!.. they do not support sessions either :)
indutny commentedon Apr 18, 2015
@silverwind to conclude, I believe that in most situations if the client support the SSL session, it support TLS session tickets too.
tls: use `SSL_set_cert_cb` for async SNI/OCSP
tls: use `SSL_set_cert_cb` for async SNI/OCSP
13 remaining items
tls: use `SSL_set_cert_cb` for async SNI/OCSP
tls: use `SSL_set_cert_cb` for async SNI/OCSP
Trott commentedon Feb 25, 2016
Hello, friends! Can someone tell me if this is still a thing?
(Doing some poking around on issues that haven't been touched in a long time and trying to figure out what, if anything, to do with them. This one hasn't seen any comments in over 10 months.)
indutny commentedon Feb 25, 2016
This is still a thing, and I firmly believe that we should eventually do this. There are lots of code that supports it, and it doesn't provide that much use in the presence of TLS session tickets (which are very common nowadays).
To support @tlivings case, I think it should be enough to leave a synchronous version of
newSession/resumeSessionas a compatibility shim.indutny commentedon Mar 15, 2016
Alright, I just spoke to @tlivings, and it looks like we will be able to figure it out with a synchronous
newSession/resumeSession. Going to file a PR with proposed changes soon.tls: deprecate `newSession`/`resumeSession` events
justinegreene commentedon Mar 30, 2016
I am a little late to this thread, but unless I am missing something, I am pretty sure that Safari on iOS and OSX lacks Session Ticket Support and only supports Session IDs, so removing new Session and Resume Session functionality would cripple SSL/TLS for iPhones and iPads which account for 40%-60% of the mobile web traffic in the US (and Safari on OS X which is about 3%).
indutny commentedon Mar 30, 2016
@justinegreene I'm not suggesting removal of support of session ids... just asynchronous APIs for loading/storing them.
justinegreene commentedon Mar 30, 2016
Thanks for the clarification. The thread started with "SSL session ids are so outdated, let's remove them" and much of the discussion was about using Session Tickets instead of Session IDs, but this isn't an option with Safari.
bnoordhuis commentedon Feb 7, 2017
@indutny What's the status of this? If it's inactive, can you close it out?
silverwind commentedon Feb 7, 2017
BTW, Safari 10 still does not support session tickets according to https://www.ssllabs.com/ssltest/clients.html.
jasnell commentedon May 30, 2017
Closing due to lack of further activity. @indutny feel free to reopen if you get back to this.
node: rmv tls-sessions