Removing `newSession`/`resumeSession`

[indutny]

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:

• https://github.com/strongloop/strong-cluster-tls-store
• ...

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

[silverwind]

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]

@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 a session option to the tls.connect().

[silverwind]

But the server uses a key to encrypt the ticket, and I think best practice dictates this key to be rotated, no?

[indutny]

@silverwind that's true. We do not provide the API to change the the ticket key in runtime.

Speaking of, I just figured that sessionTimeout controls TLS ticket lifetime, but it is only an advisory. So technically the TLS tickets are valid until the key is rotated.

[silverwind]

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]

@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]

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]

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]

@silverwind to conclude, I believe that in most situations if the client support the SSL session, it support TLS session tickets too.