谈谈HTTPS演变过程

前言

本文谈谈HTTPS设计演变过程，但愿对你们理解HTTPS有帮助，有不对的地方欢迎指出。

密码学基础知识

在讨论HTTPS以前，须要掌握一些密码学基础概念。

明文、密文、密钥

明文： 指没有通过加密的信息/数据。

密文： 明文被某种加密算法加密以后，会变成密文，从而确保原始数据的安全。密文也能够被解密，获得原始的明文。

密钥： 是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥。

对称加密

定义： 须要对加密和解密使用相同密钥的加密算法。因为其速度快，对称性加密一般在消息发送方须要加密大量数据时使用。对称性加密也称为密钥加密。

经常使用的对称加密算法： DES、3DES、TDEA、Blowfish、RC二、RC四、RC五、IDEA、SKIPJACK等。

加密过程： 明文 + 加密算法 + 私钥 => 密文

解密过程： 密文 + 解密算法 + 私钥 => 明文

因为对称加密的算法是公开的，因此一旦私钥被泄露，那么密文就很容易被破解，因此对称加密的缺点是密钥安全管理困难。

非对称加密

定义

1. 非对称加密算法须要两个密钥：公开密钥和私有密钥。公开密钥与私有密钥是一对，若是用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；若是用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。
2. 公钥指的是公共的密钥，任何人均可以得到该密钥。私钥被本身保存，不能对外泄露。
3. 由于加密和解密使用的是两个不一样的密钥，因此这种算法叫做非对称加密算法。

经常使用非对称加密算法： RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）等。

被公钥加密过的密文只能被私钥解密，过程以下：

明文 + 加密算法 + 公钥 => 密文， 密文 + 解密算法 + 私钥 => 明文

被私钥加密过的密文只能被公钥解密，过程以下：

明文 + 加密算法 + 私钥 => 密文， 密文 + 解密算法 + 公钥 => 明文

HTTP明文传输

HTTPS发展源头是HTTP（超文本传输协议），因此咱们先来看看HTTP传输，以下：

流程

客户端，把一条消息，以明文的方式，发送到服务器。

那么在网络上赤裸裸的明文传输会有什么问题呢？

问题

请君试想，若是HTTP请求被某个不怀好意的中间人截取，而且，消息包含银行密码等敏感信息的话，形成的后果不堪设想吧。

解决方案

既然明文传输会有问题，那么，咱们能够用加密算法加密嘛。

对称算法加密+HTTP

接下来，看看用对称算法加密后，是怎样的，如图：

流程

• 客户端把要发送的消息，用密钥加密成密文。
• 客户端把密文发送到服务器。
• 服务器收到密文消息，用同一把密钥把密文解密成明文。

问题

这种方式仍是有问题，一开始客户端怎么把密钥发过去呢？若是不怀好意的中间人截取到了密钥，发送的消息仍是会被盗取和利用呢。

解决方案

能够考虑非对称加密试试。

非对称加密+HTTP

OK,咱们再来看看，使用非对称加密算法，又是怎样，如图：

流程

• 客户端向服务器发起HTTPS请求，链接到服务器的443端口。
• 服务端将本身的公钥返回到客户端。
• 客户端使用返回的公钥，给要发送的消息加密。
• 客户端将加密以后的消息密文发送给服务器。
• 服务器接收到客户端发来的密文以后，会用本身的私钥对其进行非对称解密，解密以后获得消息数据。

问题

纵观整个过程，感受没啥问题，即便中间人截取了公钥，也没啥用，他没有私钥解密不了。可是，非对称算法（如：RSA）有个弊端，它很慢。试想一下，若是你用浏览器请求，它好久才响应，你能接受吗？

解决方案

由于对称加密快，可是它安全性不高，非对称加密安全性高，可是它慢，那么，能够考虑非对称加密+对称加密结合一块儿嘛。

非对称加密+对称加密+HTTP

非对称加密+对称加密双剑合璧的流程图以下：

流程

