当前位置: 首页 > article >正文

深入理解HTTPS协议原理

目录

加密

对称加密

非对称加密

中间人攻击

证书

验证证书合法性

HTTPS工作原理

常见问题


HTTPS即安全超文本传输协议,是互联网上进行安全通信的一种重要协议。它是在HTTP的基础上增加了安全性的要求,通过SSL或TLS协议对数据进行加密,以确保数据传输过程中的安全性、完整性和身份认证。

加密

加密就是把 明文 (要传输的信息)进行一系列变换, 生成 密文 . 
解密就是把 密文 再进行一系列变换, 还原成 明文 . 
在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为密钥。

加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密。

对称加密
对称加密其实就是通过同一个 " 密钥 " , 把明文加密成密文 , 并且也能把密文解密成明文。
引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密, 也就不知道 
请求的真实内容是什么了。
但是事情并没有这么简单, 其一:客户端和服务器之间如何确定传输使用的对称密钥是什么?当客户端和服务器之间没有确定传输使用的对称密钥是什么时,必须通过明文传输确定传输使用的对称密钥是什么,但是这个时候对称密钥就可能会被黑客截获,因此这样是不可行的!!!
其二,服务器同一时刻其实是给很多客户端提供服务的,这么多客户端,每个客户端使用的密钥都必须是互不相同的,因为如果是相同的,那么黑客也可以请求服务器获取相同的密钥,黑客可以拿着这个密钥对截获的密文进行解密,这样就导致所谓的加密就没有任何意义了,那么在每个客户端使用的密钥都必须是互不相同的情况下,服务器就需要维护每个客户端和每个密钥之间的关联关系,这也是个很麻烦的事情!!!
因此密钥的传输也必须加密传输! 
但是要想对密钥进行对称加密, 就仍然需要先协商确定一个 "密钥的密钥". 这就成了 "先有鸡还是先有蛋" 的问题了. 此时密钥的传输再用对称加密就行不通了. 
就需要引入非对称加密.
非对称加密
非对称加密要用到两个密钥, 一个叫做 "公钥", 一个叫做 "私钥". 
公钥和私钥是配对的. 最大的缺点就是运算速度非常慢,比对称加密要慢很多。
通过公钥对明文加密, 变成密文
通过私钥对密文解密, 变成明文

也可以反着用:

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

不过,理解“公钥”还是“私钥”,是看它是公开的还是私有的,如果这个密钥是公开的,那么它就是“公钥”;如果它是私有的,这个密钥就是“私钥”。 

前面说到,使用非对称加密安全但是运算速度非常慢,使用对称加密不安全但是运算速度比较快,因此下面考虑将对称加密和非对称加密混合使用。

步骤

1.客户端向服务器发送请求,服务端通过非对称加密生成密钥,然后明文响应给客户端“公钥”;
2.虽然“公钥”可能会被黑客截获,但是没有关系,并没有影响;
3.客户端收到服务端发过来的响应,响应中包含服务器发过来的“公钥”;
4.客户端通过对称加密生成密钥,然后使用服务器的“公钥”对这个通过对称加密生成的密钥进行加密,然后将加密后的密钥发送给服务器;
5.虽然被加密后的密钥可能会被黑客截获,但是黑客并没有服务器的“私钥”,因此不能对密钥进行解密,因此没有影响;
6.服务器收到客户端使用服务器的“公钥”加密后的密钥,服务器使用自己的“私钥”进行解密,就能够得到客户端的密钥了;
7.后续,服务器和客户端就使用客户端的密钥对消息进行加密,因为黑客并不知道这个密钥,因此就没办法对密文进行解密,因此服务器和客户端之间的消息传送是安全的。

但是,这样就真的做到绝对的“万无一失,滴水不漏”了吗?

其实并没有做到,针对上述情况还存在“中间人攻击”。

中间人攻击

步骤

1.服务器通过非对称加密生成公钥X,私钥X';

2.中间人通过非对称加密生成公钥Y,私钥Y';

3.客户端向服务器发起请求,服务器将自己的公钥X明文发送给客户端;

4.中间人截获服务器发送的含有公钥X的明文,然后将其中的公钥X替换成自己的公钥Y,并将公钥X记录保存下来,然后再将报文发送给客户端;

5.客户端收到报文后,此时客户端并不知道报文中的公钥已经被替换过了,客户端使用对称加密生成密钥M,然后使用报文中的公钥Y对自己的密钥进行加密,然后发送给服务器;

6.中间人截获客户端发送的报文,然后使用自己的私钥Y'进行解密,就能够得知客户端的密钥了,然后将这个密钥M使用公钥X进行加密,然后再发送给服务器;

7.服务器收到报文后,并不知道报文已经被中间人做过手脚,服务器使用自己的私钥X'进行解密,得到客户端的密钥M,后续服务器和客户端的消息通过密钥M进行加密和解密;

