Unable to connect with self-signed certificate about webtransport-go HOT 16 CLOSED

This is unrelated to WebTransport. You'll get exactly the same error when using crypto/tls over TCP with your certificate configuration.

from webtransport-go.

Part of the reason I'm investigating WebTransport was because it was supposed to be able to support connections using self-signed certificates through the certhash: https://blog.libp2p.io/2022-12-19-libp2p-webtransport/#meet-webtransport

I'd also like to connect via QUIC, not TCP, and from the readme it should be opening a UDP port on 443. Is this not the case?

from webtransport-go.

Part of the reason I'm investigating WebTransport was because it was supposed to be able to support connections using self-signed certificates through the certhash: https://blog.libp2p.io/2022-12-19-libp2p-webtransport/#meet-webtransport

There seems to be some severe confusion here. This applies to the browser API only.

from webtransport-go.

This doesn't appear to be specified in the RFC, and none of the documentation makes mention that this is only a browser behavior. If non-browser clients are explicitly not supported, then can this at least be reflected in the documentation?

from webtransport-go.

If non-browser clients are explicitly not supported, then can this at least be reflected in the documentation?

This is wrong again. Browsers are supported. We even have an explicit test for that in CI.

I encourage you to read the RFC and the W3C specification, and to familiarize yourself with crypto/tls.

from webtransport-go.

I understand that much of the reference material discusses browsers as this is the primary targeted use case. I have not seen mention that non-browser clients are explicitly not supported though. I've reviewed these references in addition to the first link I posted:

https://www.w3.org/TR/webtransport/#certificate-hashes
https://github.com/libp2p/specs/tree/master/webtransport
https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/

The closest I've found that any come is this:

The most exciting feature for libp2p (other than the numerous performance benefits that QUIC gives us) is that the W3C added a browser API allowing browsers to establish connections to nodes with self-signed certificates

I get that it specified "browser API allowing browsers", but much of the documentation uses the terms browser and client interchangeably and prior to this conversation, I haven't seen anything differentiate between browser clients and non-browser clients. If that's the case, that's fine, and I'll look into other approaches, but could I at least propose adding a line to the readme stating that non-browser clients are not permitted to use self-signed certs?

from webtransport-go.

This is wrong again. Browsers are supported.

I think there was some miscommunication here. I'm not saying browsers aren't supported, just that it was unclear this was a browser-only feature based on what I'd reviewed.

from webtransport-go.

I understand that much of the reference material discusses browsers as this is the primary targeted use case. I have not seen mention that non-browser clients are explicitly not supported though.

You haven't seen this because this is not correct. As I said before, the behavior you're seeing is equivalent to what you'd see when using crypto/tls. WebTransport isn't doing anything special regarding certificate verification, it just uses the Go standard library crypto/tls package, giving you all the flexibility that comes with that. Please refer to the documentation of the standard library.

Specifically, if you want to accept self-signed certificates, you need to set InsecureSkipVerify to true, and implement certificate verification yourself. See the go-libp2p implementation for how to verify certificate hashes.

from webtransport-go.

Is use of the certhash endpoint a browser-only feature or not? In this reply, you state "This applies to the browser API only." But now you're saying that my statement that non-browser clients are explicitly not supported to use the certhash endpoint is incorrect.

from webtransport-go.

Non-browsers are free to implement whatever certificate validation logic they please.

from webtransport-go.

But the library doesn't come with support for it and this is a conscious design choice correct? It has to be implmented on by users of the library.

from webtransport-go.

Support for what?

from webtransport-go.

Using the certhash endpoint as an alternate means of validating a certificate.

from webtransport-go.

You're confusing the layers here. webtransport-go doesn't concern itself with certificate verification. It is simply an implementation of the IETF draft.

from webtransport-go.

I see. I was mistaking links in the connectivity page. This appears to be what I was looking for. Apologies for the confusion.

from webtransport-go.

No worries, I know it's a bit confusing having one IETF and one W3C WebTransport spec.

from webtransport-go.