HTTPS 通过加密的方式来保存数据传输的安全性，大致可以分为五种加密方案：

1、 对称加密

方法：服务器生成对称密钥，客户端向服务器发送密钥请求（明文），服务器接收到请求后将对称密钥响应给服务端（明文），后面客户端与服务器利用此对称密钥将信息进行加密后再传输给对方。

缺点：由于服务器响应给客户端的密钥是明文的，所以可能被中间人监听到，从而该响应及以后的请求与响应都有可能中间人监听或者篡改，不安全。

2、 非对称加密

方法：服务器生成一对非对称密钥，客户端向服务器发送密钥请求（明文），服务器接收到请求后将公钥响应给服务端（明文），后面客户端利用公钥对信息加密后发送给服务端，服务端利用私钥进行解密获取报文信息。同样，服务端将利用密钥加密的报文发送给客户端之后，客户端也可以利用公钥对报文进行解密。（注意：公钥、密钥是一对一的）

缺点：和对称加密一样，服务端发送给客户端的公钥有可能被中间人监听或者替换，即客户端 -> 服务器安全（暂时安全），而服务端 -> 客户端不安全，因为客户端收到的报文有可能是被中间人篡改过的报文。

3、非对称加密 + 非对称加密

方法：为了解决非对称加密服务端 -> 客户端不安全的问题，我们在客户端也形成一对非对称密钥。这样，服务端将服务端公钥S响应给客户端（明文），客户端利用公钥S对客户端公钥C加密后发送给服务端，由于中间人没有服务端私钥S’，所以无法获取客户端公钥 （暂时是这样），后面服务器利用私钥S’进行解密，然后利用客户端公钥C进行加密，将响应发送给客户端，客户端再利用私钥C’进行解密，通过这样的方式完成安全通信。

缺点：首先，非对称加密算法速度非常慢，所以此方法的效率非常低。其次，这里其实还存在中间人从最开始直接将服务端公钥替换的问题 (我大括号标注暂时的地方)，这点我们会在后文细说。

4、非对称加密 + 对称加密

方法：服务端生成一对非对称密钥，客户端生成一对对称密钥，客户端向服务端发起密钥请求（明文），服务端将非对称公钥S响应给客户端（明文），然后客户端利用S将自己的对称密钥C进行加密然后发送给服务端（密文），由于中间人没有服务端私钥，所以无法获取该报文，后面服务端通过私钥S’获取客户端对称密钥C后，以后通信就使用该对称密钥进行加密与解密。

缺点：此方法解决了方案3效率低的问题（只有第一次通话使用非对称加密，以后均使用对称加密，而对称加密算法速度非常快），然而这里还存在一个非常严重的问题，这也是方案2、3、4存在的共同问题 – 如果服务端公钥一开始就被监听并替换了怎么办？

什么意思呢？以本方案为例，由于服务端的第一次响应是明文的，所以该响应可能被中间人获取，那么如果中间人事先准备一对非对称密钥，然后用其中的公钥H将响应中携带的服务端公钥S替换掉，然后再发送给客户端，这样不就全完了 – 客户端的非对称公钥或者对称密钥是使用响应报文中的公钥进行加密的，而客户端并不知道报文中的公钥是否是服务端公钥，即不知道该公钥是否是安全的 (是否被替换)。一旦客户端使用中间人的公钥进行加密，那么中间人就可以使用自己的私钥解密获取到客户端的对称密钥，然后再使用服务端公钥对对称密钥进行加密，最后将其发送给服务端，假装一切事情都没有发生过，。但其实客户端的请求以及服务端的响应对于中间人来说都已经是明文了，因为中间人获得了对称密钥（对于方案4来说）。

5、非对称加密 + 对称加密 + 证书认证

引入：现在的问题变成了客户端如何鉴别服务端发送过来的公钥是否是安全的。为了解决这个问题，人们引入了CA证书。CA证书是由权威CA机构及其子机构颁发的一种电子证书，服务端在上线使用 HTTPS 协议前都需要向CA机构申请CA证书，申请文件中包含了服务端的IP、公钥等信息（明文），CA机构审查后会向该服务端颁发CA证书。客户端第一次发起密钥请求时，服务端会将CA证书返回给客户端（明文），客户端可以根据此证书来鉴别服务端公钥的安全性（服务端公钥包含在CA证书中）。关于CA机构的更多信息这里我们不做过多讨论，大家可以自学Google，下面我们主要讨论CA证书如何解决服务端公钥的安全性问题以及CA证书本身的安全性。

CA证书的形成过程如下：CA机构对服务端完成审查后，会将服务端的证书请求文件 (.csr) 通过hash散列后形成一个定长字符串，即数据摘要/数据指纹 (注：hash 散列的过程是不可逆的，即不可能通过数据摘要逆向得到文件，并且文件和摘要是一对一的，文件的一点小小改动得到的数据摘要都会大不相同)。然后CA机构本身会由一对非对称密钥，CA机构会使用其中的私钥（注意不是服务端的私钥，而是CA自己的私钥）对数据摘要进行加密得到数字签名，然后这个数字签名和证书请求文件 (.csr) 合起来组成CA证书（明文）。

现在，我们来看客户端如何使用CA证书来鉴别服务端公钥的安全性：服务端将属于自己的证书响应给客户端，由于证书明文信息中包含了服务端公钥以及证书申请文件的数字签名，所以客户端可以使用相同hash算法将证书申请文件形成摘要，然后使用CA机构的公钥使用相同加密算法对数字签名进行解密，如果 hash 得到的摘要与解密得到的摘要是相同的，则说明该证书没有被篡改过，服务端公钥安全；反之则不安全，因为一旦修改了申请证书的信息，那么重新hash得到摘要与解密得到的摘要就会不同 (文件与摘要是一对一的)；而修改数字签名就不可能了，因为形成数字签名的私钥只有CA机构有，使用个人的私有加密得到的数字签名不能通过CA机构的公钥进行解密。（注意：申请证书的 hash 散列算法以及CA机构的加密算法都是公开的，并且浏览器会内置CA机构的公钥，CA机构的公钥也是公开的）

那么有没有可能把整个CA证书都掉包呢？也不可能。首先，由于客户端使用CA机构的公钥对数字签名进行解密，这就保证了发送过来的CA证书必须是真的CA证书，否则无法使用CA公钥进行解密（密钥是公钥是一对一的），而CA证书是需要使用法人信息去向CA机构申请的，这样一旦做中间人被发现代价就太大了。同时，客户端要鉴别CA证书是否被掉包也十分简单 – CA证书的明文信息中包含了服务端的IP地址，一对比就知道。

所以，通过添加CA证书，我们就保证了客户端能够鉴别服务端公钥的安全性，从而保证了客户端对称密钥的安全交换。同时，由于后续双方都使用对称密钥进行加密解密，通信效率也得到了保证。

---