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

总结 HTTPS 的加密流程

目录

1 HTTPS是什么

2 "加密"是什么

3 HTTPS的⼯作过程

3.1 引⼊对称加密

3.2 引⼊⾮对称加密

3.3 中间⼈攻击

3.4 引⼊证书


1 HTTPS是什么

HTTPS也是⼀个应⽤层协议.是在HTTP协议的基础上引⼊了⼀个加密层.

HTTP协议内容都是按照⽂本的⽅式明⽂传输的.这就导致在传输过程中出现⼀些被篡改的情况.

上篇文章中已经介绍到了臭名昭著的运营商劫持案件, 这里再介绍一下.

下载⼀个天天动听 未被劫持的效果,点击下载按钮,就会弹出天天动听的下载链接

已被劫持的效果,点击下载按钮,就会弹出QQ浏览器的下载链接

由于我们通过⽹络传输的任何的数据包都会经过运营商的⽹络设备(路由器,交换机等),那么运营商的⽹络设备就可以解析出你传输的数据内容,并进⾏篡改.点击"下载按钮",其实就是在给服务器发送了⼀个HTTP请求,获取到的HTTP响应其实就包含了该 APP的下载链接.运营商劫持之后,就发现这个请求是要下载天天动听,那么就⾃动的把交给⽤⼾的响应 给篡改成"QQ浏览器"的下载地址了.

思考下,为啥运营商要进⾏劫持? 因为劫持了他们会有钱呗.

不⽌运营商可以劫持,其他的⿊客也可以⽤类似的⼿段进⾏劫持,来窃取⽤⼾隐私信息,或者篡改内容. 试想⼀下,如果⿊客在⽤⼾登陆⽀付宝的时候获取到⽤⼾账⼾余额,甚⾄获取到⽤⼾的⽀付密码..... 

在互联⽹上,明⽂传输是⽐较危险的事情!!!

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

2 "加密"是什么

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

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

在这个加密和解密的过程中,往往需要⼀个或者多个中间的数据,辅助进⾏这个过程,这样的数据称为密 钥(正确发⾳yue四声,不过⼤家平时都读作yao四声).

<83 版>,有⼈要谋反⼲掉慈禧太后.恭亲王奕䜣给慈禧递的折⼦.折⼦内容只是扯⼀扯 家常,套上⼀张挖了洞的纸就能看到真实要表达的意思.

明⽂:"当⼼肃顺,端华,戴恒"(这⼏个⼈都是当时的权⾂,后来被慈禧⼀锅端).

密⽂:奏折全⽂

密钥:挖了洞的纸

加密解密到如今已经发展成⼀个独⽴的学科:密码学.

⽽密码学的奠基⼈,也正是计算机科学的祖师爷之⼀,艾伦·⻨席森·图灵 

3 HTTPS的⼯作过程

既然要保证数据安全,就需要进⾏"加密".

⽹络传输中不再直接传输明⽂了,⽽是加密之后的"密⽂".

加密的⽅式有很多,但是整体可以分成两⼤类:对称加密⾮对称加密

3.1 引⼊对称加密

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

⼀个简单的对称加密,按位异或 假设明⽂a=1234,密钥key=8888

则加密a^key得到的密⽂b为9834. 然后针对密⽂9834

再次进⾏运算b^key,得到的就是原来的明⽂1234.

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

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

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

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

但是如果直接把密钥明⽂传输,那么⿊客也就能获得密钥了~~

此时后续的加密操作就形同虚设了. **因此密钥的传输也必须加密传输!** 但是要想对密钥进⾏对称加密,就仍然需要先协商确定⼀个"密钥的密钥".这就成了"先有鸡还是先有 蛋"的问题了.此时密钥的传输再⽤对称加密就⾏不通了.

就需要引⼊⾮对称加密.

3.2 引⼊⾮对称加密

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

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

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

• 通过私钥对密⽂解密,变成明⽂ 也可以反着⽤

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

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

⾮对称加密的数学原理⽐较复杂,涉及到⼀些数论相关的知识.

这⾥举⼀个简单的⽣活上的例⼦. A要给B⼀些重要的⽂件,但是B可能不在.于是A和B提前做出约定: B说:我桌⼦上有个盒⼦,然后我给你⼀把锁,你把⽂件放盒⼦⾥⽤锁锁上,然后我回头拿着钥匙来开锁 取⽂件.

