展示HN:隐私实验 – 重写HTTPS、TLS和TCP/IP数据包头部
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>或者查看LP: https://404-nf/carrd.co<p>或者继续阅读...<p>在一个足够小的群体中,你的TLS握手就足以将你识别为一个独特的客户端。大约六个月前,我开始学习客户端指纹识别。我了解到这项技术正在变得越来越好、越来越精确,但没有意识到服务器可以如此轻松地对用户进行指纹识别——毕竟,你只是放弃了所有的Cookie!在现代互联网体验中,指纹识别几乎已成为一种必要。<p>令我感到担忧的是,服务器开始利用我们依赖的安全特性来识别和指纹识别客户端。<p>- JS - 收集你的JS属性值
- 字体 - 收集你下载的字体
- JA3/4 - TLS密码套件指纹
- JA4/T - TCP数据包头指纹(TTL、MSS、窗口大小/比例、TSval/ecr等)
- HTTPS - HTTPS头指纹(UA、sec-ch等)
- 还有更多...<p>因此,我构建了一个工具,让我在多个层面上控制我的指纹:<p>- 本地的mitmproxy处理HTTPS头和TLS密码套件协商
- eBPF + Linux TC重写TCP数据包头(TTL、窗口大小等)
- 协调伪装确保所有层面呈现一致的、选择的指纹(尚未完全一致)<p>当前状态:这是一个成功伪装JA3/JA4(TLS)、JA4T(TCP)和HTTP指纹的概念验证工具。它还有些粗糙,需要一定的Linux知识来设置。<p>当从单个SYN/ACK交互中收集到如此多的遥测点时,服务器识别唯一客户端的精确度令人担忧。某些个人和组织开始注意到这一点,并制作了一些资源,帮助人们更好地理解他们在互联网上留下的数据量:例如amiunique.org、browserleaks.com和coveryourtracks.eff.org等。<p>这只是一个基础,但这是与服务器端被动监视的斗争。像nmap和p0f这样的工具在过去二十年里一直在利用这一点,而几乎没有开发出任何工具来对抗它——可行的选项(burpsuite)并未被宣传为隐私工具。<p>即便如此,尽管所有值都被全面且一致地伪装,SSO令牌仍然可以跟踪我们并揭示我们的身份。当像谷歌这样的大公司的SDK深深植根于开发流程中时,这就成了一个不可接受的问题。因此,这个项目将会发展,我希望添加某种无头/有头的群体,来污染你的SSO历史——法律障碍算什么。<p>我还没有以实质性的方式分享这些内容,实际上大约一周前我刚刚完成了一个预发布的、几乎可以工作的版本。我并不是计算机科学或网络安全工程师,只是一个对隐私充满热情、对计算机有一定了解的人。这是一个更大工具的概念验证。由于TCP/IP数据包头的特性,如果这个软件能够在分布式网状网络上运行,隐私可以像Nym Technologies所尝试的那样在混合网络上分发。<p>所有的组件都在这里,只是还没有以正确的方式组合在一起。我几乎可以看到整个拼图的样子...
查看原文
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...