面试官：有了解过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个叠加使用更接近随机，比较安全。
