Hello Giorgio,
I see that you added something like NBS to NoScript and you have some feedback on https://hackademix.net/2022/02/17/contextual-policies-lan-protection-abe-quantum-in-noscript-113/.
"Even when DNS resolution is performed, it's done in a stage of the request processing when any veto from content blockers has already happened, and parallel DNS querying is already undergoing or completed by the browser itself, therefore more often than not it just uses cached DNS resolution records without even hitting the net (and only if the browser would do it anyway)."
This was also my impression and I think that we even tested this. But we did not test with HTTP proxy. Are any changes like https://github.com/hackademix/noscript/commit/878a005de8a62e2187c57d5eb23c914fc75da833 or https://github.com/hackademix/noscript/commit/b5916981c10499b213b48ccedced60c826eddc24?
Metadata Update from @polcak: - Issue tagged with: design decision, question
Issue #85 relates to a user that cannot use NBS due to a DNS leak. The issue seem to be fixed in NoScript.
Metadata Update from @polcak: - Issue untagged with: question
Hi Libor!
Your intuition is correct: before performing any DNS resolution of your own you must check whether a request is using a HTTP proxy or a proxy which otherwise wants to proxy DNS, and if that is the case skip the DNS resolution part (exactly how is it done in this commit).
Up you the choice, whether just falling back to raw IP checks (it's unlikely for a proxy to bounce back in the LAN anyway) or to the caching approach used in the Chromium version of the shield.
Actually, unless you block me really fast, I'm just taking the first route (which is the one also NoScript uses) and sending a PR :)
Fixed by 8c7b439
Metadata Update from @gioma1: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
I added related 2750740 (notify Firefox users about possible NBS deactivation) and 5fb96a2 (FAQ entry). Feel free to propose improvements of the texts. I will release the fix in 0.11.3
Sorry for being late here. As noted in our meeting yesterday, NBS is still active and working according to its contract, no matter the proxy configuration.
The fix here is just preventing DNS leaks which users wouldn't expect because they're using one or more proxies.
Therefore I think we should just revert both these commits and consider this just a fix without side effects.
Hell Giorgio,
as discussed in our yesterday meeting, I consider it beneficial to define the behaviour of the NBS in the presence of the proxies. For example, the user might be confused what network is protected. Additionally, as evident from #85, users try to validate the behaviour of the NBS in their deployment. If we document the feature, users will understand better the expected behaviour.
From #85:
NBS is still enabled, but it just doesn't use DNS on any request which is handled by a proxy which does name resolution by itself.
I agree the proxy would resolve the domain name. But after that it might initiate an HTTP request to its local network that was prevented by NBS before 8c7b439.
NBS is still active and working according to its contract, no matter the proxy configuration.
I consider the text in https://jshelter.org/nbs/ to be the NBS contract. Now, if the HTTP proxy happens to be located in the network of the computer in the network of the user, we changed NBS behaviour. It used to protect the network from requests to domain names resolving to local addresses.
But as said on the meeting, I agree that texts in 2750740 and 5fb96a2 are misleading. So I propose a4fce24. Please let me know if the description is now correct or if it needs further clarifications.
I am reopening this issue so that we can improve the docs.
Metadata Update from @polcak: - Issue status updated to: Open (was: Closed)
Metadata Update from @polcak: - Issue tagged with: documentation needed
Please let me know if the description is now correct or if it needs further clarifications.
It works for me, thanks :)
Login to comment on this ticket.