https传输流程(加密方式、证书、传输安全)

本文详细介绍了HTTP协议的明文传输风险以及为确保网络安全采取的加密措施,包括对称加密和非对称加密。讨论了非对称加密结合对称加密的方式,以及在HTTPS中防止中间人攻击的角色——证书和证书颁发机构(CA)。重点讲述了HTTPS的传输流程,包括证书验证、防止篡改的机制,以及中间人攻击的可能性和防范手段。
摘要由CSDN通过智能技术生成

http的缺点

http的数据是明文传输

如果用明文传输 很容易被第三方获取到传输的数据 因此我们一般要在网络传输过程中对数据进行加密

常见的加密方式

对称加密

秘钥key 待加密数据data

a和b是两个主机,它们都有秘钥key ,

a传输data会先用key进行加密,生成密文DATA,

b拿到DATA后再用key解密,获取到data

问题 key可能被第三方获取,从而得到原数据data

非对称加密

公钥publick_key 私钥private_key 可以公钥加密,私钥解密,也可以私钥加密,公钥解密

a第一次请求,b给a返回公钥,

a第二次请求,给b传输用公钥加密后的密文DATA

b收到后 用私钥解密DATA,拿到原数据data

由于私钥只有b才拥有,因此第三方无法获取私钥,自然无法对加密数据进行解密

问题如果b向a发送数据的话 如果用公钥加密 但a没有私钥 所以无法解密 ;如果用私钥加密,a用公钥解密,但是第三方也能拿到公钥。

既然都不行,那该怎么解决呢?

对称加密+非对称加密

  • 先使用非对称加密 得到公钥 再利用公钥生成一个传输秘钥 进行双方的数据传输
  • client第一次请求,server给client返回公钥,
  • client拿到公钥,再生成一个随机字符串,使用公钥对这个字符串进行加密,传给server
  • server收到后 用私钥解密出字符串,这个字符串用来作为之后双方进行数据传输的对称秘钥

问题 中间人攻击
clientserver请求公钥时 中间人拦截请求 并向client发送自己的公钥 因此中间人就可以在之后的传输过程中查看和篡改数据

中间人攻击的产生原因以及如何避免?

产生原因: 无法确认server的身份

需要有CA(证书颁发机构)对网站身份进行认证

申请证书

1,服务端将域名和公钥传给CA CA有自己的公钥和私钥,然后给服务端下发证书。

2,证书的内容主要有: 域名, 证书颁发机构相关信息, 用CA私钥加密过后的服务器公钥, 用CA私钥加密过后证书签名。

3,服务器会用CA公钥解密,获取证书签名 ,

4,证书签名是由服务器域名 + CA公钥 + 服务器公钥,通过hash算法加密而成的一段信息

5,证书签名用来验证是否被篡改

6,服务器收到证书,会用域名、 CA公钥、 自己公钥生成一个签名 检查该签名是否和证书的签名一致 一致则说明没有被篡改

https传输流程

  • clientserver发起请求 ,server先返回一个证书
  • 由于client的操作系统中存有ca的公钥 因此可以对证书的密文进行解密,获取到服务器的公钥和证书签名。
  • client验证证书签名 也就是用证书上的域名 + CA公钥 + 服务器公钥用hash算法进行加密 把加密结果和证书签名进行对比 若结果一致 就证明证书签名没有被篡改 没有被篡改的话 client就可以生成一个随机字符串
  • 随机字符串用服务器公钥进行加密,传给server
  • server收到后解密拿到随机字符串,作为之后双方传输数据的公钥

如果client获取到的证书是没有认证的 网页就会提示证书是不安全的

https传输过程中能否被篡改?

1.中间人能否篡改证书的公钥和证书签名?

由于每个CA公钥是公开的,所以中间人也有,能够揭秘获取到服务器公钥和证书签名,中间人如果想修改这两个数据,则需要用中间人自己的私钥进行加密,但是client会用CA公钥解密,自然是解不开的,所以无法篡改。

2.中间人能否篡改证书的域名?

验证签名的过程会出错,因为client需要将域名、 CA公钥、 自己公钥用hash算法生成一个签名,再和证书上的签名对比,此时发现不一致,则说明域名、 CA公钥、 自己公钥被篡改过了。

3.中间人能否在client请求证书时就拦截,并返回一个中间人自己的证书?

其实是可以的,但需要得到client的同意,信任此证书才行。这也是抓包工具可以截取到https传输过程中数据的原因。但也会有第三方利用这一点,出现个弹窗诱导用户点击,就可以给client植入“木马病毒”,这样就能获取和篡改clientserver的数据。

推荐阅读:

CSS 超出隐藏实现限制字数的功能代码(多浏览器支持)

JS函数集合大全

Javascript中最常用的61段经典代码

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

短暂又灿烂的

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值