简要解释 https 的工作原理

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

在学习如何使用OpenSSL创建自签名证书时，我发现网上大多数资料都假设你知道什么是证书，以及它们在 HTTPS 中的作用。

我决定尝试解释一下HTTPS，具体来说，就是解释通信是如何安全的，也就是Diffie-Hellman密钥交换和数字证书的工作原理。以下是我的理解。

HTTPS 允许我们在不安全的信道上（例如机场的开放式 Wi-Fi 网络）进行安全通信，在这种信道上，任何人都可以轻易监听所有网络流量。HTTPS 通信之所以安全，是因为它经过了加密。

通信采用对称密钥加密。这种加密方式要求发送方和接收方拥有相同的密钥（即使用相同的密钥对数据进行加密和解密）。

但是，如果发送方和接收方需要通过不安全的通道互相发送密钥，那么这一切岂不是毫无意义吗？

只有当发送方和接收方有办法在有人监听通信的情况下互相发送密钥（并且该监听者无法弄清密钥是什么）时，这种方法才有效。

这时就需要用到迪菲-赫尔曼密钥交换了。

迪菲-赫尔曼

Diffie-Hellman 协议允许双方在不泄露密钥的情况下创建共享密钥，并且是“公开”进行的，也就是说，即使有人可以访问双方交换的所有信息，他们仍然无法发现密钥是什么。

听起来像魔法，对吧？不，这只是数学。

这里有一个简单的例子来说明它的工作原理。首先选取两个数字，通常称为p和g。p是 prime（素数）的缩写，g是 generator（生成元）的缩写。

质数是大于 1 的自然数，它除了 1 和它本身之外没有其他因数。

素数p的生成元g是一个数，使得对于 1 到 p-1 之间的 x，g^x mod p 将“生成”从 1 到 p-1 的所有数。

mod（取模运算的缩写）是一个返回精确除法余数的函数，例如 5 mod 3 是 2，因为 5 除以 3 的精确结果是 1，余数是 2（3 * 1 + 2 = 5）。

既然我们知道了模数的概念，这里举一个生成素数的例子。3 是 7 的生成元，因为：

- 3^1 mod 7 = 3
- 3^2 mod 7 = 2
- 3^3 mod 7 = 6
- 3^4 mod 7 = 4
- 3^5 mod 7 = 5
- 3^6 mod 7 = 1

如果我们对得到的结果进行排序：1、2、3、4、5、6，我们可以看到它们都是从 1 到 p-1 的数字，这使得g = 3 成为p = 7的生成器。

我们现在拥有了“手动”执行 Diffie-Hellman 测试的所有条件。

举例来说，假设爱丽丝和鲍勃想互相写信。不幸的是，有人在偷看他们的信件，所以他们决定使用迪菲-赫尔曼密码进行秘密通信。

例如， Alice 选取g和p，例如 g = 3，p = 7，并将它们连同信件一起寄给 Bob。Alice
还选取一个小于p 的秘密数字，例如 2。Bob
收到p和g后，也选取一个小于p 的秘密数字，例如 5。

然后 Bob 计算：g^secretBob mod p，在本例中为 3^5 mod 7 = 5。Bob 将此数字发送给 Alice，我们称此数字为numberBobSent。

同时，Alice 计算 g^secretAlice mod p，在本例中为 3^2 mod 7 = 2，并将其发送给 Bob，我们称这个数字为numberAliceSent。

爱丽丝收到了鲍勃的信，信中包含数字 5。然后她计算 numberBobSent^secretAlice mod p，在这种情况下是 5^2 mod 7 = 4。

Bob 收到 Alice 的信，并做了同样的事情：numberAliceSent^secretBob mod p，在这种情况下是 2^5 mod 7 = 4。

他们的共同秘密是 4。任何读过信件的人都能读出 p、g、numberAliceSent 和 numberBobSent。但是，他们既不知道 Alice 和 Bob 的秘密数字，也不知道他们的共同秘密。Alice 和 Bob 现在可以使用他们的共同秘密来加密和解密他们的信件。

这样做的原因是，对于大素数，利用窃听者能够获取的信息（p、g、numberBobSent 和 numberAliceSent）来找出共享秘密的成本非常高昂。

数字证书

我们现在知道，即使有人可以访问所有交换的信息，Web 服务器和浏览器客户端也可以使用 Diffie-Hellman 密钥来建立密钥，从而加密通信。

这样就解决了在不安全介质上进行安全通信的问题，对吧？嗯，其实不然。

