【Linux系统化学习】应用层—

什么是加密、解密

为什么要加密

臭名昭著的”运营商劫持“

常见的加密方式

对称加密

非对称加密

数据摘要&&数据指纹

两个用途

HTTPS的工作过程探究

方案1——只是用对称加密

方案2——只使用非对称加密

方案3——双方都是用非对称加密

方案4——对称加密+非对称加密

中间⼈攻击 - 针对上⾯的场景

引入证书

CA认证

数据签名

⽅案 5 - ⾮对称加密 + 对称加密 + 证书认证

总结

上篇文章我们提到HTTP协议是通过明文传输数据的，这就有很大的安全问题明文数据在传输过程中可能被人盗取，为了防止这种事情需要对HTTP协议进行加密，就是HTTPS协议；也就是我们现在最常用的浏览器协议。

在传输层和网络层之间，存在加密解密层（TLS/SSL），属于应用层。这意味着当HTTP数据在TCP连接上传输时，TLS/SSL层会首先对这些数据进行加密，然后再将数据发送给传输层（TCP）。同样，当TCP接收到数据时，TLS/SSL层会首先解密数据，然后再将数据传递给应用层（HTTP）。

什么是加密、解密

加密：加密就是把明⽂ (要传输的信息)进⾏⼀系列变换, ⽣成密⽂。

解密：解密就是把密⽂再进⾏⼀系列变换, 还原成明⽂。

在这个加密和解密的过程中, 往往需要⼀个或者多个中间的数据, 辅助进⾏这个过程, 这样的数据称为密钥

加密解密到如今已经发展成⼀个独⽴的学科: 密码学.⽽密码学的奠基⼈, 也正是计算机科学的祖师爷之⼀, 艾伦·⻨席森·图灵

为什么要加密

臭名昭著的”运营商劫持“

由于我们通过⽹络传输的任何的数据包都会经过运营商的⽹络设备(路由器, 交换机等), 那么运营商的⽹络设备就可以解析出你传输的数据内容, 并进⾏篡改。

就像我们今天使用URL进入CSDN时，会先给CSDN的服务器发送请求中间会经过很多的站点、和中转服务器；每一个站点都可以将我们的URL进行修改，进入到其他目的服务器。

因为http的内容是明⽂传输的，明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务
器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双⽅察觉，这就是中间⼈攻击，所以我们才需要对信息进⾏加密。

不⽌运营商可以劫持, 其他的⿊客也可以⽤类似的⼿段进⾏劫持, 来窃取⽤⼾隐私信息, 或者篡改内容.
试想⼀下, 如果⿊客在⽤⼾登陆⽀付宝的时候获取到⽤⼾账⼾余额, 甚⾄获取到⽤⼾的⽀付密码.....
在互联⽹上, 明⽂传输是⽐较危险的事情!!!

HTTPS 就是在 HTTP 的基础上进⾏了加密, 进⼀步的来保证⽤⼾的信息安全~

常见的加密方式

对称加密

采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的
常⻅对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
特点：算法公开、计算量⼩、加密速度快、加密效率⾼

对称加密其实就是通过同⼀个 "密钥" , 把明⽂加密成密⽂, 并且也能把密⽂解密成明⽂。

例如：

⼀个简单的对称加密, 按位异或

假设明⽂ a = 1234, 密钥 key = 8888

则加密 a ^ key 得到的密⽂ b 为 9834.

然后针对密⽂ 9834 再次进⾏运算 b ^ key, 得到的就是原来的明⽂ 1234.

(对于字符串的对称加密也是同理, 每⼀个字符都可以表⽰成⼀个数字)
当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使⽤按位异或.

非对称加密

需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA
特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快

⾮对称加密要⽤到两个密钥, ⼀个叫做 "公钥", ⼀个叫做 "私钥".

公钥和私钥是配对的. 最⼤的缺点就是运算速度⾮常慢，⽐对称加密要慢很多.

通过公钥对明⽂加密, 变成密⽂
通过私钥对密⽂解密, 变成明⽂
通过私钥对明⽂加密, 变成密⽂
通过公钥对密⽂解密, 变成明⽂

例如：
A 要给 B ⼀些重要的⽂件, 但是 B 可能不在. 于是 A 和 B 提前做出约定:

