Add client API and example for connecting to self signed server via `serverCertificateHashes`

[TheButlah]

Add client API and example for connecting to self signed server via `serverCertificateHashes`

[BiagioFesta]

Hi,

Today, wtransport should already provide a way to cover your use case.

In particular, wtransport exposes TLS configuration backed by rustls. When creating your wtransport client configuration, a custom TLS configuration can be set with with_custom_tls. This allows you to fully customize the TLS layer.

rustls::ClientConfig allows you to create a custom certificate validator using set_certificate_verifier.

A verifier is quite easy to implement, and you can place the custom logic for certificate validation here.

Inside wtransport, the same mechanism is used to create a NoCertVerifier. You can have a look here.

Of course, in your case, your verifier can simply check against hashes.

---

Having said that, I am curious about the use case. I am wondering if the application is self-hosted, with_no_cert_validation should not have security implications (if machine-local).

Moreover, your feedback makes me wonder if wtransport might expose some wrapper around that to emulate the serverCertificateHashes.

Feel free to ask if something is not clear or if you need more information.

Thank you for your feedback.

[BiagioFesta]

Additional tips you might need:

• wtransport re-export rustls with the correct version. You should be able to get access to rustls directly via wtransport::tls::rustls See doc here.
• When creating a custom TLS layer, you should remember to set the correct ALPN. See here. It is just a "binary string". See here

[TheButlah]

expose some wrapper around that to emulate the serverCertificateHashes.

adding that to the builder would definitely be useful!

[BiagioFesta]

Before modifying wtransport interface, I would like to better understand the possible usage and use case.

Asking because W3C serverCertificateHashes has some security concerns and forces some constraints.
For example:

[...] the total length of the validity period MUST NOT exceed two weeks.

[TheButlah]

I would expect that because this is a helper function, the constraints on the native api match the constraints on the browser api. If someone needs a native client to bypass these constraints, they could reach for the lower level api.

In my case, I am using wtransport because I want my game to support web clients. Therefore I want my native clients and web clients to work similarly (so I don't find out later down the line that I'm doing something on native that is prevented in the browser apis).

as for security concerns, I send this hash out of band via a HTTPS relay, and I ensure that the hash is signed so I can prove that im not being man in the middled. I don't agree that the hashes "effectively downgrades the security properties of the resulting transport" as that poster was claiming.

[BiagioFesta]

I've opened a PR: #131

If you want to have a look and provide some feedback. Thanks