Introduce 'connect-certificate-hash' for WebTransport

[jan-ivar]

From w3c/webtransport#59 (comment): WebTransport acts like fetch wrt connect-src: https://A.com for normal use like:

const wta = new WebTransport("https://A.com");

But the API also allows websites to connect using custom hashes:

const wtb = new WebTransport("https://B.com", {serverCertificateHashes: [{algorithm: "sha-256", value}]});

For this we think we need of a new CSP keyword, something like: connect-certificate-hash: https://B.com/ e.g.

Content-Security-Policy: connect-src https://A.com/;
                         connect-certificate-hash: https://B.com/

The idea is:

• if connect-src is absent, then custom certs are allowed
• if connect-src is present, connect-certificate-hash is needed to allow custom certs

Does this make sense? Can someone help us with this?

[martinthomson]

See also https://github.com/JonathanLennox/raw-key-fingerprints

[dveditz]

I have a couple of different concerns about how this integrates with CSP.

Shape
It would be normal to create a specialized WebTransport directive so a site can specify a different set of allowed hosts for one feature compared to the more general "fall back" directive that affects multiple features (presumably connect-src). Splitting different uses of the same feature across two different directives as proposed here would be out of character and harder to specify. And also doesn't give the flexibility for people to allow WebTransport and restrict fetch() or vice-versa.

An alternative might be to create something like webtransport-src where the values could be a mix of allowed hosts (that must use a valid cert) and allowed certificate hashes (that could be used with any hostname). Or if you don't want to specify exact hashes, then a list of hostnames and an optional keyword that enables the use of certificate hashes. Because of the fallback mechanism we'd probably want a cert-hash syntax different from the integrity hashes currently used in other directives. Otherwise it will get very confusing in the degenerate case of only a default-src directive.

Purpose
I don't understand why a feature that is "safe for the web" (there's disagreement: webtransport #623) needs an "opt-in" only on sites that use a CSP. I admit this is exactly the pattern script-src uses with its 'unsafe-inline' keyword, but in that case we were dealing with an endless amount of legacy content, and blocking inline scripts by default was the prime motivator behind CSP for most of us pushing it. WebTransport doesn't have that legacy. Seems like either cert hashes are always safe, or they always require a site to opt-in whether or not it's using a CSP. The mechanism could still be CSP: a site could have content-security-policy: webtransport-src * 'unsafe-cert-hashes'; to opt in even if it didn't otherwise use any other CSP restriction or feature. Or the opt-in could live somewhere else: Permission-Policy would also make a lot of sense for an opt-in.

[dveditz]

I may be misreading your proposal. The text says "keyword", but the semi-colon after the a.com host (plus the later b.com host) made connect-certificate-hash into a separate "directive". An actual keyword like my 'unsafe-cert-hashes' example above could work as an opt-in (note the single quotes that signify it is not a hostname).

I'm also unclear on what threat this is trying to address. WebTransport requires script, and if you have malicious script running on your page then CSP has already failed you. If it's about exfiltration then the hostname should be good enough, or at least as good as anything else CSP tries to protect. If you have a true MITM going on then the CSP itself could be modified or removed. This seems to address a very narrow case of an active network attacker who can re-route requests, can't modify the document/CSP on the network, but still has found a way to inject scripts into the victim page.