Skip to content
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 · 6 comments

Comments

Projects
None yet
7 participants
@FiloSottile
Copy link
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.

Copy link
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.

Copy link
Contributor

oxtoacart commented Jun 27, 2018

+1

@igolaizola

This comment has been minimized.

Copy link

igolaizola 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/igolaizola/resume-tls

@glerchundi

This comment has been minimized.

Copy link

glerchundi commented Aug 23, 2018

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

@igolaizola

This comment has been minimized.

Copy link

igolaizola 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.

@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019

@petar-donchev

This comment has been minimized.

Copy link

petar-donchev commented Mar 18, 2019

A serializable TLS connection would be useful on the server side as well, for example when the transport protocol in not TCP, but wrapped inside another protocol - like RADIUS PEAP (EAP over TLS over RADIUS over UDP). I imagine security-wise if someone has access to the serialized connection, they have the session secret one way or another, but for some cases this might not be worse than having access to server transient storage already is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.