是什么让我的浏览器相信没有“中间人”并相信Connection是安全的?
以下是我的导师向我提供的方案。
假设“中间人”完成了ARP欺骗,然后进行了完美的DNS欺骗,并且还拥有域名为“ www.google.com”的完美的自签名SSL证书。我的浏览器如何知道它与坏人没有互动?
我的导师说,获得具有现有域名的自签名证书非常容易,这是否可能?
因此,简而言之,“让我的浏览器相信它正在与合法服务器通信的最终信任因素是什么?”
最佳答案
我的导师说,获得具有现有域名的自签名证书非常容易,这是否可能?
从技术上讲,是的,您可以自己创建任何带有任何名称的证书,这些证书可以自行签名,也可以由您控制的CA签名。这是一个单行命令,带有openssl
之类的库,在这里没有魔术,因为这不是Web PKI派生其身份验证功能的地方(这是由签署证书的人提供的)。
您将在这个自己的网站上找到大量答案,展示了如何为自己喜欢的任何名称生成自签名证书。
浏览器将根据它所使用的受托服务器中拥有的CA列表(它自己的或某些OS的)检查从服务器(合法或被劫持)收到的该证书。默认情况下,它将没有您控制的任何CA,因此默认情况下它将拒绝此证书。当然,除非您强行使用它,或者将自己的CA添加到其中。
但是,这只是故事的一半。
HTTP密钥固定
尽管不推荐使用,但Web服务器可以指定使用哪些密钥来创建公开的证书。见https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
看起来像这样:
$ wget -SO /dev/null https://securedrop.propublica.org
...
Public-Key-Pins: pin-sha256="PJgArNye1xwYWDAy3Og4ud5XTJd4aOvF0bLa0LzIKiw="; pin-sha256="RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn/yOhI/y+ho="; max-age=86400
...
此处描述的公共密钥是最终证书之一,或者是中间CA证书之一,也可以是根证书之一。
当然,现在,在主动攻击下,劫持者还可以修改此HTTP标头,使其包含与假证书关联的密钥。
但是,这是该机制的工作原理:我们首先假设有效的服务器开始使用此功能并提供此标头。连接到它的客户端应记录标头值,并在
max-age
秒内保留该值,这应该是一个长值。这样,在以后访问该网站时,浏览器现在可以将其获得的证书链与上次记住的任何固定密钥进行匹配。实际上,当您第一次访问服务器时,这并不能解决这种情况,因为您在本地没有任何存储。这是人们对保护事物失去兴趣的原因之一。
您可以在https://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html周围找到很多恐怖故事
看看:https://pinning-test.badssl.com/
如果您的浏览器中的所有设置都正确,那么它将触发一个错误(证书与固定的密钥不匹配)
“私人”钥匙固定
某些浏览器在源代码中还附带了一些特定的密钥/证书,用于某些特定的“高价值”域名,因此可以检查它们是否获得了证书。
有关Chromium(警告大文件)的信息,请参见https://chromium.googlesource.com/chromium/src/net/+/refs/heads/master/http/transport_security_state_static.json。
例如:
{
"name": "google",
"static_spki_hashes": [
"GoogleBackup2048",
"GoogleG2",
"GoogleG3",
"GTSCA1O1",
"GlobalSignRootCA_R2"
],
"bad_static_spki_hashes": [
"GlobalSignRootCA",
"GlobalSignExtendedValidationCA",
"GlobalSignExtendedValidationCA_G2",
"GlobalSignExtendedValidationCA_SHA256_G2"
],
"report_uri": "http://clients3.google.com/cert_upload_json"
},
因此,我们可以推断出,如果收到的证书不是由上述CA之一签名的,则浏览器将拒绝连接到“ Google”网页(并将专门拒绝其他CA)。
您可能也对Chromium浏览器的此页面感兴趣:
https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md
要启用证书链验证,Chrome可以访问两个
信任锚存储(即被授权为
发行者)。一个信任锚存储是系统或公共信任锚
商店,另一个是本地或私人信任锚商店。
...
证书链时,Chrome不执行引脚验证
链接到一个私人信任锚。该政策的主要结果是
私人信任锚可用于代理(或MITM)连接,
甚至是固定的网站。 “数据丢失防护”设备,防火墙,
内容过滤器和恶意软件可以使用此功能来击败
钥匙固定保护。
期望CT
正如上面的Wikipedia页面所写,“ Google建议使用Expect-CT作为更安全的选择。”
这或多或少是相同的想法,只是实现方式不同。
CT代表“证书透明性”,基本上,那里有服务器,其中包含所有CA遵循CAB论坛要求(如果希望它们的根继续包含在浏览器中,则必须遵循)的所有最近颁发的证书。该系统的完成方式使其行为基本上类似于仅追加模式,并且在理论上很难修改内容。
因此,一个(例如浏览器)可以连接到这些服务器之一,并仔细检查从服务器获得的证书是否确实记录在该服务器上(此操作是在建立TLS连接时带内完成的,服务器可以发送证明该证书的证据)在某些CT日志中,或者TLS客户端可以通过OCSP检查进行自我检查)。如果不是,则可能意味着出现问题,应该中止连接。
它记录在https://httpwg.org/http-extensions/expect-ct.html
但是,您第一次访问时会遇到与钥匙固定盒相同的问题。
看一下https://invalid-expected-sct.badssl.com/,如果一切都正确设置,它将失败。
丹妮
DANE使用DNS中的
TLSA
记录让域所有者指定在连接到其域下的各种服务时应该使用哪些证书(或密钥)。它可以指定有关服务结束证书/密钥的详细信息,也可以指定有关签署其证书的CA的详细信息。它具有通用性(不适用于任何特定服务)的兴趣,并且可以根据自己的意愿允许或不允许依赖于具有所有已知CA的当前Web PKI。
然而:
要使用此功能,必须使用DNSSEC,否则攻击者可以过滤或修改
TLSA
记录,从而使保护无效浏览器并不真正阅读这些记录以使用它们,目前主要在电子邮件世界中