深入解析 https

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 在使用HTTP协议时,数据传输是明文形式,容易遭受运营商劫持等安全问题,如篡改返回网页内容、修改Referer字段等。为解决这些问题,引入了HTTPS协议,它通过加密、认证和完整性保护,确保通信内容不被第三方窃听或篡改。HTTPS结合了对称加密和非对称加密,使用公钥加密对称密钥,私钥解密,确保数据安全性和传输效率。然而,中间人攻击仍可能破解这一机制,因此引入证书机制,客户端通过验证证书中的数字签名来确认公钥的有效性,从而保障数据传输的安全性。


1. 背景介绍

在使用 http 协议的时候是不安全的,可能会出现运营商劫持等安全问题,运营商通过劫持 http 流量,篡改返回的网页内容,例如广告业务,可能会通过 Referer 字段 来统计是从哪个页面转接进来的,但是运营商就可能把信息改为自己的,也就是从运营商点击的广告,从而侵害原厂商的的利益,出了这个案例,还可能会篡改其他的信息,使得用户在访问一些界面时强制跳转广告或者下载某个应用时,点击下载却下载了其他应用等等,这些问题都是由于 http 是明文传输的,所以就引入了 https

HTTPS 其实就是 HTTP 的安全版本, HTTPS通过加密、认证和完整性保护,确保通信内容不会被第三方窃听或篡改

先来介绍几个概念:

明文:要传输的原始数据

密文:把明文进行加密之后的数据

密钥:进行加密和解密的重要数据(辅助工具)

公钥:可以公开的密钥,通常可以广泛的分发给任何需要的人

私钥:严格保密的密钥,只有密钥所有者才知道,与公钥成对出现,用于解密由客户端使用服务器公钥加密后的数据

对称加密:不论是加密还是解密,都使用同一个密钥

非对称加密:使用公钥对数据进行加密,使用私钥对数据进行解密,例如,A 要向 B 发送机密信息,A 可以使用 B 的公钥对信息进行加密,B 收到加密信息后,使用自己的私钥进行解密。

为了防止上述的数据被篡改的安全问题,就需要把数据进行加密传输

2. 引入对称加密

image.gif

一般情况下都是多个客户端对应一个服务器,这些客户端在连接上服务器之后需要自己生成一个随机的对称密钥给服务器,服务器拿到这个密钥之后才能解密,如果多个客户端使用同一个密钥,那么黑客登录一个客户端就之后密钥是什么了

但是上面的过程还是存在一个问题的:

image.gif

使用对称加密的话,这其实和不加密也没什么区别

3. 引入非对称加密

这里是在之前使用对称加密的基础上引入了非对称加密,对对称加密的密钥进行加密,那为什么不都使用非对称加密呢?非对称加密的的解密过程其实是比较消耗时间的,所以进行一次非对称加密,后续的进行对称加密既保证了数据的安全性,也保证了传输效率

客户端通过服务器的公钥对后续的对称加密的密钥进行加密,服务器通过私钥进行解密:

image.gif

在上面的过程中,被黑客入侵的中间设备由于没有私钥,所以不能解析客户端使用公钥加密的数据,后续再进行对称加密就保证了数据的安全性

不过呢,上面的还是有缺陷的,通过中间人攻击就可以破解

4. 中间人攻击

被黑客入侵的设备在客户端面前假扮服务器,在服务器面前假扮客户端,就能够骗过双方

image.gif

就像上面的过程那样,客户端并不知道当前的公钥是黑客伪造的,中间设备劫持上面的数据之后,使用 自己的私钥 pri2 就知道了对称密钥的内容,信息就会被泄露篡改了

5. 证书机制

其实上面问题的关键是客户端无法区分拿到的公钥是否是正常的,通过引入证书机制就可以解决上述的中间人攻击问题,如果想要搭建服务器使用 HTTPS 就需要在公证机构里申请证书(包括证书发布机构,证书有效期,证书所有者,公钥,签名等),服务器申请到证书之后,客户端除了从服务器获取公钥之外还会获取对应的证书。

证书中的签名包括校验和 + 加密,原始数据相同,计算的校验和也就相同,校验和不同就说明被篡改过了,这里的加密采用的是非对称加密,公证机构自己也会有一对公钥和私钥,公钥分发给各种客户端,公正机构用私钥对校验和进行加密,就得到了数字签名

之后的过程就是,客户端验证数字签名

  1. 客户端吧证书中的各个字段再计算一次校验和,得到 checksum1
  2. 客户端使用公证机构的公钥对数字签名进行解密,得到 checksum2(公钥加密只有对应的私钥才能解密,私钥加密,对应的公钥才能解密)
  3. 对比两次的校验和,如果相等就表明得到的证书和服务器发过来的是同一个证书,如果不相等就意味着证书上的内容被篡改过了,就会弹出警告的信息

