前置知识
对称加密与非对称加密

信息

超文本传输安全协议（英语：HyperText Transfer Protocol Secure，缩写：HTTPS)

HTTPS 并非是应用层的一种新协议。 只是 HTTP 通信接口部分用SSL（Secure Socket Layer） 和 TLS（Transport Layer Security） 协议代替而已

作用

HTTP的不安全性

Http是明文传输的，由于这个原因，可能出现的风险非常多
主要可以分为 窃听风险、篡改风险、冒充风险

安全通信的四大原则

• 机密性：即对数据加密，解决了窃听风险
• 完整性：指数据在传输过程中没有被篡改，不多不少，保持原样，中途如果哪怕改了一个标点符号，接收方也能识别出来，从来判定接收报文不合法
• 身份认证：确认对方的真实身份，解决了冒充风险，用户不用担心访问的是某宝结果却在和钓鱼网站通信的问题
• 不可否认: 即不可否认已发生的行为，比如小明向小红借了 1000 元，但没打借条，或者打了借条但没有签名，就会造成小红的资金损失

HTTPS的作用

为了让传输过程中的数据更加安全，需要对传输的信息进行加密
为了通信双方能正确 解密对方加密的数据，通信的双方必须约定加密算法
SSL/TLS主要负责事情：让双方 安全地 约定加密算法

加密策略
为了兼顾速度与安全性。通常采用的策略：
对称加密算法加密数据，非对称加密算法加密 对称加密的密钥的方式进行加密

HTTPS 的主要作用是在不安全的网络上创建一个安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的防护
维基百科

SSL与TLS

传输层安全性协议（英语：Transport Layer Security，缩写：TLS）
安全套接层（英语：Secure Sockets Layer，缩写：SSL）

TLS实际上是SSL进行标准化后得到的产物，TLS几乎可以理解为是SSL的别称
SSL已被弃用，现在使用的基本都为TLS

协议	发布时间	状态
SSL 1.0	未公布	未公布
SSL 2.0	1995年	已于2011年弃用
SSL 3.0	1996年	已于2015年弃用
TLS 1.0	1999年
TLS 1.1	2006年
TLS 1.2	2008年
TLS 1.3	2018年

基本思路

讲述升级思路

一、全数据对称加密

在认识到HTTP不安全后，双方决定对数据进行加密
情景

1. 一方决定对称加密密钥
2. 发送对称加密密钥给对方
3. 利用对称加密密钥建立通信，传输被对称加密的数据

网络上暴露的内容
这个过程，双方交换了：对称加密密钥、被对称加密的数据

结果
显然这个加密就跟没有一样，用对称加密密钥解开被对称加密的数据就能拿到明文了

二、非对称+对称加密

在认识到直接交换 对称加密密钥 不安全, 非对称加密计算速度很慢后
进行了折中的处理

情景

1. 双方都各自根据对称加密算法生成 公钥 与 私钥
2. （交换）双方交换对称加密公钥
3. 服务器使用对称加密算法对数据进行加密，得到了 被对称加密的数据 与 对称加密密钥
4. 用 客户端的非对称加密公钥 加密 对称加密密钥，得到 被客户端公钥加密的"对称加密密钥"
5. （交换）传输 被客户端公钥加密的 对称加密公钥 给客户端
6. 客户端收到服务器的数据。使用客户端私钥解开 被客户端公钥加密的 "对称加密公钥" 的加密，得到 对称加密密钥
7. 利用对称加密密钥建立通信，传输被对称加密的数据

网络上暴露的内容
服务器对称加密公钥、客户端对称加密公钥、被客户端公钥加密的 对称加密公钥

结果
中间人攻击的可能

三、数字证书，数字签名

现实生活中，员工入职时，企业一般会要求提供学历证明。这个学历必须由第三方权威机构（Certificate Authority，简称 CA）即教育部颁发

服务端 也可以向 CA 申请证书，在证书中附上公钥，然后将证书传给 客户端

证书基本的信息

证书由站点管理者向 CA 申请，申请的时候会提交 DNS 主机名等信息，CA 会根据这些信息生成证书

数字签名

本质：被CA私钥加密过的证书主要内容的摘要信息
作用：验证证书的真实性，防止证书被篡改

数字证书（含数字签名）的生成过程

1. 服务端 向CA发出申请，提交自己服务器的信息，交钱，请求生成证书
2. CA根据服务端提供的信息，生成证书的主要内容
3. 将证书的主要内容整合，用摘要算法计算出 证书摘要值
4. 用CA私钥对 证书摘要值 进行加密，得到 被CA私钥加密的 CA计算的证书摘要值 即 数字签名
5. CA将数字签名写入证书之中
6. CA返回 数字证书 给服务端

数字证书的使用

