海绵宝宝也懂的HTTPS

面试官：有了解过HTTPS吗？说一下他的原理吧
复制代码

引言

https是创建在SSL(Secure Sockets Layer 安全套接层)上的网络安全协议，最初由NetScape公司提出，以后由IETF标准化为TLS(Transport Layer Security 安全传输层协议），其端口为443。

本文全长1900字左右，全文阅读大概须要10分钟，以后你将收获：

• HTTPS的加密过程
• 数字证书和数字签名的具体做用
• HTTPS的握手过程

正文

HTTP的困境

当咱们学习HTTP的时候，确定使用过抓包工具(wireshark， fiddler）帮助咱们认识HTTP协议。回忆一下就知道，抓包工具不管是get请求仍是post请求都能准确截取其中传输内容，若是想要隐藏传输内容，就必须进行密文传输，就像战争年代的电报密码，即便被截取也不能破解其中的内容。

加密方式

让咱们设想这样一个情景：海绵宝宝想和蟹老板秘密协商新的蟹黄堡配方，若是让你来设计加密过程，你有几种方法呢？
1.海绵宝宝和蟹老板约定一个密钥，传输和解读都经过这个密钥解密，这个密钥称为公钥。

双方使用相同密钥进行加密通信

2.当心谨慎的蟹老板有一个只有本身知道的密钥(称为私钥)和公钥，他把公钥发给海绵宝宝，海绵宝宝能够经过公钥解密私钥加密的消息，可是公钥加密的消息只有私钥能解开，这在必定程度上作到了单向安全。

这即是HTTPS中用到的两种加密方式，前者称为 对称加密，通信双方持有相同的密钥。后者称为 非对称加密。

协商

那么HTTPS中用的哪一种加密方式呢？
若是采用对称加密，那么蟹老板和全部人都拥有同一个密钥，这无异于没有加密！！！

因此蟹老板须要和每一个人 协商一个密钥，每一个人互不相同，这样就能保证加密了。

在HTTPS中，这个协商的过程通常是用非对称加密来进行的。客户端一旦获得了真的服务器公钥，往服务端传消息就是安全的。由于只有服务端的私钥才能解密公钥加密的数据。
可是，客户端可没那么容易获得真正的公钥，由于发送公钥的过程存在被别人调包的可能性，这就是传说中的中间人攻击。

中间人攻击

让咱们回到情景中。
痞老板听闻消息，企图在协商过程经过中间人的方式截取蟹黄包配方。

如图，蟹老板想告诉海绵宝宝本身的公钥，此时痞老板出现，替换了蟹老板的公钥，海绵宝宝收到一个来自痞老板的公钥并觉得是蟹老板的，由此在以后的传输中痞老板即可以轻松的浏览蟹老板和海绵宝宝的全部沟通内容了。 为了防止痞老板窃听，那这个协商的过程也必须加密，这样下去协商加密也要加密，……问题没有穷尽。那怎么办呢？

HTTPS数字证书

如今美人鱼战士和企鹅男孩登场了，他们保证做为一个权威中间机构为你们提供认证服务，负责为你们发放统一的公钥。

蟹老板先将本身要传输的公钥给美人鱼战士，美人鱼战士用本身的私钥加密后返回给蟹老板。这样你们只要能经过这个公钥解密蟹老板发来的密文，提取蟹老板的公钥，就能保证这个公钥不是来自痞老板。 这个时候即使痞老板想替换公钥，伪造的公钥也不能用美人鱼战士的公钥解开了。
这就是 数字证书。服务器经过CA认证获得证书，这个证书包含CA的私钥加密后的服务器公钥，客户端用预先存储在本地的CA公钥便可解密获得服务器的公钥，从而避免公钥被替换。

HTTPS数字签名

若是你是痞老板，你有什么方法能够再次窃取消息呢？
显然不能经过简单替换公钥来窃取了，海绵宝宝只能解开美人鱼战士颁发的证书，那我也去申请一个证书，直接替换整个证书不就能够从而替换掉公钥了吗？

企鹅男孩发现了这个问题，他决定在证书里面添加一些额外的信息以供验证。如今企鹅男孩颁发的证书格式以下：

来自：蟹堡王
加密算法：MD5
公钥：xxxx（已经过私钥加密，可经过公钥解密）
复制代码

海绵宝宝只要经过企鹅男孩的公钥提取到“蟹堡王”+“MD5” 计算出一个公钥，与证书内的公钥进行对比，就能够验证证书是否通过替换，以下图。

带有签名的证书

对比发现证书被替换

虽然痞老板依旧能够截取证书，可是他却不能替换其中任何的信息，以下：

来自：痞老板工厂
加密算法：MD5
公钥：djawdn888
复制代码

此时海绵宝宝能够发现来自不是蟹堡王而拒绝信任，而且

痞老板工厂 + MD5 !== djawdn888
复制代码

如今假设蟹堡王+ MD4 = aaaa，那只要修改公钥为aaaa不就能够经过海绵宝宝的验证了吗？痞老板的证书修改以下：

来自：蟹堡王
加密算法：MD4
公钥：aaaa
复制代码

实际上并不能，尽管能够修改公钥，可是前面提到，公钥通过企鹅男孩的私钥加密，如今海绵宝宝发现用企鹅男孩的公钥打不开了！因而发现证书已经被篡改了，从而结束通信。 这即是数字签名的意义。

小结

综上，用一句话总结https：在https协议下，服务器与客户端经过非对称加密的方式协商出一个对称加密的密钥完成加密过程。其中数字证书的做用是避免公钥被替换，而数字签名的做用是校验公钥的合法性。

HTTPS的握手过程

明白了HTTPS的原理，握手过程就十分简单，总结以下：
1.客户端：发送random1 + 支持的加密算法 + SSL Version等信息
2.服务端：发送random2 + 选择的加密算法A + 证书
3.客户端：验证证书 + 公钥加密的random3
4.服务端：解密random3，此时两端共有random1，random2，random3，使用这3个随机数经过加密算法计算对称密钥便可。
以上只有random3是加密的，因此用random1 + 2 + 3 这3个随机数加密生成密钥。

反思和总结

HTTPS优点：密文，安全性
HTTPS劣势：协商过程低效，影响用户访问速度

Q&A

1.客户端的公钥从哪里来的？
权威机构的公钥是由操做系统和浏览器共同维护，预先存储在本地的。
2.握手过程为何要用3个随机数？
一方面，https的握手过程当中出现的3个随机数，只有第三个是加密的随机数。另外一方面，因为不少主机可能产生弱随机数，所以3个叠加使用更接近随机，比较安全。

参考

• 也许，这样理解HTTPS更容易，2017/2/20 翟志军
• 数字签名是什么？ 2011/8/9 阮一峰
• SSL/TLS 握手过程详解 2016/12/04 hi_xgb
• 《深刻浅出nodejs》 P170 朴灵