目录
一.简介
1.1定义
1.2补充知识
1.2.1 对称加密与非对称加密
1.2.2. 数据摘要 && 数据指纹
二.HTTPS 的⼯作过程探究
2.1只使⽤对称加密
2.2只使用非对称加密
2.3非对称加密与对称加密
2.4中间人攻击
三.证书
3.1CA认证
3.2数据签名
3.3 ⾮对称加密 + 对称加密 + 证书认证
3.4常见问题
一.简介
1.1定义
http与tcp协议传输层中间加了一层软件层SSL/TLS，http和这层软件层合起来叫做HTTPS。由于http是明文传输的，https变引入了一个加密层。
1.2补充知识
http绑定的端口是80； https 绑定的端口是443；他们是两套服务，区别是 https 是加密的，就效率来讲http更高，但相对不安全。
加密： 加密就是把 明⽂进⾏变换, ⽣成 密⽂。
解密：解密就是把 密⽂ 再进⾏⼀系列变换，还原成 明⽂。
密钥：在这个加密和解密的过程中, 往往需要⼀个或者多个中间的数据, 辅助进⾏这个过程, 这样的数据称为 密钥
1.2.1 对称加密与非对称加密
- 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密。（例如按位异或）
- 采用公钥和私钥来进行加密和解密，用其中一个密钥进行加密就必须用另一个密钥进行解密，这种加密方法称为非对称加密。
对称加密解释：双方要进行对称加密通信，此时就要去加密方要把密钥给解密方，此时解密方才能对数据进行解密，但加密方把密钥（密钥也是数据）给解密方时也是需要对密钥进行加密的，解密方没法解密就没法拿到密钥（存在安全问题，后面解释）
1.2.2. 数据摘要 && 数据指纹
数字指纹(数据摘要),其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的字符串—数字摘要（这个字符串就叫做数据摘要/数据指纹）。数字指纹并不是⼀种加密机制，因为他不可以通过这个字符串反解出原数据，即：不可解密。只是⽤来判断数据有没有被窜改。摘要经过加密，就得到数字签明（后面解释）
二.HTTPS 的⼯作过程探究
2.1只使⽤对称加密
如果通信双⽅都各⾃持有同⼀个密钥X，且没有别⼈知道，那么两⽅的通信是安全的。（ 即使数据被截获, 由于⿊客不知道密钥是啥, 因此就⽆法进⾏解密）。
服务器同⼀时刻其实是给很多客⼾端提供服务的.，不同双方通信的秘钥最好是不一样的。⽐较理想的做法, 就是能在客⼾端和服务器建⽴连接的时候, 双⽅协商确定这次的密钥（有具体算法去实现），但在传输时秘钥也是数据，也会被黑客获取。
2.2只使用非对称加密
例如：如果 服务器先把公钥以明⽂⽅式传输给浏览器，之后浏览器向服务器传输数据时用公钥加密，从客⼾端到服务器信道似乎是安全的(但有安全问题)，但服务器到浏览器的这条路无法保障安全。
改进：二者都使用非对称加密，例如服务端拥有公钥S(server)与对应的私钥S'，客⼾端拥有公钥C与对应的私钥C'。
问题：数据传输是要消耗资源的，非对称加密的效率是更低的，若双方同时用非对称加密，并不是非常可取。
2.3非对称加密与对称加密
例如：服务端有非对称秘钥S,S$, 客户端对称秘钥T。
过程：客户端先发起请求，服务端将秘钥S给客户端。
客户端通过秘钥S加密要传输的数据（对称秘钥T），此时即使黑客截获了数据，也无法获 得加密后的对称秘钥T。
双方通过对称秘钥T进行加密解密，进行数据传输。
2.4中间人攻击
Man-in-the-MiddleAttack，简称“ MITM攻击 ”
上面使用的非对称加密与对称加密看上去没有问题，且最后通信使用的还是对称加密。但如果中间⼈的攻击，如果在最开始握⼿协商的时候就进⾏了，就会出现问题。即一方无法确定数据是另一方发送过来的。
那上面的例子来看：
这种情况使用于上面的策略，所以都不安全，客⼾端⽆法确定收到的含有公钥的数据报⽂，就是⽬标服务器发送过来的！这是最本质的原因。
三.证书
3.1CA认证
服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性。
证书内容：
• 证书发布机构
• 证书有效期
• 公钥
• 证书所有者
• 签名
注意：
服务器需要在特定平台⽣成⼀对密钥对，即公钥和私钥。这对密钥对就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。
其中公钥会随着CSR⽂件，⼀起发给CA进⾏权威认证，私钥服务端⾃⼰保留，⽤来后续进⾏通信（其实主要就是⽤来交换对称秘钥）
例如：CSR在线生成工具这个工具
3.2数据签名
给数据文档进行数据签名的意义：防止内容被篡改，这里来确保证书没有被修改。
查看浏览器的受信任证书发布机构
3.3 ⾮对称加密 + 对称加密 + 证书认证
在2.3的基础上，在客⼾端和服务器刚⼀建⽴连接的时候, 服务器给客⼾端返回⼀个 证书，证书包含了之前服务端的公钥, 也包含了⽹站的⾝份信息.。
客⼾端进⾏认证：
• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
• 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对⽐ hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的.
认证成功后，通过公钥向服务器发送对称秘钥，服务器通过私钥解密，获得对称秘钥。后面二者传输时信息加密都通过这个对称秘钥。
3.4常见问题
1.服务器向客户端发公钥时，中间⼈可不可能篡改证书呢？
证书的是明文，可以被篡改，但由于中间⼈没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名，如果强⾏篡改，客⼾端收到该证书后会发现明⽂散列后的值和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息。
2.中间⼈能否将整个掉包证书？
一般情况下，中间⼈没有CA私钥，所以⽆法制作假的证书。
如果做到证书的整体掉包，但是明⽂中包含了域名等服务端认证信息，如果整
体掉包，客⼾端依旧能够识别出来。
3.为什么摘要内容在⽹络传输的时候⼀定要加密形成签名?
以 MD5 为例, 了解其特点即可
• 定⻓: ⽆论多⻓的字符串, 计算出来的 MD5 值都是固定⻓度 (16字节版本或者32字节版本)
• 分散: 源字符串只要改变⼀点点, 最终得到的 MD5 值都会差别很⼤.
• 不可逆: 通过源字符串⽣成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.
4.为什么签名不直接加密，⽽是要先hash形成摘要?
缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度。
