crypto/tls session ID caching

[Eric Lorimer]

Hi Go team,

It looks like the TLS server implementation in crypto/tls only supports session resumption with session tickets.  I would like to add a couple hooks to the server handshake to support caching based on session IDs.  Similar to ClientSessionCache, I'm proposing adding a ServerSessionCache interface that could be implemented by server code to support caching.  In the case where the field is not set, it would behave exactly as it does now.  Would such a change be welcome?  Should I open an issue or just submit the patch?

- Eric

[Brad Fitzpatrick]

[+agl]

Adam owns that code. Adam?

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Langley]

On Thu, May 14, 2015 at 3:33 PM, Brad Fitzpatrick <brad...@golang.org> wrote:
>> It looks like the TLS server implementation in crypto/tls only supports
>> session resumption with session tickets. I would like to add a couple hooks
>> to the server handshake to support caching based on session IDs. Similar to
>> ClientSessionCache, I'm proposing adding a ServerSessionCache interface that
>> could be implemented by server code to support caching. In the case where
>> the field is not set, it would behave exactly as it does now. Would such a
>> change be welcome? Should I open an issue or just submit the patch?

Not really? Extra complexity always costs and the session resumption
is already quite complex. Now, given that we already have ticket-based
resumption, ID-based isn't that much more. However, it only benefits
poor clients. Even Windows supports tickets these days.

You might be seeing a number of clients that aren't offering ticket
support but, unless it's all old versions of SChannel, experience
suggests that even if you tried offering ID-based resumption, those
clients wouldn't actually resume. They are often robots that just
aren't setup for resumption.


Cheers

AGL

[Eric Lorimer]

Hmm...   Well, I'm not very familiar with the current state of affairs.  For web browsers, I'd guess that might be true.  (Though https://www.ssllabs.com/ssltest/clients.html shows quite a few relatively modern browsers without support).  In my particular case, we're building a service to support Android and iOS clients using custom networking code.  In one case using a popular async networking library based on Java NIO (which doesn't look like it supports tickets or at least I couldn't tell how).  And I spent a few hours this afternoon trying to get tickets working with what appear to be the standard Android libraries (android.net.SSLCertificateSocketFactory).  It looks like one needs to get an insecure factory before setUseSessionTickets works (which rather defeats much of the point of using SSL) and the default is to have them turned off.  I haven't tested if they persist across sessions.  On the other hand, android.net.SSLSessionCache and session IDs are easy to setup and persist across sessions.  I'm not an Android expert and my experience can't be generalized but it doesn't seem very easy to restrict oneself to only using libraries and APIs that work with tickets.  (I haven't even looked at our iOS clients).

To do distributed session caching right with tickets requires some sort of key generation/distribution service (and some care to make sure the keys never touch a disk).  It seems like everyone just rolls their own here.  It's unclear to me that this is always better (or easier) than server-side caching with something like a memcache pool (especially if it were already available as a third-party package).  (i.e. even if all my clients supported tickets perfectly I might still be tempted to consider server-side caching).  Ideally, one could do both or choose what makes sense.

I totally understand not wanting to complicate the existing implementation.  I made the changes locally in order to test my theories (that the clients actually do resume) and while it's quite possible that I'm missing some subtlety, it looks pretty straight-forward.  The actual resumption logic is pretty much unchanged as it gets the same sessionState structure as it would from decrypting the key.  It's about 50-100 lines of code and passes all the tests.  (It should be 100% backwards compatible).


- Eric

[igor...@gmail.com]

Hi Eric,

Did you manage to get a session ID support patch?