You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HelloRetryRequest may be sent to the client for a range of reasons, for example, to set TLS 1.3 "Cookie" extension and "demonstrate reachability at their apparent network address (thus providing a measure of DoS protection)". Client is expected to handle this case correctly.
curveID := hs.serverHello.selectedGroup
if curveID == 0 {
c.sendAlert(alertMissingExtension)
return errors.New("tls: received HelloRetryRequest without selected group")
}
and
if hs.ecdheParams.CurveID() == curveID {
c.sendAlert(alertIllegalParameter)
return errors.New("tls: server sent an unnecessary HelloRetryRequest message")
}
which essentially require HelloRetryRequest to switch curve ID. However, as mentioned above, there are other use-cases for that complicated HelloRetryRequest.
Cookie seems to be correctly added to the follow-up ClientHello, if curve changes as well.
I am not aware of any servers on the internet that actually send HelloRetryRequest for any reason other than to switch curve in Key Share (are there any such servers?), so not sure if there's any real-world impact.
The text was updated successfully, but these errors were encountered:
Clients have to reject any HelloRetryRequest message that doesn't lead
to a change in the ClientHello. Instead, we were rejecting any HRR that
didn't select an alternative group, even if it sent a cookie, which
would change the CH.
The good news is that I know of no TLS servers that use or need HRRs
exclusively for cookies (which are mostly useful in DTLS as a way to
verify the source address). The bad news is that we poisoned the
ecosystem as Go 1.12 to 1.14 will reject such HRRs. Oops, hopefully no
one needed this.
No tests because neither Go nor s_server support cookies. This would
presumably get covered once we integrate BoGo.
Fixesgolang#30149
Change-Id: I760fb1ded81148ac3096cf201cbc1e941374b83d
Reviewed-on: https://go-review.googlesource.com/c/go/+/231039
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
What version of Go are you using (
go version
)?master @ ca7c12d
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Read the source code.
What did you expect to see?
HelloRetryRequest may be sent to the client for a range of reasons, for example, to set TLS 1.3 "Cookie" extension and "demonstrate reachability at their apparent network address (thus providing a measure of DoS protection)". Client is expected to handle this case correctly.
What did you see instead?
Client has following checks:
and
which essentially require HelloRetryRequest to switch curve ID. However, as mentioned above, there are other use-cases for that complicated HelloRetryRequest.
Cookie seems to be correctly added to the follow-up ClientHello, if curve changes as well.
I am not aware of any servers on the internet that actually send HelloRetryRequest for any reason other than to switch curve in Key Share (are there any such servers?), so not sure if there's any real-world impact.
The text was updated successfully, but these errors were encountered: