目录
[2.1 明文，密钥](#2.1 明文，密钥)
[2.2 对称和非对称加密](#2.2 对称和非对称加密)
[2.3 数据摘要，数据指纹，数字签名](#2.3 数据摘要，数据指纹，数字签名)
[4.1 CA认证](#4.1 CA认证)
[4.2 证书大致内容和申请流程](#4.2 证书大致内容和申请流程)
[4.3 签名](#4.3 签名)
[4.4 方案五](#4.4 方案五)
一，关于https
- http不安全，所以选择大部分互联网公司采用的都是https协议，https的作用就是保证数据安全
- 应用层把数据交给传输层，网络层，数据链路层，但是这三个是属于操作系统范畴的，而操作系统也没有义务把你的数据做加密，主要还是解决数据传输的各种问题。
- 用户的数据以http的请求和响应为载体，把信息进行双方交互，所以在传输过程中，也会有很多人也能收到并且往上解析，这是不能忍受的。
- 所以数据安全的设计者在应用层添加了一层软件层：ssl加密解密层，作用是http先交给它，做加密后再交给操作系统，然后发给对方后，对方再解密
- 这样中间的用户能接收到数据但是无法解密，只有通信双方才知道，所以http + ssl = https。基于http封装了一层软件层
所以https本质上是对数据做的一种保证安全的解决方案：
- 一个方案现在可能没有漏洞，但是随着技术，硬件和算力的进步，在未来总会有漏洞的，所以安全问题永远都存在
- 如果一个数据安全攻破的成本大于攻破后的收益 ，我攻破你赚了10块钱，但是我为了攻破你花了100，这就认为这个网络安全协议就是安全的，这是一个标准
- ssl是权威的官方的加密解决方案，每过一段时间就会暴露一些问题，树大招风，所以会有一大堆社区人员会维护它，所以这种协议不一定是任何时候都安全的
二，关于加密
2.1 明文，密钥
问题：什么是加密？
解答：加密就是把明文（要传输的信息）进行⼀系列变换，生成密文；解密就是把密文再进行⼀系列变换，还原成明文
比如藏头诗，把数据放在诗的开头叫做加密，发给对方后，对方只读诗的开头，叫做解密
问题：什么是密钥？解答：在加密解密过程中都需要中间数据辅助这个过程，这个中间数据就叫做"密钥"。
比如，我要发7（111），然后和5（101）做异或（^），结果就变成010，也就是2，然后只把2发过去，然后再解密，2再和5做异或变成7
其中我们把7称为明文，2叫做密文，5就是密钥，做异或就是加密解密的过程
问题：为什么要加密？
解答：有一种说法叫做"运营商劫持"，点击下载请求就是发送一个http请求，运营商拿到了链接可能会把用户的响应改成其它的，比如我要下A软件，但是最后却下载了B软件，这种篡改http请求的攻击我们有一种笼统的说法叫做"中间人攻击"所以，在互联网上，明文传输是非常危险的事情，https就是再http的基础上做加密
2.2 对称和非对称加密
1，对称加密：
- 加密和解密用的同一个密钥，比如上面的异或加密，可以理解为一种对称加密的算法
- 特征：密钥相同，并且加密和解密速度快
2，非对称加密：
- 加密解密用不同的密钥，明文 + 密钥A = 密文，然后密文用密钥B来解密，A与B是不同的密钥
- 我们可以把一个密钥公开，公开的这个密钥叫做"公钥"，不被公开的叫做"私钥"
- 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快
- 缺点：运行速度非常慢，而且我用公钥加密，这个世界上只有有私钥的人才能解密，私钥丢失，就不能再解密了
2.3 数据摘要，数据指纹，数字签名
- 数据摘要和数据指纹，这俩其实是同一个东西，只是有两种说法
- 其原理是对原文数据使用Hash算法，生产一串固定长度的，非常低概率发生冲突的固定长度的字符串，特点是具有"唯一性"，比如MD5算法
- 这个形成的字符串就叫做数据摘要，由于和指纹一样具有唯一性，所以也叫做数据指纹
- 我们上一篇博客讲的session_id就可以认为是MD5的数据摘要
- 摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比
- 把摘要再次加密后就是"数字签名"，签名我们后面讲
三，https过程过程探究
加密方式有很多，下面我们来一步步探究https是如何解决数据安全的，加密方式有很多种，但是整体分为两大类：对称加密和非对称加密：
方案一：只采用对称加密
- 双方只约定好一个密钥，中间经过很多设备，假设黑客入侵了一个，截获了请求，但是解密成本太高，拿到也没用，但是黑客仍然也能拿到密钥
- 客户端第一次请求时，服务器把密钥发过去，但是这就类似于掩耳盗铃了因为黑客也能拿到
- 那好，我对密钥再进行加密，然后进入无限循环。所以方案一pass
方案二：只使用非对称加密（客户端发公钥，服务器发私钥）
- 需要公钥和私钥，起名为p和p'，客户端发过来请求，是http的，然后服务器收到了，把p发给客户端了，p'自己维护好
- 然后客户端用公钥加密后发给服务器，只有服务器有私钥，所以只有服务器能对数据做解密，这样，从客户端到服务器的数据安全就可以保证
但是问题来了：当服务器往客户端响应时，服务器只有私钥没有公钥，所以服务器只能用私钥加密，然后发给客户端，但是黑客就可以用公钥解密，这就不行了，无法保证服务器发给客户端的数据安全性，所以只使用非对称加密也不行
方案三：双方都是用非对称加密
- 服务器有公钥和私钥，S和S'，客户端也有自己的公钥和私钥，C和C'
- 客户端请求时把S交给服务器，然后服务器把公钥C交给客户端，双方都维护自己的私钥，双方只发送公钥
- 效率太低，而且依旧有安全问题
方案四：非对称加密和对称加密混合使用 --> 解决方案3的问题
- 服务器有自己的公钥和私钥S和S'，服务器把S发给客户端，客户端形成一个对称密钥C，然后"C + S + 明文"一起进行加密再给服务器，这时候服务器就能通过自己的私钥S'和对称密钥C进行解密
- 这样就是，服务器发给客户端时用非对称加密，客户端发给服务器时用对称加密，这样就能保证安全性，而且安全性也有保障。
针对方案二三四存在的问题：
问题：方案234都使用了非对称加密，但是它们都有一个公共的问题 ，或者说它们都存在一个前提性的问题，最开始客户端发请求给服务器是没用任何加密的，如果这个时候中间人已经在开始攻击了呢？场景：以方案4为背景(服务器有自己的公钥和私钥，S和S'，中间人也有自己的公钥和私钥，M和M')
- 最开始客户端发给服务器，中间人直接劫持报文，这时候不做处理直接发给服务器，服务器用S加密后发回去
- ②然后中间人劫持了报文，获取了公钥S并保存好，并把M替换掉S，交给客户端
- ③然后客户端就以为公钥M就是服务器给我发的，然后客户端生成自己的密钥X 再和 M进行加密，然后发给服务器（X + M）
- ④中间人再次截取报文，中间人用自己的私钥M'解密，然后就拿到X，再用X 和 S重新再加密，再发给服务器
- ⑤这时候在服务器和 客户端看来，它们拿到的都是对应的密钥，感觉没什么问题，于是双方就开始用对称密钥开始通信，但是此时的中间人拥有双方的密钥，就可以获取双方发送的所有报文并进行解密
- 这种欺骗客户端的攻击方式叫做：MITM中间人攻击
解答 ：问题的本质在于客户端无法验证服务器发来的密钥是否合法，所以就需要通过我们的证书来解决
四，证书
4.1 CA认证
- 服务端在使用https前，需要向CA机构申请一份数字证书，它就像身份证一样含有证书申请者信息，公钥信息等。
- 服务器只需要把把证书传给浏览器，浏览器直接从证书里面获取密钥就行了
- https一般用在搭建网站的时候所需要的第一种协议
- 访问一些网站时，会提示网站对应的证书已经过期，或者安全证书不安全
4.2 证书大致内容和申请流程
如下图：
大致步骤如下：
- 我们先准备一个公钥和私钥对，S和S'，就是服务器上那个，再确认申请信息（域名，申请者，公钥S）。如果非技术人员不熟悉操作，CA会有对应的办理服务机制
- 对我申请的资料进行审核
- 如果合格就直接签发证书，这个证书是要安装到你的服务器上的
- 服务器把证书发给浏览器或者客户端
- 浏览器或者客户端会验证证书
- 验证合法之后，就允许服务器和客户端进行密钥协商
证书中包含公钥，就是申请者曾经提交给CA的公钥 ，也就是服务器使用的公钥，这样就保证了公钥的合法性，服务器则自己把私钥保护好
4.3 签名
问题：如何保证服务器发给客户端的证书是合法的？（权威机构认证 + 是否篡改）
解答 ：现在问题从公钥是否合法 转化为了证书是否合法，所以判断证书是否合法，通过"签名"来完成
-
证书里有一个"签名"：我们用数据摘要和数据指纹生成MD5的不重复的定长字符串，把数据指纹或数据摘要再加密就获得了"数据签名"。
-
然后我们把签名和原始数据搞在一起 ，就生成了"具有数据签名的一份数据"。
-
然后浏览器拿到服务器发来的证书进而拿到签名，然后我们签名分开成"数据和签名"
-
然后对于数据做散列函数算法算出散列值，然后再用签名者的公钥解密原始文件得到散列值，
-
对于两个散列值是否相等，如果相等则代表文件没有被修改，如果不相等，就表示被篡改过
问题：CA内部如何形成合法证书呢？
解答：签名的形成是基于非对称加密算法的
- 上面说的原始数据就是用户提交上来的数据，然后在CA内部有自己的公钥和私钥，（这个公钥和私钥和我们历史讲的cs，bs毫无关系）
- 先对用户提交上来的数据做散列函数得到散列值（101100110101），然后CA在内部用它自己的私钥形成一个签名（111101101110），然后把客户提交上来的数据和签名绑定在一起就形成了证书
- 然后客户端向服务器第一次发请求，就把证书申请到了
4.4 方案五
方案五：非对称加密 + 对称加密 + 证书认证
- 客户端请求服务器端，服务器端进行响应，服务器直接把证书返回给客户端
- 客户端自己形成自己的公钥X，然后"X + 证书中的密钥pub_server" 形成密文 ，然后把密文交给服务器端（这里的密钥pub_server就是服务器的公钥S）
- 然后服务器用自己的私钥S'，解密拿到X，这和方案4一样，所以客户端需要保证pub_server密钥是合法的，所以客户端要对证书进行验证
- 客户端拿到证书后，先把证书拆成"明文"和"签名"两部分
- 客户端会内置很多权威CA机构的公钥，这个公钥与pub_server没有关系，然后用CA的公钥进行解密，验证证书是否合法
- 如果一切正常，就说这个证书是可信的，客户端才会把"X + S"加密后的报文交给服务器，因为已经验证了S就是服务器的公钥而不是中间人的公钥
结论，客户端只认CA的公钥。
历史意义：意味着只有CA能够进行证书的签发，因为只有CA自己具有私钥 --> 中间人没资格进行证书的权限生成，因为中间人0没有CA的私钥
问题：中间人自己也可以申请证书，如果把整个证书掉包成中间人的真证书了呢？
解答：证书里面包含域名，如果一个黑客自己申请真证书，得提交他自己的真信息，假如客户端要请求的是www.baidu.com，但是证书里返回的是另一个其它的域名，而世界上没办法有两个一样的域名，然后照样能识别出来而且一旦黑客自己申请证书了，那黑客就不是黑客了，也是合法了，由于黑客申请证书时提交了自己的各种信息，那么只要黑客搞事情，就能立马把网络落实到现实，具体懂的都懂哈