安全与密码学2021arxiv.org
CNAME 的游戏：基于 DNS 的跟踪规避大规模分析
The CNAME of the Game: Large-scale Analysis of DNS-based Tracking Evasion
进阶 · 约 70 分钟读完前置知识：DNS 基础、Web 追踪与 Cookie、浏览器扩展/拦截器
导读
这篇论文大规模分析了基于 DNS 的追踪规避，也就是所谓 CNAME cloaking：第三方追踪器通过把网站子域名的 CNAME 记录指向追踪厂商，让追踪请求伪装成第一方流量，从而绕过浏览器与拦截器的常规防护。研究对这种做法的普及程度和规避机制做了系统性测量与分析。
HN 关注点：这种追踪手段已在数万个高流量网站中使用，讨论焦点在于浏览器防护（uBlock Origin 仅在 Firefox 有效、Chrome 缺乏相应扩展 API）以及 DNS 层拦截能否跟上这类伪装。
HN 评论精选
这几条评论里：支持 1 补充 3
支持CNAME 追踪已大规模普及且浏览器无内置防御，uBO 的对策只在 Firefox 可用，Chrome 用户仍完全暴露。
CNAME 追踪是相对较新的现象，广告营销公司（以 Salesforce 和 Adobe 为首）说服网站修改 CNAME 记录，让浏览器把某个域名的 cookie 数据发送出去（安全影响相当严重）。这种追踪方式越来越流行，已有数万个高流量网站使用，而浏览器没有任何内置防御。更通俗的解释见 grc.com 第 8 页起的笔记。但正如标题所指，目前只有 uBlock Origin 在 Firefox 扩展中实现了对策；与 Firefox 不同，Chrome 没有提供足够强的扩展 API 让该对策生效。Chrome 用户目前在数千个高流量网站上完全可能被窃取私有 cookie 数据。即便是这个对策也显得不够，本质上就是打地鼠游戏。浏览器必须以更万无一失的方式优先关掉它，而我想不出有什么简单办法。
spenvo查看英文原文
CNAME-tracking is a relatively new phenomenon, where ad marketing firms (led by Salesforce and Adobe) are convincing sites to tweak CNAME records in order to get browsers to send a domain's cookie data (yes, security implications here are severe). This tracking method has become increasingly popular with tens of thousands of high-traffic sites utilizing it, and browsers have no built-in defenses against it. A more at-length layman's explanation can be found here, starting on page 8 https://www.grc.com/sn/sn-808-notes.pdf But as the title hits upon, there is one countermeasure that uBlock Origin has implemented for its Firefox extension. But unlike Firefox, Chrome does not provide robust enough extension APIs for the countermeasure to work there. Chrome users are currently completely susceptible to having private cookie data stolen on thousands of high-traffic sites. Even in the case of this countermeasure though, it does seem insufficient as it's essentially a whack-a-mole game. Browsers must prioritize shutting this down in a more foolproof way, and I can't imagine an easy way to do that.
补充CNAME 伪装让第三方追踪库获得第一方域名的安全权限，等同于让厂商随时改代码，是严重安全隐患。
CNAME 追踪的真正问题在于，它让被加载的广告技术库获得了宿主域名的安全权限。这意味着追踪库现在能访问所在网站的一切、挂载任意事件处理器等等。这本质上等同于从内容服务器托管追踪库，区别在于追踪厂商可以随时改源码而无需任何同意。在我看来这是安全噩梦。
yayr查看英文原文
The real problem with CNAME-tracking is that it provides the loaded adtech libraries the security privileges from the hosted domain. This means, tracking libs can now also access everything of the website they are hosted in, attach any event handlers etc. It is essentially the same as hosting the tracking library from the content server, except that the tracking provider can change the source code anytime without requiring any consent. This is a security nightmare imo.
补充DNS 层拦截将越来越低效，除 CNAME 外还有 ALIAS、Cloudflare 的 CNAME 扁平化、SVCB/HTTPS 记录链等论文未讨论的伪装手法。
我在开发一个开源的广告拦截 DNS 存根解析器和客户端。我认为随着基于 DNS 的内容拦截越来越流行，它会变得极其低效。除了 CNAME 会打破客户端软件的种种假设（并因此带来论文所述的安全麻烦）外，还有几种论文没讨论的 DNS 伪装技术：1）ALIAS 记录（似乎未标准化，由 Route53 推广）可以隐藏类似 CNAME 的指针；另一种变体是某些 DNS 服务器（如 Cloudflare）会扁平化 CNAME 记录（即透明地当作 ALIAS 端点）：应答里根本不带 CNAME，你直接拿到 A/AAAA 记录的 IP（这些 IP 很可能是第三方的），据我所知 DNSSEC 对此也无济于事。2）新出的 SVCB/HTTPS 记录又开辟了一条 DNS 伪装通道，例如可以构造一串指针链（如 example.com→example.net→example.org→……层层指向不同域名的 SVCB/CNAME 记录，最终落到任意 IP）。
ignoramous查看英文原文
I develop a FOSS adblocking DNS stub resolver and client. And I believe, DNS-based content-blocking will become drastically ineffective as it gets more popular. Besides CNAMEs breaking all sorts of assumptions a client software makes (and hence also causing security headaches in the process as outlined in the paper), there are a couple other DNS cloaking techniques that the paper doesn't discuss: 1. ALIAS records (not standardized? popularized by Route53) hide CNAME-like pointers. Another variant of this is, some DNS nameservers (like Cloudflare) flatten CNAME records (aka transparently ALIAS endpoints): CNAMEs aren't sent with the answer, that is, you're straight up served the A/AAAA record with IPs (which could easily be third-party). DNSSEC doesn't help here, afaik. 2. The shiny new SVCB/HTTPS records open up another avenue for DNS cloaking. For example, consider this (unverified if correct) record with a chain of pointers: example.com SCVB IN 0 example.net example.net CNAME IN example.org example.org SVCB IN 0 example.us example.us SVCB IN 1 example.uk (ipv4hint=2.2.2.2, ipv6hint=2:2::2) example.uk SVCB IN 0 example.de example.de CNAME IN example.fr example.fr SVCB IN 1 . (ipv4hint=..., ipv6hint=...) example.fr SVCB IN 2 example.es (ipv4hint=..., ...) example.fr SVCB IN 3 example.it (...) example.fr CNAME IN example.ru example.es CNAME IN example.it example.it SVCB IN 1 . (...) example.it SVCB IN 2 example.ch (...) example.it A IN 4.4.4.4 example.it AAAA IN 4:4::4 example.ch SVCB IN 0 example.ru example.ru SCVB IN 1 . (...) example.ru A IN 3.3.3.3 example.ru AAAA IN 3:3::3 (the above is missing the example where targets follow "port prefix naming" viz. _443._https.example.com) Though it remains trivial to uncloak domains hiding behind SVCB/HTTPS records, implementations have to be careful about what they let through. Flattened CNAMEs and ALIAS records; however, to my knowledge, remain undetectable. But: All indications are that it is foolish to rely on DNS to discern between first-party and third-party. I mean, I can already run www.example.com on Netlify, app.example.com on Vercel, api.example.com on AWS, and cdn.example.com on Cloudflare... and those endpoints could very well be running anything the cloud providers want (third party). IP based firewall doesn't suffer these shortcomings, but then, enforcing IP blocks are complicated by Virtual Hosting (multiple web services behind a single IP) and IPv6 (too many addresses to curate and block).
补充把主域名 CNAME 给追踪厂商等于让出整个域名，不安全；DNSCrypt-proxy/pihole 可拦截转发的 CNAME 请求，搭建简单。
用 CNAME 把主域名转发给某家追踪公司的网站，基本等于把整个域名拱手相让，我看不出这怎么算一种安全可靠的追踪用户方式。DNSCrypt-proxy（如今连 pihole 也行）实际上能拦截被转发的 CNAME 请求。搭建全网广告拦截一点也不复杂，见 github.com/notracking/hosts-blocklists/wiki/Install-dnscrypt-proxy。
rndomsrmn查看英文原文
Websites that use CNAME to forward their main domain to some tracking company, basically give their entire domain away, I don't see how that is a good secure way to track your users.. DNSCrypt-proxy (and even pihole these days I believe) are actually capable of blocking forwarded CNAME requests. Setting up such system for network wide adblocking is not complicated at all, see: https://github.com/notracking/hosts-blocklists/wiki/Install-dnscrypt-proxy
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2021Hacker News 讨论帖108 分 · 47 评
- 2021Hacker News 讨论帖115 分 · 82 评
同领域还值得读
如何入侵一台已关机的电脑：在 Intel ME 中运行未签名代码
How to hack a turned-off computer, or running unsigned code in Intel ME
这篇 Black Hat 2017 白皮书讨论 Intel Management Engine（ME）的安全问题：如何在 ME 中运行未签名代码，以及攻破处于关机状态的电脑的相关…
安全与密码学2017 · 543 分 · 107 评专业 · 约 40 分钟编辑精选比特币：一种点对点的电子现金系统（2008）
Bitcoin: A Peer-to-Peer Electronic Cash System (2008)
中本聪 2008 年发表的比特币白皮书，提出了无需可信第三方的点对点电子现金系统。
安全与密码学2017 · 536 分 · 394 评入门 · 约 45 分钟编辑精选GPRS 加密算法 GEA-1 的密码分析表明存在故意弱点
Cryptanalysis of GPRS Encryption Algorithms GEA-1 suggest intentional weakness
首次公开了对 GPRS 加密算法 GEA-1 和 GEA-2 的密码分析攻击。
安全与密码学2021 · 487 分 · 107 评专业 · 约 90 分钟编辑精选Signal 消息协议的形式化安全分析
A Formal Security Analysis of the Signal Messaging Protocol
用形式化方法分析 Signal 消息协议（TextSecure）的安全性：作者在多阶段密钥交换模型下，借助自动化证明工具对协议的密钥协商与 Double Ratchet 密钥更新…
安全与密码学2016 · 353 分 · 230 评专业 · 约 120 分钟编辑精选A2：模拟恶意硬件
A2: Analog Malicious Hardware
论文研究如何在芯片设计阶段植入模拟电路形式的恶意硬件后门，使其难以被常规检测发现。
安全与密码学2016 · 315 分 · 94 评专业 · 约 75 分钟编辑精选