【Linux】HTTPS协议

采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的。

常⻅对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等。

特点：算法公开、计算量⼩、加密速度快、加密效率⾼。

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

非对称加密

需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥 （private key，简称私钥）。

常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA。

特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快。

PS：

用私钥加密，有公钥就能解密。
用公钥加密的数据只有拥有私钥的人能对其进行解密。

因此只采用非对称能保证client到server的数据安全，但是不能保证server到client的数据安全，因为server向client确定公钥，黑客也能够获取。

数据摘要 && 数据指纹

数字指纹(数据摘要),其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的数字摘要。数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被窜改。

Hash => 固定长度的，非常低概率发生冲突的固定长度的字符串，具有唯一性；这种算法也就是摘要算法，典型算法：MD5；摘要算法所形成的字符串称为数据指纹。

摘要常⻅算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率⾮常低）

摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常⽤来进⾏数据对⽐

引入证书

CA认证

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

HTTPS的几种加密方案

方案 1 - 只使用对称加密

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

引入对称加密后，即使数据被截获，由于黑客不知道密钥是什么，因此也无法对其进行解密

但是服务器同一时间是要给很多客户端提供服务的，这么多客⼾端, 每个⼈用的密钥都必须是不同的(如果是相同那密钥就太容易扩散了, 黑客就也能拿到了). 因此服务器就需要维护每个客户端和每个密钥之间的关联关系, 这也是个很麻烦的。

比较理想的做法是在客户端和服务器建立连接的时候，双方协商确定这次的密钥是什么。

但是在协商密钥使用什么的时候，若采用明文传输，也会被黑客截获，后续的加密操作便形同虚设，因此密钥的传输也必须加密传输！

但是我们事先协商密钥是为了后续加密传输，想对密钥进行对称加密，就仍需要先协商确定一个为了传输这个密钥的密钥，这就成了 "先有鸡还是先有蛋" 的问题了. 此时密钥的传输再⽤对称加密就⾏不通了。

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

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

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

方案 3 - 双方都使用非对称加密

服务端拥有公钥S与对应的私钥S'，客⼾端拥有公钥C与对应的私钥C'
客⼾和服务端交换公钥
客⼾端给服务端发信息：先⽤S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥S'
服务端给客⼾端发信息：先⽤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已经成功成为中间人。

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

上面的攻击方案，同样适用于方案2，方案3

问题本质出在哪里了呢？客户端无法确定收到的含有公钥的数据报⽂，就是目标服务器发送过来的！因此需要引入证书认证。

方案 5 - 非对称加密 + 对称加密 + 证书认证

客户端进行认证

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

判定证书的有效期是否过期
判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的

原文地址:https://blog.csdn.net/lzb_kkk/article/details/136348780 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：https://www.suanlizi.com/kf/1768207957369163776.html 如若内容造成侵权/违法违规/事实不符，请联系《酸梨子》网邮箱：1419361763@qq.com进行投诉反馈，一经查实，立即删除！

阅读全部