1934402 - Webtransport connection fails

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[marten.richter]

Steps to reproduce:

I tried to run a web transport connection against my web transport servers. The connection was rejected (I am using Win 11, but I do not think that it is OS-dependent). It was not rejected on Firefox 132, and it works on Chrome-based browsers. But it is rejected on Firefox 133, nightly, and I just made a fresh build.
You can, for example, reproduce it with the webtransport suite on:
https://github.com/w3c/webtransport/issues/622
I used the suite to fix bugs in Firefox and Chromium.

Actual results:

The connection was rejected.

Expected results:

The connection should succeed.

Comment 1

[marten.richter]

I have ran the debugger already for some hours.
I am not sure, what the cause is, it could be again a race condition.
All, I have seen it that ends up here:

xul.dll!mozilla::net::WebTransportSessionProxy::ChangeState(mozilla::net::WebTransportSessionProxy::WebTransportSessionProxyState newState) Zeile 1066
	unter C:\mozilla-source\mozilla-unified\netwerk\protocol\webtransport\WebTransportSessionProxy.cpp (1066)
xul.dll!mozilla::net::WebTransportSessionProxy::OnStartRequest(nsIRequest *) Zeile 586
	unter C:\mozilla-source\mozilla-unified\netwerk\protocol\webtransport\WebTransportSessionProxy.cpp (586)
xul.dll!mozilla::net::nsHttpChannel::CallOnStartRequest() Zeile 2147
	unter C:\mozilla-source\mozilla-unified\netwerk\protocol\http\nsHttpChannel.cpp (2147)
xul.dll!mozilla::net::nsHttpChannel::ContinueOnStartRequest1(nsresult result) Zeile 7971
	unter C:\mozilla-source\mozilla-unified\netwerk\protocol\http\nsHttpChannel.cpp (7971)
xul.dll!mozilla::net::nsHttpChannel::OnStartRequest(nsIRequest * request) Zeile 7935
	unter C:\mozilla-source\mozilla-unified\netwerk\protocol\http\nsHttpChannel.cpp (7935)
xul.dll!nsInputStreamPump::OnStateStart() Zeile 504
	unter C:\mozilla-source\mozilla-unified\netwerk\base\nsInputStreamPump.cpp (504)
xul.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *) Zeile 409
	unter C:\mozilla-source\mozilla-unified\netwerk\base\nsInputStreamPump.cpp (409)

It is a change from state CONNECTING to state DONE, which results in the connection aboard.
For me it looks as if OnStartRequest is called too early, so that the state can change to "WebTransportSessionProxyState::NEGOTIATING_SUCCEEDED" .

Input on what has changed between 132-> 133 regarding Web transport is appreciated.

If you try to reproduce or debug it, it may be wise to reduce the number of tests run in the tests harness, for example, by commenting some tests in the spec.js files. You could also restrict it to a single bidirectional test.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[marten.richter]

I think I have found the reason:
https://searchfox.org/mozilla-central/rev/d1de48df1c758b3518d6cf19c643f5052b05eab9/netwerk/protocol/http/Http3Session.cpp#2315
this line is triggered.
I use serverCertificateHashes, so yes this is a third party root.
Can we add an exception, if the call comes from
https://searchfox.org/mozilla-central/rev/d1de48df1c758b3518d6cf19c643f5052b05eab9/netwerk/protocol/http/Http3Session.cpp#2254
and uses serverCertificateHashes (may be pass a bool skip thirdpartychecks?).
The changes come from:
https://bugzilla.mozilla.org/show_bug.cgi?id=1929368
it was a series of attempts to fix some problem (probably none to be discussed in public, hopefully not related to serverCertificateHashes).
The change was made by kershaw.

Comment 4

[marten.richter]

Noone is answering, so I prepare a patch anyway and I also try to add a wpt test, so that this does not happen again.

Comment 5

[marten.richter]

Attachment: Bug 1934402 - Fix Webtransport serverCertificateHashes in production. r?kershaw,valentin

A recent change broke serverCertificateHashes outside the wpt tests in Firefox by enforcing a
known root certificate. This commit adds an exceptions for certificates verified by a hash.
It also adds wpt Tests for serverCertificateHashes, however, these can not detect the current bug,
as it does not occur inside Automation.

Comment 6

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

Thank you for diagnosing and proposing the fix.
I expect this is a regression from bug 1925014 - you can confirm by setting network.http.http3.disable_when_third_party_roots_found to false.

Comment 7

[marten.richter]

Yes, it is. I did not set the flag, but I changed a line in the source code to find out. I think this is sufficient.

Comment 8

[Kershaw Chang [:kershaw]]

(In reply to marten.richter from comment #4)

Noone is answering, so I prepare a patch anyway and I also try to add a wpt test, so that this does not happen again.

Sorry for not replying and also thanks for providing a fix.

Comment 9

[marten.richter]

Attachment: Bug 1934402 - Add wpt tests for serverCertificateHashes. r?kershaw,valentin,jgraham

A recent change broke serverCertificateHashes outside the wpt tests in Firefox by enforcing a
known root certificate. This commit adds wpt Tests for serverCertificateHashes.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5b031fc405f9
Fix Webtransport serverCertificateHashes in production. r=kershaw,valentin,necko-reviewers

Comment 11

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/5b031fc405f9