前言:
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.通过私钥对明⽂加密, 变成密⽂
通过公钥对密⽂解密, 变成明⽂
客⼾端在本地⽣成对称密钥, 通过公钥加密 , 发送给服务器.
由于中间的⽹络设备没有私钥, 即使截获了数据, 也⽆法还原出内部的原⽂, 也就⽆法获取到对称密 钥
服务器通过私钥解密, 还原出客⼾端发送的对称密钥. 并且使⽤这个对称密钥加密给客⼾端返回的响应数据.
后续客⼾端和服务器的通信都只⽤对称加密即可. 由于该密钥只有客⼾端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义。
当然这样的想法很好,但是有一个问题:
客户端时如何获取到"公钥"呢??
中间人攻击:
在上述过程中,非对称加密实则是对"对称加密"而加密,也就是公钥负责对对称密钥加密。私钥对公钥解密拿到对称密钥。
针对上述的问题,我们需要清楚:客户端拿到的公钥是由"服务器"发来的,此时还是涉及到一个被劫持的情况:
此时"黑客"可以充当中间人:
具体过程如下:
- 服务器具有⾮对称加密算法的公钥S,私钥S'
- 中间⼈具有⾮对称加密算法的公钥M,私钥M'
- 客⼾端向服务器发起请求,服务器明⽂传送公钥S给客⼾端
- 中间⼈劫持数据报⽂,提取公钥S并保存好,然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M,并将伪造报⽂发给客⼾端
- 客⼾端收到报⽂,提取公钥M(⾃⼰当然不知道公钥被更换过了),⾃⼰形成对称秘钥X,⽤公钥M加密X,形成报⽂发送给服务器
- 中间⼈劫持后,直接⽤⾃⼰的私钥M'进⾏解密,得到通信秘钥X,再⽤曾经保存的服务端公钥S加密后,将报⽂推送给服务器
- 服务器拿到报⽂,⽤⾃⼰的私钥S'解密,得到通信秘钥X
- 双⽅开始采⽤X进⾏对称加密,进⾏通信。但是⼀切都在中间⼈的掌握中,劫持数据,进⾏窃听甚⾄修改,都是可以的。
一招"偷梁换柱"就可以实现"监视"!!
为了更好的解决上述存在的问题,引入新的机制:" 证书机制"。
引入证书:
解决上述"中间人"攻击的关键就是需要让"客户端"识别出自己拿到的"公钥"是不是是由服务器发出的真的"公钥"。
如何证明呢?此处引入第三方"公证机构"。
如果想搭建自己的服务器,就必须在公证机构这里申请"证书",向公证机构提交材料,
包括:网络域名,营业执照,备案号......
需要注意的是:申请证书的时候,需要在特定平台⽣成查,会同时⽣成⼀对⼉密钥对⼉,即公钥和私钥。这对密钥对⼉就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。
此时服务器发给客户端的就不止是一个普通的"公钥"了,而是"完整的证书"。
此时客户端可以对"证书"上的数字签名进行合法性校验。
这个数字签名的由来如下:
当服务端申请CA证书的时候,CA机构会对该服务端进⾏审核,并专⻔为该⽹站形成数字签名,过程如下:
- CA机构拥有⾮对称加密的私钥A和公钥A'
- CA机构对服务端申请的证书明⽂数据进⾏hash,形成数据摘要
- 然后对数据摘要⽤CA私钥A'加密,得到数字签名S
服务端申请的证书明⽂和数字签名S 共同组成了数字证书 ,这样⼀份数字证书就可以颁发给服务端了
当客⼾端获取到这个证书之后, 会对证书进⾏校验(防⽌证书是伪造的).
1.判定证书的有效期是否过期
2.判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
3.验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对⽐ hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的。
常见问题:
1.黑客会不会篡改证书?
答案是: 由于他没有CA机构的私钥,所以⽆法hash之后⽤私钥加密形成签名,那么也就没法办法对篡改后的证书形成匹配的签名
如果强⾏篡改,客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致,则说明证书已被篡改,证书不可信,从⽽终⽌向服务器传输信息,防⽌信息泄露给中间⼈
2.黑客可不可以之间掉包证书,换成自己的证书?
这个确实能做到证书的整体掉包,但是别忘记,证书明⽂中包含了域名等服务端认证信息,如果整体掉包,客⼾端依旧能够识别出来。
永远记住:中间⼈没有CA私钥,所以对任何证书都⽆法进⾏合法修改,包括⾃⼰的
3.客户端最后如何解析服务器传过来的密文的?
由于摘要内容在网络传输过程中都是以hash值的方式加密传输,该加密是由签证机构自己的私钥进行一系列的加密的,最后只能由该公证机构的公钥进行hash值解密,最后拿到密文。
客⼾端通过操作系统⾥已经存的了的证书发布机构的公钥进⾏解密, 还原出原始的哈希值, 再进⾏校验。