B 说: 我桌⼦上有个盒⼦, 然后我给你⼀把锁, 你把⽂件放盒⼦⾥⽤锁锁上, 然后我回头拿着钥匙来开锁
取⽂件.
在这个场景中, 这把锁就相当于公钥, 钥匙就是私钥. 公钥给谁都⾏(不怕泄露), 但是私钥只有 B ⾃⼰持
有. 持有私钥的⼈才能解密.

数据摘要&&数据指纹

数字指纹(数据摘要),其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的数字摘要。数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被窜改。
摘要常⻅算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率⾮常低）
摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推
原信息，通常⽤来进⾏数据对⽐

总结：

数据指纹可以对比两个文件是不是同一个

数据指纹可以判断一个文件是否被修改过

两个用途

后端服务器存储密码

后端服务器可以将我们的密码进行数字摘要，这样密码只有我们一个人可以知道；维护后端用户信息的服务器人员也无法获取。

网盘秒传

我们在使用一些网盘进行一些比较大的文件传送时可能会出现秒传功能，那是因为已经有人在后端传送了和你一样的文件，后端服务器将这个文件进行数字摘要，等你传送时服务器将你的文件进行数字摘要和后端的进行比对，如果发现一样的就可以不用上传，给你一个连接。这就是一些网盘的秒传功能的实现方法。

HTTPS的工作过程探究

方案1——只是用对称加密

如果通信双⽅都各⾃持有同⼀个密钥X，且没有别⼈知道，这两⽅的通信安全当然是可以被保证的（除⾮密钥被破解）

引⼊对称加密之后, 即使数据被截获, 由于⿊客不知道密钥是啥, 因此就⽆法进⾏解密, 也就不知道请求的真实内容是啥了.

但事情没这么简单. 服务器同⼀时刻其实是给很多客⼾端提供服务的. 这么多客⼾端, 每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了, ⿊客就也能拿到了). 因此服务器就需要维护每个客⼾端和每个密钥之间的关联关系, 这也是个很⿇烦的事情

⽐较理想的做法, 就是能在客⼾端和服务器建⽴连接的时候, 双⽅协商确定这次的密钥是啥~

但是如果直接把密钥明⽂传输, 那么⿊客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了.
因此密钥的传输也必须加密传输!

但是要想对密钥进⾏对称加密, 就仍然需要先协商确定⼀个 "密钥的密钥". 这就成了 "先有鸡还是先有蛋" 的问题了. 此时密钥的传输再⽤对称加密就⾏不通了.

方案2——只使用非对称加密

鉴于⾮对称加密的机制，如果服务器先把公钥以明⽂⽅式传输给浏览器，之后浏览器向服务器传数据前都先⽤这个公钥加密好再传，从客⼾端到服务器信道似乎是安全的(有安全问题)，因为只有服务器有相应的私钥能解开公钥加密的数据。

但是服务器到浏览器的这条路怎么保障安全？如果服务器⽤它的私钥加密数据传给浏览器，那么浏览器⽤公钥可以解密它，⽽这个公钥是⼀开始通过明⽂传输给浏览器的，若这个公钥被中间⼈劫持到了，那他也能⽤该公钥解密服务器传来的信息了。

方案3——双方都是用非对称加密

1. 服务端拥有公钥S与对应的私钥S'，客⼾端拥有公钥C与对应的私钥C'

2. 客⼾和服务端交换公钥

3. 客⼾端给服务端发信息：先⽤S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥S'

4. 服务端给客⼾端发信息：先⽤C对数据加密，在发送，只能由客⼾端解密，因为只有客⼾端有私钥C

这样貌似也⾏啊，但是

效率太低
依旧有安全问题

方案4——对称加密+非对称加密

服务端具有⾮对称公钥S和私钥S'
客⼾端发起https请求，获取服务端公钥S
客⼾端在本地⽣成对称密钥C, 通过公钥S加密, 发送给服务器.
由于中间的⽹络设备没有私钥, 即使截获了数据, 也⽆法还原出内部的原⽂, 也就⽆法获取到对称密钥
服务器通过私钥S'解密, 还原出客⼾端发送的对称密钥C. 并且使⽤这个对称密钥加密给客⼾端返回的响应数据.
后续客⼾端和服务器的通信都只⽤对称加密即可. 由于该密钥只有客⼾端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义.

由于对称加密的效率⽐⾮对称加密⾼很多, 因此只是在开始阶段协商密钥的时候使⽤⾮对称加密, 后续的传输仍然使⽤对称加密.

虽然上⾯已经⽐较接近答案了，但是依旧有安全问题；⽅案 2，⽅案 3，⽅案 4都存在⼀个问题，如果最开始，中间⼈就已经开始攻击了呢？

中间⼈攻击 - 针对上⾯的场景

• Man-in-the-MiddleAttack，简称“MITM攻击”

确实，在⽅案2/3/4中，客⼾端获取到公钥S之后，对客⼾端形成的对称秘钥X⽤服务端给客⼾端的公钥S进⾏加密，中间⼈即使窃取到了数据，此时中间⼈确实⽆法解出客⼾端形成的密钥X，因为只有服务器有私钥S'，但是中间⼈的攻击，如果在最开始握⼿协商的时候就进⾏了，那就不⼀定了，假设hacker已经成功成为中间⼈

1. 服务器具有⾮对称加密算法的公钥S，私钥S'
2. 中间⼈具有⾮对称加密算法的公钥M，私钥M'
3. 客⼾端向服务器发起请求，服务器明⽂传送公钥S给客⼾端
4. 中间⼈劫持数据报⽂，提取公钥S并保存好，然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M，并将伪造报⽂发给客⼾端
5. 客⼾端收到报⽂，提取公钥M(⾃⼰当然不知道公钥被更换过了)，⾃⼰形成对称秘钥X，⽤公钥M加密X，形成报⽂发送给服务器
6. 中间⼈劫持后，直接⽤⾃⼰的私钥M'进⾏解密，得到通信秘钥X，再⽤曾经保存的服务端公钥S加密后，将报⽂推送给服务器
7. 服务器拿到报⽂，⽤⾃⼰的私钥S'解密，得到通信秘钥X
8. 双⽅开始采⽤X进⾏对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进⾏窃听甚⾄修改，都是可以的

上⾯的攻击⽅案，同样适⽤于⽅案2，⽅案3

问题本质出在哪⾥了呢？客⼾端⽆法确定收到的含有公钥的数据报⽂，就是⽬标服务器发送过来的！

引入证书

CA认证

服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性

数据签名

首先需要将各种信息包括服务器的公钥生成请求文件（csr文件），交给CA；CA机构会审核提交信心的真假，审核通过后，CA机构会将原始的数据使用哈希散列函数形成散列值，然后使用 CA机构的密钥对散列值进行加密就形成了签名；将签名和原来的csr文件加一些认证信息组合在一起就形成了CA证书。

⽅案 5 - ⾮对称加密 + 对称加密 + 证书认证

在客⼾端和服务器刚⼀建⽴连接的时候, 服务器给客⼾端返回⼀个证书，证书包含了之前服务端的公钥, 也包含了⽹站的⾝份信息.

客户端进行认证

当客⼾端获取到这个证书之后, 会对证书进⾏校验(防⽌证书是伪造的).

判定证书的有效期是否过期
判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对⽐ hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的
客户端自己形成一个密钥，使用证书中服务器的公钥进行加密交给服务器；服务器使用自己的私钥得到密钥，以后双方都是用这个密钥进行对称加密通信

总结

HTTPS ⼯作过程中涉及到的密钥有三组:

第⼀组(⾮对称加密): ⽤于校验证书是否被篡改. 服务器持有私钥(私钥在形成CSR⽂件与申请证书时获得), 客⼾端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客⼾端请求是，返回携带签名的证书. 客⼾端通过这个公钥进⾏证书验证, 保证证书的合法性，进⼀步保证证书中携带的服务端公钥权威性。
第⼆组(⾮对称加密): ⽤于协商⽣成对称加密的密钥. 客⼾端⽤收到的CA证书中的公钥(是可被信任的)给随机⽣成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥。
第三组(对称加密): 客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密。

今天对Linux网络应用层HTTPS协议的分享到这就结束了，希望大家读完后有很大的收获，也可以在评论区点评文章中的内容和分享自己的看法；个人主页还有很多精彩的内容。您三连的支持就是我前进的动力，感谢大家的支持！！!