小小小幸运 发表于 2024-10-2 18:15:14

[Linux#60][HTTPS] 加密 | 数字指纹 | 详解HTTPS工作方案 | CA认证

目录
一.预备知识
1. 什么是HTTPS?
2. HTTP与HTTPS的区别
3. 什么是加密?
4. 常见的加密方式
4.1 对称加密
4.2 非对称加密
4.3 数据择要与数据指纹
4.4 数字署名
二. HTTPS的工作方案
1 方案一:对称加密
2 方案二:非对称加密
3 方案三:两边使用非对称加密
4 方案四:非对称加密+对称加密
5 中心人攻击
三. 非对称+对称+CA 认证
1. CA认证与证书
原理:
常见问题:
2. HTTPS 的完整工作流程
随着互联网的发展,信息安全越来越受到重视。传统的HTTP协议由于明文传输,极易受到中心人攻击和信息篡改。为相识决这一问题,HTTPS应运而生。本文将详细探究HTTPS协议的工作原理、HTTP与HTTPS的区别、加密技术的应用以及怎样通过证书认证保障安全通讯。
一.预备知识

1. 什么是HTTPS?

HTTP协议无论是使用GET还是POST方法传输数据,都是以明文情势进行传输,这意味着传输过程中的数据很轻易被拦截或篡改。例如:

https://img-blog.csdnimg.cn/img_convert/4660af7546f6f5913c2793f050468bae.jpeg
HTTPS协议则通过在应用层和传输层之间增长一个加密层(SSL/TLS),为数据传输提供安全保障。
HTTPS的工作原理如下:

[*]当用户通过HTTPS访问网站时,数据起首被加密层处理,进行加密后再交给传输层。
[*]接收方在接收到数据后,同样通过加密层解密,解密后的数据再交给应用层使用。
[*]在整个传输过程中,只有在用户层数据是明文的,而网络中的传输数据始终处于加密状态。

https://img-blog.csdnimg.cn/img_convert/79c81d4cba70649d9b1839948710e2a9.jpeg
HTTPS 也是一个应用层协议. 只是在 HTTP 协议的基础上引入了一个加密层.
   加密方式的定义?
web 构造定义的
   站在一个黑客角度

[*]攻破成本>攻破后的收益,就可以认为是相对安全的
[*]ssl 有权势巨子的官方的加密解密方案
2. HTTP与HTTPS的区别

HTTP与HTTPS在工作方式和应用场景上有显著区别:


[*]端口差别:HTTP使用80端口,而HTTPS使用443端口。
[*]安全性:HTTP是明文传输,不安全;HTTPS则通过加密包管数据的安全性。
[*]效率:由于HTTPS须要进行加密解密操纵,因此效率略低于HTTP。在内网等安全情况下,可以考虑使用HTTP进步效率。
3. 什么是加密?

加密是将明文数据通过一定的规则转换成密文的过程,从而包管数据在传输过程中不会被非法获取或篡改。

https://img-blog.csdnimg.cn/img_convert/800135f7c154f9c6e419b99be420facb.jpeg
以下是加密相干的术语:


[*]明文:未加密的原始数据。
[*]密文:经过加密后的数据。
[*]加密:将明文转换为密文的过程。
[*]解密:将密文还原为明文的过程。
[*]密钥:用于加密和解密过程的核心数据。
4. 常见的加密方式

4.1 对称加密



[*]对称加密使用相同的密钥来进行加密和解密。
[*]特点:算法公开、加密速率快、计算量小。
[*]常见的对称加密算法:DES、AES、Blowfish等。
4.2 非对称加密



[*]非对称加密须要两个密钥:公钥和私钥。
[*]公钥:用于加密,私钥:用于解密,或反向操纵。
[*]常见的非对称加密算法:RSA、DSA等。
[*]虽然非对称加密的安全性更高,但由于算法复杂,效率较低。
4.3 数据择要与数据指纹



[*]数据择要通过Hash函数(如MD5、SHA256)将信息运算生成一个固定长度的字符串。
[*]择要的作用:快速判断数据是否被篡改,但不能反推出原始信息。
[*]和加密算法的区别是,择要严格意义上不是加密,因为没有解密
4.4 数字署名


https://img-blog.csdnimg.cn/img_convert/7795d93fed29cad6d44b686675cc1a66.jpeg
数字署名是对择要进行加密后的结果,用来确保数据的完整性和身份验证。
通过非对称加密技术,使用私钥对择要加密,接收方用公钥解密,经过比对,可以验证数据是否被篡改。

预备知识整理如下:

https://img-blog.csdnimg.cn/img_convert/06698f9e0d9ee10719fadbf2f4beee64.png
二. HTTPS的工作方案

既然要包管数据安全, 就须要进行 “加密”.
网络传输中不再直接传输明文了, 而是加密之后的 “密文”.
加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密
其实在网络通讯,我们要解决的是如下问题:

[*]数据被监听
[*]数据被篡改
1 方案一:对称加密

如果通讯两边都各自持有同一个密钥X,且没有别人知道,这两方的通讯安全当然是可以被包管的(除非密钥被破解)

https://img-blog.csdnimg.cn/img_convert/9f1f1e7d2795e12b12f9f98b4a2124e4.jpeg
服务器同一时刻其实是给很多客户端提供服务的. 这么多客户端, 每个⼈用的秘钥都必须是差别的(如果是相同那密钥就太轻易扩散了, ⿊客就也能拿到了). 因此服务器就须要维护每个客户端和每个密钥之间的关联关系, 这也是个很麻烦的事情~
缺点:
上面还不是最重要的,最重要的是最开始的时候我们怎么包管客户端和服务器看到的是同一个密钥。


[*]如果最开始客户端把密钥发给服务器,那这个密钥是明文传还是密文传?
[*]明文传那黑客不就拿到了,
[*]暗文加密传那就须要对密钥进行加密,就仍然须要先协商确定一个 “密钥的密钥”
这不就是鸡生蛋还是蛋生鸡的问题吗?所以纯纯使用对称加密是不可的!
2 方案二:非对称加密

通讯之前先得交换密钥,鉴于非对称加密的机制,用公钥和私钥都可以加密,但用公钥加密就要使用私钥解密,使用私钥加密就要使用公钥解密,所以可以尝试如下图操纵:

https://img-blog.csdnimg.cn/img_convert/5fb36c13207f93c621f1db0ddae440d8.jpeg
缺点:
现在只能包管从C->S的安全性(临时的安全),没有办法解决S->C的安全性。
没事我们在提第三种方案。
3 方案三:两边使用非对称加密


[*]服务端拥有公钥S与对应的私钥S’,客户端拥有公钥C与对应的私钥C’
[*]客户和服务端互相交换公钥
[*]客户端给服务端发信息:先用S对数据加密,再发送,只能由服务器解密,因为只有服务器有私钥S’
[*]服务端给客户端发信息:先用C对数据加密,在发送,只能由客户端解密,因为只有客户端有私钥C’

https://img-blog.csdnimg.cn/img_convert/04a03874e18d899b5e525a5364e8461e.jpeg
缺点:

[*]慢
[*]还是有安全问题,这是和方案二安全问题是一样的,下面在提它们的安全问题
4 方案四:非对称加密+对称加密

这种方案通过非对称加密进行密钥交换,之后的数据传输使用对称加密,从而分身了安全性和效率。具体流程如下:

[*]客户端发起HTTPS哀求,获取服务器的公钥。
[*]客户端生成一个对称密钥,并使用服务器的公钥加密后发送给服务器。
[*]服务器通过私钥解密,得到对称密钥。
[*]随后的通讯使用对称加密进行数据传输。

https://img-blog.csdnimg.cn/img_convert/b96b811c9c43059af8119ef1b949a01b.jpeg
前半部门采用非对称加密:交换密钥,后半部门采用对称加密:两边不存在了安全问题。既安全,又高效。
但真的没有问题了吗?
方案二、方案三、方案四都存在⼀个问题,如果最开始,中心⼈就已经开始攻击了呢?
5 中心人攻击

中心人攻击是指在客户端与服务器通讯的过程中,攻击者通过挟制并篡改数据进行窃听或伪造。
在方案2/3/4中,客户端获取到公钥S之后,客户端形成的对称秘钥C,然后用服务端给客户端的公钥S对C进加密,中心人纵然窃取到了数据,此时中心人确实无法解出客户端形成的密钥C,因为只有服务器有私钥S’。
但是中心人的攻击,如果在最开始握手协商的时候就进行了,那就不一定了,如果 M 在哀求公钥后就已经乐成成为了中心人


[*]客户端向服务器发起哀求,服务器明文传送公钥S给客户端
[*]中心人挟制数据报文,提取公钥S并保存好,然后将被挟制报文中的公钥S替换成为自己的公钥M,并将伪造报文发给客户端

https://img-blog.csdnimg.cn/img_convert/17522afd9e9e9bbd7f614f767189350e.jpeg
上面的攻击方案,同样适用于方案2、方案3
问题本质出在那里了呢?
服务器返回公钥的时候,被中心人窃取并替换了&&客户端没有辨别公钥是否合法的本领
下面要围绕 客户端可以或许具有辨别服务器发过来的公钥的合法性! 来解决问题,避免公钥被替换
为了防止这种攻击,HTTPS引入了证书认证机制。
三. 非对称+对称+CA 认证

1. CA认证与证书

为了防止中心人篡改公钥,HTTPS采用了数字证书认证机制。CA(Certificate Authority)作为权势巨子的第三方机构,为服务器颁发数字证书,包管公钥的真实性。证书的验证流程如下:

https://img-blog.csdnimg.cn/img_convert/a567ac9e21e5af1c00c5b756031600a4.jpeg

[*]服务器向CA机构申请证书,CA机构对服务器的公钥进行署名并颁发证书。
[*]客户端在建立HTTPS连接时,会起首获取服务器的证书,并验证证书是否由可信的CA签发、是否逾期、是否被篡改。
[*]只有在证书验证通事后,客户端才会信任服务器,并使用其公钥进行加密通讯。
证书可以理解成是⼀个结构化的字符串,里面包含了以下信息:证书发布机构、证书有效期、公钥、证书所有者、署名等等

https://img-blog.csdnimg.cn/img_convert/73dc0605f6402764004caf259f2651cf.png
客户端可以或许具有辨别服务器发过来的公钥的合法性! 我们说是通过证书来进行甄别的,那证书怎样做到的呢?
原理:

署名:


[*]对一份文本(可以认为这里是CA证书内的明文信息)经过hash散列形成散列值,我们称之为数据择要。然后用署名者的私钥(CA机构的私钥)对数据择要加密形成了数据署名
[*]更重要的把这个数据署名和这个明文信息合在一起,形成数字署名的数据。
验证:


[*]把原始文本和署名分开,一个对原始文本使用相同的散列函数进行散列形成散列值,另一个对署名用署名者的公钥解密形成散列值
[*]然后对比两个散列值,如果这两个散列值不一样,就注定有人要么改了原始文件,要么改了署名。
[*]只要这两个散列值一样,那么原始文本和它曾经形成的署名是一样的,阐明这个原始文本没有被篡改过!

https://img-blog.csdnimg.cn/img_convert/ce5b7c1c301ff3ac0e63317e1078e540.png
通过验证可以确保:数据和署名的证书不被更改啦
起首说一下,CA为了签发证书,CA也有自己的CA公钥,CA私钥。
因为我们使用CA的私钥形成数据署名,所以只有CA能形成可信任的证书!(CA私钥只在CA)
实际验证场景:


[*]将证书上的明文数据和数字署名分开,把明文数据经过相同的hash映射(这个hash是公开的)形成数据择要。因为CA会在所有的浏览器中内置自己的公钥!
[*]所以浏览器会拿着CA公钥对CA曾经的数字署名进行解密!得到曾经原始数据的择要。然后对比两个择要。两者相等阐明证书内部没被串改,如果两者不相等阐明证书被篡改过。

https://img-blog.csdnimg.cn/img_convert/12459a955f2c370ca1edee76870e927b.jpeg
   ⭕中心人有没有可能篡改该证书?


[*]明文篡改:


[*]

[*]中心人可以尝试篡改证书的明文部门。
[*]但是,由于中心人不具备证书颁发机构(CA)的私钥,因此无法生成与篡改后的证书相匹配的有效数字署名。



[*]验证失败:


[*]

[*]如果证书被篡改,客户端会使用其存储的信任链中的CA公钥来验证证书署名。
[*]客户端将计算证书明文的哈希值,并用CA的公钥解密署名。
[*]如果哈希值不匹配,则表明证书已被篡改,客户端会认为证书不可信并中断连接。



[*]私钥加密:


[*]

[*]中心人不能使用自己的私钥来替换或重新加密证书,因为客户端会使用特定CA的公钥来验证署名。
[*]客户端将无法精确解密署名,从而检测到篡改。

   ⭕中心人整个掉包证书?


[*]证书掉包:


[*]

[*]纵然中心人试图用自己的合法证书来完全替换原始证书,这也会导致问题。
[*]证书包含了诸如域名等标识信息,这些信息必须与客户端正在访问的服务匹配。


https://img-blog.csdnimg.cn/img_convert/b1da48d828e256ce4f5bad8a7c581d7a.png


[*]

[*]如果证书中的域名与实际服务不符,客户端同样会拒绝接受该证书。

结论:


[*]中心人缺乏须要的CA私钥,无法对任何证书进行合法修改。
[*]证书包含的信息以及数字署名机制确保了纵然中心人尝试篡改或替换证书,客户端也能检测出非常并采取安全措施,如中断连接以防止埋伏的信息泄露。

   检察浏览器的受信任证书发布机构
Chrome 浏览器, 点击右上角的

https://img-blog.csdnimg.cn/img_convert/e73eb8d0822fe957ccec49fb5987eef3.png
选择 "设置", 搜索 "证书管理" , 即可看到以下界面. (如果没有,在隐私设置和安全性-> 安全里面找找)
,然后我们就可以检察到啦

https://img-blog.csdnimg.cn/img_convert/c83ec6efce6e4826acadd25d5d6add9b.png
常见问题:

   为什么择要内容在网络传输的时候一定要加密形成署名?


[*]MD5 特性:


[*]

[*]定长: 不论输入字符串的长度怎样,生成的 MD5 值都是固定长度(16 字节或 32 字节)。
[*]分散: 输入字符串的任何微小变化都会导致输出的 MD5 值显著差别。
[*]不可逆: 从原始字符串生成 MD5 值轻易,但从 MD5 值反推回原始字符串在理论上是不可能的。

由于这些特性,如果两个字符串具有相同的 MD5 值,则可以认为这两个字符串是相同的。这使得 MD5 可以用来验证数据完整性。
理解证书篡改的判定过程:


[*]假设有一个简单的字符串 "hello" 作为证书内容,其 MD5 值为 BC4B2A76B9719D91。
[*]如果 "hello" 被篡改为 "hella",则新的 MD5 值将完全差别,例如 BDBD6F9CF51F2FD8。
[*]当服务器发送 "hello" 和其对应的 MD5 值给客户端时,客户端可以通过重新计算 "hello" 的 MD5 来验证是否被篡改。

https://img-blog.csdnimg.cn/img_convert/2655a25bc548a5cabd25224786b28125.png
存在的问题:


[*]如果攻击者篡改了 "hello" 而且同时更新了相应的 MD5 值,那么客户端就无法检测到这种篡改。
解决方案:


[*]对证书明文进行哈希处理后,使用 CA 的私钥对哈希值进行加密形成署名。
[*]将明文+加密后的署名一起组成完整的 CA 证书,并发送给服务端。
[*]客户端接收证书后,使用操纵系统中预存的 CA 公钥解密署名,还原出原始哈希值,并与自己计算的哈希值对比,以此来验证证书的合法性。
   为什么署名不直接加密,而是要先hash形成择要?


[*]减少须要加密的数据量,从而加速数字署名的生成和验证速率。
   怎样成为中心人?


[*]ARP 诱骗: 在局域网内,攻击者通过监听 ARP 哀求广播包获取其他节点的 IP 和 MAC 地址信息,然后向受害者发送伪造的 ARP 应答,声称自己是另一台主机,从而使受害者的流量被重定向到攻击者处。
[*]ICMP 重定向攻击: 使用 ICMP 协议中的重定向报文类型,攻击者可以伪造一个 ICMP 重定向消息,使目标装备误以为攻击者提供了一个更优的路由路径,进而所有流量都被导向攻击者指定的位置。
[*]假 WiFi 和假网站: 攻击者设置虚假的无线网络接入点或模拟合法网站的界面,诱使用户连接并泄露敏感信息。
2. HTTPS 的完整工作流程

左侧都是客户端做的事情, 右侧都是服务器做的事情.

https://img-blog.csdnimg.cn/img_convert/3cf4b9b7a29473b509a1dab72dc707a0.png
⭕ HTTPS的完整工作流程涉及三组密钥:

[*]第一组密钥(非对称加密):用于验证证书的合法性。客户端通过CA的公钥验证服务器证书是否被篡改。
[*]第二组密钥(非对称加密):用于加密传输对称密钥。客户端使用服务器的公钥加密对称密钥,服务器通过私钥解密。
[*]第三组密钥(对称加密):用于后续数据传输的加密解密操纵。
这个流程确保了客户端与服务器之间的通讯安全,避免数据在传输过程中被窃取或篡改。

   其实齐备的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.


[*]第⼆组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
[*](CA 认证中进行)第一组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥.
总结:
HTTPS通过非对称加密与对称加密的联合,再辅以CA证书认证,极大地进步了数据传输的安全性。在现在信息安全至关重要的时代,HTTPS已经成为网站保护用户隐私和数据安全的标准协议。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页: [1]
查看完整版本: [Linux#60][HTTPS] 加密 | 数字指纹 | 详解HTTPS工作方案 | CA认证