Partition WebSockets Limits to prevent side channels

[pes10k]

Currently WebSockets have a large global limit in the Chromium. This limit is shared by all open sites. Trackers on those sites can use this limit to communicate across site boundaries, and so track users across the web, circumventing many of Brave's partitioning protections.

To prevent the most dangerous forms of this attack (attacks that target the largest limited-but-unpartitioned pools in Chromium), Brave should do the following:

• Partition: impose a per-site (as determined by top-level frame eTLD+1) cap of how many websockets can be open. Initial suggestion is 10, but any cap thats << the global cap would work
• De-limit: remove, or greatly expand, the global cap, to increase the number of eTLD+1s an attack has to control to carry out the attack

Once this is done for websockets, we could look for other connection pools and global limits to apply similar mitigations to.

[stephendonner]

@goodov can we get a testplan for this when you get a chance? Thanks!

[goodov]

@pes10k wdyt about adding a test page for WebSockets limits? A manual testing can have many steps here and it's not easy to get all expectations from different frames in a quick manner.

[pes10k]

I've requested that devops create a websocket server we can use here. That issue is here: https://github.com/brave/devops/issues/6722

Once the above issue is complete, i can implement a QA test

[pes10k]

QA test here: https://dev-pages.brave.software/network-state/web-sockets.html

[LaurenWags]

Verified using

Brave	1.36.94 Chromium: 98.0.4758.87 (Official Build) beta (x86_64) 
Revision	e4cd00f135fb4d8edc64c8aa6ecbe7cc79ebb3b2-refs/branch-heads/4758@{#1002}
OS	macOS Version 12.2.1 (Build 21D62)

Confirmed able to run the web sockets test on https://dev-pages.brave.software/network-state/web-sockets.html with default shield settings:

Confirmed when shields are down more than 10 connections can be created on the same page:

Confirmed able to run the test (with shields up) on both of the following pages simultaneously:
https://dev-pages.brave.software/network-state/web-sockets.html
https://dev-pages.bravesoftware.com/network-state/web-sockets.html

---

Verified PASSED using

Brave | 1.36.90 Chromium: 98.0.4758.87 (Official Build) beta (64-bit)
Revision | e4cd00f135fb4d8edc64c8aa6ecbe7cc79ebb3b2-refs/branch-heads/4758@{#1002}
OS | Windows 11 Version 21H2 (Build 22000.493)

Scenario 1:
Verified browser is able to create 10 connections at a time using https://dev-pages.brave.software/network-state/web-sockets.html with default shield settings

Visited https://dev-pages.brave.software/network-state/web-sockets.html
Clicked Start Test
10 connections are created with 200 message
The table shows a connection error for the 11th.

Scenario 2:
Verified browser is able to create more than 10 connections on the same page with shields down.

Visited https://dev-pages.brave.software/network-state/web-sockets.html
Turn Shields down
Clicked Start Test
More than 10 connections are created with 200 message
No errors returned for 11th row

Scenario 3:
Verified browser is able to create 10 connections at a time on both pages simultaneously with default shields settings
https://dev-pages.brave.software/network-state/web-sockets.html
https://dev-pages.bravesoftware.com/network-state/web-sockets.html

Visited https://dev-pages.brave.software/network-state/web-sockets.html
Clicked other site link and open in new a window - https://dev-pages.bravesoftware.com/network-state/web-sockets.html
Clicked start test simultaneously
11th row failed in both windows

---

Verification PASSED using

Brave	1.36.93 Chromium: 98.0.4758.87 (Official Build) beta (64-bit)
Revision	e4cd00f135fb4d8edc64c8aa6ecbe7cc79ebb3b2-refs/branch-heads/4758@{#1002}
OS	Linux

Confirmed able to run the web sockets test on https://dev-pages.brave.software/network-state/web-sockets.html with default Shields settings:

Confirmed when Shields are down more than 10 connections can be created on the same page:

Confirmed able to run the test (with Shields up) on both of the following pages simultaneously:
https://dev-pages.brave.software/network-state/web-sockets.html
https://dev-pages.bravesoftware.com/network-state/web-sockets.html

[srirambv]

Verification passed on Oppo Reno 5 with Android 12 running 1.36.105 x64 build

• Verified with shields enabled only 10 connection are created and 11th one errors out
• Verified with shields disabled more than 10 connections can be created

https://dev-pages.brave.software

Shields Enabled	Shields Disabled

https://dev-pages.bravesoftware.com

Shields Enabled	Shields Disabled

---

Verification passed on Samsung Tab A with Android 10 running 1.36.105 x64 build

• Verified with shields enabled only 10 connection are created and 11th one errors out
• Verified with shields disabled more than 10 connections can be created

https://dev-pages.brave.software

Shields Enabled	Shields Disabled

https://dev-pages.bravesoftware.com

Shields Enabled	Shields Disabled

[jonathanpdunne]

I'm currently opening around ~45 web socket connections from an extension and being hampered by this limit recently. We haven’t noticed any problems with unpartitioned pools with our extension so far, so would be interested in your appetite to increase the limit - it looks like this has been considered previously. Given Chromium extensions have to pass a review process prior to publishing, an alternative might be to lift the cap for an application in the extension environment entirely. However, unpacked extensions might be an exception to this rule.

[goodov]

I'm currently opening around ~45 web socket connections from an extension and being hampered by this limit recently. We haven’t noticed any problems with unpartitioned pools with our extension so far, so would be interested in your appetite to increase the limit - it looks like this has been considered previously. Given Chromium extensions have to pass a review process prior to publishing, an alternative might be to lift the cap for an application in the extension environment entirely. However, unpacked extensions might be an exception to this rule.

cc @pes10k would like to hear your opinion here. I believe technically we can ignore/increase the limit for extensions.

[pes10k]

Sure, extensions already have global / unpartitioned storage, so imposing the limit on extensions isn't useful.

That said, i think this (~45 parallel websockets w/in the same partition) is a pretty tail case. If we can easily remove the limitation for extensions (say 1-2 days of work) i think its worth doing. Otherwise, i think its a P4 or P5 kind of thing (it'd be good to address, but its low priority, given other tasks)

[goodov]

I'm currently opening around ~45 web socket connections from an extension and being hampered by this limit recently. We haven’t noticed any problems with unpartitioned pools with our extension so far, so would be interested in your appetite to increase the limit - it looks like this has been considered previously. Given Chromium extensions have to pass a review process prior to publishing, an alternative might be to lift the cap for an application in the extension environment entirely. However, unpacked extensions might be an exception to this rule.

@jonathanpdunne
Should be fixed in the upcoming nightly build. If you can check it, would be amazing :)

[jonathanpdunne]

@jonathanpdunne Should be fixed in the upcoming nightly build. If you can check it, would be amazing :)

@goodov looks like it's fixed! Big thanks for attending to this issue, really appreciate it.