关于HTTPS及SSL证书的白话理解

协议 专栏收录该内容
1 篇文章 0 订阅

看了几篇关于这方面的帖子,用白话说说自己的理解
http是明文传输,密码都能被人抓包轻易获取,所以不安全,
https本质还是http,它只是对传输内容进行加密后再传输,就算被抓包了,没有秘钥也无法解密内容

说起来简单,就是加密后再传输而已,但是中间还有很多细节要考虑,所以这件事情就变得复杂了,我们之所以看不太懂,
主要还是不知道是什么原因导致为什么要这么处理。
如果世界上还没有https协议,今天老大把这个任务分给你,说http明文传输不安全,你把数据加密后再传输,
你一想,这还不简单,分分钟的事情,就用AES加解密,客户端和服务端约定一个秘钥就行了,然后再把所有发请求的地方统一改成加密后再发请求(或者封装一个加密发请求的方法),
再深入想一下,问题就出来了:

问题一:
这个秘钥客户端怎么获取呢?写死在客户端?可是web都是可以看到源码的,你写死在客户端了,别人就可以查看网站源码找到这个秘钥,照样不安全。

看看https的解决办法:
既然这个秘钥你能想办法看到,那就让你看呗,干脆公开,搞两个秘钥,一个给所有客户端,都可以看到,就是公钥,另一个只存放于服务器端,叫私钥, 然后让这两个秘钥达到一个目的------公钥加密的数据只有私钥可以解密,私钥加密的数据只有公钥才能解密。

看了https的解决办法,是不是感觉很棒,这样就没问题了吗?
仔细一分析,客户端用公钥加密后传输,被人把数据抓包了,他没有私钥解密不了,但是服务器返回数据用私钥加密,他可以用公钥将服务器返回的数据解密,所以还是存在安全隐患

问题二:
怎么防止服务器返回的数据被别人抓包后用公钥解密?
你又陷入了沉思。还是看https怎么解决的吧:
客户端自己随机生成一个字符串(随机串临时生成,只存在与内存中,别人获取不到),用这个随机串作为秘钥对数据进行加密,然后用公钥对这个随机串加密,最后发送给服务器的数据就是--------用随机串加密的数据 + 用公钥加密的随机串。
要想解密这个数据, 首先得用私钥解密已加密的随机串,得到随机串的明文后,用这个明文对数据进行解密,所以,这个数据被人抓包了也没用,因为他没有私钥解不开随机串,也就更不能解密数据。
然后服务器返回数据时,用客户端发送过来的随机串对数据加密后返回数据,这时服务器返回的数据即便被人抓包了,也没办法解析,就算你花很大的力气来破解这个随机串,但是我们可以每次请求都产生一个新的随机串,让你破了随机串也没用。

问题都解决了?
是的
公钥写死在客户端(后面所说的客户端内置公钥),确实就没问题了,但是公钥写死在客户端,然后自己在客户端和服务端都要做加解密的处理逻辑,你觉得方便吗,LOW吗?肯定希望浏览器和服务器内置这个加解密的功能, 我只要在地址栏输入的是https就行了,所以这就要形成一个通用协议,于是https就这样产生了,写服务器的人(比如写apache、tomcat)就要实现https协议, 写浏览器的人(比如chrome、firfox)也要实现https协议,这样https就通用了,
既然加解密都交给浏览器和服务器了, 那我们就要将公钥给客户端,私钥给服务器,让它们自动帮我们加解密, 那怎么样将公钥给客户端了?

问题三
客户端怎么获得公钥?
当然是从服务器上获取, 所以服务器上存放这公钥和私钥, 客户端可以从服务器上获取公钥,
只是获取的不光是公钥,而是SSL 证书,证书里面包含了公钥和一些其他信息。
SSL证书可以购买,也可以自己生成,有什么区别了?
本质是一样的,只是一个有名分(由具有公信力的公司颁发),一个没有名分;就像一颗树上长的苹果,贴个标了卖5元1斤,没贴标卖2元1斤。
经常会看到根证书、中间证书这些词,有什么区别?
可以看这个 https://blog.csdn.net/sj349781478/article/details/85049221
浏览器如何验证SSL证书?