1. 在客户端，服务端交换密钥时，服务端返回 数字证书 给客户端，而不是单纯的服务器公钥
2. 客户端收到 数字证书。使用操作系统自带的 CA公钥 对 被CA私钥加密的 证书摘要值进行解密，得到 CA计算的证书摘要值
3. 客户端根据证书内容计算摘要 得到 客户端计算的证书摘要值
4. 客户端使用 客户端计算的证书摘要值 与 CA计算的证书摘要值进行对比。如果摘要值一致，说明内容未被篡改

其中第2、3、4步被称为验签

为何只是对摘要进行加密？
非对称加密算法效率低下，速度过慢

客户端操作系统自带CA公钥？
如果CA公钥通过网络传输，那么依然存在被攻击的可能，情况与前面说明的中间人攻击类似
为了解决这个套娃问题，CA公司 与 操作系统公司 达成了PY交易，使它们的证书内置在了操作系统里面

那么抓包工具如何工作
在用 charles 抓 HTTPS 的包之前我们先要安装 charles 的证书
这个证书里有 charles 的公钥，这样的话 charles 就可以将 server 传给 client 的证书调包成自己的证书
client 拿到后就可以用你安装的 charles 证书来验签等，验证通过之后就会用 charles 证书中的公钥来加密对称密钥了

证书信任链

全世界的顶级 CA（Root CA） 就只有那几个。但它可以向下一级CA，下下级 CA 授权。所以一个 一级/二级/三级 CA 也是可以申请证书的

怎么证明这些 下级CA证书被 Root CA 授权过了?
下一级 CA 可以让上一级 CA 来签名认证，比如一级 CA 让 Root CA 来签名认证，二级 CA 让一级 CA 来签名认证

Root CA 没有人给他签名认证，只能自己证明自己了，这个证书就叫「自签名证书」或者「根证书」，我们必须信任它，不然证书信任链是走不下去的

「根证书」就是那些内置在操作系统中的证书

客户端认证
如果站点申请的是二级 CA 颁发的证书，服务端 传了传给二级 CA 的证书外，还会把证书信任链也一起传给客户端
这样客户端会逐级验签进行验证：

1. 浏览器使用信任的根证书（根公钥）解析证书链的根证书得到一级 证书的公钥 + 摘要验签
2. 拿一级证书的公钥解密一级证书，拿到二级证书的公钥和摘要验签
3. 拿二级证书的公钥解密 服务端 传过来的二级证书
   ……
   直到得到服务器的公钥和摘要验签，验证过程就结束了

SSL流程-四次握手

一次握手

1. 客户端通过发送 Client Hello 报文 开始 SSL通信

报文中包含客户端支持的 SSL版本、 加密组件（CipherSuite） 列表（客户端支持的加密算法 及 密钥长度等）

维基百科-加密组件-CipherSuite：链接

二次握手

2. 服务器可进行 SSL通信 时，会以 Server Hello 报文 作为应答

和客户端一样, 在报文中包含 SSL版本 以及 加密组件
服务器的加密组件内容 是 从接收到的客户端加密组件内 筛选出来的

• 因为是要进行通信的，所以加密组件必须是双方都有的
• 服务器也可以根据客户端的加密组件拒绝相应

3. 之后服务器发送 Certificate 报文

报文中包含公开密钥证书

4. 最后服务器发送 Server Hello Done 报文 通知客户端

至此，最初阶段的 SSL握手协商部分结束

三次握手

5. 客户端以 Client Key Exchange 报文作为回应

报文中包含通信加密中使用的一种被称为 Pre-mastersecret 的随机密码串
该报文已用步骤 3 中的公开密钥进行加密

6. 接着客户端继续发送 Change Cipher Spec 报文

该报文会提示服务器，在此报文之后的通信会采用Pre-master secret 密钥加密

7. 客户端发送 Finished 报文

该报文包含连接至今全部报文的整体校验值
这次握手协商是否能够成功， 要以服务器是否能够正确解密该报文作为判定标准

四次握手

8. 服务器同样发送 Change Cipher Spec 报文

9. 服务器同样发送 Finished 报文

总的来说，SSL会话的建立完成了以下几个工作：
交换协议版本号，选择一个通信双方都支持的加密方式；对两端实现身份验证；密钥交换
服务器和客户端的 Finished 报文交换完毕之后， SSL连接就算建立完成，通信会受到 SSL的保护。 从此处开始进行应用层协议的通信， 即发送 HTTP 请求

其它

可否修改443端口

Https传输数据，需要服务器开启两个端口80与443
其中，443端口仅用来建立连接，并不传输真正的数据

443端口是约定的Https端口，被写入到了浏览器中
浏览器在域名中识别到https，就默认请求443

如果你修改了https端口，又没有特别指定访问端口。那么用户会无法用浏览器访问（浏览器访问443发现无响应）

HTTPS的缺点

• 变慢
  • 网络
    和使用 HTTP 相比， 网络负载可能会变慢 2 到 100 倍。进行 SSL通信 使得整体上处理通信量不可避免会增加
  • 处理速度
    加密/解密 要大量消耗CPU 及内存等资源，导致处理速度变慢
• 证书购买花销
  证书并不是免费的，是需要向 认证机构（CA） 购买的