1518971 - DoH bypass on startup when tabs are pinned or restored from previous session setting.

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Konark Modi - @konarkmodi]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

1. Enable DNS over HTTPS by visiting Network settings.
2. Open few webpages:
   a. theguardian.com
   b. nytimes.com
   and pin both the tabs.
3. Quit the browsers.

Now monitor the network for DNS traffic. I usually prefer using tshark:
tshark -n -T fields -e ip.src -e dns.qry.name -f 'src port 53' -Y 'dns.qry.name'

5. Restart Firefox (might have to wait for a minute or so)
6. The tabs will auto-reload because they are pinned.

Actual results:

In the DNS traffic you can observe few calls to Mozilla backend services, but you will also see the calls to the website and third-parties on the pages which were pinned.

Expected results:

When DoH in enabled, the expectation is no DNS call to happen via normal channel.

Few other ways DoH is bypassed on startup is:

Set the option to restore previous session in about:preferences => General
Now open multiple pages in multiple windows. The DNS call to last focussed pages will happen on normal channel instead of DoH.

Third way, it leaks is:

1. User has the setting restore tabs enabled.
2. browser.sessionstore.restore_on_demand to false.

This forces all the tabs to be restored on startup instead of limiting to the focussed ones.

I tested both Firefox Release 64.0.2 and Nightly, both of them seem to be impacted with this issue.

Comment 1

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

(In reply to Konark Modi - @konarkmodi from comment #0)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

1. Enable DNS over HTTPS by visiting Network settings.

The checkbox enables DoH in mode 2 (TRR first, with a fallback to regular DNS).
Can you check if the value of the pref network.trr.mode is indeed 2?

Can you also set the value to 3, and recheck that you don't see any DNS traffic?

Comment 2

[Konark Modi - @konarkmodi]

(In reply to Valentin Gosu [:valentin] from comment #1)

(In reply to Konark Modi - @konarkmodi from comment #0)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

1. Enable DNS over HTTPS by visiting Network settings.

The checkbox enables DoH in mode 2 (TRR first, with a fallback to regular DNS).
Can you check if the value of the pref network.trr.mode is indeed 2?

Can you also set the value to 3, and recheck that you don't see any DNS traffic?

Set to 3 now, but DNS resolution is not working at all now. Is there some other setting I need to change with mode set to 3 ?

Comment 3

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

(In reply to Konark Modi - @konarkmodi from comment #2)

Set to 3 now, but DNS resolution is not working at all now. Is there some other setting I need to change with mode set to 3 ?

I think you also need to set the bootstrap address to the IP of mozilla.cloudflare-dns.com (I think 1.1.1.1 should work)
Let me know if you encounter any issues.

Comment 4

[Konark Modi - @konarkmodi]

(In reply to Konark Modi - @konarkmodi from comment #2)

(In reply to Valentin Gosu [:valentin] from comment #1)

(In reply to Konark Modi - @konarkmodi from comment #0)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

1. Enable DNS over HTTPS by visiting Network settings.

The checkbox enables DoH in mode 2 (TRR first, with a fallback to regular DNS).
Can you check if the value of the pref network.trr.mode is indeed 2?

Can you also set the value to 3, and recheck that you don't see any DNS traffic?

Set to 3 now, but DNS resolution is not working at all now. Is there some other setting I need to change with mode set to 3 ?

Ok, had to change the bootstrap address - network.trr.bootstrapAddress. Now, I am using 1.1.1.1 as bootstrap address to test.

Comment 5

[Konark Modi - @konarkmodi]

:valentin : By setting the mode to 3, I can no longer reproduce the issue.

Comment 6

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

(In reply to Konark Modi - @konarkmodi from comment #5)

:valentin : By setting the mode to 3, I can no longer reproduce the issue.

Excellent! Thanks for checking this for us. And thanks for reporting the issue in the first place.

Comment 7

[Konark Modi - @konarkmodi]

Does Resolution -> Invalid means it's the intended and not to be fixed?

Comment 8

[Frederik Braun [:freddy]]

Please excuse the brevity in comment 6.

There are different modes of operation for DoH (aka TRR).

• network.trr.mode set to 2: DNS requests should go through DoH, but can fall back to unencrypted DNS to ensure we do not break requests.
• network.trr.mode set to 3: DNS requests must go through DoH. If DoH doesn't work, then the whole request will fail.

We do not consider DNS unencrypted traffic problematic when the setting is 2.
We value your scrutiny and I'm looking forward to your next bug report :-) Maybe you will find something when it is indeed set to 3?

Comment 9

[val.zapod.vz]

You can reproduce it must simpler. Very fast open browser, ctrl-V https://cloudflare.com/cdn-cgi/trace