本文试图一步步还原HTTPS的设计过程，从而理解为什么HTTPS最终会变成这样。 但这并不代表HTTPS的真实设计过程。 在阅读这篇文章时，你可以试着放下你对HTTPS的现有认识，这更有利于“恢复”过程。 我们不能先谈HTTP和HTTPS。先说一个聊天软件。如果我们要实现这个聊天软件，可以给B发一个hello消息，如果我们要实现这个聊天软件，本文只考虑安全问题，我们要认识到，即使A发给B的hello消息包被中介屏蔽了，我们也无法知道消息的内容如何才能真正安全。对于这个问题，很多人马上想到的就是各种加密算法，对称加密，非对称加密，DES，RSA，XX，或者噼里啪啦~而我想说的是加密算法只是解决方案。我们要做的第一件事是理解我们的问题域——什么是安全性？我个人的理解是:A和B之间交流的内容，只有A和B才能看到交流的真实内容。好了，问题域已经定义好了(当然，现实中不止这个定义) 对于处理方案，很容易想到加密消息。 跑题了，但这是唯一的办法吗？我不这么认为。也许在未来，会有一种材料打破当前世界的通信假设，实现真正的保密。 对于A和B这样简单的通信模型，我们很容易做出选择:这就是对称加密算法，图中的密钥S同时起到加密和解密的作用。 具体细节超出了本文的范围。 只要这个密钥S不向第三方公开，并且密钥S足够安全，我们就处理我们一开始设定的问题域。 因为世界上只有A和B知道如何加密和解密他们之间的消息。 然而，在WWW环境中，我们的Web服务器的通信模型并不那么简单:如果服务器对所有客户端通信使用相同的对称加密算法，那就等于没有加密。 那我该怎么办？也就是说，可以使用对称加密算法而不泄露密钥？请思考21秒。 答案是:Web服务器和每个客户端使用不同的对称加密算法:如何确定对称加密算法？等等，另一个问题来了。我们的服务器如何告诉客户端使用哪种对称加密算法？当然是通过谈判。 但是你的谈判过程没有加密，不然会被中间人屏蔽。 然后我们对称加密协商过程。如果对协商过程进行加密或不加密，应该怎么做？再加密一次就好了...好了，先说鸡下蛋和鸡下蛋的问题。 如何加密谈判过程？新的问题是，如何加密协商过程？在密码学领域，有一种加密算法叫做“非对称加密”，其特点是用私钥加密的密文只要是公钥就可以解密，而用公钥加密的密文只能用私钥解密。 只有一个人有私钥，而公钥可以分发给所有人。 尽管服务器端指向A、B，...还是不安全，至少A，B方向到服务器端是安全的。 好了，如何协商加密算法，我们已经处理过了:使用非对称加密算法协商对称加密算法。 现在，你明白为什么HTTPS需要对称和非对称加密算法了吗？应该协商什么加密算法，以便Web服务器对每个客户端使用不同的对称加密算法？同时也不能让第三方知道这个对称加密算法是什么。我们做什么呢使用随机数意味着使用随机数生成对称加密算法。 也就是说，服务器和客户端的每一次交互都可以是一个新的加密算法，加密算法只能在交互中确定。 现在，你明白为什么在HTTPS协议的握手阶段有这么多随机数了吧？ 如何获得公钥？细心的人可能已经注意到，如果使用非对称加密算法，我们的客户端A和B需要一开始就持有公钥，否则无法启动加密。 现在，我们遇到了一个新问题。A客户端和B客户端如何安全地获得公钥？我只能想到这几个方案:方案一。服务器将公钥发送给每个客户端。方案二。服务器将公钥放在远程服务器中，客户端可以请求获得我们的选项1。因为方案2还有一个要求，需要解决公钥放置的问题。 公钥被转移了怎么办？又是一个下蛋的鸡下蛋的鸡问题？但是方案1有一个问题:服务器把公钥发给客户端，包被中间人掉包了怎么办？为了便于理解，我画了一张图:显然，让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。 利用第三方机构的公钥处理下蛋和下蛋鸡的问题。公钥被切换的问题是因为我们的客户端分不清返回公钥的人是中间人还是真正的服务器。 其实这就是密码学中提到的认证问题。 如果让你来处理，你会怎么处理？如果你了解HTTPS，你会知道如何处理它与数字证书。 但是你想过证书的本质吗？请放下你现有的关于HTTPS的知识，自己想办法解决。 我是这样处理的。 既然服务器需要将公钥发送给客户端，那么这个进程本身就是不安全的，那么我们为什么不再次加密这个进程本身呢？但是，你用对称加密还是非对称加密？太好了，我觉得我又遇到了一个鸡生蛋生鸡的问题。 问题的难点在于，如果我们选择直接将公钥传递给客户端的方案，就不能总是处理公钥的传递被中间人切换的问题。 所以我们不能直接把服务器的公钥传给客户端，而是由第三方机构用自己的私钥加密我们的公钥，然后传给客户端。 用户终端用第三方组织的公钥解密它。 下图是我们设计的第一版“数字证书”。证书中只有服务器交给第三方机构的公钥，这个公钥是用第三方机构的私钥加密的:如果能解密，说明这个公钥没有被中间人转移。 如果中间人用他的私钥加密的东西被发送给客户，客户不能用第三方的公钥解密它。 说到这里，我以为我在处理问题。 但在现实中，HTTPS有一个数字签名的概念，我不能理解它的设计原因。 原来我漏看了一个场景:第三方机构不仅可以为你的公司出证，它还可以像中间商一样为居心不良的公司出证。 这样中间人就有机会调换你的证书。这种情况下，客户分不清是你的证书还是中间人的。 无论中间人还是你的证书，都可以用第三方的公钥解密。 这是这样的:当一个第三方机构给多家公司颁发证书时；客户端可以解密同一个第三方机构颁发的所有证书；最后，其他持有同一第三方机构证书的中间商可以换包；数字签名，处理同一组织颁发的不同证书的篡改问题；处理这个问题，首先要弄清楚一个问题，认定同一机构下不同证书的责任。我们应该把它放在哪里？只能放在客户端。 意思是客户端拿到证书后，可以判断证书是否被篡改。 怎样才能拥有这种力量？我们从现实中寻找灵感。 比如你是HR，你拿到的是应聘者的学历证书。证书上写着持证人、发证机构、发证时间等。同时，证书上还写着最重要的一条:证书编号！怎么才能鉴别这个证书的真伪呢？拿着这个证号去相关机构查一下就行了。如果证件上的持证人与实际考生一致，证件号码也能与之对应，说明这个证件是真实的。 我们的客户可以使用这个机制吗？像这样:但是这个“第三方机构”在哪里呢？是远程服务吗？可以吗？如果是远程服务，整个交互会比较慢。 所以这个第三方机构的验证工作只能放在用户端本地。 客户端如何在本地验证证书？客户端如何在本地验证证书？答案是证书本身告诉客户端如何验证证书的真实性。 也就是证书上说如何根据证书的内容生成证书号。 得到证书后，客户端根据证书上的方法自行生成一个证书号。如果生成的证书号与证书上的证书号相同，说明该证书是真实的。 同时为了避免证书号本身被更改，用第三方的私钥加密。 这个地方有些笼统，我们来拍张图帮助理解:证书的制作如图。 证书中的“数字生成方法MD5”告诉客户端，您可以通过使用MD5评估证书的内容来获得证书编号。 当客户端获得证书时，它开始验证证书的内容。如果客户端计算的证书号与证书中的证书号相同，验证通过:但是第三方的公钥是怎么到客户端机器上的呢？世界上有如此多的机器 实际上，在现实中，浏览器和操作系统都维护着一个权威的第三方机构列表(包括它们的公钥)。 因为客户端收到的证书中会写入一个颁发机构，所以客户端会根据这个颁发机构的值在本地找到相应的公钥。 题外话:如果浏览器和操作系统的防线被突破了，那就没办法了。 想想当年我装的非常规XP系统，我就害怕。 说到这里，我想你已经知道我上面说的了，证书是HTTPS的数字证书，证书号是数字签名，第三方机构是指数字证书颁发机构(CA)。 CA如何向服务器颁发数字证书？听到这个问题的时候，我误以为我们的服务器需要向CA部门的服务器发送网络请求才能得到这个证书。 我理解力的问题了吗，还是 实际上，问题应该是如何将CA颁发给我们的网站管理员，我们的网站管理员如何将这个数字证书放在我们的服务器上？ 我们如何向CA申请？每个CA组织都是相似的。我在网上找到一个:我们拿到证书后，可以把证书配置到自己的服务器上。 那么如何配置呢？这些都是细节，我就交给谷歌了。 也许我们需要理清思路。我们试图通过计算还原HTTPS的设计过程。 这样我们就能理解为什么HTTPS和HTTP的互动那么多，为什么HTTPS的性可以差，如何找到HTTPS的最优点。 上面的大量工作是为了客户端和服务器安全地协商对称加密算法。 这是SSL/TLS协议在HTTPS的主要工作。 剩下的就是双方在通信过程中使用这种对称加密算法进行加密和解密。 以下是HTTPS协议的真实交互图(复制自网络，忘记在哪里了，如果侵权麻烦请告诉我):能否用一句话概括HTTPS？答案是否定的，因为HTTPS本身太复杂了。 不过我还是试着总结一下HTTPS:HTTPS的一段话:HTTPS需要对称加密算法来保证客户端和服务器之间的通信安全。然而，协商对称加密算法的过程需要非对称加密算法来保证安全性。但是，直接使用非对称加密的过程本身并不安全，会存在中间人篡改公钥的可能性。因此，客户端和服务器不直接使用公钥，而是使用数字证书颁发机构颁发的证书来保证非对称加密过程本身的安全性。 这样通过这些机制协商出一个对称的加密算法，双方使用这个算法进行加密和解密。 从而解决用户端和服务器端之间的通信安全问题。 作者:翟志军