Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firefox support #166

Closed
cBournhonesque opened this issue Apr 18, 2024 · 8 comments · Fixed by #192
Closed

Firefox support #166

cBournhonesque opened this issue Apr 18, 2024 · 8 comments · Fixed by #192
Labels
bug Something isn't working Investigation

Comments

@cBournhonesque
Copy link

Hi, I was wondering if there were any caveats/special handling that is needed for Firefox support.

I've had an issue where WebTransport connections get rejected on Firefox.
It doesn't seem to be certificate-related, since the exact same code/certificate works on google chrome.

@MOZGIII suggested that it might be on the server side.
I quote:

This is actually most likely the issue with the server-side
Firefox requires some special response from the server, I don't recall exactly - but please report this to wtransport

Maybe you have more information?

@MOZGIII
Copy link
Contributor

MOZGIII commented Apr 18, 2024

Context on why I think so:

if !user_agent.contains("firefox") {
response.add("sec-webtransport-http3-draft", "draft02");
}

Maybe latest FF needs something else...

@BiagioFesta
Copy link
Owner

I was able to connect with firefox 123.0.2 (linux) to wtransport/full.rs.

image

Of course, as already mentioned in the parent issue, Firefox does not support serverCertificateHashes yet. That means you will need a trusted certificate to make it work.


I understand OP says Google Chrome works with the same certificate, did they set the correct anchors on FF?

Would it be possible to have wtransport server logs?
For example, I'd expect something like

INFO Connection{id=0}: full::webtransport: Result: Err(connection aborted by peer: the cryptographic handshake failed: error 42)

@MOZGIII
Copy link
Contributor

MOZGIII commented Apr 20, 2024

Yes, on the second thought, this is most likely due to the lack of the trust to server certificate by FF. It works when set up properly without the serverCertificateHashes.

@MOZGIII
Copy link
Contributor

MOZGIII commented Apr 22, 2024

Actually, Firefox should support serverCertificateHashes - as they have had patches for it in 125a. For me it still doesn't work though...

See the meta bug at their tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1709355

Here's the (second) fix for the serverCertificateHashes: https://bugzilla.mozilla.org/show_bug.cgi?id=1873263

Apparently the still didn't get it right

@BiagioFesta BiagioFesta added invalid This doesn't seem right question Further information is requested labels Apr 25, 2024
@easrng
Copy link

easrng commented Jun 10, 2024

I'm getting the "WebTransport connection rejected" intermittently, retrying fixes it but it's annoying :/

@BiagioFesta
Copy link
Owner

Testing with Firefox 127.0.1 (64-bit) (cargo run --example full).

Sporadically I get:

Uncaught (in promise) 
WebTransportError { source: "session", streamErrorCode: null, name: "WebTransportError", message: "WebTransport connection rejected", code: 0, result: 0, filename: "", lineNumber: 0, columnNumber: 0, data: null }

(in the webclient).

This is not related to serverCertificateHashes (as Firefox now supports it).


Note: The issue is not always reproducible.


By protocol packets inspection, it seems Firefox closes the session stream right after CONNECT request.

wtransport server logs:

2024-07-08T21:16:13.405552Z DEBUG Connection{id=2}:Driver{quic_id=129670632847136}: wtransport::driver::worker: New incoming bi stream (0)
2024-07-08T21:16:13.405985Z DEBUG Connection{id=2}:Driver{quic_id=129670632847136}:Stream{id=0}: wtransport::driver::worker: First frame kind: Headers
2024-07-08T21:16:13.406446Z DEBUG Connection{id=2}:Driver{quic_id=129670632847136}:Stream{id=0}: wtransport::driver::worker: Headers: Headers({"dnt": "1", "sec-fetch-dest": "webtransport", "accept": "*/*", "priority": "u=4", "cache-control": "no-cache", "sec-webtransport-http3-draft02": "1", "origin": "http://localhost:8080", ":authority": "localhost:40719", "sec-fetch-mode": "no-cors", ":scheme": "https", ":method": "CONNECT", "accept-encoding": "gzip, deflate, br, zstd", "sec-fetch-site": "same-site", "user-agent": "Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0", "accept-language": "en-US,en;q=0.5", "pragma": "no-cache", ":protocol": "webtransport", ":path": "/"})
2024-07-08T21:16:13.406631Z  INFO Connection{id=2}: full::webtransport: New session: Authority: 'localhost:40719', Path: '/'
2024-07-08T21:16:13.407053Z  INFO Connection{id=2}: full::webtransport: Waiting for data from client...
2024-07-08T21:16:13.408235Z DEBUG Connection{id=2}:Driver{quic_id=129670632847136}: wtransport::driver::worker: Ended with error: NotConnected
2024-07-08T21:16:13.408549Z  INFO Connection{id=2}: full::webtransport: Result: Err(connection closed by peer: 256)

And network inspection:

Client ------------> Server
     HTTP3: Request Stream (0) CONNECT

    <-----------------
      HTTP3: Request Stream (0) OK
 
   ---------------------->
      QUIC: Stop Sending (0) Error code: 0x101

In short, Firefox close the session stream (0) right after receiving the 200 OK response.

Considering this only happens sometimes, it might not be a missing protocol feature required by Firefox

@BiagioFesta BiagioFesta added bug Something isn't working Investigation and removed invalid This doesn't seem right question Further information is requested labels Jul 8, 2024
@BiagioFesta
Copy link
Owner

Current master branch (https://github.com/BiagioFesta/wtransport/tree/623cc0b409c5409d2ce32b2f2a1ea79948bc8373) should now fixes the issue.

If anyone can test and provide feedback to me it would be great so I can enforce a new release

@easrng
Copy link

easrng commented Jul 10, 2024

Yep, it fixes the issue! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Investigation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants