我们先通过一个例子来了解https。如果我们想实现A，我们可以向b发送消息。 要实现以下功能，a可以向b发送一个hello消息包，即使被中间人屏蔽，也不可能知道消息的内容。对于这个问题，很多人马上会想到各种加密算法，比如对称加密，非对称加密。加密算法只是一种解决方案。首先要做的是理解我们的问题——什么是安全？这个例子的理解是:A和B之间交流的内容，只有A和B才能看到交流的真实内容。问题已经定义，很容易想到为解决方案加密消息。 对于A和B这样简单的通信模型，我们很容易做出选择:这就是对称加密算法，图中的密钥S同时起到加密和解密的作用。只要这个密钥S不向第三方公开，并且密钥S足够安全，就可以解决开头设置的问题。由于世界上只有A和B知道如何对它们之间的消息进行加密和解密，然而，WWW环境下Web服务器的通信模型并不那么简单:如果服务器对所有客户端通信使用相同的对称加密算法，那就等于没有加密。我们应该怎么做，即在不泄露密钥的情况下使用对称加密算法？答案是Web服务器和每个客户端使用不同的对称加密算法:另一个问题来了，我们的服务器如何告诉客户端使用哪种对称加密算法？当然是通过协商，但是协商过程没有加密，会被中间人屏蔽。然后，我们可以对称地加密协商过程。那么，你对协商过程加密与否，我们该怎么办？最好加密一下。那就是鸡生蛋，鸡生蛋的问题。 如何加密谈判过程？在密码学领域，有一种加密算法叫做“非对称加密”，其特点是用私钥加密的密文，只要是公钥就可以解密。而公钥加密的密文只能用私钥解密，私钥只有一个人有，公钥可以发给所有人。虽然服务器端在A和B方向还是不安全的，但至少A和B在服务器端是安全的。 在用非对称加密算法处理了对称加密算法的协商过程之后，你就可以明白为什么HTTPS既需要对称加密算法，又需要非对称加密算法了。Web服务器需要对每个客户端使用不同的对称加密算法，同时不允许第三方知道这个对称加密算法是什么。要做的就是用随机数，也就是用随机数生成对称加密算法。这样服务器和客户端的每一次交互都可以是一个新的加密算法，加密算法只能在交互中确定。 你明白为什么HTTPS协议的握手阶段有这么多随机数吗？如何获得公钥？细心的人可曾注意到，如果使用非对称加密算法，客户端A和B一开始就需要持有公钥，否则无法启动加密。我们又遇到了新问题。客户端A和B如何安全地获得公钥？只有这些可以想到的方案:方案1。服务器将公钥发送给每个客户端。 2.服务器将公钥放在远程服务器上，用户可以请求它。 选项1，因为在选项2中多了一个请求，所以必须解决公钥的放置问题。公钥被转移了怎么办？选项1有一个问题:如果服务器向客户端发送公钥，并且是通过中介传递的，该怎么办？？显然，每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。只有第三方机构的公钥才能用来处理问题。 公钥被调换的问题之所以发生，是因为我们的客户端分不清返回公钥的人是中间人还是真实的服务器。 其实这就是密码学中提到的认证问题。如果让你来处理，你会怎么处理？如果你了解HTTPS，你会知道如何处理它与数字证书。 但是你想过证书的本质吗？既然服务器需要把公钥发送给客户端，那么这个过程本身就不安全，那么我们为什么不把这个过程本身再加密一次，但是你用对称加密还是非对称加密就是另外一个问题了。 问题的难点在于，如果我们选择直接将公钥传递给客户端的方案，总是无法处理公钥的传递被中间人切换的问题，因此无法将服务器的公钥直接传递给客户端。而是由第三方机构用自己的私钥加密我们的公钥，然后传输给客户端。 然后客户端用第三方组织的公钥解密。下图显示的是“数字证书”。证书中只有服务器交给第三方机构的公钥，这个公钥是用第三方机构的私钥加密的。 如果可以解密，说明公钥没有被中间人调换。 如果一个中间人向客户发送用他的私钥加密的东西，客户就不能用第三方的公钥解密。但在现实中，HTTPS仍然有数字签名的概念。比如第三方机构不能只给你一个证书，它还可以像中间人一样给一个居心不良的公司开证书，让中间人有机会调换你的证书。这种情况下，委托人分不清是你的证书还是中间人，因为不管中间人。 处理这个问题，首先要想清楚一个问题。这个区分同一机构下不同证书的职责应该放在哪里？只能放在用户端。用户拿到证书后，就可以判断证书是否可以被篡改。怎样才能拥有这种力量？从现实中寻找灵感。比如你拿到考生的学历证书，证书上写着持证人、发证机构、发证时间等。同时，证书上还写着如何鉴别这个证书的真伪？拿着这个证号去相关机构查一下就行了。如果证件上的持证人与实际考生一致，证件号码也能对应，那么就说明这个证件是真实的。我们的客户可以使用这个机制吗？如果这个“第三方机构”是远程服务，如果是远程服务，整个交互会比较慢，所以这个第三方机构的验证工作只能放在客户端本地。 客户端如何在本地验证证书？答案是证书本身已经告诉了客户端如何验证证书的真实性，也就是证书说如何根据证书的内容生成证书号。 客户端拿到证书后，根据证书上的方法自己生成一个证书号。如果生成的证书号与证书上的证书号相同，说明该证书是真实的。同时，为了避免证书号本身被更改，采用第三方私钥加密。使用图表来帮助您理解。证书中的“数字生成方法MD5”告诉客户端，您可以通过使用MD5评估证书的内容来获得证书编号。 当客户端获得证书时，它开始验证证书的内容。如果客户端计算的证书号与证书中的证书号相同，则验证通过:但是第三方的公钥是如何进入客户端机器的呢？由于客户端收到的证书中写入了颁发机构，因此客户端将根据该颁发机构的值在本地查找相应的公钥。如你所知，证书是HTTPS的数字证书，证书号是数字签名，第三方指。 CA如何向服务器颁发数字证书？如何申请CA？每个CA组织都是类似的，如图:拿到证书后，可以将证书配置到自己的服务器上。那么如何配置呢？留给百度，通过计算尽量还原HTTPS的设计过程。 这样我们就能理解为什么HTTPS和HTTP的交互那么多，为什么HTTPS的性能可以差，找到HTTPS性能可以优化的点，都是为了客户端和服务器安全协商一个对称加密算法。 这是SSL/TLS协议在HTTPS的主要工作。剩下的就是双方在通信时使用这种对称加密算法进行加密和解密。这是HTTPS协议的真实交互图？用一段话来概括HTTPS:HTTPS要求对称加密算法来保证客户端和服务器端通信过程的安全性。然而，在协商对称加密算法的过程中，需要使用非对称加密算法来保证安全性。但是直接使用非对称加密的过程本身并不安全，会存在中间人篡改公钥的可能，所以客户端和服务器端并不直接使用公钥。相反，由数字证书颁发机构颁发的证书用于确保不对称加密过程本身的安全性。这样通过这些机制协商出一个对称的加密算法，双方使用这个算法进行加密和解密，从而解决了客户端和服务器之间的通信安全问题。