Show HN: 隐私实验 – 重写 HTTPS、TLS 和 TCP/IP 数据包头
2 分•作者: un-nf•7 个月前
README：<a href="https://github.com/un-nf/404/blob/main/README.md" rel="nofollow">https://github.com/un-nf/404/blob/main/README.md</a>
或者 LP：https://404-nf/carrd.co
或者继续阅读...
在一个足够小的群体中，你的 TLS 握手就足以将你识别为一个独特的客户端。大约六个月前，我开始学习客户端指纹识别。我了解到它正在变得越来越好、越来越精确，但没有意识到服务器可以多么容易地进行用户指纹识别——毕竟，你只是交出了所有的 Cookie！对于现代互联网体验来说，指纹识别几乎已经成为一种必需品。
令我担忧的是，服务器开始使用我们依赖的安全功能来识别和指纹识别客户端。
- JS - 收集你的 JS 属性值
- 字体 - 收集你下载的字体
- JA3/4 - TLS 密码套件指纹
- JA4/T - TCP 数据包头指纹（TTL、MSS、窗口大小/比例、TSval/ecr 等）
- HTTPS - HTTPS 标头指纹（UA、sec-ch 等）
- 还有更多...
因此，我构建了一个工具，让我可以控制我在多个层面的指纹：
- 本地主机 mitmproxy 处理 HTTPS 标头和 TLS 密码套件协商
- eBPF + Linux TC 重写 TCP 数据包头（TTL、窗口大小等）
- 协调的欺骗确保所有层呈现一致的、选择的指纹——（尚未连贯）
当前状态：这是一个概念验证，成功地欺骗了 JA3/JA4 (TLS)、JA4T (TCP) 和 HTTP 指纹。它还很粗糙，需要一些 Linux 知识才能设置。
当从单个 SYN/ACK 交互中收集如此多的遥测点时，服务器识别唯一客户端的精确度变得令人担忧。某些个人和组织开始注意到这一点，并提供了帮助人们更好地了解他们在互联网上留下多少数据的资源：amiunique.org、browserleaks.com 和 coveryourtracks.eff.org 等。
这只是基础，但它是一场对抗服务器端被动监视的斗争。像 nmap 和 p0f 这样的工具在过去二十年中一直在利用这一点，但几乎没有开发任何工具来对抗它——可行的选择（burpsuite）也没有被用于隐私保护。
甚至超越这一点，即使所有值都被全面且连贯地欺骗，SSO 令牌仍然可以跟踪我们并揭示我们的身份。当像 Google 这样的大公司的 SDK 如此深入地融入开发流程时，这是不可行的。因此，这个项目将会发展，我希望添加某种无头/有头的集群，污染你的 SSO 历史——无视法律障碍。
我还没有以实质性的方式分享这个，而且大约一周前才完成了预发布、勉强可用的版本的完善。我不是计算机科学或网络安全工程师，只是一个对隐私充满热情并且对计算机感兴趣的人。这是更大工具的概念验证。由于 TCP/IP 数据包头的性质，如果此软件在分布式网状网络上运行，隐私可以在混网中分布，就像他们试图在 Nym Technologies 实现的那样。
所有的部分都在那里，只是还没有以正确的方式组合在一起。我想我几乎可以看到整个拼图...
查看原文
The README: <a href="https://github.com/un-nf/404/blob/main/README.md" rel="nofollow">https://github.com/un-nf/404/blob/main/README.md</a><p>Or the LP: https://404-nf/carrd.co<p>Or read on...<p>In a small enough group of people, your TLS-handshake can be enough to identify you as a unique client. Around six-months ago, I began learning about client-fingerprinting. I had understood that it was getting better and more precise, but did not realize the ease with which a server could fingerprint a user - after all, you're just giving up all the cookies! Fingerprinting, for the modern internet experience, has become almost a necessity.<p>It was concerning to me that servers began using the very features that we rely on for security to identify and fingerprint clients.<p>- JS - Collection of your JS property values
- Font - Collection of your downloaded fonts
- JA3/4 - TLS cipher-suite FP
- JA4/T - TCP packet header FP (TTL, MSS, Window Size/Scale, TSval/ecr, etc.)
- HTTPS - HTTPS header FP (UA, sec-ch, etc.)
- Much more...<p>So, I built a tool to give me control of my fingerprint at multiple layers:<p>- Localhost mitmproxy handles HTTPS headers and TLS cipher-suite negotiation
- eBPF + Linux TC rewrites TCP packet headers (TTL, window size, etc.)
- Coordinated spoofing ensures all layers present a consistent, chosen fingerprint - (not yet cohesive)<p>Current Status: This is a proof-of-concept that successfully spoofs JA3/JA4 (TLS), JA4T (TCP), and HTTP fingerprints. It's rough around the edges and requires some Linux knowledge to set up.<p>When there are so many telemetry points collected from a single SYN/ACK interaction, the precision with which a server can identify a unique client becomes concerning. Certain individuals and organizations began to notice this and produced sources to help people better understand the amount of data they're leaving behind on the internet: amiunique.org, browserleaks.com, and coveryourtracks.eff.org to name a few.<p>This is the bare bones, but it's a fight against server-side passive surveillance. Tools like nmap and p0f have been exploiting this for the last two-decades, and almost no tooling has been developed to fight it - with the viable options (burpsuite) not being marketed for privacy.<p>Even beyond this, with all values comprehensively and cohesively spoofed, SSO tokens can still follow us around and reveal our identity. When the SDKs of the largest companies like Google are so deeply ingrained into development flows, this is a no-go. So, this project will evolve, I'm looking to add some sort of headless/headful swarm that pollutes your SSO history - legal hurdles be damned.<p>I haven't shared this in a substantial way, and really just finished polishing up a prerelease, barely working version about a week ago. I am not a computer science or cysec engineer, just someone with a passion for privacy that is okay with computers. This is proof of concept for a larger tool. Due to the nature of TCP/IP packet headers, if this software were to run on a distributed mesh network, privacy could be distributed on a mixnet like they're trying to achieve at Nym Technologies.<p>All of the pieces are there, they just haven't been put together in the right way. I think I can almost see the whole puzzle...