警告
本篇文章所有内容仅供学习和研究使用。请各位读者遵循所在国家/地区的相关法律法规，勿将对应技术手段用于逃避监管或违法犯罪，否则产生的一切后果将由您自行承担。 此外，本篇文章引用的所有内容、新闻均不代表本人态度、立场，列出或推荐的所有软件均与本人无任何利害关系。
前言
4月13日，未登录用户从中国大陆访问Github时，会出现403错误。听群友讲起时，还以为是最近有什么大型会议，GFW进一步强化了阻断。后面想想，一般GFW都是通过SNI(Server Name Indication)阻断、DNS污染、屏蔽IP段阻止访问。但不论是以上哪种情况，都不应返回403状态码。恰逢美国加征关税，群友戏称：“紧急通知，由于美国加征关税，Github访问响应码现已从200上调至403”。
确认真的被主动屏蔽后，心情有些复杂，毕竟中国大陆中做的比较大的Gitee，至少目前，狗看了都摇头。我想，可能这是继OpenAI之后，又一个主动屏蔽中国大陆请求的大型网站（事实上，香港地区也被纳入了OpenAI的屏蔽名单…）。我也猜测过是否是又出现了12306 订票助手插件拖垮 GitHub 事件原因始末这种事件，导致Github短期屏蔽了来自中国大陆的流量。但最近貌似没什么大动作，可能性应也不大。
截至我个人最后一次检查，都未在Access to this site has been restricted #156515中，看到Github的官方回复。次日，Github发布[Retroactive] Access from China temporarily blocked for users that were not logged in，宣告该问题是出于意外的配置错误。
如果只是讲Github主动屏蔽事件，此文应就此终结。但在v2ex冲浪时，发现Github主动屏蔽事件全记录及其绕过中提到一个小工具Sheas Cealer，其可以通过在选定IP后绕过Github的主动屏蔽，这引起了我的一咩咩兴趣。细看了下，这一小工具主要通过伪造SNI拓展标记绕过部分阻断方式（详情可参考：通过配置Chromium系列浏览器启动参数以解决DNS污染与SNI阻断）。这让我想起了以往的一个选题：网络冲浪中各个可能泄露隐私的环节（包括但不限于SNI泄露）都有哪些？只是最后未成形，搁置较久忘了。于是就抓住这恰巧的一丝热情，提笔重启了这一系列文章。
隐私保护其实是个老生常谈的问题，随意搜索都能搜到大量的讨论。在Github上，也有许多以个人信息安全、隐私保护为主要内容的仓库，如Lissy93/personal-security-checklist、ffffffff0x/Digital-Privacy等等。
如你认为“保护隐私”不重要，那“窥探隐私”是否能从进攻方的角度，勾起你的兴趣？试想一下，你作为进攻方，逆向运用隐私保护技术，将盾化为矛，从其他无隐私意识的人的蛛丝马迹中，推导出更多相关信息。或许你会问，这样的推导又有什么用？我在人工智能解析人情世故是银弹还是亵渎？中，简单概述了以开源情报分析的思路为引，以人工智能模型为基，实现另一种解析、处理人情世故的方式。通过逆向运用隐私保护技术得到的数据，我认为其往往会与“真实”较为接近，属于较优的情报分析信息源。如内容过多看不过来，还可借助AI模型进一步筛选。
此外，我想再引用两个案例强化一下开源情报分析的概念。在互联网时代，每一条短信息、每一张图片都可能包含比发布者认为多得多的信息，隐私往往就是这样在不经意间被泄露、利用。
太空小孩发布的文章：如何用一张照片推理具体位置｜网络迷踪入门指南。
EyeOpener制作的视频：荷兰警方用了8年也逮不到的逃犯，网络大神一天就破解了关键位置（Bellingcat原文入口）
最后，以上逆向运用隐私保护技术推导信息的方式，距离普通人可能比较遥远。所以接下来我分享一个常见的攻击情形，仅作抛砖引玉：通过建立一个WIFI热点，我能嗅探到哪些用户数据？ 这一攻击情形底层实际与企业上网行为管理系统、校园网、ISP流量监控等是一致的。
通过WiFI热点我能看到什么？
（一）用户如未启用加密DNS，可通过嗅探用户DNS解析记录推导日常惯用的APP、网页以及相应的使用习惯。详见下文3.1 DNS泄露。
（二）用户如未启用仅https模式浏览，可嗅探获得用户访问网页的完整内容（除非另有加密，否则一切浏览行为形同裸奔）。特别的，部分社交平台创建分享链接时，默认生成的是http前缀的链接。此时可通过受控的WiFi热点截取完整访问链接，再通过完整分享链接携带的跟踪属性反推用户个人社交账号。关于如何从分享链接反查得到用户社交账号，详见下文3.2 社交平台跟踪链接泄露。
（三）即使用户启用了仅https模式浏览，由于https连接的建立往往伴随着SNI数据的交互，且ECH(Encrypted Client Hello)技术需用户使用加密DNS、Web服务器支持ECH，估计大部分的用户在访问网站时存在SNI泄露的风险。任一上层路由的管理员，都能通过嗅探SNI信息推断用户访问网站、应用程序的情形。详见下文3.4 SNI泄露。
（四）用户安装了部分天然使用http协议与服务器进行交互的APP，导致部分信息泄露。例如，微信所使用的是自己的魔改协议，其部分请求底层实现了自己的加密后，使用http与服务器进行数据传输。
虽然加密后的数据确实不会被窃取，但并不是所有的数据都会被加密。类似用户的聊天记录这种高度敏感的数据确实不会被泄露，但类似设备型号等非敏感内容，能从客户端到腾讯的微信服务器中的每一个路由器设卡嗅探得到。我估计，微信应该不认为这些属于隐私，因此也没什么动力再进行修改。毕竟：《微信隐私保护指引》1.2 明确列出：为了预防病毒、木马程序或其他恶意程序、网站，我们可能会收集你设备安装的应用信息、正在运行的进程信息或设备内存中寄存的数据，以防止你的个人信息泄露。隐私协议都能写的如此宽泛和不合理，很难让人相信微信会修改这一个小小的泄漏点。
分条列点，泄露项都有什么？
实务中，泄露的项实在太多，不便一一列举，这里主要围绕常见的一些泄露点讨论一下。
DNS泄露
一般情况下，DNS解析请求将以明文形式发送到远程的DNS服务器的53端口请求解析。这里的远程的DNS服务器，可能是内网的DNS服务器（如：192.168.1.1），可能是预先配置的远程DNS服务器（如：223.5.5.5）。但不论哪种，由于传输过程中没有任何加密，任一网络路径上的节点都能捕获解析这些DNS请求记录，侧面泄露用户的上网习惯。
除泄露用户上网习惯外，明文形式DNS解析请求也是DNS劫持的必要条件。在一些国家/地区，ISP的恶意网络节点在接收到用户的DNS请求时，抢答“预设的IP地址”给用户；或者，丢弃掉应原样转发的DNS解析请求结果后，应答“预设的IP地址”给用户。通过这样的方式，ISP能够影响用户浏览部分网站，或误导用户向错误网络节点发起请求，达到阻止用户访问某些网站、插入广告、跳转到其他页面等目的。不过，随着政策法规的完善，以及DoH、DoT、DNSCrypt等保障DNS请求不被第三方监听或篡改的技术愈发成熟，ISP的恶意网络节点进行DNS劫持的成本越来越高。目前通过DNS劫持插入广告、跳转到其他页面这种如此恶意的行为，已经很少见了。但抢答DNS解析请求，影响用户浏览部分网站的行为仍广泛存在。
如希望加密所有的DNS解析请求，可参考Adguard DNS文档中列举的DNS服务提供者，选用安全、可靠的DNS请求协议与DNS服务器。需注意，在某些配置软件中，设置DoH/DoT等加密DNS服务协议时，往往还需设置一个纯IP的DNS请求服务器。一些情况下，这个纯IP的DNS请求服务器仅用于解析其他DNS服务器中的域名（例如：https://doh.opendns.com/dns-query中的doh.opendns.com），以便后续发起DNS解析请求。但在另一些情况下，配置软件会在其他DNS请求服务器都不可用时，采用这个纯IP的DNS请求服务器进行解析。这将引入意外的DNS泄露。如需避免，一方面应尽量选用可用性较高的DNS服务，另一方面应注意配置软件自身的实现逻辑。
最后，DNS泄露可以说是个老生常谈的问题，在LINUX DO上也有比较热烈的讨论，感兴趣的读者可以额外参考下。
社交平台跟踪链接泄露
部分社交平台在生成分享链接时，未对用户标识符进行有效的加密或混淆，这将允许任一恶意攻击者都能从分享的链接中逆推出分享用户的个人主页。
截至2025年4月15日，你分享的链接泄露隐私了吗？宣称能够从分享链接反查“小红书、微博、网易云音乐、QQ音乐、全民K歌、喜马拉雅、雪球、Keep、微信读书、汽水音乐、百度、酷安、小宇宙、知识星球、知乎、哔哩哔哩、即刻”的用户主页。博主抽取了部分平台进行测试，确认有效。
部分媒体数据分析工具也自带该类功能，如Tikhub。估计在广告推荐的领域，这种嗅探已持续了相当一段时间。
浏览器指纹泄露
浏览器指纹是一项通过一系列特征识别和追踪用户的技术。使用这类技术，网站不需要依赖Cookies等方式，可以实现无感追踪，具体实现方式可参考FingerprintJS。
距离日常生活较近的利用方式，可能是调研问卷中的“去匿名化”。使用问卷星等途径创建调研问卷时，默认会记录填报途径、IP地址等，这可以被视作一种简略的浏览器指纹。当然，问卷星等常见的调研问卷与通过浏览器指纹“去匿名化”的功能重合度是比较低的，如需真正实现“去匿名化”，需要自己构建一套调研问卷服务。
整个攻击可以分以下几步：首先，通过在用户常访问的一些内部网站上插入浏览器指纹采集代码，通过聚合用户User Agent、HTTP_ACCEPT Headers、Time Zone、Screen Size and Color Depth、System Fonts等特征，将用户的浏览器指纹与用户关联起来。而后，通过发布带有浏览器指纹采集代码的“匿名问卷”，要求用户进行填报。最后，通过比较日常情况下采集到的用户浏览器指纹、该“匿名问卷”填报过程中采集到的用户浏览器指纹破解匿名难题。只要用户的浏览器指纹自身足够特殊，用户通过挂载VPN、开启浏览器隐身模式等试图强化匿名性的方式几乎不会起到作用，从而实现调研问卷的“去匿名化”。
如何避免因浏览器指纹泄露个人隐私？我认为需因地制宜分情况看待，只有5. 大隐隐于市，小隐隐于野才能最大程度避免个人隐私的泄露。例如，在企业内网环境中，你不使用Edge等自带浏览器，而是为保护隐私，阻止浏览器指纹特征的采集，自己安装使用了LibreWolf等强隐私保护的浏览器。在这种情况下，尽管你的浏览器特征难以被精确采集，但因为其他人不会这么做，对抗浏览器特征采集的行为就是最大的特征，一抓一个准。
最后，如希望了解你的浏览器指纹有多特别，可以通过以下链接自测：
SNI泄露
在使用https访问网站时，并非所有数据都是加密的。
为了向服务器指定需要访问网站的域名，在TLS/SSL握手流程中客户端往往会将域名明文（因为彼时加密连接尚未建立）发送到服务端。在这一过程中，所有途中的流量监测点都能得到这一条新建的https连接所对应的网站域名，此即为SNI泄露。
更详细的数据包交互过程可参考syncsynchalt/illustrated-tls12（在线演示入口：The Illustrated TLS 1.2 Connection）。
为了缓解SNI泄露，较新的TLS协议引入了ECH。但ECH的发展需要一定过程，目前很多时候ECH仍不能有效保护隐私：一是因为有效的ECH需用户启用加密DNS以及Web服务器支持ECH；二是因为目前大部分ECH的网站是托管在Cloudflare上的，其SNI被指定为cloudflare-ech.com，这是一个非常明确的特征，可以被简单规则直接拦截掉。
如需自测目前配置是否支持ECH，可使用tls-ech.dev。
剪贴板信息泄露
目前，各操作系统对于剪贴板数据的保护仍略显不足。在大部分情况下，剪贴板的内容默认情况下不会被自动清除，且一般能够被网页、应用程序直接读取，这带来了隐私风险。特别的，中国大陆许多应用程序会在启动时读取用户的剪贴板，以实现“淘口令”跳转商品、“口令红包”等效果。软件厂商采用这一方式实现分享链接需求的原因有很多。例如，腾讯曾通过一些方式限制用户通过微信分享部分平台的营销链接。某种程度上，这可能也算一个历史遗留问题。
为了防范这类攻击，Edge浏览器做了针对剪贴板读取的权限拦截，会在网页读取前弹窗询问用户是否允许该操作；KeepassXC等密码管理器，则会通过在复制密码后一段时间内后清空对应剪贴板条目，减少敏感信息通过剪贴板被泄露的可能；小米手机在系统层强化了对剪贴板的控制，用户可以自由选择是否允许各应用程序能否访问剪贴板内容。
但在很多时候，针对剪贴板的保护仍是缺位的。某些时候，无需任何前置条件，用户只需打开特定网页即可窃取或修改当前剪贴板的内容。用户需要使用第三方保护工具或定期清空剪贴板、反复比对剪贴板信息，才能保障安全性和隐私性。例如，近期有一种被称为MassJacker的恶意软件通过盗版软件进行分发。这一恶意软件将在后台实时监控用户的剪贴板活动，并在用户复制加密货币钱包地址执行转账时，对钱包地址进行篡改，达到窃取用户资产的目的。此类通过剪贴板攻击窃取加密货币资产的攻击，据我了解，应该很早就有了。MassJacker应只是较新发现的恶意软件，形式上应该没有实质性的更新。某种意义上，这也侧面反映了，招不在新，好用就行。
DPI、DFI检测
由于https的推行，目前访问网络的大部分流量均已加密。在正常的安全配置下，DPI解密数据包的成本非常高（几乎不可能），因此DPI分析的主要是传输的数据包中未加密的部分（如Client Hello）。而DFI主要针对用户一段时间内流量的行为特征进行分析。DFI通过分析连接流的包长度等信息，可以推断用户访问的目标、所使用的应用类型（如VoIP、视频会议）等信息。
DPI、DFI检测较为依赖所采用的识别规则以及模型，且规则和模型对于普通用户而言基本都是黑盒，比较复杂，这里不再展开说明。
如需进一步了解，可参考：
ValdikSS/GoodbyeDPI，一个对数据包进行细微修改以干扰DPI检测的工具；
xvzc/SpoofDPI，另一个对数据包进行细微修改以干扰DPI检测的工具；
ntop/nDPI，DPI检测的一个开源实现；
流量转发？
如果你只是希望避开部分局域网或ISP的监控（例如：校园网的流量审计设备），将流量转发到其他地区是一个很直接的想法。例如，由于版权等原因，许多国家/地区对BT下载抓的很严，甚至设立了一系列蜜罐节点。但中国大陆几乎不直接对BT资源做管辖，热门且刚出炉的资源基本上能比较快下载到且不需要担心被ISP封禁上网账号。
也存在部分用户，在使用BT下载时除合规检测外还担心隐私泄露。例如，I Know What You Download是一个利用BT网络特征，查询对应IP在过去一段时间内所下载过资源的工具。如果未对IP进行伪装，且恰好该用户又对BT下载比较热衷，那么恶意攻击者就可以通过用户IP反推出你近期感兴趣的领域。
为解决这些问题，可以采用Cloudflare WARP、Wireguard组网、SSH Tunnels等方式。这些都是比较简单、易用的流量转发方案。
DNS任播泄露地理位置
DNS提供商往往使用Anycast等技术接收用户的DNS请求，这使得用户在需要DNS解析时，会将DNS请求发往就近的DNS解析服务器节点，这可能引入潜在的地理位置泄露风险。
具体来说，恶意网站可以通过生成一系列随机的域名要求用户进行解析，这些生成的域名不会存在于任何就近的DNS解析服务器缓存中，因此就近的DNS解析服务器节点会将这些域名转发至其他DNS服务器进行查询。通过这一转发过程，即可获取就近DNS解析服务器的IP，从而反推出用户所在的大致位置。
可使用DNS Leak Test - Browserleaks进行DNS泄露情况自测。
WebRTC泄露真实IP地址
WebRTC(Web Real-Time Communication)多用于在线音视频通话，允许在浏览器之间直接建立点对点的连接，在无需服务器中介的情况下实现音视频通信。部分用户使用VPN、代理服务器或NAT等方式期望隐藏自身真实IP时，其配置不会涵盖代理WebRTC连接，这使得只需通过WebRTC协议建立点对点连接，即可获取用户的真实IP。且通过比对用户当前浏览网页时发起请求的IP与通过WebRTC协议嗅探得到的真实IP，即可判断用户是否正使用VPN、代理服务器或NAT等方式上网。
为阻止其泄露真实IP地址，多数情况下使用浏览器拓展是比较方便的方式。安装浏览器拓展后，可访问WebRTC Leak Test、WebRTC 泄漏测试进行自测。
常用的通过配置项或浏览器拓展阻止WebRTC泄露真实IP的方式，可参考以下文章：阻止浏览器 WebRTC 泄露真实 IP 地址。
不可信的代理服务
为实现较为良好的代理服务效果，用户的DNS请求许多时候是交由代理服务器进行解析，部分软件还通过Fake IP等方式进一步加速代理过程。此外，用户通过代理服务所建立连接的四元组信息，代理服务器上一般也是可见的。
因此，如果所选用的代理服务是不可信的，用户的DNS解析记录、用户所访问IP的记录都可能会被泄露，很多时候相当于裸奔。
为缓解此类问题，一个显然的思路是在本地采用DoH服务。通过在客户端直接向DoH服务器发起DNS解析请求，并期望代理服务器加速这一请求过程，而不是借助代理服务器辅助解析DNS后返回以减少DNS泄露风险。但由于3.4 SNI泄露客观存在，且代理服务器能记录用户连接的四元组信息，这一思路实际上对于隐私泄露的缓解能力有限。
目前比较可靠的方式应是配置链式代理。实务上，一般是新增一个完全受控的云服务器或使用Cloudflare的WARP服务，作为代理服务器的后置节点。这样，不可信的代理服务只能监测到加密流量流向了这一完全受控的云服务器或Cloudflare，减少了隐私泄露的风险。
大隐隐于市，小隐隐于野
如果我针对以上可能泄露隐私的点一一解决了，我真的变得更有隐私了吗？
我认为，这主要取决于你如何看待隐私。
回到“通过建立一个WIFI热点，我能嗅探到哪些用户数据？”的例子。如果你认真落实了以上这些方案，诚然，这能保证你的流量不被中间的各个网关记录，你的上网痕迹难以被恶意第三方窥探，