BiagioFesta / wtransport

Async-friendly WebTransport implementation in Rust
Apache License 2.0
470 stars 31 forks source link

Firefox support #166

Closed cBournhonesque closed 4 months ago

cBournhonesque commented 7 months ago

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 commented 7 months ago

Context on why I think so: https://github.com/BiagioFesta/wtransport/blob/4b25852afdb1a5f2beeb0a8a03eef7db0e7168ac/wtransport/src/endpoint.rs#L668-L670

Maybe latest FF needs something else...

BiagioFesta commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

easrng commented 5 months ago

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

BiagioFesta commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

Yep, it fixes the issue! Thanks!