HTTP密钥固定

Question

是什么让我的浏览器相信没有“中间人”并且信任连接是安全的？以下是我的导师向我提供的方案。

让我们假设“中间人”完美地完成了ARP欺骗，然后进行了完美的DNS欺骗，并且还拥有一个完美的自签名SSL证书，域名为“ www.google.com”。我的浏览器如何知道它与坏人没有互动？

我的导师说，很容易获得具有现有域名的自签名证书，这有可能吗？

因此，简而言之，“我的浏览器认为与合法服务器通信的最终信任因素是什么？”

Answer 1

我的导师说，很容易获得具有现有域名的自签名证书，这有可能吗？

从技术上讲，是的，您可以自己创建任何具有任何名称的证书，这些证书可以自行签名，也可以由您控制的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/ 如果您的浏览器中的所有设置均正确（证书与固定的密钥不匹配），它将触发错误

“私人”钥匙固定

某些浏览器在源代码中还附带了特定的密钥/证书，用于某些特定的“高价值”域名，因此可以检查它们是否获得了证书。

例如，有关铬（警告大文件）的信息，请参见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）连接，   甚至是固定的网站。 “数据丢失防护”设备，防火墙，   内容过滤器和恶意软件可以使用此功能来击败   密钥固定的保护。

Expect-CT

如上面的维基百科页面所述，“ 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

DANE使用DNS中的TLSA记录来让域所有者指定在连接到其域下的各种服务时应预期使用哪些证书（或密钥）。它可以指定有关服务结束证书/密钥的详细信息，也可以指定有关签署其证书的CA的详细信息。

具有通用性（不针对任何特定服务量身定制）并允许或不希望依赖于具有所有已知CA的当前Web PKI的兴趣。

但是：

要使用此功能，必须使用DNSSEC，否则攻击者可以过滤或修改TLSA记录，从而使保护无效
浏览器并没有真正阅读这些记录以使用它们，目前主要在电子邮件世界中

我可以使用域名为www.google.com的自签名SSL证书吗？

1 个答案:

HTTP密钥固定

“私人”钥匙固定

Expect-CT

DANE