http到https
背景
http通过tcp/ip协议建立连接。但是我们都知道tcp协议只保证可靠传输，并不保证加密。于是普通的http可能面临以下问题：
- 明文传输被读取：传输保密内容被其他人直到
- 传输内容被篡改：转账100元被篡改为转正50元
- 无法确认对方是不是真实的服务器：被劫持到了攻击者的网站
HTTPS是什么
针对安全问题，诞生https，本质是HTTP 数据通过 TLS 加密后再传输。 与http对比：
| 对比 | HTTP | HTTPS |
|---|---|---|
| 是否加密 | 否 | 是 |
| 默认端口 | 80 | 443 |
| 是否防窃听 | 否 | 是 |
| 是否防篡改 | 基本没有 | 是 |
| 是否验证服务器身份 | 不验证 | 通常验证 |
| 性能 | 简单一些 | 有握手和加密开销 |
| 网址 | http:// | https:// |
加密需要解决什么问题
1. 机密性
别人看不懂内容。
明文：password=123456密文：a8F#2kL...2. 完整性
别人不能悄悄修改内容。 如果内容被修改，接收方能发现。
3. 身份认证
你确认通信对象是真正的服务器，而不是冒牌服务器。
对称加密和非对称加密
非对称加密负责“交换钥匙”，对称加密负责“搬运货物”。
对称加密
接收方和发送方使用同一把钥匙。
明文 + 密钥 → 密文密文 + 同一把密钥 → 明文常见的对称加密算法：
- AES
- ChaCha20
对称加密存在的问题： 一开始双方并不知道需要用什么算法和秘钥进行加密和解密。所以需要先通信一次，共享秘钥。
这时候秘钥存在被偷走的风险。于是引入非对称加密
非对称加密
非对称加密使用一对公钥和私钥
- 公钥：公开的
- 私钥：必须报名，服务器持有
加密和签名
加密
发送方使用公钥加密并向服务器发送内容，服务器使用私钥进行解密。 这样只有持有私钥的服务器能解开这份内容。
签名
服务器使用私钥进行签名，浏览器使用公钥对签名进行验证，验证通过才能说明，这份内容是来自服务器，是安全的。
数字签名可以证明：
- 内容确实来自私钥持有者
- 内容没有被修改
注意：
“公钥加密、私钥解密”主要用于保密
“私钥签名、公钥验证”主要用于身份和完整性
非对称加密算法之一：RSA
它的安全性主要来自一个数学难题：两个很大的质数相乘很容易，但你只拿到乘积以后，想把它分解回那两个质数非常难，所以在合理的密钥长度下，暴力破解成本极高。从公钥反推出私钥非常困难.
在使用上，一般是：公钥负责加密、私钥负责解密；另外 RSA 也常用来做数字签名：我用私钥对摘要做签名，别人用公钥就能验证签名，确认“确实是我发的而且没被改”。
工程里像 HTTPS 这种场景，RSA 通常不会拿来全程加密业务数据，因为它太慢，更多是用在证书/身份认证，以及的密钥交换；真正大量传输还是用 AES/ChaCha20 这种对称加密。
RSA秘钥交换：
- 服务器把包含公钥的证书发送给浏览器
- 浏览器验证证书，确认公钥确实属于目标服务器
- 浏览器生成一个随机的预主密钥可以理解为“本次通信的种子密码”
- 浏览器使用服务器公钥加密这个预主密钥
- 浏览器把加密后的预主密钥发送给服务器注意：发送的是密文，不是明文随机数
- 服务器使用自己的私钥解密，得到预主密钥
- 浏览器和服务器根据预主密钥、双方随机数，共同计算出实际的会话密钥
- 后续 HTTP 数据使用会话密钥进行对称加密传输
HTTPS 针对三个问题的解决办法
1. 明文传输被读取
HTTPS 在 TLS 握手阶段，先通过非对称密码算法协商出一个临时的会话密钥。
正式传输 HTTP 数据时，使用速度更快的对称加密算法，例如 AES-GCM 或 ChaCha20-Poly1305。
非对称密码：协商会话密钥对称加密：加密实际 HTTP 数据不用非对称加密直接加密全部内容，是因为非对称加密速度较慢。
2. 传输内容被篡改
正式传输数据时，TLS 会使用会话密钥对数据进行加密，并附带完整性校验信息。
浏览器或服务器收到数据后会进行验证：
如果数据被修改，校验失败，数据就会被拒绝。因此，实际内容的防篡改主要依靠：
对称加密 + 完整性校验服务器在 TLS 握手阶段使用私钥签名，主要是为了证明服务器身份，而不是给每一段网页内容单独签名。
3. 无法确认对方是否是真实服务器
服务器向浏览器发送由 CA 签发的数字证书。
证书中包含：
服务器域名服务器公钥证书有效期CA 的签名浏览器验证证书后，可以确认：
这个公钥确实属于目标域名随后服务器使用对应的私钥完成签名，浏览器用证书中的公钥验证签名，从而确认服务器确实拥有这把私钥。
因此，这一部分是：
证书：证明公钥属于哪个域名数字签名：证明服务器确实拥有对应私钥SSL/TSL过程
关于 HTTPS 的连接建立过程，也就是 TLS 四次握手，其实本质上就是客户端和服务端为了安全地协商出一个对称加密的密钥而进行的一系列沟通。具体过程我是这样理解的：
第一步，客户端先去‘打招呼’（Client Hello）。
客户端主动联系服务端，主要是交底，告诉服务端：‘我当前支持哪些 TLS 版本’以及‘我支持哪些加密算法’。同时，客户端会自己生成一个随机数 A，一并带过去，留作后面备用。
第二步，服务端给以回应（Server Hello 与发证书）。
服务端收到后，会从客户端提供的算法列表里，挑一个双方都能用的算法，告诉客户端：‘我们就用这个加密算法吧’。同时，服务端也会生成一个自己的随机数 B 发给客户端。
除了确认参数，服务端还需要证明自己的身份，所以它紧接着会把自己的数字证书（这里面包含了服务端的公钥）发送给客户端。
第三步，客户端验明正身，并发送‘核心机密’。
客户端拿到证书后，第一件事就是利用系统或浏览器内置的 CA 根证书，去校验这个服务端证书是不是合法的、有没有被篡改。
只要验证通过，客户端就在本地生成第三个随机数（叫做 Pre-Master Secret）。为了保证这个数字在传输时不被别人偷窥，客户端会用刚才证书里的公钥对它进行加密，然后发送给服务端。
第四步，服务端解密，双方算出最终密钥。
这段密文只有服务端手里对应的私钥才能解开。服务端解密后，也就拿到了第三个随机数。
到这里最关键的一步就完成了：现在客户端和服务端手里，都同时凑齐了随机数 A、随机数 B 和第三个随机数。双方会非常默契地使用第一步商量好的算法，把这三个随机数混合在一起，计算出一个最终的会话密钥（Master Secret）。
第五步，正式开始加密通信。
前面的握手过程为了绝对安全，利用了非对称加密和证书机制，但它太耗时了。所以一旦双方算出了这个最终的‘会话密钥’，之后所有的 HTTP 请求和响应，双方就都会切换到高效的对称加密模式，用这个最终密钥来加密业务数据了。”