crypto/tls: add fields to ClientHelloInfo

[FiloSottile]

ClientHelloInfo is how callbacks make decisions on how to treat an incoming connection, which is becoming very powerful with https://golang.org/cl/30790/

As mentioned in #16066 (comment) it would be useful to have some more information in there.

The Cloudflare fork exposes Version, SignatureSchemes and LocalAddr. RemoteAddr seems fitting for completeness. ALPNProtocols as asked in #16066.

Looking at clientHelloMsg, only session resumption information, ocspStapling and scts are left, for which I can't think of a use case.

[titanous]

Looking at clientHelloMsg, only session resumption information, ocspStapling and scts are left, for which I can't think of a use case.

It would be useful to have access to all of the information provided in the ClientHello to collect statistics on handshakes.

[FiloSottile]

@titanous Something we did again in the Cloudflare fork is expose the serialized CH in the ConnectionState, but I don't think anything that low-level fits in the standard library. Or did you have anything else in mind?

[titanous]

Something we did again in the Cloudflare fork is expose the serialized CH in the ConnectionState, but I don't think anything that low-level fits in the standard library. Or did you have anything else in mind?

It's not unprecedented. x509.Certificate has a bunch of Raw* fields. Another option would be exposing all parameters/extensions that the package is aware of and then using a single field for all unknown extensions.

[FiloSottile]

True, but then I would go for having a high-level CHI, and a RawClientHello, rather than polluting CHI with sort-of-raw fields. Opinions on whether it should go on CHI or on ConnState? We wanted it in ConnState so we could observe it from a http.Handler. Maybe ConnectionState should expose a CHI?

Also, in 1.3 a CH might be a significant chunk of memory to keep around.

[FiloSottile]

Here is my patch on top of https://golang.org/cl/30790/, which I can't submit yet because the Go Gerrit does not seem to support CL with dependencies on CLs by other authors.

SupportedVersions is terrible, but needed to be forward-compatible with the TLS 1.3 extension-based version negotiation. The SignatureSchemes term is stolen from 1.3 and is uint16 to be forward-compatible.

/cc @agl

EDIT: patch mailed

[bradfitz]

@agl, decision?

[gopherbot]

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