ssl - SSL 究竟是如何工作的？

Question

SSL 如何工作？

客户端(或浏览器？)和服务器(或 Web 服务器？)上安装的证书在哪里？

当您在浏览器中输入 URL 并从服务器获取页面时，信任/加密/身份验证过程是如何开始的？

HTTPS 协议(protocol)是如何识别证书的？当证书完成所有信任/加密/身份验证工作时，为什么 HTTP 不能与证书一起使用？

Answer 1

Note: I wrote my original answer very hastily, but since then, this has turned into a fairly popular question/answer, so I have expanded it a bit and made it more precise.

TLS 功能

“SSL”是最常用于指代此协议(protocol)的名称，但 SSL 特指 Netscape 在 90 年代中期设计的专有协议(protocol)。 “TLS”是基于 SSL 的 IETF 标准，因此我将在我的回答中使用 TLS。如今，几乎所有网络上的安全连接实际上都在使用 TLS，而不是 SSL。

TLS 具有多种功能:

加密您的应用层数据。 (在您的情况下，应用层协议(protocol)是 HTTP。)

向客户端验证服务器。

向服务器验证客户端。

#1 和 #2 很常见。 #3 不太常见。你似乎专注于#2，所以我会解释那部分。

验证

服务器使用证书向客户端进行身份验证。证书是包含有关网站信息的一组数据 [1]:

域名

公钥

拥有它的公司

发布时间

到期时

谁发的

等

您可以通过使用证书中包含的公钥来加密只能由相应私钥解密的消息来实现 secret 性(上面的#1)，这些消息应该安全地存储在该服务器上。 [2]让我们称这个 key 对为 KP1，这样我们以后就不会混淆了。您还可以验证证书上的域名是否与您正在访问的站点匹配(上面的 #2)。

但是，如果对手可以修改发送到服务器和从服务器发送的数据包，并且如果该对手修改了您提供的证书并插入了他们自己的公钥或更改了任何其他重要细节，该怎么办？如果发生这种情况，对手可以拦截和修改您认为已安全加密的任何消息。

为了防止这种攻击，证书由其他人的私钥加密签名，这样签名就可以被任何拥有相应公钥的人验证。我们将此 key 对称为 KP2，以明确这些 key 与服务器使用的 key 不同。

证书颁发机构

那么谁创造了 KP2？谁签署了证书？

稍微简化一点，证书颁发机构创建 KP2，他们出售使用其私钥为其他组织签署证书的服务。例如，我创建了一个证书，然后我付钱给像 Verisign 这样的公司用他们的私钥对其进行签名。 [3]由于只有 Verisign 才能访问此私钥，因此我们中的任何人都无法伪造此签名。

我个人如何获得 KP2 中的公钥以验证该签名？

好吧，我们已经看到证书可以持有公钥——而计算机科学家喜欢递归——那么为什么不将 KP2 公钥放入证书并以这种方式分发呢？乍一听这有点疯狂，但实际上这正是它的工作原理。继续 Verisign 示例，Verisign 生成一个证书，其中包含有关他们是谁、他们被允许签署的内容类型(其他证书)以及他们的公钥的信息。

现在，如果我有该 Verisign 证书的副本，我可以使用它来验证我想要访问的网站的服务器证书上的签名。容易吧？!

嗯，没那么快。我必须从某个地方获得 Verisign 证书。如果有人欺骗 Verisign 证书并将他们自己的公钥放在那里怎么办？然后他们可以伪造服务器证书上的签名，我们又回到了开始的地方:中间人攻击。

证书链

继续递归思考，我们当然可以引入第三个证书和第三个 key 对 (KP3) 并使用它来签署 Verisign 证书。我们称之为证书链:链中的每个证书都用于验证下一个证书。希望您已经可以看到这种递归方法只是海龟/证书。它在哪里停止？

由于我们无法创建无限数量的证书，因此证书链显然必须在某处停止，这是通过在链中包含一个自签名证书来实现的。

I'll pause for a moment while you pick up the pieces of brain matter from your head exploding. Self-signed?!

是的，在证书链的末尾(也就是“根”)，会有一个证书使用它自己的 key 对来签署自己。这消除了无限递归问题，但并没有解决身份验证问题。任何人都可以创建一个自签名证书，上面写着任何内容，就像我可以创建一个伪造的普林斯顿文凭，上面写着我主修政治、理论物理和应用屁股，然后在底部签上我自己的名字。

这个问题的 [有点乏味] 解决方案只是选择一些您明确信任的自签名证书。例如，我可能会说，“我信任这个 Verisign 自签名证书。”

有了这种明确的信任，现在我可以验证整个证书链。无论链中有多少证书，我都可以验证每个签名一直到根。当我到达根目录时，我可以检查该根证书是否是我明确信任的证书。如果是这样，那么我可以信任整个链条。

授予信任

TLS 中的身份验证使用授予信任的系统。如果我想雇用一名汽车修理工，我可能不会相信我找到的任何随机修理工。但也许我的 friend 担保特定的机械师。既然我信任我的 friend ，那么我就可以信任那个机械师。

当您购买计算机或下载浏览器时，它会附带数百个它明确信任的根证书。 [4]拥有和运营这些证书的公司可以通过签署他们的证书将这种信任授予其他组织。

这远非完美的系统。有时，CA 可能会错误地颁发证书。在这些情况下，可能需要吊销证书。撤销很棘手，因为颁发的证书在密码上总是正确的；需要使用带外协议(protocol)来查明哪些先前有效的证书已被撤销。在实践中，其中一些协议(protocol)不是很安全，而且许多浏览器无论如何都不会检查它们。

有时，整个 CA 都会受到威胁。例如，如果您要闯入 Verisign 并窃取他们的根签名 key ，那么您就可以欺骗世界上的任何证书。请注意，这不仅会影响 Verisign 客户:即使我的证书是由 Thawte(Verisign 的竞争对手)签署的，这也无关紧要。我的证书仍然可以使用威瑞信泄露的签名 key 伪造。

这不仅仅是理论上的。它发生在野外。 DigiNotar was famously hacked并随后破产。 Comodo was also hacked ，但令人费解的是，他们一直营业到今天。

即使 CA 没有直接受到威胁，该系统中也存在其他威胁。例如，政府使用法律强制手段强制 CA 签署伪造的证书。您的雇主可能会在您的员工计算机上安装他们自己的 CA 证书。在这些不同的情况下，您期望“安全”的流量实际上对控制该证书的组织来说是完全可见的/可修改的。

已经建议了一些替换，包括 Convergence , TACK , 和 DANE .

尾注

[1] TLS 证书数据根据 X.509 standard 格式化. X.509 基于 ASN.1 (“Abstract Syntax Notation #1”)，这意味着它不是二进制数据格式。因此，X.509 必须编码为二进制格式。 DER and PEM是我所知道的两种最常见的编码。

[2] 实际上，该协议(protocol)实际上会切换到对称密码，但这是与您的问题无关的细节。

[3] 据推测，CA 在签署证书之前实际上会验证您的身份。如果他们不这样做，那么我可以为 google.com 创建一个证书并要求 CA 对其进行签名。有了该证书，我就可以中间人与 google.com 建立任何“安全”连接。因此，验证步骤是CA运行中非常重要的因素。不幸的是，目前尚不清楚全局数百个 CA 的验证过程有多严格。

[4] 参见 Mozilla 的 list of trusted CAs .