Adding support for session ID-based TLS session reuse

[Ben Kehoe]

I am interested in contributing session ID-based session resumption support to the crypto/tls package.

The crypto/tls package supports RFC 5077-style session resumption, which uses a TLS extension. In the first connection, the server passes an opaque, encrypted session ticket to the client, who sends the ticket to the server in the client hello of the next connection along with a random session identifier. If the server accepts the ticket for resumption, it responds with the same session id, and the full handshake is skipped.

However, the TLS spec describes a different mechanism (not extension-based) for session reuse: in the first connection, the server provides a session identifier in the server hello. In the next connection, the client hello includes that same session identifier. If the server has the session cached, it responds with that session id in the server hello. While the RFC 5077 method is more scalable, resource-constrained clients may not want to store large session tickets.

This change is minor in code terms; clientSessionState gains a sessionId field, which is set only if there is no session ticket. This session ID is used for the client hello if there is no ticket in the cached state. Recognition of the session id being resumed happens using the existing code that matches session IDs between the hello messages.

I don't think it would be worthwhile to implement support for this for the server code, as it would require more extensive code changes, is a resource-hungry way to do session reuse, and doesn't play well with load balancing (exactly why RFC 5077 was created). However, this creates a dilemma: most of the tests use symmetric support in the client and server to test one against the other.

Any advice on acceptability for inclusion would be appreciated.

--Ben

[Ian Lance Taylor]

[ +agl ]

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

[Adam Langley]

On Fri, Jul 31, 2015 at 9:50 AM, Ian Lance Taylor <ia...@golang.org> wrote:
> [ +agl ]
>
> On Fri, Jul 31, 2015 at 7:34 AM, Ben Kehoe <bke...@irobot.com> wrote:
>> I don't think it would be worthwhile to implement support for this for the
>> server code, as it would require more extensive code changes, is a
>> resource-hungry way to do session reuse, and doesn't play well with load
>> balancing (exactly why RFC 5077 was created). However, this creates a
>> dilemma: most of the tests use symmetric support in the client and server to
>> test one against the other.
>> Any advice on acceptability for inclusion would be appreciated.

Supported session-id resumption in the client would be reasonable. Not
so much in the server, as you note.

For testing, the golden-files approach would probably be needed
against an OpenSSL server.


Cheers

AGL

[Igor Gatis]

What is the current status? Is session ID supported?

I agree session ticket is the way to go. But it is useful for old TLS client implementations.

I have 10k terminals which do HTTPS requests over gprs. TLS handshake alone costs ~4s. With ip-based server affinity and session ID support, latency for these terminals could improve by impressive 50%!