当遇到安全漏洞时，我有一个基本的理念：尽最大努力将其报告给合适的人。有时候，报道是毫无痛苦的。通常情况下，这有点挑战性。十多年前，我试图向Verisign报告一个问题。一名安全工作人员花了数周时间不断纠缠，才将漏洞传递到链条上。他的经理看到了这个问题，在电话里感谢了我，并给我寄了一盒礼物，以表示我的努力得到了赞赏。(我很高兴他们解决了这个问题。对我来说，这些电话和礼物实在是太棒了。)。不幸的是，有时公司反应迟钝。在这一点上，我有几个选择。我可以把这个漏洞卖给其他肯定会利用它的人。我可以把它放在一边--也许这个bug会因为巧合而被修复或者过时，或者也许我以后会为它找到另一个用途。(我收集了大量的静坐漏洞，其中一些可以追溯到几十年前。)。然而，有时我有需要尽快解决某个特定问题的原因。如果公司不回应安全报告，那么他们可能会对公众的羞辱做出反应。对于关注我博客的人来说，你知道我花了几年时间试图向Tor项目报告安全漏洞。仅仅是找出报告窃听器的对象就像是一场受虐狂的寻宝游戏。在我公开羞辱Tor项目之后(2017年)，他们改变了他们的网站设计，使报告漏洞变得更容易。他们还在黑客一号(HackerOne)开设了漏洞赏金计划。不幸的是，虽然现在向Tor项目报告漏洞变得更容易了，但它们仍然不太可能修复任何问题。我已经让Tor项目关闭了一些报告，因为它们是已知问题，并且没有解决问题。对于一个以自己的安全解决方案为荣的组织来说，不清楚为什么他们不能解决已知的严重问题。今年有两件事真的让我心潮澎湃。第一个问题与去年2月Tor网络上的大规模DDoS攻击有关。很多洋葱服务都下线了，很多中继都崩溃了。我自己的洋葱服务受到了重创，但在我找出根本原因并修补了我的Tor守护进程后，我设法保持了正常运行。我向Tor项目报告了此漏洞(HackerOne bug#789065)。结果并不那么出色：首先，Tor项目要求提供概念证明。我用源代码和日志文件作为回应。
然后他们询问了更多关于它是如何工作的细节。我提供了非常详细的描述。这导致了大量的双向交流，包括描述、解释和示例。(在这一点上，我认为事情进展顺利。)。
经过大量的技术讨论后，Tor项目的代表写道：这张票上的所有信息让我有点不知所措。我觉得这里的很多讨论都很有成效，但它们更具集思广益，更具研究性，不太适合开出一张漏洞赏金罚单。他们的结论是：你有没有想要提交某个特定的漏洞来获得漏洞赏金？在我看来，描述漏洞和缓解选项并不是头脑风暴和研究。在我看来，这听起来要么是他们没有足够的能力修复这个错误，要么是他们对此不感兴趣。无论如何，他们只是在浪费时间。
在这一点上，我决定不值得尝试向Tor项目报告任何新的错误。第二个问题发生在上个月，当时我决定将Tor 0day公之于众。就在那时，经过三年的等待，我放弃了Tor项目。三年多前，我试图向Tor项目报告Tor浏览器中的一个漏洞。错误非常简单：使用JavaScript，您可以识别滚动条的宽度。每个操作系统都有不同的默认滚动条大小，因此攻击者可以识别底层操作系统。这是一个独特的属性，可用于帮助唯一跟踪Tor用户。(很多用户认为Tor让他们匿名。但Tor用户可以在线跟踪；他们不是匿名的。)。我找不到直接向Tor项目报告错误的方法。最终，我放弃了他们关于寻宝游戏的报道，并在博客上记录了这个漏洞。我提供了详细信息和一个工作示例。很多Tor社区的人写信给我，有效地说那又怎么样？然而，Tor项目的初步回应证实了它的重要性。他们将该漏洞输入他们的系统(缺陷#22137)，并给予其高优先级。当他们在HackerOne上开放他们的漏洞赏金计划时，他们甚至为这个问题付给了我一笔赏金。此问题在3年前通过HackerOne于2017年7月22日报道。它被分配了错误#252580，支付了赏金，问题在'；解决'；时就结束了。HackerOne漏洞在三个月后(2017年10月20日)公开披露。但这就是积极进展停止的地方。尽管它被标记为
一家发行商。此记录仅包含以"；www."；开头、以"；.com"；结尾的通用名称(CN)。中间是8-20个随机字母和数字。这是不寻常的，因为发行人CN通常是发证机构的适当名称。对于ToR，没有国家(C)、州(ST)、组织(O)或其他颁发者字段通常与验证证书和自签名证书一起出现。
只有一个主题。主题通用名称(CN)以"；www.."；开头，以"；.net"；结尾。中间是8-20个随机字母和数字，这些字母和数字与发行者不同。与发行人记录一样，没有其他字段(S、ST、O等)。它们通常与真正的证书一起被发现。
在一个非常技术性的节点上：对于我自己的数据包扫描器，我编写了一个函数，该函数遍历x509证书的ASN.1结构，并生成显示数据和范围的打包签名。ToR服务器的签名如下：{{[2]，#，{1.2.840.113549.1.1.#，null}，{2.5.4.3，"；www.X.com"；}，{"；#Z"；，"；#Z"；}，{2.5.4.3，"；www.X.net"；}，{{1.2.840.113549.1.1.1，NULL}，D}}，{1.2.840.113549.1.1.#，NULL}，D}其中："；X"；是[a-Z2-7]范围内的8-20个字符。此字符范围是因为Tor使用Base32编码。
此示例来自ToR服务器：{{[2]，10893829876978619801，{1.2.840.113549.1.1.11，NULL}，{2.5.4.3，"；www.xds4wpy6r7uq.com"；}}，{"；1712280000Z"；，"；180517000000Z"；}，{2.5.4.3，"；www.ph4l62eo.。}，{{1.2.840.113549.1.1.1，NULL}，DATA[271]}}，{1.2.840.113549.1.1.11，NULL}，DATA[129]}ASN.1使用点数字序列定义特定代码。例如，2.5.4.3是标识通用名称。它在签名中出现了两次：一次是针对发行者的，一次是针对主题的。ASN.1代码1.2.840.113549.1.1.11使用RSA加密标识sha256。我的签名使用"；1.2.840.113549.1.1.#"；，因为特定加密可能会因服务器的SSL库版本而异。(哦，耶！分析服务器的库！又是0天！)。当数据包嗅探器看到TLS服务器端证书时，它会生成签名。如果签名与ToR服务器的模式匹配，扫描程序会将该连接标记为ToR连接。(这真的很快。)。
早在2017年，我就用扫描仪和Shodan搜索TLS证书。从理论上讲，可能存在某些服务器，其服务器端TLS证书与此签名匹配，但不是ToR节点。实际上，每一场比赛都是一个Tor节点。我甚至发现运行Tor守护进程并且具有开放的洋葱路由(OR)端口的服务器不在已知Tor节点列表中。(有些是非公共桥梁。其他节点是私有Tor节点。)。同样，我扫描了每个已知的Tor节点。每个都与此ToR特定证书配置文件匹配。这使得检测100%准确；没有假阳性，也没有假阴性。(虽然现在我已经将此公之于众，但有人可能会故意生成假阳性或假阴性证书。假阳性相对容易构造。假阴性将需要编辑Tor守护程序的源代码。)。虽然扫描仪可以用来识别和记录每台ToR服务器，但公司不需要这样做。公司已经在其网络边界上使用状态数据包检测来扫描潜在的恶意软件。使用单个规则，他们还可以检查此ToR签名的每个新连接。无需使用大型网络地址列表，您就可以发现ToR节点的每个连接，并在会话层(TLS)完成初始化和将任何数据传输出网络之前将其关闭。我在2017年12月27日向Tor项目报告了这个检测ToR流量的简单方法(HackerOne bug#300826)。我得到的回应令人失望。您好，感谢您报道这一问题！这是一个影响公共桥梁(通过Bridge gedb分发的桥梁)的已知问题；有关更多详细信息，请参阅标签#7349。此问题不会影响专用网桥(以P2P点对点方式分发的网桥)。正如罚单上所指出的，为了解决这个问题，我们的目标是使Tor继电器的ORPort关闭成为可能。在我们看来，我们不应该试图模仿普通的SSL证书，因为这是一场我们无法取胜的战斗(它们看起来总是不同的，或者有区别，就像可插拔传输军备竞赛中的情况一样)。不幸的是，票据#7349不容易实施，并且具有各种工程复杂性；由于该问题已知并计划修复，请参阅票据了解更多信息，我将此问题标记为信息性问题。
让我想想：他们向我推荐了另一个已经打开了五年的bug(优先级非常高)。(它现在已经开业八年了。)。
他们只认为这是对桥梁的风险，而不是对所有Tor交通的风险。即使它会影响到
他们让我参考相关(未修复的)bug中的技术讨论，但我看不出他们不能添加更多种类以防止数据包剖析和过滤的任何理由。作为测试，我在我的一个Tor守护进程上更改了随机证书的配置文件，它继续工作，没有任何问题。
这个特殊的问题并不是太复杂，解决不了。它位于Tor守护程序源代码中。文件：src/lib/tls/tortls.c，函数tor_tls_context_init_Certificate。前几行生成8-20个随机字符的域名，其余行在没有任何其他设置的情况下生成证书。昵称=CRYPTO_RANDOM_HOSTNAME(8，20，"；www."；，"；.NET"；)；#ifdef DISABLE_V3_LINKPROTO_SERVERSIDE nn2=CRYPTO_RANDOM_HOSTNAME(8，20，"；www."；，"；.net"；)；#ELSE nn2=CRYPTO_RANDOM_HOSTNAME(8，20，#endif/*生成用于TLS的短期RSA密钥。*/IF(！(RSA=CRYPTO_PK_NEW()转到错误；IF(CRYPTO_PK_GENERATE_KEY_WITH_BITS(rsa，RSA_LINK_KEY_BITS)<；0)转到错误；/*生成用于协议内("；v3"；)*验证握手的短期RSA密钥。*/IF(！(RSA_AUTH=CRYPTO_PK_NEW()转到错误；IF(CRYPTO_PK_GENERATE_KEY(Rsa_Auth)<；0)转到错误；/*创建由身份密钥签名的链接证书。*/cert=TOR_TLS_CREATE_CERTIFICATE(rsa，IDENTITY，NICKNAME，nn2，KEY_LIFEST)；/*为身份密钥创建自签名证书。*/idcert=TOR_TLS_CREATE_CERTIFICATE(Identity，Identity，nn2，nn2，Identity_CERT_LIFEST)；/*创建身份密钥签名的认证证书。*/authcert=TOR_TLS_CREATE_CERTIFICATE(rsa_auth，Identity，Nickname，nn2，KEY_LIFEST)；
有很多解决此问题的选择。这里只有几个例子：.com和.net名称使用相同的随机字符。极少数域在TLS证书中使用完全不同的名称。(使用备用名称的公司通常有一长串名字，而不仅仅是两个名字。)。此外，还应在颁发者和主题记录中包括"；S"；、"；O"；和其他x509属性。
允许torrc文件指定通用名称和TLS属性。例如，如果我的Tor节点驻留在Digital Ocean，那么我会选择一个看起来像其他Digital Ocean客户的信息。更好的是：让我提供TLS证书。我可以提供一个真正的使用让的加密，没有人会知道它的ToR。
因为证书无论如何都没有经过验证，所以在链中包括1-2个额外的证书，这样它看起来就不像是自签名的。
将参数排序随机化，并添加一些TLS扩展。使它们看起来不那么规格化。
如果每个ToR证书看起来都与ToR节点唯一相似，则可以过滤流量。如果每个ToR节点看起来都不同，那么发现和阻止来自会话或应用层的ToR流量就会困难得多。如果你曾经与臭虫赏金合作过，那么你肯定会认出凯蒂·穆苏里斯这个名字。她在微软和国防部创建了第一个漏洞赏金计划。她是HackerOne(漏洞赏金服务)的首席政策官，她负责NTIA意识和采用小组标准化漏洞披露和报告的工作。(全面披露：我曾在同一个NTIA工作组工作了一年。我发现凯蒂是一个积极乐观的人。(她非常精明、公正、务实。)。本月早些时候，凯蒂接受了Vergecast播客的采访。我原以为她会赞扬漏洞披露和漏洞赏金计划的好处。然而，她让我大吃一惊。她已经对公司如何使用漏洞赏金不再抱有幻想。她指出，公司的漏洞赏金大多是失败的。公司往往更愿意将责任外包，而不是解决问题。他们认为漏洞赏金是一种为漏洞买单并保持沉默的方式，而不是解决问题。Katie提出的关于漏洞披露过程的每一个问题都与我在Tor项目中的经历相呼应。Tor项目使得报告漏洞变得困难。他们无法修复漏洞。他们将从未解决的问题标记为已解决。他们把简单的问题外包出去，比如把一个简单的滚动条问题上游传给Firefox，在那里它永远不会被修复。他们为不解决严重的安全问题找借口。在采访中，她提到研究人员和报告漏洞的人。
.