crypto/tls: make ClientSessionState serializable

[FiloSottile]

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]

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]

+1

[igolaizola]

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]

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

[igolaizola]

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.

[petar-donchev]

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.

[gopherbot]

Change https://go.dev/cl/496820 mentions this issue: crypto/tls: add ClientSessionState.ResumptionState and NewResumptionState