【网络安全】聊一聊HTTPS的加密机制

众所周知，HTTP协议是以明文形式传递数据，而HTTPS就是在HTTP基础上多了SSL加密。以往对HTTPS的了解也仅限于此了，没有过多深入的探究。最近实验室小伙伴面试时关于HTTPS的问题出现频率较高，那么就来系统的整理下吧。开整！

目的

这个不必多说，自然是为了安全性。特别是一些对安全性要求比较高的信息，如信用卡、电商购物信息等。安全性具体来说还可以分为三点：

• 可靠性：即用户访问的网站，是不是真正的官网？还是“李鬼”网站
• 机密性：保证数据在网络上传输时的- 机密性，即使被第三方截获，也不能获取数据内容
• 完整性：保证服务端/客户端获取到的都是完整的信息

苹果也在2017年1月1日强制要求必须使用HTTPS协议，可见这也是未来的大势所趋。

方式

一般所熟知的加密方式有对称加密和非对称加密。那么HTTPS使用的是哪种方式呢？

对称加密（假设）

对称加密，即加密和解密过程使用的是同一个密钥。比如服务端将数据加密，然后传输给客户端。客户端就需要用相同的密钥对数据解密，这就存在一个问题–如何把密钥传递给客户端？如果直接在网络上传递，就基本和不加密一样了，因为第三方一样可以截获密钥对数据解密。难道需要再用一个【密钥】来加密这个密钥吗？那就变成了一个递归加密的过程。。。
可见直接使用对称加密这种方式行不通。

非对称加密（假设）

对称加密，即加密和解密使用的是不同的密钥（公钥和私钥）。一般公钥是可以发给别人的，私钥必须保密。用公钥加密的数据，可以用私钥解密。用私钥加密的数据可以使用公钥解密。

如果服务器把公钥发个客户端。客户端将要发送的数据使用公钥加密后发送给服务端，就能保证只有拥有私钥的服务器可以对数据解密。反过来的过程就不行了，因为公钥在网上公开传输了，服务器使用私钥加密的数据，相当于还是在网上“公开”的。

用两组公钥私钥似乎能解决这个问题。就是服务端和客户端分别把自己的公钥发送给对方，然后每次发送数据时使用对方的公钥加密。对方收到后自己的私钥解密。这样看起来是可行的，但是存在的一个问题是非对称加密算法对于大数据的加密非常耗时。

非对称加密 + 对称加密

这种方式其实就是解决了第一种假设中的【密钥如何安全传输】的问题。主要步骤如下：

1. 客户端向服务端发起请求；
2. 服务端发送【公钥A】给客户端；
3. 客户端使用【公钥A】加密 【密钥X】，然后传输给服务端；
4. 服务端收到后，可以使用【私钥A‘】解密获得【密钥X】

其中【密钥X】就是后续用于数据加密的密钥（对称加密）。这种方式就巧妙的把密钥传递给了另一方，也避免了使用非对称加密来对大量数据加解密。

漏洞！

上述的【非对称 + 对称】方式看起来已经是很完美了，但是其实还存在一个严重的漏洞。其实在【非对称加密】中就埋下了隐患，所以上文用的是“似乎”。假设这样的场景：

1. 服务端将【公钥A】发送给客户端的过程中被【黑客】截获。黑客将其替换为自己的【公钥B】再发送给客户端
2. 客户端使用了假的公钥–【公钥B】加密【密钥X】，然后发送给服务端
3. 再次被【黑客】截获，并使用【私钥B’】解密获得【密钥X】。再用【公钥A】对其加密后发送给服务端
4. 服务端使用【私钥A‘】解密获得【密钥X】

整个场景下来，服务端和客户端其实都没有感知到中间有【黑客】的存在，他们确实都拥有了【密钥X】。但是【密钥X】同时也被【黑客】掌握了。那么后续数据传递就没有任何安全性可言了，【黑客】可以任意查看数据，甚至篡改数据。

要解决这个问题的关键就是如何判断客户端收到的【公钥】是服务端发送的。套用我们生活中常用的概念，就是【身份证】–一个由权威机构证明的证件。所以网站在使用HTTPS之前，需要向CA机构申请一份数字证书。证书中包含了网站信息、公钥信息等。

数字签名

上文中提到了需要权威机构的【数字证书】，其实又牵扯到一个问题：怎么保证【数字证书】的没有被篡改过呢？这里就需要用到【数字签名】
【数字证书】 = 【明文信息】 + 【数字签名】
数字签名是CA机构经过如下过程制作的：
1.对明文进行hash；
2.对哈希的结果使用私钥加密，获得【数字签名】

后续浏览器可以这样对【数字证书】验证：
1.对【数字证书】中的【明文信息】进行hash获得T；
2.使用CA机构提供的公钥解密【数字签名】获得S；
3.比较S是否等于T，若相等则说明证书可靠。

如此一来，由于【黑客】不具有【私钥】无法篡改签名，如果对明文部分做了修改，就无法通过校验了。

参考资料

https://zhuanlan.zhihu.com/p/43789231
https://zhangzifan.com/https-http-tls-ssl.html