HTTPS是怎么保证数据安全传输的？

前言

关于HTTPS的连接过程，也是老生常谈的话题了。

其中涉及到的数字证书、电子签名、SSL/TLS、对称加密、非对称加密的问题总是让人摸不清头脑，不知道怎么回答。

今天就和大家再熟悉熟悉这其中千丝万缕的关系。

确实不安全！（HTTP协议传输）

传统的HTTP传输协议，是一种明文传输协议。也就是通信过程中都没有对数据进行加密，很容易泄漏数据。

比如泄漏了重要的用户信息、被伪造数据发送、都会造成不小的问题。

所以有的朋友就想到可以自己对数据进行加密，但是这种自己加密数据的方法也存在了很多问题，比如：

• 不够安全。虽然数据加了密看似安全了，但是加密的密钥怎么管理呢？这是个大问题，保存在客户端？引入插件？感觉都不是什么比较好的办法，都还是有可能被破解。
• 兼容问题。自己对数据加密，那么就要涉及到对加密算法的管理了，而加密算法是在不断发展的，而这就要求客户端和服务器端要对加密保持更新兼容，而且不能实时进行更新，需要线下更新代码逻辑。所以这也是一个比较麻烦的问题。
• 性能问题。通过代码去加密解密这个过程也是比较耗时的，会影响到性能。

所以，在原有的HTTP协议基础之下就增加了一种协议——SSL/TLS协议，形成新的较安全的网络协议——HTTPS。

对数据进行加密～（HTTPS传输数据）

在之前的网络数据传输过程中我说过，对数据进行解析的一系列应用层的工作都是交给了浏览器和操作系统的TCP协议栈。

所以HTTPS的加密解密工作自然也就是交给了浏览器，这样就不存在上述的性能问题了。

具体怎么做的呢？用到了对称加密算法：

• 客户端用对称密钥对数据进行加密。
• 服务器端用对称密钥对数据进行解密。

有人就会问了，这不还是和刚才说到的一样吗？这个密钥怎么管理呢？

这就需要在正式传输数据之前 想办法 把这个对称密钥告诉对方了。
而这个办法就是——非对称加密。

怎么告诉对方这个对称密钥？（非对称加密）

大家都知道非对称加密是分私钥和公钥，也就是你通过公钥加密数据，然后我用私钥来解密。
私钥只有自己有，所以只有自己能解开这个数据，即使中间人拿到数据，也破解不了。

放到实际客户端服务器通信中，就是服务器端将公钥发给客户端，然后客户端拿这个公钥对 对称密钥进行加密，并发给服务器端，只有客户端有私钥可以解这个含有对称加密的密文。用张图表示：

image

但是，公钥是明文传输的呀，那么中间人就可以利用这个公钥伪造数据了:

image

所以怎么解决呢？就需要这个消息证明他是来自真正的服务器端，拿到真正的公钥，而不是伪造的，这就需要电子签名了。

我要证明我是我！（电子签名）

电子签名其实也是一种非对称加密的用法。

它的使用方法是：

A使用私钥对数据的哈希值进行加密，这个加密后的密文就叫做签名，然后将这个密文和数据本身传输给B。

B拿到后，签名用公钥解密出来，然后和传过来数据的哈希值做比较，如果一样，就说明这个签名确实是A签的，而且只有A才可以签，因为只有A有私钥。

反应实际情况就是：

服务器端将数据，也就是我们要传的数据（公钥），用另外的私钥签名数据的哈希值，然后和数据（公钥）一起传过去。
然后客户端用另外的公钥对签名解密，如果解密数据和数据（公钥）的哈希值一致，就能证明来源正确，不是被伪造的。

但是，这个用作签名的另外的私钥和另外的公钥怎么来的呢？这就需要强大的CA来验证了。

强大的后台机构～（数字证书）

证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

实际情况中，服务器会拿自己的公钥以及服务器的一些信息传给CA，然后CA会返回给服务器一个数字证书，这个证书里面包括：

• 服务器的公钥
• 签名算法
• 服务器的信息，包括主机名等。
• CA自己的私钥对这个证书的签名

然后服务器将这个证书在连接阶段传给客户端，客户端怎么验证呢？

细心的小伙伴肯定知道，每个客户端，不管是电脑、手机都有自带的系统根证书，其中就会包括服务器数字证书的签发机构。所以系统的根证书会用他们的公钥帮我们对数字证书的签名进行解密，然后和证书里面的数据哈希值进行对比，如果一样，则代表来源是正确的,数据是没有被修改的。

当然中间人也是可以通过CA申请证书的，但是证书中会有服务器的主机名，这个主机名（域名、IP）就可以验证你的来源是来源自哪个主机。

扩展一下：

其实在服务器证书和根证书中间还有一层结构：叫中级证书，我们可以任意点开一个网页，点击左上角的🔒按钮就可以看到证书详情：

image

可以看到一般完整的SSL/TLS证书有三层结构：

• 第一层：根证书。也就是客户端自带的那些。
• 第二层：中级证书。一般根证书是不会直接颁发服务器证书的，因为这种行为比较危险，如果发现错误颁发就很麻烦，需要涉及到跟证书的修改。所以一般会引用中间证书，根证书对中间证书进行签名，然后中间证书再对服务器证书进行签名，一层套一层。
• 第三层：服务器证书。也就是跟我们服务器相关的这个证书了。

再来个图总结下：

image

兢兢业业的好伙伴❤️（SSL/TLS）

以上说的所有的工作都是HTTPS里面的S帮我们做的，也就是SSL/TLS协议。

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。

这个过程其实就是在传统的传输层——HTTP层，拿到数据后交给SSL层，然后进行认证、加密等操作。

而TLS是SSL的升级版，主要目标是使SSL更安全，并使协议的规范更精确和完善。

今天要说的就这么多了。

其实只说了HTTPS连接过程中的一个步骤，即数字证书的发送。

完整的连接过程下周再说吧，来不起了哈哈。下周会出一个网络问题全解的文章，期待一下～

参考

https://wetest.qq.com/lab/view/110.html
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
https://www.zhihu.com/question/52790301

拜拜

感谢大家的阅读，有一起学习的小伙伴可以关注下我的公众号——码上积木❤️❤️
每日一个知识点，积少成多，建立知识体系架构。
这里有一群很好的Android小伙伴，欢迎大家加入～