• 客户端向服务器发起HTTPS请求，链接到服务器的443端口。
• 服务端将本身的公钥返回到客户端。
• 客户端产生对称加密密钥，并用服务端返回的公钥对它加密
• 客户端会发起HTTPS中的第二个HTTP请求，将加密以后的客户端密钥发送给服务器。
• 服务器接收到客户端发来的密文以后，会用本身的私钥对其进行非对称解密，解密以后获得客户端密钥，而后用客户端密钥对返回数据进行对称加密，这样数据就变成了密文。
• 服务器将加密后的密文返回给客户端。
• 客户端收到服务器发返回的密文，用本身的密钥（客户端密钥）对其进行对称解密，获得服务器返回的数据。

问题

这个流程看来，彷佛已经完美无缺了呢？可是，若是中间人又来搞事情呢？要是中间人截取公钥，把公钥进行篡改呢? 打个比喻，把公钥比喻你本身的手机号，它是公开的，谁均可以给你打电话。假设你发消息给你朋友，告诉他你的手机号，而后消息被中间人截取修改了，改成110，而后你朋友不知情的状况下，拨通110，打电话给你。。。

解决方案

为了不公钥被篡改，须要引入数字签名，相似给你的公钥盖个章，证实身份用。

数字证书登场

为了不公钥被篡改，引入了数字证书，如图所下：

数字证书构成

• 公钥和我的信息，通过Hash算法加密，造成消息摘要；将消息摘要拿到拥有公信力的认证中心（CA），用它的私钥对消息摘要加密，造成数字签名.
• 公钥和我的信息、数字签名共同构成数字证书。

数字证书验证

• 拿到数字证书以后，用一样的Hash算法， 先再次生成消息摘要；
• 而后用CA的公钥对数字签名解密， 获得CA建立的消息摘要， 二者对比，就知道有没有人篡改了。

完整的HTTPS运行流程图

介绍完数字证书，完整的HTTPS流程千呼万唤始出来了，如图：

1. 用户在浏览器里输入一个https网址，而后链接到server的443端口。
2. 服务器必需要有一套数字证书，能够本身制做，也能够向组织申请，区别就是本身颁发的证书须要客户端验证经过。这套证书其实就是一对公钥和私钥。
3. 服务器将本身的数字证书（含有公钥）发送给客户端。
4. 客户端收到服务器端的数字证书以后，会对其进行检查，若是不经过，则弹出警告框。若是证书没问题，则生成一个密钥（对称加密），用证书的公钥对它加密。
5. 客户端会发起HTTPS中的第二个HTTP请求，将加密以后的客户端密钥发送给服务器。
6. 服务器接收到客户端发来的密文以后，会用本身的私钥对其进行非对称解密，解密以后获得客户端密钥，而后用客户端密钥对返回数据进行对称加密，这样数据就变成了密文。
7. 服务器将加密后的密文返回给客户端。
8. 客户端收到服务器发返回的密文，用本身的密钥（客户端密钥）对其进行对称解密，获得服务器返回的数据。

总结

1. 对称加密 效率高，因此最终目的是要使用对称加密进行客户端与服务端的通讯。 但客户端如何告诉服务端要共同使用的密钥，而不被第三方获取
2. 因此引入了非对称加密，客户端先与服务端创建链接，而后服务端保留本身的私钥，把公钥返回给客户端。 但客户端接收公钥的过程当中，第三方也能够截取公钥，甚至对公钥进行篡改
3. 因此引入了数字证书，起初服务端在返回给客户端公钥的时候，附带了数字证书。数字证书是使用非对称加密，切私钥永远只保存在CA，且数字证书的造成是可逆的。
4. 因此客户端在对比服务端的公钥没问题后，使用服务端的公钥非对称加密 对将要使用的 对称加密密钥 加密后，发送给服务端，而后服务端私钥解密。
5. 至此客户端、服务端仅彼此得到了对称加密的密钥，达成了高效安全传输数据的目的。

参考与感谢

• Https原理及流程
• 谈谈 HTTPS
• 图解HTTPS
• 一个故事讲完https

我的公众号

• 若是你是个爱学习的好孩子，能够关注我公众号，一块儿学习讨论。
• 若是你以为本文有哪些不正确的地方，能够评论，也能够关注我公众号，私聊我，你们一块儿学习进步哈。