Closed fishboy25uk closed 4 years ago
We don't surface values to the application when there is no other use case than fingerprinting. Not because fingerprinting is not a valid use case, but because it asymptotically tends to require access to everything, polluting the API.
Instead, I usually recommend making a net.Conn
wrapper that reads the ClientHello off the wire and makes all of the details available as needed.
Adding to proposal minutes, seems headed for likely decline.
Based on the discussion above, this seems like a likely decline.
No change in consensus, so declined.
The clientHelloMsg unmarshal function (in handshake_messages.go) currently exports client information such as supported cipher suites and curves but does not export a list of supported extensions in the form of a uint16 slice. Client extension information is already parsed so this would be a simple mod. Modification of the ClientHelloInfo struct (common.go) and the clientHelloInfo functions (handshake_server.go) would also be required to export this info in the GetConfigForClient callback.
A use case for this would be to allow for TLS server client fingerprinting on the server side using JA3 (https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967).