Intent to Ship: WebTransport serverCertificateHashes option
Victor Vasiliev
Contact emails
yhi...@chromium.org, vas...@chromium.org
Explainer
https://github.com/w3c/webtransport/blob/main/explainer.md
Spec
https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes
WebTransport has been already covered by a series of TAG reviews (389, 669).
Summary
In WebTransport, the serverCertificateHashes option allows the website to connect to a WebTransport server by authenticating the certificate against the expected certificate hash instead of using the Web PKI. This feature allows Web developers to connect to WebTransport servers that would normally find obtaining a publicly trusted certificate challenging, such as hosts that are not publically routable, or virtual machines that are ephemeral in nature.
During the WebTransport Intent to Ship email thread, concerns were raised regarding the security considerations of this portion of the spec being incomplete. We believe that we have addressed those concerns (notably, in this PR). In terms of the actual code behavior, the only major difference since the previous thread is that we no longer allow RSA keys for the certificates.
Link to “Intent to Prototype” blink-dev discussion
https://groups.google.com/a/chromium.org/g/blink-dev/c/I6MS2kOKcx0/m/NAdg7Sc-CwAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Debuggability
The certificate-related errors for WebTransport sessions are logged into the developer console.
Measurement
The use of this feature is tracked by the WebTransportServerCertificateHashes use counter.
Risks
Interoperability and Compatibility
There is some discussion about adding a mechanism to prevent websites from using this feature via an HTTP header (either CSP or a new header). Some of the proposals could potentially break existing usage under certain conditions (e.g. if a webpage both uses serverCertificateHashes and has a connect-src directive, and we decide to extend connect-src); I expect for those cases to be sufficiently niche to ultimately not be a problem, and the question itself is of fairly low priority as there does not seem to be a strong security reason for a website to restrict serverCertificateHashes.
Gecko: worth prototyping
WebKit: no signal
Web / Framework developers: positive (we have received indication in the past that serverCertificateHashes is a blocker for migrating from WebRTC at least one of them)
Ergonomics
The API is roughly modeled after a similar WebRTC API (RtcDtlsFingerprint), with a noted improvement that the certificate hash no longer requires to be serialized into a specific format.
Activation
Using this feature would require web developers to design their application in a way that supports generating and distributing ephemeral certificates on demand.
Security
Security considerations for this feature are discussed at length in PR #375.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
WebTransport itself is tested by web-platform-tests; this specific feature requires infra support that is currently not available (issue).
Entry on the feature dashboard
Yoav Weiss
Contact emails
yhi...@chromium.org, vas...@chromium.org
Explainer
https://github.com/w3c/webtransport/blob/main/explainer.md
Spec
https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes
WebTransport has been already covered by a series of TAG reviews (389, 669).
Summary
In WebTransport, the serverCertificateHashes option allows the website to connect to a WebTransport server by authenticating the certificate against the expected certificate hash instead of using the Web PKI. This feature allows Web developers to connect to WebTransport servers that would normally find obtaining a publicly trusted certificate challenging, such as hosts that are not publically routable, or virtual machines that are ephemeral in nature.
During the WebTransport Intent to Ship email thread, concerns were raised regarding the security considerations of this portion of the spec being incomplete. We believe that we have addressed those concerns (notably, in this PR).
In terms of the actual code behavior, the only major difference since the previous thread is that we no longer allow RSA keys for the certificates.
Link to “Intent to Prototype” blink-dev discussion
https://groups.google.com/a/chromium.org/g/blink-dev/c/I6MS2kOKcx0/m/NAdg7Sc-CwAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Debuggability
The certificate-related errors for WebTransport sessions are logged into the developer console.
Measurement
The use of this feature is tracked by the WebTransportServerCertificateHashes use counter.
Risks
Interoperability and Compatibility
There is some discussion about adding a mechanism to prevent websites from using this feature via an HTTP header (either CSP or a new header). Some of the proposals could potentially break existing usage under certain conditions (e.g. if a webpage both uses serverCertificateHashes and has a connect-src directive, and we decide to extend connect-src); I expect for those cases to be sufficiently niche to ultimately not be a problem, and the question itself is of fairly low priority as there does not seem to be a strong security reason for a website to restrict serverCertificateHashes.
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a591c7e-ef31-4015-8b34-256e12bcfce3n%40chromium.org.
Victor Vasiliev
During the WebTransport Intent to Ship email thread, concerns were raised regarding the security considerations of this portion of the spec being incomplete. We believe that we have addressed those concerns (notably, in this PR).
Please followup on the PR to ensure it lands. Thanks! :)
Interoperability and Compatibility
There is some discussion about adding a mechanism to prevent websites from using this feature via an HTTP header (either CSP or a new header). Some of the proposals could potentially break existing usage under certain conditions (e.g. if a webpage both uses serverCertificateHashes and has a connect-src directive, and we decide to extend connect-src); I expect for those cases to be sufficiently niche to ultimately not be a problem, and the question itself is of fairly low priority as there does not seem to be a strong security reason for a website to restrict serverCertificateHashes.
Are you planning to file a separate intent once those plans materialize?
Victor Vasiliev
Daniel Bratell
LGTM3
Comment about double checking the security review stands.
(We decided this was fine two weeks ago but not all the necessary mails ended up on the list - our fault, good that you pinged us!)
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZdMaetk7JoQ-gOmhcPKgRh2uo%2BnKNeG%3DYOF%3Dnrat0YVPUgBQ%40mail.gmail.com.
Joe Medley
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/546df1df-f975-85d1-ff9b-b59eadeab4a8%40gmail.com.