那么客户端怎么确定拿到的公钥是公证机构的而不是黑客篡改过的?

客户端拿到公证机构的公钥主要通过操作系统或浏览器内置的方式获得,并不是通过网络传输获得的

一般情况下黑客获得不了公证机构的私钥,如果说黑客自己去生成一个私钥,客户端的公证机构的公钥也解密不了,所以通过引入证书机制就使得传输过程更加的安全了


Fiddler 等抓包工具为什么可以解析 HTTPS 加密的数据?

抓包工具也会提供一个证书,客户端同意信任之后就能够拿到客户端的对称密钥,大概是下面的过程:

image.gif

当服务器发送的证书被 Fiddler 抓到之后,就会篡改证书中的内容,变成自己的证书,然后把整数中服务器的公钥替换成自己的公钥,根据新生成的证书重新计算得到校验和,并且使用自己的私钥来加密,得到数字签名,由于已经信任了 Fiddler 的证书,也就拿到了 Fiddler 的公钥 ,之后也是使用这个公钥进行加密和对称密钥的加密

相关文章
|
6月前
|
移动开发 JSON 监控
网络协议解析:在员工上网监控软件中实现HTTP流量分析
随着企业对员工网络活动的监控需求不断增加,开发一套能够实现HTTP流量分析的网络协议解析系统变得愈发重要。本文将深入探讨如何在员工上网监控软件中实现HTTP流量分析,通过代码示例演示关键步骤。
279 0
|
3月前
|
安全 Nacos 数据安全/隐私保护
【技术干货】破解Nacos安全隐患:连接用户名与密码明文传输!掌握HTTPS、JWT与OAuth2.0加密秘籍,打造坚不可摧的微服务注册与配置中心!从原理到实践,全方位解析如何构建安全防护体系,让您从此告别数据泄露风险!
【8月更文挑战第15天】Nacos是一款广受好评的微服务注册与配置中心,但其连接用户名和密码的明文传输成为安全隐患。本文探讨加密策略提升安全性。首先介绍明文传输风险,随后对比三种加密方案:HTTPS简化数据保护;JWT令牌减少凭证传输,适配分布式环境;OAuth2.0增强安全,支持多授权模式。每种方案各有千秋,开发者需根据具体需求选择最佳实践,确保服务安全稳定运行。
293 0
|
4月前
|
存储 安全 搜索推荐
HTTPS协议深度解析
【7月更文挑战第12天】HTTPS协议通过加密通信和身份验证机制,为数据传输提供了强有力的安全保障。在现代互联网环境中,HTTPS已成为保障网站和用户数据安全的重要手段。了解HTTPS的工作原理和安全性特性,有助于更好地应用和维护HTTPS,提升网络安全水平。
|
4月前
|
数据安全/隐私保护
https【详解】与http的区别,对称加密,非对称加密,证书,解析流程图
https【详解】与http的区别,对称加密,非对称加密,证书,解析流程图
142 0
|
5月前
|
安全 网络安全 数据安全/隐私保护
深入解析HTTPS:安全机制全方位剖析
深入解析HTTPS:安全机制全方位剖析
|
6月前
|
域名解析 网络协议 安全
【域名解析DNS专栏】DNS-over-TLS与DNS-over-HTTPS:安全升级新标准
【5月更文挑战第26天】随着网络技术的发展,DNS协议面临安全挑战,DNS-over-TLS (DoT) 和 DNS-over-HTTPS (DoH) 作为解决方案出现,旨在通过加密增强隐私和安全。DoT使用TLS封装DNS查询,防止流量被窥探或篡改;DoH则利用HTTPS隐藏DNS查询。实施DoT需在客户端和服务器间建立TLS连接,DoH需DNS服务器支持HTTPS接口。这两种技术为网络安全提供支持,未来有望更广泛部署,提升网络环境的安全性。
553 0
|
6月前
|
安全 数据安全/隐私保护
深入解析:HTTP和HTTPS的三次握手与四次挥手
在这些握手和挥手过程中,双方交换信息,协商参数,建立或关闭连接,以保证数据的可靠传输。HTTPS在此基础上加入了数字证书验证和加密通信,增加了安全性。这些步骤确保了HTTP和HTTPS协议的通信过程的稳定和安全。
357 0
|
6月前
|
XML JSON 编解码
HTTP Content-Type 类型解析
【1月更文挑战第10天】HTTP Content-Type 类型解析
|
6月前
|
算法 安全 网络安全
HTTPS加密原理解析:保障通信安全的密码学算法
HTTPS加密原理解析:保障通信安全的密码学算法
593 0
|
6月前
|
移动开发 自然语言处理 网络协议
Http解析实现/服务器Get请求的实现
Http解析实现/服务器Get请求的实现
84 0

推荐镜像

更多
下一篇
无影云桌面