应用层协议(Https)(超详解)

前言:

https是在http基础上的进行一些"加密"操作,也可以认为是http的强化版。

在下面展开对https的讨论中,可能不会再涉及到http的相关协议,如有对http的疑惑或是其他不一样的看法可以浏览上一篇文章:应用层协议(Http)(超详解)-CSDN博客

欢迎留言一起交流技术!!

Https:

Https是什么,和Http有什么关系?

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

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

例如:

当我们需要在浏览器上面下载一个应用程序,有的时候,**我们点击下载,发现下载的程序并不是我们想要的,会自定开始下载"迅雷加速,360、qq浏览器......",**当有这些情况出现的时候,那么大概率你被"运营商劫持 "了!!

此时从客户端发给服务器的请求被运营商劫持,并充当服务器发送响应请求,此时响应请求里面url的路径就会被篡改!!如下图:

那么以前只有http西医的时候,这样的情况是时常发生的。

现如今有了https的加入,这样的情况发生的概率大幅度下降!!

加密:

加密是什么?如何加密?

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

解密就是把 密⽂ 再进⾏⼀系列变换, 还原成 明⽂
在这个加密和解密的过程中, 往往需要⼀个或者多个中间的数据, 辅助进⾏这个过程, 这样的数据称为密钥

加密方法:

对称加密:

加密和解密使用同一把密钥。


引⼊对称加密之后, 即使数据被截获, 由于⿊客不知道密钥是啥, 因此就⽆法进⾏解密, 也就不知道请求的真实内容是啥了.
因此再客户端与服务器建立链接的时候,有一个"协商密钥"的过程,但是这个过程中密钥还是会被泄露出去,如下图:

此时黑客可以充当中间站获取"密钥",还是非常不安全,所以此时引入"非对称加密"。

非对称加密:

有一对密钥A和B:

如果A负责加密,B就负责解密;

如果B负责加密,A就负责解密;

注:公开出来的密钥叫做"公钥",私藏起来的密钥叫做"私钥"。

最⼤的缺点就是运算速度⾮常慢

有两种用法:

1.通过公钥对明⽂加密, 变成密⽂
通过私钥对密⽂解密, 变成明⽂
也可以反着⽤
2.通过私钥对明⽂加密, 变成密⽂
通过公钥对密⽂解密, 变成明⽂


客⼾端在本地⽣成对称密钥, 通过公钥加密 , 发送给服务器.
由于中间的⽹络设备没有私钥, 即使截获了数据, 也⽆法还原出内部的原⽂, 也就⽆法获取到对称密 钥
服务器通过私钥解密, 还原出客⼾端发送的对称密钥. 并且使⽤这个对称密钥加密给客⼾端返回的响应数据.
后续客⼾端和服务器的通信都只⽤对称加密即可. 由于该密钥只有客⼾端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义。
当然这样的想法很好,但是有一个问题:

客户端时如何获取到"公钥"呢??

中间人攻击:

在上述过程中,非对称加密实则是对"对称加密"而加密,也就是公钥负责对对称密钥加密。私钥对公钥解密拿到对称密钥。

针对上述的问题,我们需要清楚:客户端拿到的公钥是由"服务器"发来的,此时还是涉及到一个被劫持的情况:

此时"黑客"可以充当中间人:

具体过程如下:

  1. 服务器具有⾮对称加密算法的公钥S,私钥S'
  2. 中间⼈具有⾮对称加密算法的公钥M,私钥M'
  3. 客⼾端向服务器发起请求,服务器明⽂传送公钥S给客⼾端
  4. 中间⼈劫持数据报⽂,提取公钥S并保存好,然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M,并将伪造报⽂发给客⼾端
  5. 客⼾端收到报⽂,提取公钥M(⾃⼰当然不知道公钥被更换过了),⾃⼰形成对称秘钥X,⽤公钥M加密X,形成报⽂发送给服务器
  6. 中间⼈劫持后,直接⽤⾃⼰的私钥M'进⾏解密,得到通信秘钥X,再⽤曾经保存的服务端公钥S加密后,将报⽂推送给服务器
  7. 服务器拿到报⽂,⽤⾃⼰的私钥S'解密,得到通信秘钥X
  1. 双⽅开始采⽤X进⾏对称加密,进⾏通信。但是⼀切都在中间⼈的掌握中,劫持数据,进⾏窃听甚⾄修改,都是可以的。
    一招"偷梁换柱"就可以实现"监视"!!
    为了更好的解决上述存在的问题,引入新的机制:" 证书机制"。

