157

SSL 是如何工作的？

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

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

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

4

4 回答 4

160

注意：我很仓促地写了我的原始答案，但是从那以后，这已经变成了一个相当流行的问题/答案，所以我对其进行了扩展并使其更加精确。

TLS 功能

“SSL”是最常用于指代该协议的名称，但 SSL 特指 Netscape 在 90 年代中期设计的专有协议。“TLS”是基于 SSL 的 IETF 标准，所以我将在我的回答中使用 TLS。这些天来，您在网络上的几乎所有安全连接实际上都在使用 TLS，而不是 SSL。

TLS 具有多种功能：

  1. 加密您的应用层数据。（在您的情况下，应用层协议是 HTTP。）
  2. 向客户端验证服务器。
  3. 向服务器验证客户端。

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

验证

服务器使用证书向客户端验证自己。证书是一团数据[1]，其中包含有关网站的信息：

  • 域名
  • 公钥
  • 拥有它的公司
  • 什么时候发出
  • 到期时
  • 谁发的
  • 等等。

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

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

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

证书颁发机构

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

稍微简化一下，证书颁发机构创建了 KP2，并且他们出售使用他们的私钥为其他组织签署证书的服务。例如，我创建了一个证书，然后我向 Verisign 这样的公司付费，让他们使用他们的私钥对其进行签名。 [3] 由于除了 Verisign 之外没有人可以访问此私钥，因此我们任何人都无法伪造此签名。

为了验证签名，我个人如何获得 KP2 中的公钥？

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

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

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

证书链

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

由于我们不能创建无限数量的证书，证书链显然必须在某个地方停止，这是通过在链中包含一个自签名的证书来完成的。

我会暂停片刻，等你捡起脑袋里爆炸的脑物质碎片。自签？！

是的，在证书链（又名“根”）的末尾，会有一个证书使用它自己的密钥对来签名。这消除了无限递归问题，但不能解决身份验证问题。任何人都可以创建一个自签名的证书，上面写着什么，就像我可以创建一个假的普林斯顿文凭，上面写着我主修政治、理论物理和应用屁股踢，然后​​在底部签上我自己的名字。

这个问题的[有点令人兴奋的]解决方案只是选择一组您明确信任的自签名证书。例如，我可能会说“我信任这个威瑞信自签名证书”。

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

授予信任

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

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

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

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

这不仅仅是理论上的。它发生在野外。DigiNotar 因被黑客入侵而闻名，随后破产。Comodo 也被黑了，但莫名其妙地他们至今仍在营业。

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

有人提出了一些替代方案，包括Convergence、TACK和DANE。

尾注

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

[2] 在实践中，协议实际上切换到对称密码，但这是与您的问题无关的细节。

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

[4] 请参阅 Mozilla 的受信任 CA 列表。

于 2011-09-11T22:26:58.123 回答
58

HTTPS 是HTTP和SSL（安全套接字层）的组合，用于在客户端（浏览器）和 Web 服务器（应用程序托管在这里）之间提供加密通信。

为什么需要它？

HTTPS 对通过网络从浏览器传输到服务器的数据进行加密。因此，没有人可以在传输过程中嗅探数据。

浏览器和 Web 服务器之间如何建立 HTTPS 连接？

  1. 浏览器尝试连接到https://payment.com。
  2. payment.com 服务器向浏览器发送证书。该证书包括payment.com 服务器的公钥，以及该公钥实际上属于payment.com 的一些证据。
  3. 浏览器验证证书以确认它具有正确的 payment.com 公钥。
  4. 浏览器随机选择一个新的对称密钥 K 用于连接到 payment.com 服务器。它在 payment.com 公钥下加密 K。
  5. payment.com 使用其私钥解密 K。现在浏览器和支付服务器都知道 K，但没有其他人知道。
  6. 任何时候浏览器想向payment.com发送一些东西，它都会在K下加密；payment.com 服务器在收到后对其进行解密。每当 payment.com 服务器想要向您的浏览器发送内容时，它都会在 K 下对其进行加密。

这个流程可以用下图表示： 在此处输入图像描述

于 2014-08-05T03:41:49.863 回答
4

我写了一篇简短的博客文章，简要讨论了这个过程。请随意看看。

SSL 握手

来自相同的一个小片段如下：

“客户端通过 HTTPS 向服务器发出请求。服务器发送其 SSL 证书 + 公钥的副本。在使用其本地受信任的 CA 存储验证服务器的身份后，客户端生成一个秘密会话密钥，使用服务器的公共密钥对其进行加密密钥并发送它。服务器使用其私钥解密秘密会话密钥并向客户端发送确认。已建立安全通道。

于 2016-01-11T10:28:38.497 回答
3

Mehaase 已经详细解释过了。我将把我的 2 美分加到这个系列中。我有很多关于 SSL 握手和证书的博文。虽然其中大部分都围绕 IIS Web 服务器，但该帖子通常仍然与 SSL/TLS 握手相关。这里有几个供您参考：

不要将证书和SSL视为一个主题。将它们视为 2 个不同的主题，然后尝试查看它们与谁一起工作。这将帮助您回答问题。

通过证书存储在通信方之间建立信任

SSL/TLS 通信仅在信任的基础上工作。互联网上的每台计算机（客户端/服务器）都有一个它维护的根 CA 和中间 CA 的列表。这些会定期更新。在 SSL 握手期间，这用作建立信任的参考。例如，在 SSL 握手期间，当客户端向服务器提供证书时。服务器将尝试检查颁发证书的 CA 是否存在于其 CA 列表中。当它不能这样做时，它声明它不能进行证书链验证。（这是答案的一部分。它还着眼于AIA为此。）客户端还对其在 Server Hello 中收到的服务器证书进行类似的验证。在 Windows 上，您可以通过 PowerShell 查看客户端和服务器的证书存储。从 PowerShell 控制台执行以下命令。

PS Cert:> ls Location : CurrentUser StoreNames : {TrustedPublisher, ClientAuthIssuer, Root, UserDS...}

位置：LocalMachine StoreNames：{TrustedPublisher、ClientAuthIssuer、远程桌面、根...}

Firefox 和 Opera 等浏览器不依赖底层操作系统进行证书管理。他们维护自己独立的证书存储。

SSL 握手使用对称和公钥加密。服务器身份验证默认发生。客户端身份验证是可选的，取决于服务器端点是否配置为对客户端进行身份验证。请参阅我的博客文章，因为我已经详细解释了这一点。

最后对于这个问题

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

证书只是一个文件，其格式由X.509标准定义。它是一种证明通信方身份的电子文件。 HTTPS = HTTP + SSL是一种协议，它定义了 2 方应如何相互通信的准则。

更多信息

  • 为了理解证书，您必须了解证书是什么，并阅读证书管理。这些很重要。
  • 一旦理解了这一点，然后继续进行 TLS/SSL 握手。您可以为此参考 RFC。但它们是定义准则的骨架。包括我在内的几篇博文都详细解释了这一点。

如果完成了上述活动，那么您将对证书和 SSL 有一个大致的了解。

于 2017-06-23T12:45:30.827 回答