8.但是后续服务器和客户端发的消息都可以被中间人截获并解密,因为中间人知道密钥M.

图解

我们想一下,为什么会导致上述情况的发生,原因就是因为客户端和服务器并不知道报文是否被动了手脚。

那么如何解决这个问题,使用第三方机构的“证书”。

证书

日常生活中,有些人的行为举止可能会引起警察蜀黍的怀疑,这个时候警察蜀黍可能会查看这个人的“身份证”来辨别这个人是不是好人,此时“身份证”就相当于下面我们要讲解的“证书”,那么二者有何相似之处?

身份证是国家颁发的,是非常权威的,包含的信息有:姓名,住址,身份证号,办理机构,有效日期。

证书也是第三方权威机构颁发的,包含的信息有:颁发机构,有效日期,申请办理机构的公钥,证书所有者,数字签名(对除此之外的其他信息得到的哈希值使用权威机构的私钥加密后得到的值)。

验证证书合法性

每台机器都自带权威机构的公钥,机器收到含证书的报文后,使用内置公钥对数字签名进行解密得到哈希值,然后对除数字签名之外的其他信息计算得到哈希值,通过比较两个哈希值是否相等来判断证书是否被动了手脚。

如果有人对证书动了手脚,比如将证书中的公钥进行替换,那么之后在验证证书时,对除数字签名之外的其他信息计算得到哈希值,和使用内置公钥对数字签名进行解密得到哈希值会不相同;其他情况亦能判断出证书的真假。

HTTPS工作原理

加密方式为  对称加密+非对称加密+引入证书。

常见问题

中间⼈有没有可能篡改该证书?

• 中间⼈篡改了证书的明⽂
• 由于他没有CA机构的私钥,所以⽆法hash之后⽤私钥加密形成签名,那么也就没法办法对篡改后的证书形成匹配的签名
• 如果强⾏篡改,客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致,则说明证书已被篡改,证书不可信,从⽽终⽌向服务器传输信息,防⽌信息泄露给中间⼈

中间⼈整个掉包证书?

• 因为中间⼈没有CA私钥,所以⽆法制作假的证书(为什么?)
• 所以中间⼈只能向CA申请真证书,然后⽤⾃⼰申请的证书进⾏掉包
• 这个确实能做到证书的整体掉包,但是别忘记,证书明⽂中包含了域名等服务端认证信息,如果整体掉包,客⼾端依旧能够识别出来。
• 永远记住:中间⼈没有CA私钥,所以对任何证书都⽆法进⾏合法修改,包括⾃⼰的 

为什么签名不直接加密,⽽是要先hash形成摘要?

• 缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度 

如何成为中间⼈?

• ARP欺骗:在局域⽹中,hacker经过收到ARP Request⼴播包,能够偷听到其它节点的 (IP, MAC)地址。例, ⿊客收到两个主机A, B的地址,告诉B (受害者) ,⾃⼰是A,使得B在发送给A 的数据包都被⿊客截取。
• ICMP攻击:由于ICMP协议中有重定向的报⽂类型,那么我们就可以伪造⼀个ICMP信息然后发送给局域⽹中的客⼾端,并伪装⾃⼰是⼀个更好的路由通路。从⽽导致⽬标所有的上⽹流量都会发送到我们指定的接⼝上,达到和ARP欺骗同样的效果 。

 


http://www.kler.cn/a/375134.html

相关文章:

  • 05-07实现面向对象领域模型-停车案例
  • 如何批量裁剪图片?5个软件帮助你快速进行图片裁剪
  • Redis高频面试题
  • 【真题笔记】15年系统架构设计师要点总结
  • LLMs在股票投资组合崩溃中的时间关系推理
  • 方差和标准差哪些事儿
  • 闲一品交易新趋势:SpringBoot技术应用
  • 【Java SE】类型转换
  • 数据源分层开发和连接池
  • 资深项目经理推荐的这五款国产项目管理软件值得收藏使用
  • Pyhton自动化测试持续集成和Jenkins
  • maven 学习笔记:20241024
  • HJ38 求小球落地5次后所经历的路程和第5次反弹的高度
  • 使用Linux连接阿里云
  • 后端检测_文件头检测漏洞
  • 多处理机调度(李昂学长视频总结)25新增考点
  • 探索Python终端美化的终极利器:Rich库
  • SCRM系统的价格揭秘及投资回报分析
  • 边缘计算网关在机床数据采集中的应用-天拓四方
  • pandas——DataFrame
  • 多模态大模型的应用探索:多样场景下的创新实践
  • sql练习专场(一) 1-5
  • Linux·进程间通讯(管道)
  • python/Django创建应用(app)
  • 逗号运算符应用举例
  • SpringBoot国际化:创建多语言支持的Web应用