目录

一，关于https

二，关于加密

2.1 明文，密钥

2.2 对称和非对称加密

2.3 数据摘要，数据指纹，数字签名

三，https过程过程探究

四，证书

4.1 CA认证

4.2 证书大致内容和申请流程

4.3 签名

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')

1. 最开始客户端发给服务器，中间人直接劫持报文，这时候不做处理直接发给服务器，服务器用S加密后发回去
2. ②然后中间人劫持了报文，获取了公钥S并保存好，并把M替换掉S，交给客户端
3. ③然后客户端就以为公钥M就是服务器给我发的，然后客户端生成自己的密钥X 再和 M进行加密，然后发给服务器（X + M）
4. ④中间人再次截取报文，中间人用自己的私钥M'解密，然后就拿到X，再用X 和 S重新再加密，再发给服务器
5. ⑤这时候在服务器和 客户端看来，它们拿到的都是对应的密钥，感觉没什么问题，于是双方就开始用对称密钥开始通信，但是此时的中间人拥有双方的密钥，就可以获取双方发送的所有报文并进行解密
6. 这种欺骗客户端的攻击方式叫做：MITM中间人攻击

解答：问题的本质在于客户端无法验证服务器发来的密钥是否合法，所以就需要通过我们的证书来解决

四，证书

4.1 CA认证

• 服务端在使用https前，需要向CA机构申请一份数字证书，它就像身份证一样含有证书申请者信息，公钥信息等。
• 服务器只需要把把证书传给浏览器，浏览器直接从证书里面获取密钥就行了
• https一般用在搭建网站的时候所需要的第一种协议
• 访问一些网站时，会提示网站对应的证书已经过期，或者安全证书不安全

4.2 证书大致内容和申请流程

如下图：

大致步骤如下： 

1. 我们先准备一个公钥和私钥对，S和S'，就是服务器上那个，再确认申请信息（域名，申请者，公钥S）。如果非技术人员不熟悉操作，CA会有对应的办理服务机制
2. 对我申请的资料进行审核
3. 如果合格就直接签发证书，这个证书是要安装到你的服务器上的
4. 服务器把证书发给浏览器或者客户端
5. 浏览器或者客户端会验证证书
6. 验证合法之后，就允许服务器和客户端进行密钥协商

证书中包含公钥，就是申请者曾经提交给CA的公钥，也就是服务器使用的公钥，这样就保证了公钥的合法性，服务器则自己把私钥保护好

4.3 签名

问题：如何保证服务器发给客户端的证书是合法的？（权威机构认证 + 是否篡改）

解答：现在问题从公钥是否合法转化为了证书是否合法，所以判断证书是否合法，通过”签名“来完成 

• 证书里有一个“签名”：我们用数据摘要和数据指纹生成MD5的不重复的定长字符串，把数据指纹或数据摘要再加密就获得了“数据签名”。

• 然后我们把签名和原始数据搞在一起，就生成了“具有数据签名的一份数据”。

• 然后浏览器拿到服务器发来的证书进而拿到签名，然后我们签名分开成”数据和签名“

• 然后对于数据做散列函数算法算出散列值，然后再用签名者的公钥解密原始文件得到散列值，

• 对于两个散列值是否相等，如果相等则代表文件没有被修改，如果不相等，就表示被篡改过

 

问题：CA内部如何形成合法证书呢？

解答：签名的形成是基于非对称加密算法的

1. 上面说的原始数据就是用户提交上来的数据，然后在CA内部有自己的公钥和私钥，（这个公钥和私钥和我们历史讲的cs，bs毫无关系）
2. 先对用户提交上来的数据做散列函数得到散列值（101100110101），然后CA在内部用它自己的私钥形成一个签名（111101101110），然后把客户提交上来的数据和签名绑定在一起就形成了证书
3. 然后客户端向服务器第一次发请求，就把证书申请到了

4.4 方案五

方案五：非对称加密 + 对称加密 + 证书认证

1. 客户端请求服务器端，服务器端进行响应，服务器直接把证书返回给客户端
2. 客户端自己形成自己的公钥X，然后”X + 证书中的密钥pub_server“ 形成密文，然后把密文交给服务器端（这里的密钥pub_server就是服务器的公钥S）
3. 然后服务器用自己的私钥S'，解密拿到X，这和方案4一样，所以客户端需要保证pub_server密钥是合法的，所以客户端要对证书进行验证
4. 客户端拿到证书后，先把证书拆成“明文”和“签名”两部分
5. 客户端会内置很多权威CA机构的公钥，这个公钥与pub_server没有关系，然后用CA的公钥进行解密，验证证书是否合法
6. 如果一切正常，就说这个证书是可信的，客户端才会把”X + S“加密后的报文交给服务器，因为已经验证了S就是服务器的公钥而不是中间人的公钥

结论，客户端只认CA的公钥。

历史意义：意味着只有CA能够进行证书的签发，因为只有CA自己具有私钥 --> 中间人没资格进行证书的权限生成，因为中间人0没有CA的私钥

问题：中间人自己也可以申请证书，如果把整个证书掉包成中间人的真证书了呢？
解答：证书里面包含域名，如果一个黑客自己申请真证书，得提交他自己的真信息，假如客户端要请求的是www.baidu.com，但是证书里返回的是另一个其它的域名，而世界上没办法有两个一样的域名，然后照样能识别出来

而且一旦黑客自己申请证书了，那黑客就不是黑客了，也是合法了，由于黑客申请证书时提交了自己的各种信息，那么只要黑客搞事情，就能立马把网络落实到现实，具体懂的都懂哈