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

Question

是什么让我的浏览器相信没有 "Man in the middle" 并且相信连接是安全的？以下是我的导师给我提供的一个场景。

让我们假设"man in the middle"已经完美地完成了ARP欺骗，然后完成了完美的DNS欺骗并且还有一个完美的域名为"www.google.com"的自签名SSL证书。我的浏览器如何知道它没有与坏人互动？

我发现用现有域名很容易获得自签名证书，这可能吗？

简而言之，"What is the ultimate trust factor for my browser to believe that it is communicating with a legitimate server? "

Answer 1

My mentor says that it is very easy to get a self-signed certificate with existing domain names, is this even possible?

从技术上讲，是的，您可以自己创建任何证书，其中包含任何名称、自签名或由您控制的 CA 签名。这是一个带有像 openssl 这样的库的单行命令，这里没有魔法，因为这不是 Web PKI 派生其身份验证功能的地方（这来自 who 签署证书). 您会在这个自己的网站上找到大量答案，展示如何为您喜欢的任何名称生成 self-signed 证书。

浏览器将根据它在其使用的信任库中的 CA 列表（它自己的，或某个 OS 之一）检查从服务器收到的证书（合法的或被劫持的）。默认情况下，它不会有任何您控制的 CA，因此默认情况下它会拒绝该证书。当然，除非你强制它，或者将你自己的 CA 添加到其中。

但这只是故事的一半。

HTTP 密钥固定

虽然有点被弃用，但网络服务器可以指定使用哪些密钥来创建公开的证书。参见 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
...

此处描述的 public 个密钥要么是最终证书之一，要么是中间 CA 证书之一，要么是根证书之一。

当然，在主动攻击下，劫持者还可以修改此 HTTP Header，使其包含与其假证书关联的密钥。但该机制应该如何工作：我们首先假设有效服务器开始使用此功能并提供此 header；连接到它的客户端应该记录 header 值并在 max-age 秒内保留它，这应该是一个长值。因此，在随后访问该网站时，浏览器现在可以将它获得的证书链与它之前记住的任何固定密钥相匹配。

事实上，当您第一次访问服务器时，您没有在本地存储任何内容，这并不能解决这种情况。这就是人们对这种保护事物的方式失去兴趣的原因之一。

你可以在 https://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html

找到很多关于它的恐怖故事

看看：https://pinning-test.badssl.com/ 如果浏览器中的所有设置都正确，它应该会触发错误（证书与固定的密钥不匹配）

"Private" 键固定

一些浏览器在其源代码中也附带了特定的 keys/certificates，用于某些特定的 "high value" 域名，因此可以检查它们获得的证书。

有关 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 之一签署的（并且会明确拒绝其他一些 CA），浏览器将拒绝连接到 "Google" 网页。

您也可能对 Chromium 浏览器的此页面感兴趣： https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md

To enable certificate chain validation, Chrome has access to two stores of trust anchors (i.e. certificates that are empowered as issuers). One trust anchor store is the system or public trust anchor store, and the other other is the local or private trust anchor store.

...

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

Expect-CT

如上述维基百科页面所写，"Google recommends using the Expect-CT as a safer alternative." 这或多或少是相同的想法，只是实现方式不同。

CT 代表证书透明度，基本上那里有服务器 collection 所有 CA 最近颁发的所有证书都遵循 CAB 论坛的要求（如果他们希望他们的根保留，他们需要遵循被包含在浏览器中）。该系统以这样一种方式完成，它的行为基本上就像在仅附加模式下一样，理论上很难修改内容。因此，一个人（如浏览器）可以连接到这些服务器之一，并仔细检查它从服务器获得的证书是否确实记录在那里（这在建立 TLS 连接时 in-band 完成，服务器可以发送证明证书在某些 CT 日志中，或者 TLS 客户端可以检查自己进行 OCSP 检查）。如果不是，则可能意味着有问题，应该中止连接。

记录在 https://httpwg.org/http-extensions/expect-ct.html

然而，您第一次访问时会遇到与钥匙固定盒相同的问题。

看看 https://invalid-expected-sct.badssl.com/ 如果一切设置正确，应该会失败。

丹麦人

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

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

但是：

要发挥作用，必须使用 DNSSEC，否则攻击者可以过滤或修改 TLSA 记录，从而使保护失效
浏览器并不会真正读取这些记录来使用它们，目前主要是在电子邮件世界中

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

Can I use a self-signed SSL certificate with the domain name www.google.com?

ip

ssl

web

server

HTTP 密钥固定

"Private" 键固定

Expect-CT

丹麦人