1,在IE浏览器的菜单中点击“工具 /Internet选项”,选择“内容”标签,点击“证书”按钮,然后就可以看到IE浏览器已经信任了许多“中级证书颁发机构”和“受信任的根证书颁发机构。当我们在访问该网站时,浏览器就会自动下载该网站的SSL证书,并对证书的安全性进行检查。

2,由于证书是分等级的,网站拥有者可能从根证书颁发机构领到证书,也可能从根证书的下一级(如某个国家的认证中心,或者是某个省发出的证书)领到证书。假设我们正在访问某个使用 了 SSL技术的网站,IE浏览器就会收到了一个SSL证书,如果这个证书是由根证书颁发机构签发的,IE浏览器就会按照下面的步骤来检查:浏览器使用内置的根证书中的公钥来对收到的证书进行认证,如果一致,就表示该安全证书是由可信任的颁证机构签发的,这个网站就是安全可靠的;如果该SSL证书不是根服务器签发的,浏览器就会自动检查上一级的发证机构,直到找到相应的根证书颁发机构,如果该根证书颁发机构是可信的,这个网站的SSL证书也是可信的。

那么浏览器从哪些方面验证SSL服务器证书的?
第一,检查SSL 证书是否是由浏览器中“受信任的根证书颁发机构”颁发,如果不是,则浏览器会有安全警告,例如:IE7 浏览器的警告信息为“此网站出具的安全证书不是受信任的证书颁发机构颁发的,安全证书问题可能显示试图欺骗您或截获您向服务器发送的数据,建议关闭此网页,并且不要继续浏览该网站。而”IE6浏览器会提示 “该安全证书由您没有选定信任的公司颁发”。

第二,检查SSL证书中的证书吊销列表,检查证书是否被证书颁发机构吊销?如果已经被吊销,则会显示警告信息:“此组织的证书已被吊销。安全证书问题可能显示试图欺骗您或截获您向服务器发送的数据。建议关闭此网页,并且不要继续浏览该网站。”

第三,检查此SSL证书是否过期?如果证书已经过了有效期,则会显示警告信息:“此网站出具的安全证书已过期或还未生效。安全证书问题可能显示试图欺骗您或截获您向服务器发送的数据。建议关闭此网页,并且不要继续浏览该网站。”

第四,检查部署此SSL证书的网站的域名是否与证书中的域名一致?如果不一致,则浏览器也会显示警告信息:“此网站出具的安全证书是为其他网站地址颁发的。安全证书问题可能显示试图欺骗您或截获您向服务器发送的数据。建议关闭此网页,并且不要继续浏览该网站。”

第五,IE7浏览器会到欺诈网站数据库查询此网站是否已经被列入欺诈网站黑名单?如果是,则会显示:“IE已发现一个已报告的仿冒网站。仿冒网站假冒其他网站并试图欺骗您泄漏个人信息或财务信息。建议关闭此网页,并且不要继续浏览该网站。”

好了, 公钥放到了SSL证书中,而且将SSL证书放到了服务器上,让浏览器自己从服务器上下载,这下你安心的笑了,以为这样就安全了,殊不知你还没考虑代理服务器的坑,因为证书在下载的过程中可以被替换!
啥?代理服务器就能把我这么严密的方案破了?
是的,SO EASY !

那你说代理服务器怎么破这么严密的方案?
假设代理服务器有它自己的SSL证书(且叫proxy), 你要访问的真实网站也有自己的SSL证书(且叫real),
浏览器向代理proxy发起请求,告知要访问real, 这时proxy 将自己的SSL证书返给浏览器,然后向real发起请求,得到real的SSL证书存放在本地,当浏览器发送数据给proxy时,由于浏览器用的是proxy的SSL证书中的公钥加密的,所以proxy可以解密数据,然后用real的公钥加密后发给real,real返回数据后,proxy用real的公钥解密数据,然后用proxy的私钥加密数据返给浏览器,浏览器用proxy的公钥解密数据,我们可以看到这个过程中,不论是浏览器发出的还是收到的数据,都被proxy完全拿到了。

问题四:
如何防止代理服务器替换证书?
只有客户端内置SSL证书,比如我们在做一些APP时,最好内置SSL证书,防止别人利用fiddler之类的进行证书替换

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值