是什么让我的浏览器相信没有“中间人”并相信连接是安全的？ 以下是我的导师提供给我的一个场景。
让我们假设“中间人”完美地完成了 ARP 欺骗，然后完美地完成了 DNS 欺骗，并且还拥有一个完美的域名“www.google.com”的自签名 SSL 证书。我的浏览器如何知道它没有与坏人交互？
我发现用现有域名很容易获得自签名证书，这甚至可能吗？
简而言之，“让我的浏览器相信它正在与合法服务器通信的最终信任因素是什么？”
【问题讨论】：
我的导师说用现有域名很容易获得自签名证书，这甚至可能吗？
从技术上讲，是的，您可以自己创建任何证书，其中包含任何名称、自签名或由您控制的 CA 签名。这是一个带有类似openssl 的库的单行命令，这里没有魔法，因为这不是Web PKI 派生其身份验证功能的地方（这来自谁 签署了证书）。
您将在这个自己的网站上找到大量答案，展示如何为您喜欢的任何名称生成自签名证书。
浏览器将根据它在其正在使用的信任库中的 CA 列表（它自己的或某些操作系统的）检查从服务器接收到的证书（合法的或被劫持的）。默认情况下，它没有您控制的任何 CA，因此默认情况下它将拒绝此证书。当然，除非您强制使用它，或者将您自己的 CA 添加到其中。
但这只是故事的一半。
虽然不推荐使用，但网络服务器可以指定使用哪些密钥来创建公开的证书。见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，例如 Chromium（警告大文件）。
例如：
{
"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 在证书链时不执行 pin 验证 链接到私人信任锚。该政策的一个关键结果是 私有信任锚可用于代理（或 MITM）连接， 甚至固定的网站。 “数据丢失防护”设备、防火墙、 内容过滤器和恶意软件可以使用此功能来击败 密钥固定的保护。
如上述 Wikipedia 页面中所述，“Google 建议使用 Expect-CT 作为更安全的替代方案。” 这或多或少是相同的想法，只是实现方式不同。
CT 代表 Certificate Transparency，基本上有服务器收集所有 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。
但是：
TLSA 记录，从而使保护失效【讨论】：