1612701 - WebSocket blocked by uBlock Origin still does a DNS request

Status: UNCONFIRMED

(Core :: Networking: DNS, enhancement, P3)

Description

[joeysazo]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

With uBlock Origin installed, add this static filter:
||pubsub-edge.twitch.tv

network.dns.disablePrefetch* = false (both of them)

network.trr.mode = 5

Run Wireshark

Open https://www.twitch.tv
The page will repeatedly try to make a WebSocket connection to the hostname blocked by the filter above. The Browser Console will show a message for each failed connection.

Actual results:

Wireshark shows that DNS Prefetching occurs for the blocked WebSocket requests.

Expected results:

No DNS Prefetch

Comment 1

[joeysazo]

Need to correct myself:

network.dns.disablePrefetch* = true

(I do indeed have DNS Prefetch disabled. This bug is the only case I'm aware of it occurring.)

Comment 2

[Miruna Curtean]

Hello,

I've installed uBlock Origin and then navigated to the extension's option page. Over there, in my Filters section I have added the "||pubsub-edge.twitch.tv" static filter and applies the change.
In about: config I've set network.dns.disablePrefetch = true (and network.dns.disablePrefetchFromHTTPS too?) and network.trr.mode = 5 and restarted the browser to make sure preference changes were applied.
After which I navigated to https://www.twitch.tv/ and opened the browser console.
The "Firefox can’t establish a connection to the server at wss://pubsub-edge.twitch.tv/v1." was shown in the console log.
In The Wireshark capture I don't see any queries towards twitch, as opposed to when I had the network.dns.disablePrefetch preferences set to false.
Is there something that I am doing incorrectly?
Thanks

Comment 3

[joeysazo]

| In about: config I've set network.dns.disablePrefetch = true (and network.dns.disablePrefetchFromHTTPS too?)

Yes, both of them set to true.

| In The Wireshark capture I don't see any queries towards twitch, as opposed to when I had the network.dns.disablePrefetch preferences set to false. Is there something that I am doing incorrectly?

The bug is a DNS query for the blocked WebSocket request. Thus the Wireshark capture will have at least one DNS query for the pubsub-edge.twitch.tv server. (By setting trr.mode = 5 it should be your ISP as DNS provider.)

You'll probably see multiple DNS queries for pubsub-edge.twitch.tv because Twitch will repeatedly try to connect to it, which will result in new DNS queries after some time. uBlock will block each of the actual WebSocket requests for it, which you can see in the uBlock logger.

Comment 4

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

The priority flag is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Shane Caraveo (:mixedpuppy)]

The extension layer doesn't really have anything to do with the actual mechanics of dns prefetch, so passing on to the netwerk team.

Comment 6

[Andy Grover [:grover]]

Valentin what do you make of this?

Comment 7

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

This isn't as much a DNS prefetch isn't blocked, but a problem with the fact that the WebSocketChannel does a DNS request [1] before the extension gets the chance to block the channel [2].
From the comments it seems to me that we can't really delay the DNS request after we open the channel. Maybe there's a way to make the extension blocking code run during websocketchannel::asyncOpen() ?

Michal, what do you think?

[1] https://searchfox.org/mozilla-central/rev/fca0be7e2cf2f922c9b927423ce28e8a04b3fd90/netwerk/protocol/websocket/WebSocketChannel.cpp#2788
[2] https://searchfox.org/mozilla-central/rev/fca0be7e2cf2f922c9b927423ce28e8a04b3fd90/netwerk/protocol/websocket/WebSocketChannel.cpp#3427

Comment 8

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

Note that the DNS resolution done by WebSocketChannel that is not a prefetch, which is why it isn't blocked.

Comment 9

[Shane Caraveo (:mixedpuppy)]

The earliest stage that an extension gets access to is during http-on-modify-request, which translates to webRequest.onBeforeRequest. We generally presume that no network connection has been made at that point. It would be ideal to wait on dns till after that, but if that is simply not possible, we probably have to live with how it works for now. If that is the case, toss this bug back into our bucket as I'd want to think about a future solution.

Comment 10

[Michal Novotny [:michal]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #8)

Note that the DNS resolution done by WebSocketChannel that is not a prefetch, which is why it isn't blocked.

It's not a prefetch, we need to know the IP address of the host to avoid having more that 1 connection to the host in CONNECTING state as required by spec (https://tools.ietf.org/html/rfc6455#section-4.1).

Comment 11

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

(In reply to Shane Caraveo (:mixedpuppy) from comment #9)

The earliest stage that an extension gets access to is during http-on-modify-request, which translates to webRequest.onBeforeRequest. We generally presume that no network connection has been made at that point.

Technically we don't make network connection, we just make a DNS request. If the user has it in the cache, or if the resolver has it in the cache, the DNS server wouldn't even see it. But potentially someone could use it for tracking by trying to open a websocket to [uuid].blocked-domain.com then listening for the DNS request ? The websocket would be blocked, of course, but the DNS request would go through.
But I suppose they could achieve the same by making connections directly to IP addresses, so maybe it's not that big of a deal?

Comment 12

[Shane Caraveo (:mixedpuppy)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #11)

(In reply to Shane Caraveo (:mixedpuppy) from comment #9)

The earliest stage that an extension gets access to is during http-on-modify-request, which translates to webRequest.onBeforeRequest. We generally presume that no network connection has been made at that point.

Technically we don't make network connection, we just make a DNS request.

What I was trying to express is, a regular http channel request doesn't make any dns or socket connection until after http-on-modify-request. In terms of something like ublock, when they block http, the dns query doesn't have a chance to be made because of this.

This would be nice to fix, but in real terms I'm not sure its important enough to prioritize.

Comment 13

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

(In reply to Shane Caraveo (:mixedpuppy) from comment #12)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #11)

(In reply to Shane Caraveo (:mixedpuppy) from comment #9)

The earliest stage that an extension gets access to is during http-on-modify-request, which translates to webRequest.onBeforeRequest. We generally presume that no network connection has been made at that point.

Technically we don't make network connection, we just make a DNS request.

What I was trying to express is, a regular http channel request doesn't make any dns or socket connection until after http-on-modify-request. In terms of something like ublock, when they block http, the dns query doesn't have a chance to be made because of this.

This would be nice to fix, but in real terms I'm not sure its important enough to prioritize.

I agree. We probably could send an observer notification from the websocket channel too so it could have the chance to get cancelled earlier, with the hope that it doesn't break anything.

Comment 14

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

The priority flag is not set for this bug.
:mayhemer, could you have a look please?

For more information, please visit auto_nag documentation.