基础概念
https也是一个应用层协议，是在http协议上基础上添加保密层（TLS/SSL，对数据进行加密，解密）
加密 就是明文变密文
解密就是密文变明文
中间人攻击
如运营商替换下载链接， 钓鱼wifi， 钓鱼热点等位于client与server中间的第三者进行的攻击
常见加密方式
对称加密
加密解密用相同密钥
加密速度快，效率高
DES，RC2
非对称加密
两个密钥进行加密/解密
可以公钥加密/私钥解密
也可以私钥加密/公钥解密
++不能只用一个钥同时加密/解密++
数据摘要 && 数据指纹
图片
两者是同意思
不是加密机制（没有解密方法），但可以用来判断数据有无篡改（即使修改了一个比特位，数据摘要也会发生巨大变化
原理是使用单向散列函数（hash）对信息进行运算，生成固定长度数字摘要
为什么说数据摘要具有唯一性？
既然数据摘要是定长且唯一的，那么当数据非常大时，不违反抽屉原理（鸽巢原理）么？
实际上是有可能碰撞的，但两者（源数据和被修改后的数据）数据摘要的碰撞概率极低，我们就认为不会碰撞，即视为数据摘要是唯一的
例如非常常用的SHA-256方法，无论输入数据大小如何，都输出256位（32字节）的摘要值，两个不同数据的碰撞概率仅为2^-128，几乎不可能。
数据摘要的应用
应用1：云盘的"云秒传功能"
百度云盘把所有资源都形成各自数据摘要，用户如要上传的资源的数字摘要已经存在，服务器直接把其他用户相同资源保存在此用户网盘上
应用2：数据库保存用户账号与密码
数据库中不可直接存储密码的明文，应存储数据摘要，通过比较数据摘要来对比密码是否正确
四种加密方案：
1.只使用对称加密
server端如何得知密钥？
方案一只使用对称加密不可行：不能保证密钥安全传输
2.只使用非对称加密
服务器将公钥给client，自己持有私钥
貌似client->server安全
但server->client不安全
方案2：
++貌似++ 保证单向数据安全
通信速度非常慢
3.双方都使用非对称加密
方案3：
++貌似++ 两方向都安全
通信速度比较慢
4.非对称加密＋对称加密
使用非对称加密保证对称加密密钥的安全传输，之后都使用对称加密
++看起来++ 很安全，完善，但和方案2/3一样，都有漏洞
之所以使用单词"貌似安全"，是指实际上也不安全。2/3/4加密方案的相同漏洞（ 上述"貌似正确"部分的安全漏洞**）**，可见下"中间人攻击"
中间人攻击
站在中间人（攻击者）角度分析安全问题（寻找安全漏洞）
2/3/4方案问题在哪：client不知道密钥是否合法 
CA证书与签名
签名
只有本人有私钥，也就意味着只有本人有对数据进行签名的能力
所有客户端都内置信任的CA机构的公钥（用来解析证书）
签名者：CA机构
证书只能由只能CA机构颁发，server颁发/生成不了证书
client第一次请求，得到的结果，不仅有公钥。实际上，得到的是证书。证书包含密钥，是++明文信息++ 。证书使用签名来保证证书完整性与不被修改。
证书图片：
签名+非对称加密+对称加密 配合关系
总的来说，签名和非对称加密就是为了保证client的对称密钥安全地传输给server
签名保证证书完整性
保证server公钥不被中间人掉包
中间人无法在不被发现情况下对证书进行篡改，因为没有CA私钥
非对称加密保证只有server收到client对称密钥
只有服务器拥有server私钥，所以只有服务器可以解密/真正收到client的密钥，防止中间人获取client密钥
使用client对称密钥通信
此时可保证只有client，server拥有client对称密钥，之后client与server即可使用对称密钥安全且快速通信
签名为什么先hash再形成摘要，而不是直接对签名形成摘要？
缩小签名密文长度，加快数字签名的运算速度
HTTPS整体流程
板书笔记
