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: don't overwrite Config.sessionTicketKeys if already set #15421

Closed
wmark opened this issue Apr 23, 2016 · 3 comments
Closed

crypto/tls: don't overwrite Config.sessionTicketKeys if already set #15421

wmark opened this issue Apr 23, 2016 · 3 comments
Assignees
Milestone

Comments

@wmark
Copy link

@wmark wmark commented Apr 23, 2016

With Go 1.6.2 and earlier and in tls.Config, serverInit() overwrites effects of a prior SetSessionTicketKeys().

Initializing SessionTicketKey to an arbitrary non-null value does not sort this in case of TLS ticket key rotation: SetSessionTicketKeys() could have already been called several times without being allowed to update that lone field because »after [tls.Config has] been passed to a TLS function it must not be modified«.

I expected serverInit() to:

diff --git a/src/crypto/tls/common.go b/src/crypto/tls/common.go
index c68ebfe..94be97e 100644
--- a/src/crypto/tls/common.go
+++ b/src/crypto/tls/common.go
@@ -388,6 +388,9 @@ func (c *Config) serverInit() {
        if c.SessionTicketsDisabled {
                return
        }
+       if len(c.ticketKeys()) > 0 {
+               return
+       }

        alreadySet := false
        for _, b := range c.SessionTicketKey {
@wmark

This comment has been minimized.

Copy link
Author

@wmark wmark commented Apr 23, 2016

go/src/crypto/tls/common.go

Lines 424 to 435 in 57e459e

func (c *Config) SetSessionTicketKeys(keys [][32]byte) {
if len(keys) == 0 {
panic("tls: keys must have at least one key")
}
newKeys := make([]ticketKey, len(keys))
for i, bytes := range keys {
newKeys[i] = ticketKeyFromBytes(bytes)
}
c.mutex.Lock()
c.sessionTicketKeys = newKeys

go/src/crypto/tls/common.go

Lines 387 to 407 in 57e459e

func (c *Config) serverInit() {
if c.SessionTicketsDisabled {
return
}
alreadySet := false
for _, b := range c.SessionTicketKey {
if b != 0 {
alreadySet = true
break
}
}
if !alreadySet {
if _, err := io.ReadFull(c.rand(), c.SessionTicketKey[:]); err != nil {
c.SessionTicketsDisabled = true
return
}
}
c.sessionTicketKeys = []ticketKey{ticketKeyFromBytes(c.SessionTicketKey)}

wmark added a commit to caddyserver/caddy that referenced this issue Apr 23, 2016
[1] https://github.com/golang/go/blob/57e459e02b4b01567f92542f92cd9afde209e193/src/crypto/tls/common.go#L424
[2] https://github.com/golang/go/blob/57e459e02b4b01567f92542f92cd9afde209e193/src/crypto/tls/common.go#L392-L407

[2] has overwritten the first tls ticket key on round N=0, that has previously
been written using [1].

Go's stdlib does not use c.sessionTicketKeys≥1 as indicator if those values had
already been set; initializing that lone SessionTicketKey does the job for for
now.
    If c.serverInit() were called in round N+1 all existing tls ticket keys
are being overwritten (in round N<4 except the very first one, of course).
Member variables for tls.Config are read-only by then, so we cannot just keep
updating SessionTicketKey as well.

This has been escalated to upstream with golang/go#15421 here:
golang/go#15421

Thanks to Matthew Holt for the initial report!
wmark added a commit to caddyserver/caddy that referenced this issue Apr 23, 2016
…#785)

[1] https://github.com/golang/go/blob/57e459e02b4b01567f92542f92cd9afde209e193/src/crypto/tls/common.go#L424
[2] https://github.com/golang/go/blob/57e459e02b4b01567f92542f92cd9afde209e193/src/crypto/tls/common.go#L392-L407

[2] has overwritten the first tls ticket key on round N=0, that has previously
been written using [1].

Go's stdlib does not use c.sessionTicketKeys≥1 as indicator if those values had
already been set; initializing that lone SessionTicketKey does the job for for
now.
    If c.serverInit() were called in round N+1 all existing tls ticket keys
would be overwritten (in round N<4 except the very first one, of course).
As member variables of tls.Config are read-only by then, we cannot keep
updating SessionTicketKey as well.

This has been escalated to Go's authors with golang/go#15421 here:
golang/go#15421

Thanks to Matthew Holt for the initial report!
@bradfitz bradfitz changed the title tls: Don't overwerwrite tls.Config.sessionTicketKeys if already set crypto/tls: Don't overwerwrite tls.Config.sessionTicketKeys if already set Apr 23, 2016
@bradfitz bradfitz added this to the Unplanned milestone Apr 23, 2016
@bradfitz bradfitz changed the title crypto/tls: Don't overwerwrite tls.Config.sessionTicketKeys if already set crypto/tls: don't overwrite Config.sessionTicketKeys if already set Apr 23, 2016
Burmudar added a commit to Burmudar/caddy that referenced this issue Apr 24, 2016
…caddyserver#785)

[1] https://github.com/golang/go/blob/57e459e02b4b01567f92542f92cd9afde209e193/src/crypto/tls/common.go#L424
[2] https://github.com/golang/go/blob/57e459e02b4b01567f92542f92cd9afde209e193/src/crypto/tls/common.go#L392-L407

[2] has overwritten the first tls ticket key on round N=0, that has previously
been written using [1].

Go's stdlib does not use c.sessionTicketKeys≥1 as indicator if those values had
already been set; initializing that lone SessionTicketKey does the job for for
now.
    If c.serverInit() were called in round N+1 all existing tls ticket keys
would be overwritten (in round N<4 except the very first one, of course).
As member variables of tls.Config are read-only by then, we cannot keep
updating SessionTicketKey as well.

This has been escalated to Go's authors with golang/go#15421 here:
golang/go#15421

Thanks to Matthew Holt for the initial report!
@wmark

This comment has been minimized.

Copy link
Author

@wmark wmark commented Aug 8, 2016

Given that this is a minor bugfix, any chance to see this in Go 1.7 or 1.8?

@bradfitz bradfitz modified the milestones: Go1.8, Unplanned Aug 8, 2016
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Aug 18, 2016

CL https://golang.org/cl/27317 mentions this issue.

@gopherbot gopherbot closed this in 4e79c15 Aug 18, 2016
@golang golang locked and limited conversation to collaborators Aug 18, 2017
FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018
If SetSessionTicketKeys was called on a fresh tls.Config, the configured
keys would be overridden with a random key by serverInit.

Fixes golang#15421.

Change-Id: I5d6cc81fc3e5de4dfa15eb614d102fb886150d1b
Reviewed-on: https://go-review.googlesource.com/27317
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018
If SetSessionTicketKeys was called on a fresh tls.Config, the configured
keys would be overridden with a random key by serverInit.

Fixes golang#15421.

Change-Id: I5d6cc81fc3e5de4dfa15eb614d102fb886150d1b
Reviewed-on: https://go-review.googlesource.com/27317
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.