HTTPS详解

HTTPS

协议概念

​ HTTP 协议（HyperText Transfer Protocol，超文本传输协议）是客户端浏览器或其他程序与Web服务器之间的 应用层 通信协议

​ HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer），可以理解为 HTTP + SSL/TLS， 即在 HTTP 层的基础上加入 SSL 层，从而来实现身份验证、信息加密、完整性校验等安全性。HTTPS 不同于 HTTP 的默认端口（443端口）及一个加密/身份验证层（在 HTTP与TCP之间）

TLS/SSL

SSL（Secure Socket Layer，安全套接字层），SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持

TLS（Transport Layer Security，传输层安全），其前身是 SSL

HTTP向HTTPS演化的过程

1.对称加密

客户端和服务端使用相同的秘钥对数据进行加密传输，即使黑客拦截也无法解析数据

但是这种方式的缺点：

1. 一对客户端和服务端就需要维护一个秘钥，那么多个客户端和服务端时，双方都需要维护大量的密钥，维护的成本很高
2. 客户端和服务端的安全级别不一样，容易泄露秘钥

2.非对称加密

​ 非对称加密，服务端有一对公钥和私钥。公钥公开给所有客户端获取

​ 客户端使用公钥加密数据后发送给服务端，服务端使用私钥进行解密，如果其他人截获这个数据，没有私钥是无法进行解密的。服务端与客户端进行通信，则通过私钥进行数据加密，客户端使用公钥进行解密获取数据

​ 这种方式也存在问题：因为公钥是公开的，所以所有人都能获取到该公钥，服务端给客户端发送的数据如果被黑客拦截到，那么就可以使用公钥进行解密了，这就是中间人攻击

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

使用对称加密和非对称加密的结合：

1. 客户端先获取服务端公钥
2. 客户端将之后通信用的对称加密秘钥 KEY 使用该公钥进行加密，然后发送给服务端
3. 服务端使用私钥解密该数据，获取秘钥 KEY
4. 以后服务端和客户端的通信就使用该秘钥KEY进行对称加密传输数据

但是这样也会遭到中间人攻击

中间人攻击

中间人攻击过程为：

1. 黑客端会伪造成中间人端，拦截客户端的请求，将黑客端的公钥 BPK 发给客户端
2. 黑客端正常向服务端请求公钥 PK
3. 客户端将对称加密秘钥 KEY 使用 BPK 进行加密后发给黑客端，黑客端使用私钥 BSK 解密获得对称加密秘钥。然后使用服务端返回的公钥PK进行加密
4. 也就是正常代理服务端和客户端的数据交互，但是两端进行加密用的对称秘钥已经被黑客端拦截获取了。已经是不安全了

CA证书

概述

​ 在网络上，只要是客户端和服务端在交互，那就有可能被挟持。而客户端是需要确切地知道服务端是不是真实的，所以就需要CA（公信机构）来帮客户端认定服务端是真实的

使用CA证书的流程

1. 服务端在使用 HTTPS 之前，需要去认证的CA机构申请一份 数字证书

   • 数字证书里包含有证书持有者、证书有效期、服务器公钥等信息

2. CA 机构也有自己的一份公私钥，在发布数字证书之前，会 用自己的私钥对这份数字证书进行加密，发送给服务端

3. 当客户端请求服务器的时候，服务端返回该证书给客户端。客户端用 CA 机构的公钥对证书解密

   • 因为 CA 是工信机构，所以会内置到浏览器或操作系统中

4. 这个时候，客户端会判断这个证书是否可信/有无被篡改

   • 证书被 CA 机构的私钥加密，然后客户端用 CA 证书的公钥解密

5. 客户端发现证书是可信，然后解密出服务器的公钥

6. 客户端生成一个对称加密的随机Key，并用证书内的服务器公钥进行加密，发送给服务端

   • 证书中包含了服务器公钥的信息

7. 服务端收到消息，用自己的私钥进行解密，拿到客户端随机生成的Key

8. 之后服务端和客户端的数据交互就会使用这个 Key 进行对称加密传输数据

工作流程

1. 用户在浏览器发起HTTPS请求（如 http://daiadrian.top/），默认使用服务端的443端口进行连接

2. HTTPS需要使用一套CA数字证书

   • 证书内会附带一个公钥Pub
   • 与公钥对应的私钥Private，保留在服务端不公开

3. 服务端收到请求，返回配置好的包含公钥Pub的证书给客户端

4. 客户端收到证书，校验合法性

   • 主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书）
   • 如果合法性检验不通过，则显示HTTPS警告信息，如果通过则继续

5. 客户端生成一个用于对称加密的随机Key，并用证书内的公钥Pub进行加密，发送给服务端

6. 服务端收到随机Key的密文，使用与公钥Pub配对的私钥Private进行解密，得到客户端真正想发送的随机Key

7. 服务端使用客户端发送过来的随机Key对要传输的HTTP数据进行对称加密，将密文返回客户端

8. 客户端使用随机Key对称解密密文，得到HTTP数据明文

9. 后续HTTPS请求使用之前交换好的随机Key作为对称加解密的秘钥

SSL/TLS协议

基本流程

SSL/TLS 协议基本流程：

1. 客户端向服务器索要并验证服务器的公钥

2. 双方协商生产「会话秘钥」

3. 双方采用「会话秘钥」进行加密通信

详细握手流程

SSL/TLS 的「握手阶段」涉及 四次通信，建立的详细流程如下：

1. ClientHello

   • 首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求
   • 在这一步，客户端主要向服务器发送以下信息：
     1. 客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本
     2. 客户端生产的随机数（Client Random），后面用于生产「会话秘钥」
     3. 客户端支持的密码套件列表，如 RSA 加密算法

2. SeverHello，服务端ACK

   • 服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello
   • 服务器回应的内容有如下内容：
     1. 确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信
     2. 服务器生产的随机数（Server Random），后面用于生产「会话秘钥」
     3. 确认的密码套件列表，如 RSA 加密算法
     4. 服务器的数字证书

3. 客户端回应

   • 客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，校验服务器的数字证书的真实性
   • 如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
     1. 一个随机数（pre-master key）。该随机数会被服务器 CA 公钥加密
        • 这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」
     2. 随后的信息都将用「会话秘钥」加密通信
     3. 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验

4. 服务器的最后回应

   • 服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」
   • 然后向客户端发生最后的信息：
     1. 随后的信息都将用「会话秘钥」加密通信
     2. 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验

​ 至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容
务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」

• 然后向客户端发生最后的信息：
  1. 随后的信息都将用「会话秘钥」加密通信
  2. 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验

​ 至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容