在这个场景中,这把锁就相当于公钥,钥匙就是私钥.公钥给谁都⾏(不怕泄露),但是私钥只有B⾃⼰持 有.持有私钥的⼈才能解密.

• 客⼾端在本地⽣成对称密钥,通过公钥加密,发送给服务器.

• 由于中间的⽹络设备没有私钥,即使截获了数据,也⽆法还原出内部的原⽂,也就⽆法获取到对称密 钥

• 服务器通过私钥解密,还原出客⼾端发送的对称密钥.并且使⽤这个对称密钥加密给客⼾端返回的响应数据.

• 后续客⼾端和服务器的通信都只⽤对称加密即可.由于该密钥只有客⼾端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义.

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

那么接下来问题⼜来了:

• 客⼾端如何获取到公钥?

• 客⼾端如何确定这个公钥不是⿊客伪造的?

3.3 中间⼈攻击

⿊客可以使⽤中间⼈攻击,获取到对称密钥.

推荐大家去看看毒战, 这个就和下面的情形很相似.

1. 服务器具有⾮对称加密算法的公钥pub1,私钥pri1

2. 中间⼈具有⾮对称加密算法的公钥pub2,私钥pri2

3. 客⼾端向服务器发起请求,服务器明⽂传送公钥pub1给客⼾端

4. 中间⼈劫持数据报⽂,提取公钥pub1并保存好,然后将被劫持报⽂中的公钥pub1替换成为⾃⼰的公钥pub2, 并将伪造报⽂发给客⼾端

5. 客⼾端收到报⽂,提取公钥pub2(⾃⼰当然不知道公钥被更换过了),⾃⼰形成对称密钥888888,⽤公钥pub2加密888888,形成报⽂发送给服务器

6. 中间⼈劫持后,直接⽤⾃⼰的私钥pri2进⾏解密,得到通信密钥888888,再⽤曾经保存的服务端公钥pub1加密后,将报⽂推送给服务器

7. 服务器拿到报⽂,⽤⾃⼰的私钥pri1解密,得到通信密钥888888

8. 双⽅开始采⽤X进⾏对称加密,进⾏通信。但是⼀切都在中间⼈的掌握中,劫持数据,进⾏窃听甚⾄修改,都是可以

3.4 引⼊证书

解决中间人攻击的关键, 就是需要让客户端能够确认当前收到的公钥,确实是服务器返回的,而不是黑客伪造的!这就引入了证书机制. 需要有一个第三方的认证机构.通过第三方机构作保,来确认当前的公钥是有效的.服务端在使⽤HTTPS前,需要向CA机构申领⼀份数字证书,数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器,浏览器从证书⾥获取公钥就⾏了,证书就如⾝份证,证明服务端公钥的权威性.

平时上网的时候,访问一些奇怪的网站,浏览器可能会提示"证书错误,就说明刚才客户端进行证书验证的过程不通过.此时就会明确提示用户存在风险!!到了这一步,黑客仍然还有办法!黑客还可以把自己伪装成认证机构,骗客户端安装自己公钥.此时,就可以光明正大的替换掉证书中的数字签名. 所以最好小心无视风险安装.


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

相关文章:

  • 【栈数据结构应用解析:常见算法题详细解答】—— Leetcode
  • 计算机网络——路由器
  • 用 Vue 3.5 TypeScript 重新开发3年前甘特图的核心组件
  • HTML5 Web SQL
  • 我的创作纪念日 打造高效 Python 日记本应用:从基础搭建到功能优化全解析
  • Java EE Web环境安装
  • MCU详解:嵌入式系统的“智慧之心”
  • 【Prometheus】prometheus监控pod资源,ingress,service资源以及如何通过annotations实现自动化监控
  • 宝塔-服务器部署(1)-环境准备
  • 如何处理PHP中的日期和时间问题
  • HTML块级元素和内联元素(简单易懂)
  • vue/react/vite前端项目打包的时候加上时间最简单版本,防止后端扯皮
  • Centos7系统基于docker下载ollama部署Deepseek-r1(GPU版不踩坑)
  • plantuml画甘特图gantt
  • SpringBoot中使用AJ-Captcha实现行为验证码(滑动拼图、点选文字)
  • stm32u5
  • std::stack和std::queue
  • iOS OC匹配多个文字修改颜色和字号
  • Language Models are Few-Shot Learners,GPT-3详细讲解
  • 【最后203篇系列】014 AI机器人-2