在2020-07-30，Tor Project在推特上回复了我之前两次公开披露的信息。虽然我期待着回复，但我认为这封信应该是直接寄给我的，或者可能是通过私人渠道发送的，因为他们知道如何联系我。我没想到他们会把我从收件人名单中漏掉。我写这封回信是为了澄清Tor项目认为令人困惑的项目，纠正错误陈述，并重新提出未回答的问题。下面是我寄回给Tor Project的信，以及他们推文中的文本副本。我希望这能重新为与Tor项目进行更友好、更具接受性的交流铺平道路。2020年8月2日亲爱的Tor项目，我注意到你在Twitter上发布了对我最新博客系列的回复。然而，我很失望你没有直接回复我。特别值得一提的是：2020年7月30日，您在Twitter上发布了您的回复。(https://twitter.com/torproject/status/1288955073322602496)你的回复由一条带有4张文字图片的推文组成。通过使用文本图片，您可以防止基于文本的搜索发现您的响应。
您的推文中没有包含我的推特账号@hackerfactor。如果不是其他人在推特上回复你，我可能会错过你的回复。
在你回复的文字图片中，你没有提到我的名字，也没有提到你指的是谁，但你确实直接回应了我的一些批评和引用。
由于你的回复方式，我在推特上没有提到你的回复。这就好像你不想让我阅读或回复你的回复一样。话又说回来，在两年多的时间里，您一再要求与我进行直接讨论。每一次，您要么忽略请求，要么不同意会面。我已经包括了你的文字图片，并抄写在下面。这将允许搜索引擎和未来的研究人员轻松找到您的公开回复。此外，我在这封信中对它们进行了定位，以便在上下文中考虑我的答复。Tor项目回复，tweet介绍(文本)：人们向我们询问了一系列被宣传的错误，并错误地贴上了0天的标签。每当我们收到高风险安全漏洞的通知时，我们都会一如既往地解决这些问题并发布正式响应，以便您了解正在发生的情况。
你在Twitter上的回复提到了我在我的博客系列中提出的问题：不幸的是，你只提到了三个主题，而这些博客条目指出了更多的问题。此外，您的答复包含了许多暗示您的困惑和误解的评论。在这封信中，我详细说明了这些具体问题。我还注意到，你在推特上给ZDnet(https://www.zdnet.com/article/multiple-tor-security-issues-disclosed-more-to-come/).)的记者Catalin Cimpanu发送了一条推特回复的变体。项目1：讨论0day Tor项目回复的定义，图片1：我们很高兴以记者愿意提供的任何方式获得错误报告。上周的两份报告并不新鲜，今天的报告值得调查，但几乎没有证据表明它们具有规模效应。我们还鼓励人们在一份报告中研究一下0天的定义。计算机安全社区通常认为0天是一个尚未公开的具体安全缺陷--因此，根据这个定义，到目前为止，我们还没有在这个博客文章系列中看到过任何0天，把它们称为0天可能会让公众感到困惑。到目前为止，已经提出了三个问题：
在您的答复中，您试图辩论0day的定义。但是，您忽略了这样一个事实，即0day有不同的定义，并且没有一个标准化的定义。CMU的人员有一个不同的、通用的0day定义列表，这些定义在安全和软件开发社区中使用。(https://insights.sei.cmu.edu/cert/2015/07/like-nailing-jelly-to-the-wall-difficulties-in-defining-zero-day-exploit.html)我的用法与定义3、4、6和10一致；0day仍然是0day，直到供应商发布补丁程序、解决办法或其他某种可行的解决方案。我在第一篇博客文章中明确地包含了我的定义。争论0day的定义就像争论Tor是拼写为Tor还是拼写为Tor。它只不过是一个偏离中心讨论的侧边栏。就我个人而言，我更愿意把重点放在漏洞和解决方案上，而不是争论没有供应商提供的解决方案的漏洞是否被认为是零日漏洞。第2项：忽略Tor项目答复中的滚动条漏洞，图片2：(1)声称可以使用用户ToR浏览器的滚动条宽度来区分他们正在使用的操作系统。我们在22137号票中一直在研究这个问题。这起信息泄露事件是众所周知的，也是公开记录的，还有其他
你的推特介绍、第一张图片回复和第四张图片回复质疑我的概念验证检测系统是否会被民族国家利用。你还说了一句贬低在客厅里测试的话。我的工作代码目前部署在几个大容量网络上，几乎不需要任何资源。考虑到漏洞的影响，我很惊讶您关注的是理论上的缩放因素，而不是漏洞本身的严重程度。该攻击演示了如何检测Tor的所有obfs4网络连接。在您回复的第四张图片中，您还提到检测obfs4连接时1%的误报是一个很大的数字。但是，我的系统容易出现假阴性(丢失一些obfs4流)，并且不会出现重大的假阳性匹配(错误地断言某些内容是obfs4)。无论如何，你似乎忽略了这是一个功能性的概念证明。正如我提到的，我已经实施了它，它在企业千兆网络上运行良好。通过更多的微调，我确信错误检测可以进一步减少。同样，Tor项目似乎将工作和部署的概念验证的质量与已演示威胁的严重性混为一谈。第6项：混淆现有技术与当前检测方法Tor项目答复，图片#4，#2至#5：帖子中写道：然而，我不知道公开披露检测和阻止obfs4."；的工作在学术文献中。参见Wang等人的CCS&39；LS论文：看穿网络协议混淆。也参见Frolov等人的NDSS'；20论文：检测抗探针的代理。这篇博文引用了邓纳的FOCI&18论文来支持他的说法，即GFW可以检测到obfs4。这次引用一定是误会的结果。在第2页，该报称：我们发现，两种最流行的可插拔传输工具(Meek[7]和Obfs4[18])在规避GFW对Tor的屏蔽方面仍然有效(5.1节)。这篇博文还引用了菲比·克罗斯(Phoebe Cross)的另一篇关于在中国使用Tor的中等标题的文章来支持同样的说法。这篇博客文章正确地指出，分布在BridgeDB上的obfs4桥被阻止，而私有obfs4桥可以工作。这意味着审查员没有阻止obfs4协议，但能够拦截来自我们分销商的网桥信息。必须将协议与分发端点的方式区分开来。今天(7/30)公布的发现是现有攻击的变体(这太棒了！)。但不是0天。它们值得调查，但几乎没有证据表明它们在规模上发挥作用。
在您回复的第三点(第四张图片)中，您引用了我引用的现有技术中讨论检测obfs4流量的内容。您还包括了另一个引文，说明如何主动扫描obfs4服务器。不幸的是，我认为您没有抓住要点：这些论文讨论了积极的端口扫描、深度包检查和加密数据的统计分析。每一种都很慢，而且计算成本很高。我的解决方案没有端口扫描，也没有统计分析。我的解决方案侧重于TCP报头，完全是被动的。(对于复杂性，有限状态机只需要2个计数器。它总共跟踪4个活动状态，其中一个状态不是必需的。)。在您的答复中，您说这是现有检测方法的变体，因为其他人有其他方法来检测obfs4。但是，我公开了一种非常不同的利用方法，它速度更快、需要的资源更少、效率更高。这是一个完全不同级别的漏洞。您的答复还指出，引用的论文无法检测到私有的obfs4网桥。同样，您似乎遗漏了我的博客中详细介绍的一个重要元素：我的解决方案检测obfs4，无论它是公共的还是私有的。我的解决方案可以检测私有obfs4网桥。你把引用的历史文献中的发现与当前的最新技术混为一谈。第7条：未能解决温克的检测问题，你的答复遗漏了我的一些关键披露。例如，您完全忽略了检测温顺天青的方法。这比检测obfs4通信量更容易利用漏洞，因为它只需要跟踪TCP负载大小和请求与回复之间的时间。Tor浏览器的启动器使用温顺的可插拔传输(包括温顺-lite)来获取新的网桥，Snowflake用于获取WebRTC服务器，而选择温顺-天蓝色网桥的用户则使用它。区分Meek的域名前置使用和非域前置请求会对所有这些服务产生负面影响。第8项：未能解决审查问题Tor项目没有回应人们的担忧，即检测(1)直接连接、(2)obfs4网桥和(3)温顺天蓝色网桥意味着用户连接到Tor网络的所有方法都