Repository navigation
Removing newSession/resumeSession #1462
Description
Activity
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?
@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().But the server uses a key to encrypt the ticket, and I think best practice dictates this key to be rotated, no?
@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.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.@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.
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?
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 :)
@silverwind to conclude, I believe that in most situations if the client support the SSL session, it support TLS session tickets too.
- added 2 commits that reference this issue
on Apr 18, 2015 13 remaining items
- added a commit that references this issue
on May 1, 2015 - added a commit that references this issue
on May 19, 2015 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.)
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.- added a commit that references this issue
on Mar 18, 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%).
@justinegreene I'm not suggesting removal of support of session ids... just asynchronous APIs for loading/storing them.
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.
@indutny What's the status of this? If it's inactive, can you close it out?
BTW, Safari 10 still does not support session tickets according to https://www.ssllabs.com/ssltest/clients.html.
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_cbis 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