Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring back Network Boundary Shield heuristics including tweaking #76

Open
polcak opened this issue Dec 16, 2020 · 0 comments
Open

Bring back Network Boundary Shield heuristics including tweaking #76

polcak opened this issue Dec 16, 2020 · 0 comments

Comments

@polcak
Copy link
Owner

polcak commented Dec 16, 2020

4367460 removes the heuristics from NBS. However, for some use cases, the heuristics can be beneficial, both for Firefox-like and Chrome-like browsers.

We should go through the errors at

var httpErrorList = {
and propose weights that reflect how much information the error leaks and how common the error is.

So for example 404 adds 1 to the hostStatistics at

currentHost[targetUrl.hostname]["httpErrors"] += 1;
while maybe 406 could be a sign of some incompatibility between the client and the server. So I propose something like:

var httpErrorList = {
...
	404:1,
	405:0.5,
	406:0.1,
...
...
			currentHost[targetUrl.hostname]["httpErrors"] += httpErrorList[headers.statusCode];

Going back to 401, it leaks that the server exists but once known, there is not much to be learn in respect to the proxy discovery attack. That is the reason we decided to omit 401. However, blocking a server with excessive 401 errors makes sense because it might be a distributed password cracking attack. Suppose a malicious server distributes to a connected client passwords and lets the clients do the dirty work of connecting to the victim server. This way, server logs will show the browser proxy IP address and not the real attacker. If we pick weight 0.01 for 401 that means 1000 attempts. Does it make sense to reintroduce 401 and similar errors with a smallish weight? If so, does it make sense to have something like that for Firefox as well?

We should go through potential attacks that the heuristics can block and try to mitigate them.

The issue was originally a part of #62.

polcak added a commit that referenced this issue Dec 16, 2020
Implement custom DNS cache using resolved data available in onResponseStartedListener().

Deals with the original problem of #62. This merge closes #75.

This removes the heuristics. But we should bring them back for other
types of attacks, see #76 for more details.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant