简单聊聊Https的来龙去脉

---

Http 通信具有哪些风险

• 使用明文通信，通信内容可能会被监听
• 不验证通信双方身份，因此可能会遭遇伪装
• 无法验证报文完整性，可能会遭到中间人攻击，从而篡改请求和响应报文中的内容

---

Https = Http + SSL/TLS

Http 协议直接和TCP进行通信，而 Https 在 Http 和 Tcp 之间加了一层 SSL 实现加密传输 :

SSL ( Secure Socket Layer ) 安全套接层 是一种密码通信框架，于1995年发布了3.0版本，而TLS(Transport Layer Security)传输层安全是在SSL 3.0基础上设计的协议，对SSL的安全性进行增强，相当于SSL的后续版本。

SSL是一个独立的协议，不只有Http可以使用，其他应用层协议如果需要加密支持都可以使用，比如FTP，SMTP等都可以使用SSL来加密。

---

对称加密 和 非对称加密

常用的加密算法分为两类:

• 对称加密
• 非对称加密

对称加密: 加密和解密使用同一把秘钥，服务器和客户端在通信初始阶段需要协商秘钥，该阶段存在窃听导致秘钥泄露的风险。

对称加密: 客户端和服务端均拥有一个公钥和私钥，公钥可以对外暴露，而私钥只有自己可见；使用公钥加密的信息，只有对应的私钥才能破解，反过来，使用私钥加密的消息，只有公钥才能解开。

对称加密可能存在公钥被拦截，然后被替换为中间人公钥的场景:

或者中间人不替换公钥，但是通过拦截客户端发送的消息，然后篡改，使用服务器公钥加密后再发送，此时服务器将收到错误的消息

非对称加密另一个缺点就是会比对称加密慢上很多。

---

数字证书

为了解决非对称加密过程中公钥传递的不安全性，人们想到了使用数字证书加上数字签名来解决这个问题。

数字证书的申请

在现实生活中，有一些专门的权威机构用来颁发证书，我们称之为认证中心 CA ，我们的服务器可以向这些CA来申请数字证书，申请流程大致如下:

1. 服务器自己本地先生成一对秘钥，然后拿着自己的公钥以及其他信息(企业名称等)去CA申请数字证书。
2. CA拿到这些信息后，会选择一种单向Hash算法(比如MD5)对这些信息进行加密，加密后的东西我们称之为摘要

• 单向Hash算法有一种特点就是不可逆，只要原始内容有一点变化，加密后的结果都是不一样的(当然也存在很小的概率会发生重复 – 鸽巢原理)，这样可以防止信息被篡改。
• 比如用于检验IP报文是否完整的校验和，文件上传与下载对于的文件校验和，原理都是一样的

3. 生成摘要后，CA还会用自己的私钥对摘要进行加密，摘要加密后的结果我们称之为数字签名
4. 最后，CA 会将我们申请的信息(包含服务器公钥)和数字签名整合在一起，由此生成数字证书
5. 然后CA把数字证书返回给服务器

---

数字证书怎么起作用

服务器在获取到数字证书后，服务器会将数字证书发送给客户端，客户端需要用CA的公钥解密数字证书并检验数字证书的合法性，所以，首要问题是如何拿到CA的公钥 ？

我们的电脑和浏览器已经内置了一部分权威机构的根证书，这些根证书包含了CA的公钥：

之所以是根证书，是因为现实生活中，认证中心也是分层级的，类似一个树状结构，虽然计算机中内置的是最顶级机构的根证书，但是根证书的公钥在子级也是适用的。

1. 客户端用CA的公钥解密数字证书，如果解密成功说明证书来源于合法认证机构，解密成功后，客户端就可以拿到摘要。
2. 然后，客户端按照和CA一样的Hash算法将申请信息(公钥，服务器域名，. . . ) 生成一份摘要，并和解密出来的那份做对比，如果相同说明内容完整，没有被篡改。
3. 最后，客户端安全的从认证中心拿到服务器的公钥
4. 随后就可以使用公钥和服务器进行安全的非对称加密通信了

---

Https工作流程

Https = Http + SSL/TLS , 说白了，无非就是在http上披了一层加密的外壳，Https的整个通信流程如下图所示:

1. 客户端通过发送Client Hello报文开始通信，报文中包含客户端支持的SSL的指定版本，加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)
2. 服务器可进行SSL通信时，会以Server Hello报文作为回答，和客户端一样，在报文中包含SSL版本以及加密组件，服务器加密组件内容是从接收到的客户端加密组件内容筛选出来的
3. 服务器发送证书报文，报文中包含公开秘钥证书
4. 最后，服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束
5. SSL第一次握手结束后，客户端以Client Key Exchange报文作为回应，报文包含通信加密中使用的一种被称为Pre-master secret的随机密码串，该报文已用步骤3中的公开秘钥进行加密
6. 接着客户端继续发送Change Cipher Spec报文，该报文会提示服务器，在此报文之后的通信会采用Pre-master secret秘钥进行加密
7. 客户端发送Finished报文，该报文包含连接至今全部报文的整体校验值，这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准
8. 服务器同样发送Change Cipher Spec报文
9. 服务器同样发送Finished报文
10. 服务器和客户端的Finished报文交换完毕后，SSL连接就算建立完成了
11. 从此处开始进行应用层协议的通信，即发送Http请求，此时的通信过程会受到SSL的保护
12. 最后，由客户端端口连接，断开连接时，发送close_notify报文
13. 这步之后，再发送TCP FIN报文来关闭与TCP的通信

另外，在以上流程图中，应用层发送数据时会附加一种叫做MAC（Message Authentication Code）的报文摘要。MAC能够查知报文是否遭到篡改，从而保证报文的完整性。

经过上面的介绍，我们可以看出https先是利用数字证书保证服务器端的公匙可以安全无误的到达客户端。然后再用非对称加密安全的传递共享密匙，最后用共享密匙安全的交换数据。

---

一定需要Https吗？

Https那么的安全，是不是我们在什么场景下都要去使用https进行通信呢？答案是否定的。

1. https虽然提供了消息安全传输的通道，但是每次消息的加解密十分耗时，消息系统资源。所以，除非在一些对安全性比较高的场景下，比如银行系统，购物系统中我们必须要使用https进行通信，其他一些对安全性要求不高的场景，我们其实没必要使用https。
2. 使用https需要使用到数字证书，但是一般权威机构颁发的数字证书都是收费的，而且价格也是不菲的，所以对于一些个人网站特别是学生来讲，如果对安全性要求不高，也没必要使用https。