Closed Bug 1806693 Opened 1 year ago Closed 5 months ago

Support serverCertificateHashes in the WebTransport constructor options

Categories

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

task

Tracking

()

RESOLVED FIXED
123 Branch
Tracking Status
firefox123 --- ?

People

(Reporter: jesup, Assigned: jfernandez+alt)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, Whiteboard: [necko-triaged])

Attachments

(1 file)

Depends on: 1806694
Severity: -- → N/A
Type: enhancement → task
Priority: -- → P3
Whiteboard: [necko-triaged]

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!

Flags: needinfo?(rjesup)
Flags: needinfo?(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.

Flags: needinfo?(rjesup)
Flags: needinfo?(kershaw)

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 😅

Flags: needinfo?(kershaw)

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.

Flags: needinfo?(kershaw)

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

I have started to work on this.

Thanks. Let us know if you need any support.

Assignee: nobody → jfernandez+alt

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

Attachment #9367816 - Attachment description: WIP: Bug 1806693 - Implement the serverCertificateHashes option → Bug 1806693 - Implement the serverCertificateHashes option
Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/14115a54c58b
Implement the serverCertificateHashes option r=necko-reviewers,kershaw,jesup
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch

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

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

Depends on: 1873263
Blocks: 1873263
No longer depends on: 1873263
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: