Intent to Ship: WebTransport serverCertificateHashes option

429 views
Skip to first unread message

Victor Vasiliev

unread,
Jan 20, 2022, 1:08:59 AM1/20/22
to blink-dev

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

https://chromestatus.com/feature/5690646332440576

Yoav Weiss

unread,
Feb 2, 2022, 6:28:34 AM2/2/22
to blink-dev, Victor Vasiliev
LGTM1

On Thursday, January 20, 2022 at 7:08:59 AM UTC+1 Victor Vasiliev wrote:

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).


Please followup on the PR to ensure it lands. Thanks! :)
 

  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.


Are you planning to file a separate intent once those plans materialize?

Chris Harrelson

unread,
Feb 2, 2022, 11:53:23 AM2/2/22
to Yoav Weiss, blink-dev, Victor Vasiliev
LGTM2

My understanding is that there is a security/privacy review ongoing to double-check this feature, so if there is an LGTM3 please make sure that review has concluded as well.

--
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

unread,
Feb 7, 2022, 4:36:33 PM2/7/22
to Yoav Weiss, blink-dev
On Wed, Feb 2, 2022 at 6:28 AM Yoav Weiss <yoav...@chromium.org> wrote:

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! :)

Will do!  I believe we're almost there, though this might have to wait until the next WG meeting.
 
 

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?

Yes, that is the intention.

Victor Vasiliev

unread,
Feb 16, 2022, 7:39:50 AM2/16/22
to Chris Harrelson, Yoav Weiss, blink-dev
Friendly ping.

Daniel Bratell

unread,
Feb 16, 2022, 11:20:07 AM2/16/22
to Victor Vasiliev, Chris Harrelson, Yoav Weiss, blink-dev

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

Joe Medley

unread,
Feb 16, 2022, 12:14:37 PM2/16/22
to Daniel Bratell, Victor Vasiliev, Chris Harrelson, Yoav Weiss, blink-dev
Which version of Chrome are you wanting to ship in?
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


Victor Vasiliev

unread,
Feb 22, 2022, 5:18:06 AM2/22/22
to Joe Medley, Daniel Bratell, Chris Harrelson, Yoav Weiss, blink-dev
Hi Joe,

This is currently scheduled to ship in M100.

Thanks,
  Victor.

Joe Medley

unread,
Feb 22, 2022, 10:28:46 AM2/22/22
to Victor Vasiliev, Daniel Bratell, Chris Harrelson, Yoav Weiss, blink-dev
Thanks!

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Reply all
Reply to author
Forward
0 new messages