[hackerone] Block DNS for .onion requests in non-Tor contexts

[diracdeltas]

according to https://datatracker.ietf.org/doc/html/rfc7686:

Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup.

originally reported at https://hackerone.com/reports/2098135, credit xiaoyinl

[LaurenWags]

Have reached out to @diracdeltas for additional information, marking as QA/Blocked for now.

Update - @fmarier will provide needed info 👍🏻

[LaurenWags]

Removed QA/Blocked, this can be tested via the test plan @fmarier provided under https://github.com/brave/brave-core/pull/19621#issue-1842521618.

@brave/qa-team verification notes can be put in comments below (confirmed via https://bravesoftware.slack.com/archives/C8MP8ME4C/p1695228213555579?thread_ts=1695151239.787889&cid=C8MP8ME4C).

[LaurenWags]

Verifed with

Brave | 1.59.100 Chromium: 117.0.5938.92 (Official Build) beta (arm64)
-- | --
Revision | 3243fffc43431ab8677e8139859670b4cd2df843
OS | macOS Version 14.0 (Build 23A344)

Verified test plan from https://github.com/brave/brave-core/pull/19621#issue-1842521618.

Reproduced the issue using 1.58.x.

1. Create a new browser profile 2. Turn off Secure DNS in `brave://settings/security` 3. Start wireshark, choose appropriate interface 4. Click the shark fin icon in the toolbar 5. Type `dns` in the filter bar and press enter 6. Go back to Brave and in a **normal window**, open , open dev tools for this window 7. Click on the button 8. Go back to wireshark At this point, you should see brave4u7jddbv7cyviptqjc7jusxh72uik7zt6adtckl5f4nwy2v72qd.onion in the wireshark log: and errors in the devtools console:

Confirmed issue resolved with 1.59.x - PASSED

1. Create a new browser profile 2. Turn off Secure DNS in `brave://settings/security` 3. Start wireshark, choose appropriate interface 4. Click the shark fin icon in the toolbar 5. Type `dns` in the filter bar and press enter 6. Go back to Brave and in a **normal window**, open , open dev tools for this window 7. Click on the button 8. Go back to wireshark 9. Confirmed I do not see brave4u7jddbv7cyviptqjc7jusxh72uik7zt6adtckl5f4nwy2v72qd.onion in the wireshark log: 10. Confirmed I still see errors in dev tools console.

[stephendonner]

Verified PASSED using

Brave | 1.59.107 Chromium: 117.0.5938.140 (Official Build) beta (64-bit)
-- | --
Revision | 5bbd53ed3e41461e15555b7ce0490464656b236f
OS | Windows 10 Version 22H2 (Build 19045.3516)

First, reproduced the issue using 1.58.x:

``` Brave | 1.58.131 Chromium: 117.0.5938.92 (Official Build) (64-bit) -- | -- Revision | 2cd98952c615ae83a524a0285aa7dcf5acac5aea OS | Windows 10 Version 22H2 (Build 19045.3516) ``` ### Steps: 1. installed `1.58.131` 2. launched Brave 3. toggled `Use Secure DNS` off in `brave://settings/security` 4. launched `Wireshark` 5. captured 3 interfaces 6. filtered by `dns` request type 7. loaded `https://fmarier.github.io/brave-testing/brave-onion-dns-resolution.html` 8. opened the `Developer Tools`' `Console` 9. clicked on `Request Onion` 10. confirmed blocked `.onion` DNS requests 11. examined `Wireshark` 12. confirmed lookup-requests for `brave4u7jddbv7cyviptqjc7jusxh72uik7zt6adtckl5f4nwy2v72qd.onion` show up in `dns` traffic example | example | example ----------|-----------|----------  |  |  |

Then, verified the fix using 1.59.107:

example	example	example

[MadhaviSeelam]

Verification PASSED using

Brave   1.59.103 Chromium: 117.0.5938.140 (Official Build) beta (64-bit) 
Revision    e0f257d585b29dd1194e82717cf18db50a7c0edb
OS  Linux

Reproduced the issue in

1.58.122 Chromium: 117.0.5938.62 (Official Build) (64-bit) 
Revision    623437a8c792953b7bc4574f2d9ccdfd59e0ca67
OS  Linux

Steps:

1. installed 1.58.131
2. launched Brave
3. toggled Use Secure DNS off in brave://settings/security
4. launched Wireshark
5. captured with loopback:lo interfaces
6. filtered by dns request type
7. loaded https://fmarier.github.io/brave-testing/brave-onion-dns-resolution.html
8. opened the Developer Tools' Console
9. clicked on Request Onion
10. confirmed blocked .onion DNS requests
11. examined Wireshark
12. confirmed lookup-requests for brave4u7jddbv7cyviptqjc7jusxh72uik7zt6adtckl5f4nwy2v72qd.onion show up indns` traffic

example	example	example

Then, verified the fix using 1.59.103:

• Confirmed I do not see brave4u7jddbv7cyviptqjc7jusxh72uik7zt6adtckl5f4nwy2v72qd in the wireshark log:
• Confirmed I still see errors in dev tools console.

example	example	example

[queesamor]

The implementation of this has caused a huge issue. Browsers on my network, including Brave, are configured to automatically proxy all requests for .onion addresses through an intranet Tor proxy; this is accomplished with browser extensions which manage the proxy settings on a per-tab basis. However now that this has been released, SURPRISE, all .onion sites which load any resources via fetch() -- or other methods -- that are requested on my network by Brave browsers are failing. There is NO explanation of why "net::ERR_BLOCKED_BY_CLIENT" errors are thrown for each resource request, there is NO logical deduction being made by the browser about whether or not blocking such requests makes sense (e.g. The domain in the address bar is a .onion, so ALLOW fetch/etc. requests to .onion addresses // vs // The domain in the address bar is not .onion, so DENY fetch/etc. requests to .onion addresses), and finally there is NO ability to change this behavior.

I had to come find this issue and connect that to a recent release to determine that this breaking behavior was released on purpose without notice or consideration of the harm that it would cause.

Must I move every single person on my network off of the Brave browser? Or will this regression be addressed and solved with more consideration to real-world usage?

[fmarier]

@queesamor Thanks for explaining your use case. I just suggested a fix for this in https://github.com/brave/brave-browser/issues/33735.

[queesamor]

@fmarier Thank you so much! When all of a sudden much of our daily access went down it became a seemingly never-ending adventure to try and diagnose and fix, starting with our Tor proxy, then realizing it was just Brave but not other things, and then trying to figure out how to downgrade all our Brave installations -- which required perusing backups to determine which Brave versions had worked -- and not let them auto-upgrade again, and then trying to figure out why it stopped working... it's been harrowing. And then when I finally found this feature mentioned in recent release notes I had no idea how to even begin.

So thank you, thank you, thank you. Thank you for replying so soon after my shout into what seemed to be a giant void, and thank you for identifying a workable solution and helping to prioritize it.

In the meantime, do I need to continue to hold all our Brave installations where they are (<=1.58.137)? Should we reasonably expect this to get addressed in the next major version (1.60?), or should we set our expectations somewhere further along? Do we need to be worried about missing security updates in the meantime?

[fmarier]

@queesamor I'm sorry it took so much effort to figure this one out. It's not a use case we had anticipated.

The way that we roll out fixes is one step at a time. So first it goes to the nightly channel, then to beta, and then finally to release. There is a channel migration (i.e. nightly -> beta and beta -> release) roughly every 3 weeks. So if we were to fix this tomorrow, then it would take up to 3 weeks to make it to beta and then another 3 weeks to make it to release. That said, we don't have a fix for it yet (you'll see a PR show up on #33735 once we do. Once that PR has been merged then the fix would be in your hands within 3-6 weeks.

In the meantime, I would suggest you keep updating. There are security fixes in almost every major release (and in many minor releases) and so staying on an old version is risky from a security point of view. Browsers really need to be kept up-to-date because they are essentially engines for running untrusted code from the Internet.

Right now, the only work-around would be to open pages that rely on .onion resources in Tor windows. Not ideal, but it should work.