New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/tls: make ClientSessionState serializable #25351

Open
FiloSottile opened this Issue May 11, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@FiloSottile
Member

FiloSottile commented May 11, 2018

The ClientSessionCache interface passes ClientSessionState objects to the application to hold on to. Since these objects are opaque, they can only be held in memory, and they can't be saved or synchronized.

We should add a way to serialize and deserialize these objects, without making promises about their contents, but aiming for backwards compatibility if possible. Probably worth doing after 1.3 so that we skip that format change.

This can probably be just an implementation of BinaryMarshaler and BinaryUnmarshaler.

There isn't even a forward secrecy concern here because in 1.2 the tickets are sent in plaintext with the connection (sigh), and in 1.3 there's a DH round anyway.

See also #19199 and #25228 for the server-side story of keeping state.

@DanielMorsing

This comment has been minimized.

Contributor

DanielMorsing commented May 11, 2018

While the session tickets are sent over the network, the master secret that needs to be stored is not. I'm not sure if that might cause any issues with secrecy between programs running on the same machine

@oxtoacart

This comment has been minimized.

Contributor

oxtoacart commented Jun 27, 2018

+1

@igarciaolaizola

This comment has been minimized.

igarciaolaizola commented Aug 23, 2018

A serializable ClientSessionState would help the task or resuming TLS connections from an external data storage (other than memory).
But wouldn't it be nice to have a way to resume a TLS state without performing any additional handshake. Perhaps serializing/loading the necessary data from tls.Conn?

I have a proposal here where some handshake data is stored and sequential numbers are retrieved and loaded with some reflection code: https://github.com/igarciaolaizola/resume-tls

@glerchundi

This comment has been minimized.

glerchundi commented Aug 23, 2018

I didn't know this is even possible! How is this from a security standpoint? /cc @FiloSottile

@igarciaolaizola

This comment has been minimized.

igarciaolaizola commented Aug 23, 2018

I didn't know this is even possible! How is this from a security standpoint? /cc @FiloSottile

@glerchundi If you asking about my proposal, I guess it has the same security problems as if someone could intercept the handshake messages and count the received and transmitted packages, but I am not a TLS expert. The code it's just a quick proof of concept.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment