Go version
go 1.25, gotip as of 1bd5dbf
Output of go env in your module/workspace:
AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/espadolini/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/espadolini/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/lz/zx55m0p53qvc7yqvfmkcln5r0000gn/T/go-build936092076=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/Users/espadolini/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/espadolini/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/espadolini/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.25.6.darwin-arm64'
GOSUMDB='sum.golang.org'
GOTELEMETRY='off'
GOTELEMETRYDIR='/Users/espadolini/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/espadolini/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.25.6.darwin-arm64/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.25.6'
GOWORK=''
PKG_CONFIG='pkg-config'
What did you do?
Use a tls.Config for a TLS server with a zero SessionTicketKey and without calling SetSessionTicketKeys.
What did you see happen?
Depending on when incoming connections are served and when new ticket keys are generated, the oldest ticket key that's still considered valid can be up to 8 days old rather than 7 days old as documented in tls.Config. This is because the early exit in (*tls.Config).ticketKeys only checks the creation time of the most recent ticket key, so if a new connection triggers the creation of a new ticket key when the oldest is 6d23h59m59s old, that oldest key will be considered valid to decrypt tickets until the new ticket key is 1d old, so up to 7d23h59m59s.
What did you expect to see?
I expected the oldest ticket key to be considered invalid as soon as its creation time becomes 7 days old.
Go version
go 1.25, gotip as of 1bd5dbf
Output of
go envin your module/workspace:What did you do?
Use a
tls.Configfor a TLS server with a zeroSessionTicketKeyand without callingSetSessionTicketKeys.What did you see happen?
Depending on when incoming connections are served and when new ticket keys are generated, the oldest ticket key that's still considered valid can be up to 8 days old rather than 7 days old as documented in
tls.Config. This is because the early exit in(*tls.Config).ticketKeysonly checks the creation time of the most recent ticket key, so if a new connection triggers the creation of a new ticket key when the oldest is 6d23h59m59s old, that oldest key will be considered valid to decrypt tickets until the new ticket key is 1d old, so up to 7d23h59m59s.What did you expect to see?
I expected the oldest ticket key to be considered invalid as soon as its creation time becomes 7 days old.