1806693 - Support serverCertificateHashes in the WebTransport constructor options

Status: RESOLVED FIXED

(Core :: Networking: HTTP, task, P3)

Description

[Randell Jesup [:jesup] (needinfo me)]

See https://w3c.github.io/webtransport/#web-transport-configuration

Comment 1

[Dietrich Ayala (:dietrich)]

The libp2p (and thus IPFS) stack depends on this piece of WebTransport API.

Chromium implemented, so is working fine there.

We can't move to WebTransport on Firefox until this is implemented.

A full description of how it's being used is here: https://github.com/libp2p/js-libp2p/issues/1999

Do you have a rough ETA for when this will be implemented?

Looks like it's already triaged, but is not clear if it's coming soon or not for a very long time.

Thanks!

Comment 2

[Kershaw Chang [:kershaw]]

(In reply to Dietrich Ayala (:dietrich) from comment #1)

The libp2p (and thus IPFS) stack depends on this piece of WebTransport API.

Chromium implemented, so is working fine there.

We can't move to WebTransport on Firefox until this is implemented.

A full description of how it's being used is here: https://github.com/libp2p/js-libp2p/issues/1999

Do you have a rough ETA for when this will be implemented?

Looks like it's already triaged, but is not clear if it's coming soon or not for a very long time.

Thanks!

It's a bit difficult to give an ETA, since webtransport is not used widely.
However, I'll try to put this in our roadmap of 2024 H1.

Comment 3

[Dietrich Ayala (:dietrich)]

Thanks Kershaw!

If we provide the patch, do you think you would be able to review and merge sooner?

since webtransport is not used widely.

Yes, the perennial web platform chicken and egg problem 😅

Comment 4

[Valentin Gosu [:valentin] (he/him)]

I think this should be easy to support.

First of all we need the cert hashes to be passed from the content constructor all the way to the parent.
Then in AsyncConnectWithClient where we create the channel we need to pass the hashes into the channel and save them.
Then in nsHttpChannel::OnStartRequest, after mSecurityInfo is set we need to compute the actual hash of the certificate, then compare it with the serverCertificateHashes from the webtransport constructor and if they don't match to abort the channel.

If someone were to implement this I think we can review and accept the patch.

Comment 5

[Dietrich Ayala (:dietrich)]

Thanks :valentin for the implementation notes, and clear ok to implement!

Comment 6

[u738353]

I have started to work on this.

Comment 7

[Valentin Gosu [:valentin] (he/him)]

Thanks. Let us know if you need any support.

Comment 8

[u738353]

Attachment: Bug 1806693 - Implement the serverCertificateHashes option

This change implements the serverCertificateHashes option from the
Web Transport specification [1].

It includes an additional verification step in the OnStartRequest
callback after the web transpostion session has been negotiated, so
that we can be sure the certificate has been set in the security
info data structure.

[1] https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/14115a54c58b
Implement the serverCertificateHashes option r=necko-reviewers,kershaw,jesup

Comment 10

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/14115a54c58b

Comment 11

[u738353]

The bug 1873263 seems legit, so perhaps we could reopen this and mark is as dependent of 1873263.

Comment 12

[Valentin Gosu [:valentin] (he/him)]

I think it should be fine to just fix the issue in bug 1873263.