引入证书:

解决上述"中间人"攻击的关键就是需要让"客户端"识别出自己拿到的"公钥"是不是是由服务器发出的真的"公钥"。

如何证明呢?此处引入第三方"公证机构"。

如果想搭建自己的服务器,就必须在公证机构这里申请"证书",向公证机构提交材料,

包括:网络域名,营业执照,备案号......
需要注意的是:申请证书的时候,需要在特定平台⽣成查,会同时⽣成⼀对⼉密钥对⼉,即公钥和私钥。这对密钥对⼉就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。
此时服务器发给客户端的就不止是一个普通的"公钥"了,而是"完整的证书"。
此时客户端可以对"证书"上的数字签名进行合法性校验。
这个数字签名的由来如下:
当服务端申请CA证书的时候,CA机构会对该服务端进⾏审核,并专⻔为该⽹站形成数字签名,过程如下:

  1. CA机构拥有⾮对称加密的私钥A和公钥A'
  2. CA机构对服务端申请的证书明⽂数据进⾏hash,形成数据摘要
  3. 然后对数据摘要⽤CA私钥A'加密,得到数字签名S
    服务端申请的证书明⽂和数字签名S 共同组成了数字证书 ,这样⼀份数字证书就可以颁发给服务端了

    当客⼾端获取到这个证书之后, 会对证书进⾏校验(防⽌证书是伪造的).
    1.判定证书的有效期是否过期
    2.判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
    3.验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对⽐ hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的。

常见问题:

1.黑客会不会篡改证书?

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

2.黑客可不可以之间掉包证书,换成自己的证书?

这个确实能做到证书的整体掉包,但是别忘记,证书明⽂中包含了域名等服务端认证信息,如果整体掉包,客⼾端依旧能够识别出来。
永远记住:中间⼈没有CA私钥,所以对任何证书都⽆法进⾏合法修改,包括⾃⼰的

3.客户端最后如何解析服务器传过来的密文的?

由于摘要内容在网络传输过程中都是以hash值的方式加密传输,该加密是由签证机构自己的私钥进行一系列的加密的,最后只能由该公证机构的公钥进行hash值解密,最后拿到密文。

客⼾端通过操作系统⾥已经存的了的证书发布机构的公钥进⾏解密, 还原出原始的哈希值, 再进⾏校验。

相关推荐
禁默2 分钟前
深入浅出:Java 抽象类与接口
java·开发语言
小万编程1 小时前
【2025最新计算机毕业设计】基于SSM的医院挂号住院系统(高质量源码,提供文档,免费部署到本地)【提供源码+答辩PPT+文档+项目部署】
java·spring boot·毕业设计·计算机毕业设计·项目源码·毕设源码·java毕业设计
白宇横流学长1 小时前
基于Java的银行排号系统的设计与实现【源码+文档+部署讲解】
java·开发语言·数据库
123yhy传奇1 小时前
【学习总结|DAY027】JAVA操作数据库
java·数据库·spring boot·学习·mybatis
想要打 Acm 的小周同学呀1 小时前
亚信科技Java后端外包一面
java·求职·java后端
像污秽一样3 小时前
《计算机网络A》单选题-复习题库解析-最终
网络·计算机网络
lishiming03085 小时前
TestEngine with ID ‘junit-jupiter‘ failed to discover tests 解决方法
java·junit·intellij-idea
HEU_firejef5 小时前
设计模式——工厂模式
java·开发语言·设计模式
云计算DevOps-韩老师5 小时前
【网络云SRE运维开发】2024第52周-每日【2024/12/31】小测-计算机网络参考模型和通信协议的理论和实操考题
开发语言·网络·计算机网络·云计算·运维开发