Consider removing serverCertificateHashes

[annevk]

Without more restrictions this feature could lead to the same kind of problem plaguing Web Push, where messages are not end-to-end encrypted because it's easier to let middleware worry about the complexity of encryption and dealing with the Web Browser Endpoint in general.

I also heard that the main motivation for this feature is local development and testing, which does not meet the high bar we have for web platform features.

As things stand today WebKit does not intend to implement this.

[vasilvv]

Without more restrictions this feature could lead to the same kind of problem plaguing Web Push, where messages are not end-to-end encrypted because it's easier to let middleware worry about the complexity of encryption and dealing with the Web Browser Endpoint in general.

I do not understand this comparison. What does Web Push or middleware has to do with serverCertificateHashes?

I also heard that the main motivation for this feature is local development and testing, which does not meet the high bar we have for web platform features.

This is not correct; the motivation for this feature is to provide the ability to connect to endpoints that cannot have a publicly trusted certificate, in order to have feature parity with WebRTC in that regard. The original reasoning for adding it is documented in #18. Since that discussion happened, more motivation came from scenarios like WICG/private-network-access#23.

[annevk]

I do not understand this comparison. What does Web Push or middleware has to do with serverCertificateHashes?

The risk that people will just use a shared private certificate across a range of devices just to get this to work without actually caring much about end user security.

And while there is definitely a need for some kind of HTTPS for local networks, we should not solve it on a per-API basis.

[youennf]

in order to have feature parity with WebRTC in that regard

WebRTC is peer-to-peer hence the current solution for WebRTC.
WebTransport being client/server, it seems more consistent to stick with what other client/server networking stacks like HTTP or WebSocket are doing.

[vasilvv]

The risk that people will just use a shared private certificate across a range of devices just to get this to work without actually caring much about end user security.

We have discussed this issue previously in #349; this resulted in an expiry requirement being added, as documented in https://w3c.github.io/webtransport/#certificate-hashes.

[annevk]

I don't see how that addresses the concern. You can generate fresh certificates with a shared private key quite easily, but it's not actually secure.

[vasilvv]

You can generate fresh certificates with a shared private key quite easily, but it's not actually secure.

I don't believe this is in any way different from regular Web PKI certificates.

[jan-ivar]

Meeting:

• Write down all the reasons this is ok
• @jesup to check Mozilla position
• See also WebTransport mozilla/standards-positions#167 (comment)

[annevk]

@vasilvv regular certificates have all kinds of safeguards, including being able to distrust the root if practices like this were to be discovered.

[vasilvv]

As far as I am aware, there isn't anything in CA/B BR that requires CAs to check for private key reuse; furthermore, as far as I am aware, reusing private keys is not uncommon in practice.

[martenrichter]

Just a few thoughts: I use the hashes for:
a) Development, as webtransport has no HTTP. I was not able to set up a development setup without it.
b) For VMs rented from cloud providers. Without this mechanism, one must at least integrate them into a DNS domain for let's encrypt to work. Or set up some automated CA issuer. All this requires a much more infrastructure. (Currently I have to do both because of the websocket fallback).

Regarding reusing certificates:
c.) Yes, people do stupid things, but it would always be bound to the JS code of a particular website. So, if this is compromised, everything is already lost.
d.) One may decide that the IP (for the VM use case) or hostname is set on the CN field and is checked (in the moment 0.0.0.0) and forbid wildcards. In this way, mechanisms are in place to generate certificates for each client individually.

Support in Firefox:
e) In light of this discussion, did Mozilla break serverCertificateHashes intentionally (It requires a root CA in the moment):
https://bugzilla.mozilla.org/show_bug.cgi?id=1934402
f) If no, does it make sense to patch it?
g) Would it make sense to invest time to provide time for a wpt test to prevent such breakage? Or may it happen fast that the feature is removed?

Of course, I would prefer that Webkit support the hashes. But for a web app it may also be an option to recommend other browsers if European DMA results in Gecko and Blink appearing on iOS etc.

[martenrichter]

Regarding e-g) I have made it anyway: https://phabricator.services.mozilla.com/D231479 .

[martinthomson]

messages are not end-to-end encrypted

I want to address this, because it is a misconception about this feature.

Consider the two cases where a site, "https://some.example" say, initiates a WebTransport connection:

1. The site specifies a domain name: "https://example.com".
2. The site specifies a certificate hash (some long hex string).

In neither case does the identity of the WebTransport host come from something that the user specifies. The root of trust is the site.

In both cases, an attack on the site that results in providing the wrong server identity causes the connection to be vulnerable to interception.

The only difference that I've been able to identify is that the identity of the server in the first case will be logged in a CT log somewhere.

The risk that people will just use a shared private certificate across a range of devices just to get this to work

The identified remedy is only capable of making the API a modest amount harder to use. It doesn't change the security posture meaningfully. Servers like Caddy or tools like mkcert largely eliminate those differences. Of course, the use of the WebPKI tends to lead to people sharing the same private key across a range of devices as well, so it's a bit meaningless.

This feature exists in support of rapid deployment, which includes development scenarios. While I'm somewhat ambivalent about its general utility in a world that includes widespread ACME deployment, I don't think that there's a meaningful security argument for its removal.