HTTPS工作原理

一. 我眼中的HTTPS：

在HTTP和TCP的基础上加了一层安全传输协议SSL/TLS, 在以往我们进行通信时， 客服端不能对服务端身份进行校验， 也不能判断数据的安全性！HTTPS则保证了， 服务端的真实身份， 以及信息加密。

二. HTTPS是身披SSL/TLS外壳的HTTP

TLS协议由两层协议叠加而成：

1. TLS Record protocol: TLS记录协议， 主要作用是，负责使用对称加密对信息进行加密通信的部分。其次，加密协议使用的密钥来自于握手协议在服务端和客服端进行协商而出的。

2. TLS Handshaking Protocols握手协议由TLS Change Ciper Spec Protocol（密码规格变更协议）和TLS Alert Protocol（警告协议）组成。

A. 负责在客户端和服务器之间协商决定密码算法和共享密钥。

B. 密码规格变更协议负责向通信对象传达变更密码方式的信号，当协议中 途发生错误时，就会通过警告协议传达给对方。

C. 警告协议是 TLS 握手协议负责在发送错误时将错误传达给对方。 

总结： 记录协议保证了数据的完整性以及隐私性。  握手协议保证身份认证。

三. 理解HTTPS还需理解一下概念

1. 对称加密

我的理解是： 首先我们需要协商使用什么算法（AES）, 接着我们通过相同的密钥对数据进行加密即可实现：明文 + 密钥 ==> 密文   密文 + 密钥 ==> 明文。由此我们可以看出， 都使用相同的密钥，一旦密钥泄露， 那么数据相当于公开。 优点： 效率高。 改进：能不能提前把密钥加密，只能由服务端才能解密。

2. 非对称加密

是网络通信的基石， 保证了非对称加密 密钥的安全。 首先， 非对称加密需要 私钥 和 公钥， 公钥加密的数据只能由私钥解开， 而私钥加密的数据只能由公钥解开。 公钥存储在客服端， 私钥存储在服务端， 永远不对外暴漏。

流程：首先客服端请求公钥， 服务端响应公钥， 之后客服端通过公钥加密数据传输， 服务端通过私钥解密获取信息。

存在的安全隐患: 我们的公钥是直接进行传输的， 那么黑客就可以得到我们的公钥从而获取信息。

3. 非对称加密 + 对称加密

1. 客服端请求公钥 

2. 响应后， 客服端通过公钥可以加密一串随机数，作为以后信息传输对称加密的密钥， 而这串随机数也只能由服务端的私钥才能解析。

3. 服务端通过私钥解析后， 通过对称加密对数据进行加密。

问题： 假如在客服端请求公钥的时候， 就被黑客拦截， 充当了服务器， 给了黑客的公钥给客服端， 此问题产生的主要原因是： 报文可能被篡改， 客服端完全相信服务端！

4. 数字签名 解决报文被篡改

(1).  能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。

(2).  数字签名能确定消息的完整性 , 证明数据是否未被篡改过。

发送者将数据先于hash算法生成信息摘要， 然后用私钥加密生成数字签名， 一起发送给接收方。

接收方只有用发送者的公钥才能解密被加密的数据， 然后通过hash对原文参数一个摘要信息， 进行比对， 即可确认报文是否被篡改。

问题：  我们的公钥还是不安全的在网络中传输， 解决 证书

5. 证书  解决服务端身份问题

有专门的机构进行颁发， 而证书中包含了你的公钥， 同时包含数字签名

此后我们请求公钥改为请求证书， 如何保证不会得到一个假证书了！ 我们CA机构在已把证书嵌套在了浏览器以及操作系统， 所以证书都不用经过网络自然不会出现假的。

6. TLS完整的通信流程

step1. 浏览器给出TLS版本， 客服端生成随机数1， 以及客服端支持的加密方法(明文通讯) 

step2. 服务器确认双方加密算法， 并给出数字证书， 以及随机数2 (明文通讯)

step3. 浏览器确认随机数有效， 生成随机数3， 通过证书的公钥进行加密， 传递给服务端(使用非对称加密算法加密)

step4. 服务端使用私钥进行解密， 最后双方都有三个随机数， 第三个只有客服端和服务端才能知道。

step5. 根据约定的算法， 把三个随机数生成密钥， 用来加密以后的通信数据。

step6. 双方进行第一次加密一个消息发送给对方。

备注：客户端收到服务端发送的Certificate 报文后首先会校验证书的合法性：

1. 证书路径信任链逐级校验通过（证书确由可信 CA 认证签发）；

2. 签名解密成功（确系证书持有者亲笔）；

3. 从签名解析出的摘要和证书公开内容的摘要一致（证书内容完整，未被篡 改）；

4. 主题子域与 URL 中的 HOST 一致，综上确保访问的网站是来自预期目标服

务器且非劫持或钓鱼。

sesion恢复：

握手阶段用来建立 SSL 连接。如果出于某种原因，对话中断，就需要重新握手。

这时有两种方法可以恢复原来的 session ：一种叫做 session ID ，另一种叫做

session ticket 。

session ID：

指双方每一次对话都有一个编号（ session ID）， 下次重连， 只需要client给出session ID, server有记录即可完成重连。双方就可以重新使用已有的 " 对话密钥 " ，而不必重新生成一把。

存在问题： 往往只保留在一台服务器上面。

        

session ticket：

指在客服端存储上次会话发送过来的session ticket， 它加密的只能由服务端进行解密， 其中包括了本次会话信息以及对话密钥以及加密方法。 这样服务端解密后就不必生成新的密钥。