Https及其安全性

Https比Http安全性？

Https是以安全为目标的Http版本，在Http上使用SSL层，进行加密传输（对称和非对称加密），还具备身份验证的功能（下面会重点说HTTPS的双向验证）。当然，Https是需要配置CA证书的，一般要从某些机构购买。

为何Https依然会被截取？

我们利用fiddler可以截取到了客户端与后台的https接口的明文内容，这是一个可怕的问题。目前的一些抓包工具，fiddler、charles使用了叫做man-in-the-middle（中间人）机制：

我们看到Fiddler抓取HTTPS协议主要由以下几步进行：

1. 第一步，Fiddler截获客户端发送给服务器的HTTPS请求，Fiddler伪装成客户端向服务器发送请求进行握手。
2. 第二步，服务器发回相应，Fiddler获取到服务器的CA证书， 用根证书公钥进行解密， 验证服务器数据签名， 获取到服务器CA证书公钥。然后Fiddler伪造自己的CA证书， 冒充服务器证书传递给客户端浏览器。
3. 第三步，与普通过程中客户端的操作相同，客户端根据返回的数据进行证书校验、生成密码Pre_master、用Fiddler伪造的证书公钥加密，并生成HTTPS通信用的对称密钥enc_key。
4. 第四步，客户端将重要信息传递给服务器， 又被Fiddler截获。Fiddler将截获的密文用自己伪造证书的私钥解开， 获得并计算得到HTTPS通信用的对称密钥enc_key。Fiddler将对称密钥用服务器证书公钥加密传递给服务器。
5. 第五步，与普通过程中服务器端的操作相同，服务器用私钥解开后建立信任，然后再发送加密的握手消息给客户端。
6. 第六步，Fiddler截获服务器发送的密文， 用对称密钥解开， 再用自己伪造证书的私钥加密传给客户端。
7. 第七步，客户端拿到加密信息后，用公钥解开，验证HASH。握手过程正式完成，客户端与服务器端就这样建立了”信任“。

在之后的正常加密通信过程中，Fiddler如何在服务器与客户端之间充当第三者呢？

服务器—>客户端：Fiddler接收到服务器发送的密文， 用对称密钥解开， 获得服务器发送的明文。再次加密， 发送给客户端。
客户端—>服务端：客户端用对称密钥加密，被Fiddler截获后，解密获得明文。再次加密，发送给服务器端。由于Fiddler一直拥有通信用对称密钥enc_key， 所以在整个HTTPS通信过程中信息对其透明。

从上面可以看到，Fiddler抓取HTTPS协议成功的关键是根证书（具体是什么，可Google），这是一个信任链的起点，这也是Fiddler伪造的CA证书能够获得客户端和服务器端信任的关键。

从技术上讲，证书其实包含三部分，用户的信息，用户的公钥，还有CA中心对该证书里面的信息的签名，要验证一份证书的真伪（即验证CA中心对该证书信息的签名是否有效），需要用CA中心的公钥验证，而CA中心的公钥存在于对这份证书进行签名的证书内，故需要下载该证书，但使用该证书验证又需先验证该证书本身的真伪，故又要用签发该证书的证书来验证，这样一来就构成一条证书链的关系，这条证书链在哪里终结呢？答案就是根证书，根证书是一份特殊的证书，它的签发者是它本身，下载根证书就表明您对该根证书以下所签发的证书都表示信任，而技术上则是建立起一个验证证书信息的链条，证书的验证追溯至根证书即为结束。所以说用户在使用自己的数字证书之前必须先下载根证书。

这就解释了问什么截取到了Https的数据，并且，Https在传输过程加密，所以到了客户端已经不是Https传输加密的范围了，这个时候其实很多人都是这么解决的，对Https数据先自己进行加密（Ex：AES、RSA），再Https传输，这样即使截取到Https数据，也看不到明文。那么有没有方式可以不让fiddler&charles这种家伙截取到Https呢？有，就是Https的双向验证。

Https双向验证

服务器端对请求它的客户端要进行身份验证，客户端对自己所请求的服务器也会做身份验证。服务端一旦验证到请求自己的客户端为不可信任的，服务端就拒绝继续通信。客户端如果发现服务端为不可信任的，那么也中止通信。具体怎么做呢？如下图所示。