背景
网络安全需求
在浏览器bs模式下交互中,我们考虑数据安全性一般会从一下几个方面着想 : ① 内容可以明文公开,但是不能被修改 ② 内容不能被公开,且不能被修改 ③ 请求不能被伪造
http请求的不安全性
http请求在应用层之外被抓包后可以对参数进行篡改,进而对用户的商业行为或敏感行为进行破坏.
https技术
非对称加密
因为有了以上缺点,http请求的网络安全性需求也就出现了,很直接我们能想到防止数据泄露的手段就是进行加密. 但是普通的对称性加密不能满足 b/s架构的交互场景, 因为对称性加密势必需要传输加密的秘钥,此时线上传输一定是不可行的,那相当于把密文和秘钥都给别人看了. 但每次线下同步秘钥也不太现实.
此时,我们看到非对称加密的特性可以让服务端和客户端之间的加密通信比较可靠,因为这种加密方式即便传递公钥,密文也是无法解密的.
非对称性加密的特点 : ① 公私钥是相对的 ② 公钥加密,私钥解密 ③ 单方面的加密是不可逆的.
CA机构
即使我们可以使用非对称性加密的公钥进行加密数据并传输,但是我们并不能鉴别手上对方公钥的真实性:
我们不知道拿到手的公钥到底是网站官方的公钥,还是中间人自己中途掉包之后给你的公钥. 如果我们使用了被掉包的公钥,那么中间人是有私钥的,这时候我们的信息就能轻而易举的被中间人解密. 这时候,我们需要一个第三方信任机构来为我们的网站颁发公钥,这就是CA机构.
CA将网站公钥(以 BUUKLE.PUB为例)和站点资料(url:www.buukle.top...) 打包用CA的私钥(CA.KEY)加密生成证书(BUUKLE.PEM),并签发给网站, 网站每次响应用户的请求都会将证书BUUKLE.PEM 一并返回.用户安装了CA的根证书,其中有CA的公钥(CA.PUB),这时候用 CA.PUB 进行验签并解密证书,获取 BUUKLE.PUB 和网站的信息,并进行验证;此时只要保证CA的私钥 CA.KEY 没有泄露,那 BUUKLE.PUB 就是可信任的.
https整体流程
大体的流程可以参考以下
代码语言：javascript复制① CA权威机构(以阿里云为例 aliyun.ca)生成自己的公私钥对 CA.PUB 和 CA.KEY,事先将CA.PUB下发给各大主流浏览器;
② buukle.top 网站管理员向 aliyun.ca 购买证书服务并提交资料,资料中包含网站的一些基本信息,例如域名之类的.
③ CA证书的生成过程
(1) aliyun.ca 对资料进行审核,通过后为buukle.top生成公私钥对 : BUUKLE.PUB 和 BUUKLE.KEY;
(2) aliyun.ca 使用 CA.KEY 将网站资料 BUUKLE.PUB 打包加密,生成 BUUKLE.PEM (证书)文件;
(3) 通过安全渠道将 BUUKLE.PEM, BUUKLE.KEY 颁发给buukle.top 管理员;
④ buukle.top 管理员将BUUKLE.PEM ,BUUKLE.KEY 配置在服务器指定的位置;
⑤ https请求流程
(1) 客户端(浏览器) 请求https:www.buukle.top , buukle.top将 BUUKLE.PEM (证书) 返回给客户端;
(2) - 浏览器内置的TLS模块在本地CA公钥列表中找到 alinyun.ca 在 ① 中下发的 CA.PUB,找不到则提示用户不权威,提示是否继续;
- 找得到就使用CA.PUB 对BUUKLE.PEM(证书)进行解密,验签.同样,不通过也会提示;
- 解密后的内容里包括:基本资料 BUUKLE.PUB, 首先TLS会进行基本资料的验证,比如域名之类的,同样,不通过也会提示;
- 以上都没问题的话,浏览器会使用BUUKLE.PUB对数据进行加密,然后在传输给buukle.top;
⑥ buukle.top接受到数据后,会在 ④ 中已经配置好的地方取出 BUUKLE.KEY 对数据进行解密;简单来讲,就是两个人之间直接传递公钥不安全, 需要找另外一个可以信任的机构帮我把公钥加密并签名一下,只要该机构的签名私钥不泄露,我们两个人的公钥就是可信的.
通过以上机制,保证了传输过程中的数据安全性. 但是由于https中的ssl协议是传输层之上,应用层之下的,本地抓包还是可以看到加密前的数据的. 所以本地如果有什么病毒的话,也可能会在ssl协议执行之前就获取了信息. 这种情况下, 需要在输入密码或关键信息时使用本地安装的安全控件,比如工商银行的.这样就能更加安全的保护我们的数据了.
课后思考
为什么不完全伪造证书呢?
代码语言：javascript复制完全伪造证书没有用,因为我们没有私钥,拿到数据后没有办法解密.风险点
代码语言：javascript复制一 . 伪造证书
攻击者 : 可能会劫持用户的请求,并再返回正确的证书之前(https握手过程中), 自己生成一份公私钥, 然后按照正确的网站信息和伪造的公钥进行伪证书的生成,私钥自己保存好,将伪证书返还给客户端;
客户端 : 浏览器的TLS模块用真正的CA公钥解密时会出现错误提示,但是网站的信息都是正确的,这时候如果用户点了继续,就会用伪证书的公钥进行数据加密,并请求到劫持者的服务器,劫持者将数据获取后,再用正确的公钥加密数据,请求到真正的服务器上;
这个风险告诉我们,不要再敏感网站弹出证书提示信息后随意点击继续访问.也不要随意信任来历不明的证书.
二 . CA私钥泄露
一旦CA权威机构不再权威,私钥一旦泄露,那持有者可随意颁发证书.攻击者一旦在劫持正常用户的请求,并替换调原来的证书, 浏览器也不会有任何察觉.
这个风险告诉我们,没有绝对的安全.在注意的同时,也要对权威作出有效监管.
