Repository: go
Issue: crypto/tls: session resumption fails with a cloned tls.Config
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.20.3 darwin/arm64
</pre>

### Does this issue reproduce with the latest release?

Yes, reproduced with tip.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/marten/Library/Caches/go-build"
GOENV="/Users/marten/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/marten/src/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/marten/src/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/marten/bin/go1.20ex"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/marten/bin/go1.20ex/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.20.3"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/q0/b5ynf00142l7bl9sp8y098zr0000gn/T/go-build2554136632=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

I take a (potentially user-provided) `tls.Config`, clone it and start the first TLS server. I then connect to this server with a TLS client and obtain a session ticket.
I then start a second server using a clone of the same `Config` under the same IP and port, and have the TLS client connect to it. 

This is exactly what a 0-RTT enabled QUIC stack needs to do to support 0-RTT resumption: every incoming QUIC connection needs to use a clone of the original `tls.Config`. This is because it needs to wrap the user-provided `WrapSession` and `UnwrapSession` callback on the `tls.Config` (see [here](https://github.com/quic-go/quic-go/blob/aa1c1a50b2fdf054d26cf23b3c27d078971db5e9/internal/qtls/go121.go#L57-L97) for the corresponding code in quic-go).

### What did you expect to see?

I expected session resumption to succeed.

### What did you see instead?

The client uses the ticket obtained from the first connection, but session resumption fails. This is because the session ticket keys on the `tls.Config` are lazily initialized.

I currently [work around](https://github.com/quic-go/quic-go/blob/aa1c1a50b2fdf054d26cf23b3c27d078971db5e9/internal/qtls/go121.go#L48) this by explicitly calling `tls.Config.DecryptTicket` with an arbitrary value for the ticket, since this triggers initialization of the session ticket keys. A cleaner way would be to initialize session ticket keys on `Clone` (potentially restricted to configs that can be used for the server, i.e. have `Certificates` or `GetCertificate` configured for performance reasons).

cc @FiloSottile