回到爱丽丝和鲍勃的例子，想象一下，如果阅读他们信件的人，比如说伊芙，采取更积极主动的态度。伊芙会抢走爱丽丝的信，换成自己的信，也会对鲍勃的信做同样的事。

她将能够分别与爱丽丝和鲍勃建立秘密联系。爱丽丝会以为自己在和鲍勃通信，鲍勃也会以为自己在和爱丽丝通信，但实际上他们都在和伊芙通信。

然后她只需要收到爱丽丝的信件，用她和爱丽丝建立的密钥解密信件，阅读信件，用她和鲍勃建立的密钥加密信件，然后发送给他。

爱丽丝和鲍勃无从得知他们的通信并非私密。

这就是所谓的“中间人攻击”。

那么我们该如何解决这个问题呢？

这时数字证书就派上用场了，但在此之前，我们需要谈谈非对称密钥加密。

非对称密钥加密

非对称密钥系统有两个密钥，一个私钥和一个公钥。两个密钥都可以进行加密和解密，但如果你用其中一个密钥加密，就只能用另一个密钥解密。

私钥绝对不能发送，而公钥可以自由发送给任何人。因为任何用私钥加密的内容都只能用公钥解密，所以如果有人给你发送了加密内容，而你可以用公钥解密它，那么你就知道只有私钥的持有者才能加密发送的内容。

证书只是一个公钥，它与有关私钥持有者的信息捆绑在一起（例如主题名称，通常包含网站域名，例如 blinkingcaret.com）。

证书之所以可信，是因为它由证书颁发机构（例如赛门铁克，前身为Verisign）进行数字签名。但首先，什么是数字签名？

数字签名

数字签名的目的是证明信息发送者的身份，以及信息在传输过程中没有被篡改。

数字签名分两步完成。首先，生成待签名数据的哈希值（哈希函数可以将任意长度的数据转换为固定长度的数据）。然后，使用私钥对哈希值进行加密。加密后的哈希值与签名信息一起打包。加密后的哈希值即为签名。

当有人收到一条带有加密哈希值的信息时，他们可以自行生成该信息的哈希值（使用相同类型的哈希函数，例如MD5），然后使用公钥解密签名并比较两个哈希值。如果它们匹配，则意味着该信息不仅没有被篡改，而且是由私钥的所有者创建的。

如果您想知道为什么我们不直接加密所有信息，而是使用哈希函数，那是因为哈希值要小得多，并且仍然具有我们保证信息未被篡改所需的所有属性。

证书颁发机构

证书颁发机构是负责签署证书的实体。要签署证书，证书颁发机构需要私钥，而私钥又与公钥相关联，公钥也包含在证书中。

证书颁发机构的证书比较特殊。它们是自签名证书，这意味着它们使用与证书中的公钥配对的私钥进行签名。此外，您的计算机操作系统预装了多个证书颁发机构的证书。

当有人给我们颁发证书时，如果该证书是由我们信任的证书颁发机构（我们电脑上安装了证书的任何证书颁发机构）签发的，我们就信任该证书（这时你的浏览器地址栏就会显示绿色）。

所以，回到爱丽丝和鲍勃的例子，我们应该改变一下这个故事，因为用字母来比喻有点不恰当。

想象一下，鲍勃和爱丽丝会亲手把信递给对方。

另外，想象一下爱丽丝和鲍勃从未见过面，他们不知道对方长什么样。

尽管情况更加复杂，但中间人攻击在这种情况下仍然可能发生。想象一下，比如乔，他会让自己经过鲍勃身边去见爱丽丝，然后另一个人，比如简，会让自己经过爱丽丝身边去见鲍勃。约翰和简可以互相配合，这样即使爱丽丝和鲍勃试图使用迪菲-赫尔曼推理，最终也会在不知情的情况下与简和约翰交谈。

但是，现在想象一下，鲍勃和爱丽丝都持有政府颁发的身份证，而且这种身份证极难伪造。

爱丽丝可以向鲍勃索要身份证。身份证上有鲍勃的姓名和照片，而且是由爱丽丝信任的政府机构颁发的。爱丽丝确信鲍勃的身份属实。鲍勃也可以对爱丽丝做同样的核实。

在HTTPS协议中，证书就是身份识别卡，而证书颁发机构就是颁发者。此外，通常情况下，HTTPS协议中只有Web服务器提供证书。然而，虽然不常见，但也可以使用证书对用户进行身份验证。

希望这能让你更好地理解这些组件如何协同工作以实现 HTTPS。请务必查看我的博客，了解更多相关内容，例如如何创建自己的证书颁发机构、安装证书颁发机构以及使用 OpenSSL 创建签名证书。