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

+1

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

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

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.

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.

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