阅读:5391回复:23
启用ub去广告扩展后发现dns泄露是什么原因? |
|
最新喜欢:![]() |
1楼#
发布于:2020-11-20 21:04
这个 bug 在 firefox 80 修复了才对。
https://github.com/uBlockOrigin/uBlock-issues/issues/1294 https://bugzilla.mozilla.org/show_bug.cgi?id=1618271 如果使用了 firefox 之前的版本使用最新的 uBO 版本也会自动关闭导致泄漏 dns 功能,除非你手动打开了。 https://github.com/gorhill/uBlock/wiki/Advanced-settings#cnameuncloakproxied 关于 uBO 这个功能的作用介绍: https://blog.apnic.net/2020/08/04/characterizing-cname-cloaking-based-tracking/ |
|
2楼#
发布于:2020-11-22 13:56
lonely_8:这个 bug 在 firefox 80 修复了才对。我使用的是最新正式版火狐,ub也是最新版的(默认设置),但还是如此。是不是要对ub进行特殊的设置呢 ? |
|
3楼#
发布于:2020-11-22 17:04
|
|
4楼#
发布于:2020-11-22 19:23
|
|
5楼#
发布于:2020-11-22 20:06
marb:谢谢,第一项改为无效果,直接关闭有效果了。而且使用Proxy SwitchyOmega扩展必须设置成全局走代理不能设置成自动,即使在自动模式下将测试网站改成代理模式也会泄露。自动模式泄漏可能是你的规则没有匹配全部的子资源域名。 会变得无法拦截通过 cname 伪装成第一方网站的广告跟踪脚本。 关闭后拦截效果会变得跟 Chrome 浏览器相当, 因为这个功能依赖的 api 当前是 Firefox Only,也是主楼问题的元凶, 但我这里测试是没问题的(Nightly 85 + uBO 1.31.1.2)。 一楼最后的链接有对比图(uBO rc1 为开启后的效果): ![]() Brave 浏览器听说将内置拦截这种类型的广告过滤器。 https://www.theregister.com/2020/10/28/brave_cname_block/ |
|
6楼#
发布于:2020-11-23 10:35
lonely_8:自动模式泄漏可能是你的规则没有匹配全部的子资源域名。您说的自动模式泄漏可能是你的规则没有匹配全部的子资源域名是不是指的代理扩展中的规则列表?现在我使用的是https://raw.githubusercontent.com/gfwlist/gfwlist/master/gfwlist.txt 不知如何解决。 您所说的但我这里测试是没问题的(Nightly 85 + uBO 1.31.1.2)。 是指关闭第一项和完全关闭还是指使用自动代理导致的泄露,如果是使用自动代理导致的泄露,我发现在使用自动代理下https://ipleak.net/不会显示泄露而在https://browserleaks.com/dns下会显示泄露。 |
|
7楼#
发布于:2020-11-23 11:29
如果仅仅将将 cnameUncloakProxied 设置成 true在https://ipleak.net/测试不会出现泄露,但在https://browserleaks.com/dns下会泄露。
|
|
8楼#
发布于:2020-11-23 14:58
marb:如果仅仅将将 cnameUncloakProxied 设置成 true在https://ipleak.net/测试不会出现泄露,但在https://browserleaks.com/dns下会泄露。回到原帖的确,从 https://bugzilla.mozilla.org/show_bug.cgi?id=1618271 中看, Firefox 并没有修复通过戴笠扩展设置的戴笠通道导致的 dns 泄漏。 仅仅修复了通过 Firefox 网络设置自带的“手动戴笠配置”项导致的泄漏。 https://searchfox.org/mozilla-central/rev/48151c3619b0b5b4b92d5f14eaa839e619605d2d/netwerk/dns/nsDNSService2.cpp#874 |
|
9楼#
发布于:2020-11-23 17:14
lonely_8:的确,从 https://bugzilla.mozilla.org/show_bug.cgi?id=1618271 中看, ![]() 将如下两个dns检测网站设为代理,将代理扩展无论设为自动还是全局情况下使用https://ipleak.net/进行检测都不会出现泄露,但使用https://browserleaks.com/dns进行检测则必须将代理扩展设置成全局否则会发现dns泄露,从图上看即使将这个测试网站加入了代理。以上的测试都是在彻底关闭cnameUncloak 的情况下进行的。 在https://proxy-switchyomega.com/faq/中提及了,“如果您使用 SOCKS5 代理,请注意一个可能的 DNS 泄漏”在 Chromium 浏览器(以及基于 Chromium 的所有浏览器)中使用 SOCKS 代理时,部分 DNS 请求不会经过服务器发送(英文参考资料)。这是由 DNS 预加载造成的(https://github.com/FelisCatus/SwitchyOmega/wiki/DNS-and-SOCKS-proxy#%E4%B8%AD%E6%96%87)我发现network.dns.disablePrefetch 已经是true状态了(https://developer.mozilla.org/zh-CN/docs/Controlling_DNS_prefetching)。这个问题到底如何处理? |
|
10楼#
发布于:2020-11-23 17:41
marb:将如下两个dns检测网站设为代理,将代理扩展无论设为自动还是全局情况下使用https://ipleak.net/进行检测都不会出现泄露,但使用https://browserleaks.com/dns进行检测则必须将代理扩展设置成全局否则会发...回到原帖 我已经提交 bug 到 bugzilla了。 之前的修复似乎是没考虑到一些戴笠扩展设置的戴笠, 导致 uBO 使用 browser.dns API, 其产生的 DNS 查询流量依然没通过远程解析,导致了泄漏。 介意的话直到 FF 修复了再打开 uBO 的 cnameUncloak 功能吧。 或者不要使用戴笠扩展,只使用 FF 内置的“手动戴笠配置”功能使用 pac 设置戴笠。 |
|
11楼#
发布于:2020-11-23 18:58
|
|
12楼#
发布于:2020-11-23 19:01
也就是说不是SwitchyOmega扩展的问题而是火狐自身的问题是这样理解吗?
|
|
13楼#
发布于:2020-11-23 19:17
|
|
14楼#
发布于:2020-12-17 16:26
|
|
上一页
下一页