苹果推出MacOS Big Sur之后,几乎立刻就出现了服务器问题,导致用户无法在电脑上运行第三方应用。虽然人们很快就在Twitter上找到了解决办法,但也有人提出了一些与该问题相关的隐私问题。
嗨,苹果用户:如果你现在遇到在Mac上运行应用程序挂起的问题,我用Little Snitch解决了这个问题。它信任连接到https://t.co/FzIGwbGRan,拒绝该连接修复它,因为OCSP是一个软故障。(断开互联网也可以修复。)。Pic.twitter.com/w9YciFltrb。
-杰夫·约翰逊(@rapcatsoft)2020年11月12日。
OCSP代表在线证书状态协议1。顾名思义,它用于验证证书的有效性,而无需下载和扫描大型证书吊销列表。MacOS使用OCSP来确保开发者证书在应用程序启动之前没有被吊销。
正如杰夫·约翰逊在上面的推文中解释的那样,如果MacOS无法联系到苹果的OCSP响应器,它就会跳过检查,无论如何都会启动应用程序--这基本上是一种失效开放行为。问题是苹果的响应器没有掉下来;它是可以到达的,但变得非常慢,这阻止了软故障触发和放弃检查。
显然,这一机制要求MacOS在应用推出前与苹果取得联系。公众突然意识到苹果的问题带来了这一事实,这引发了一些隐私问题,安全研究员杰弗里·保罗2(Jeffrey Paul 2)的一篇帖子在Twitter上非常流行。他声称。
在当前版本的MacOS中,当你运行它时,操作系统会向苹果发送你运行的每个程序的散列(唯一标识符)。
更糟糕的是,OCSP经常使用HTTP--我说的是端口80上的老旧的纯文本HTTP,而不是HTTPS的垃圾。这通常有一个很好的理由,当OCSP服务用于Web浏览器时,这一点就变得特别明显:防止循环。如果您使用HTTPS通过OCSP检查证书,则还需要使用OCSP检查HTTPS连接的证书。这意味着要打开另一个HTTPS连接,以此类推。
当然,虽然OCSP不强制加密,但它确实要求服务器对响应进行签名。这仍然不能解决最初的担忧,即任何在你的网络上安装流量分析器的人都可能逃避你打开的每一个应用程序,以及当你打开它的时候。
了解了一些OCSP基础知识后,就会出现更多的问题。OCSP是关于检查证书的;为什么这与发送您运行的应用程序的散列有什么关系?MacOS真的在每次启动时计算每个可执行文件的散列吗?大号的怎么样?这将需要相当长的时间;有没有可能没有人注意到呢?也许哈希值只计算一次(例如,第一次运行应用程序时),然后将其存储在某个地方。但我并不信服,我认为这些说法需要更多的研究。
捕获OCSP请求与设置HTTP代理或启动Wireshark一样简单。没有HTTPS意味着没有加密,没有证书锁定,没有任何问题。我在打开Firefox时捕获了以下请求。
我还应该补充的是,在关闭Firefox并再次打开它之后,没有人提出任何请求。这是合理的,并且表明证书检查不是在每次启动时执行,而是在一段时间内没有执行之后才执行。
该请求是一个非常简单的GET,它将有效负载包含为Base64编码的字符串。可以很容易地将实际的二进制数据转储到一个文件中:
我们获得了一个80字节长的有效负载,它看起来一点也不像散列。果不其然,它不是。我们可以使用OpenSSL从二进制文件中提取可读信息。
OCSP请求数据:版本:1(0x0)申请者列表:证书ID:散列算法:SHA1颁发者名称散列:3381D1EFDB68B085214D2EEFAF8C4A69643C2A6C颁发者密钥散列:5717EDA2CFDC7C98A110E0FCBE872D2CF2E31754序列号:06C794216C7A930。
很明显,MacOS上的Trustd服务不会发送你启动的应用的哈希信息。相反,它只是发送有关某些证书的信息--正如我们在了解OCSP是什么之后肯定会预料到的那样。
嗯,这并不能解决问题,不是吗?如果每个应用程序都有一个唯一的证书,那么仍然可以创建一个表,将每个序列号与相应的应用程序关联起来,因此这仍然是一个隐私问题。让我们来看看是不是这样。
首先,我想确定这些信息来自哪个证书。我使用苹果的CoDesign实用程序从Firefox应用程序中提取证书,以便查找匹配的数据。
该命令将创建几个名称为cosign0、cosign1等的文件。第一个文件是叶证书,而其他文件则属于证书链,直至根证书。CoDesign 0应该是我们正在寻找的,我们可以再次使用OpenSSL来提取有关它的一些信息。
证书:数据:版本:3(0x2)序列号:488521955867797808(0x6c794216c7aa930)签名算法:sha256WithRSAEncryption颁发者:CN=开发者ID认证机构,OU=苹果认证机构,O=苹果公司,C=美国有效期不早:5月8日19:08:58 2017GMT不在:5月9 19:08:58 2022GMT主题:uid=43AQ936H96,CN=开发者ID。
检查我们获得的序列号(0x6c794216c7aa930),并将其与OCSP请求的有效负载进行比较。我们找到火柴了!这证明OCSP请求实际上发送了有关应用程序开发人员证书的信息。
“那又怎样?”你可能会问。嗯,开发者证书对于每个应用程序来说并不是唯一的。再说一次,不要轻信我的话。雷鸟说:我们可以通过检查Mozilla的另一款应用的证书来快速验证这一点。
证书:数据:版本:3(0x2)序列号:488521955867797808(0x6c794216c7aa930)签名算法:sha256WithRSAEncryption颁发者:CN=开发者ID认证机构,OU=苹果认证机构,O=苹果公司,C=美国有效期不早:5月8日19:08:58 2017GMT不在:5月9 19:08:58 2022GMT主题:uid=43AQ936H96,CN=开发者ID。
这与Firefox使用的证书完全相同(当然!)。因此,杰弗里·保罗的分析并不十分准确--至少在这几个方面(强调我的观点)是不准确的。
当你运行操作系统时,它会向苹果发送你运行的每个程序的散列(唯一标识符)。
[IP地址]允许使用具有以下标题的表:日期、时间、计算机、ISP、城市、州、应用程序散列。
[这意味着苹果知道]你在那里打开哪些应用程序,以及打开的频率。他们知道你什么时候在朋友家用Wi-Fi打开Premiere,也知道你什么时候在去另一个城市的旅途中打开酒店的Tor浏览器。
MacOS确实发出了一些关于这些应用的开发者证书的不透明信息,从隐私的角度来看,这是一个相当重要的区别。
我想澄清一些可能是这种误解的根源。事实上,有一种情况是MacOS实际上可以向苹果发送可执行文件的哈希,那就是当GateKeeper在第一次启动时检查苹果的服务器上是否存在公证票证,以防票证没有钉在应用程序3上。
这与OCSP无关。它在特定情况下发生,检查通过位于api.apple-cloudkit.com的安全(HTTPS)端点执行。在此过程中,会向用户显示一个带有进度条的弹出窗口。
在Apple的OCSP响应器中断期间,您可能已经了解到,您可以通过几种方式阻止OCSP请求,其中最流行的是Little Snitch 4和编辑您的/etc/hosts文件。就我个人而言,我不建议这样做,因为这会阻止一个重要的安全功能发挥作用。
现在你已经知道了实际情况,如果你认为这个功能比在你的系统上运行潜在的未被检测到的恶意软件更会危及你的隐私,那就继续吧。否则,就别费心了。
如果你使用MacOS Big Sur,拦截OCSP可能不是那么简单。然而,在抱怨阴谋之前,请记住,普通用户通常不能完全理解和评估禁用计算机上如此复杂和微妙的安全功能的影响。
不,MacOS不会在你每次运行你的应用程序时向苹果发送这些应用程序的哈希。
你应该知道,MacOS可能会传输一些关于你运行的应用程序的开发者证书的不透明信息。此信息在您的网络上以明文形式发送。
您可能不应该使用Little Snitch或在Hosts文件中阻止ocsp.apple.com。