数字签名和CA数字证书的核心原理和作用
数字签名和CA数字证书的核心原理和作用
这是华盛顿大学的官方网页等等
真的确定这是官网吗?
你们的浏览器正在提示这个网站不安全呢
很多人知道这是因为没有使用HTTPS导致的
但是具体又是哪方面不安全呢?
我们不妨回想一下
当你需要登录只使用了HTTP的门户网站的时候
输入并且发送了账号密码给网站
网站验证了账号密码没问题后
把带有你个人信息的网页发送给你
这个过程听起来很合理
是不好像!? 是也好像不是?
既然要访问网站
就需要用到网络
如果此时有人刻意记录你有收发的网络信息
你的账号密码会暴露给中间人
门户网站发给你的个人信息
网页也会暴露给中间人
这就是没有HTTPS的第一个缺点
保证不了数据的机密性
容易泄密,你们之间的网络相当于是"高清无码"的内容
因此我们必须给内容"打码"
打码以后
中间人并不是就没有办法知道内容了
而是极大的增加了中间人辨认内容的难度
稍微具体一些
就是你和门户网站之间需要有一模一样的私钥
你和网站两边各执一把
既然是叫私钥
当然不能给任何人
这把私钥简单理解为某种数学运算
比如你要发送一串字符
用这把私钥加密就会把字符导过来
明文就变成了密文
我们假设中间人很笨
看不懂网站,收到密文后
用同一把私钥解密后,就把密文倒过来,这样就得到明文了
网站发给你也是一样的方法
使用"倒序"来加密和解密
就是这里的私钥
这种只用同一把私钥的加密叫做对称加密
中间人不知道私钥的具体就很难进行破解
而且这把私钥是有期限的
你和网站之间的每一次会话
都需要一把新的私钥
为了后续讲解
就把这样有期限的私钥统称为会话密钥
现在中间人要破解所有会话就更困难了
听起来很合理
是不好?
像是也好像不是?
既然你和网站之间需要不能公开的绘画密钥
那你们就需要实打实的见上一面
把会话密钥沟通好
在进行网络通信
如果真要这样
你们还愿意上网吗?
为了不见面就可以进行距离网络通信
我们需要巧妙地协商
或者送这把会话密钥给对方
现在网站有一把公钥和一把私钥
用公钥加密的内容只能用私钥进行解密
记住它们是成对的
密钥就跟公鸡和母鸡一起才能下蛋的道理
因此在网站把公钥发给你以后
你需要生成一串只有你自己知道的神秘字符
并且用收到的公钥进行加密
得到了加密后的神秘字符
接着你需要把加密后的神秘字符发送给网站
网站用谁都不晓得的事要解密
得到那串神秘字符
于是你们两边都可以用这串神秘字符生成
只有你们知道的"会话密钥"了
在通信过程中
中间人可以得到公钥以及加密后的神秘字符
但是用公钥进行解密是得不到神秘字符的
只能用私钥解密
因为用到公钥和私钥
这样的加密叫做非对称加密
这就解决了和发送和协商会话密钥的问题了
听起来很合理
是不好?
像是也好像不是?
我们不妨让时光倒流
当网站要把公钥发送给你的时候
中间人拿到了网站的公钥以后
不直接发给你
因为中间人要"加戏"中间人
此时要生成自己的一对公钥和私钥
并且把他自己的公钥发给你
于是你就傻乎乎的
用中间人的公钥加密自己生成的神秘字符
中间人再次进行截获
并且用自己的私钥破解了你的神秘字符
破解以后不直接发送给网站
而是修改里面的内容
并且用网站给的公钥加密
修改后的内容再发送给网站
网站收到后用自己的私钥解密
收到的信息会发现能够成功解密
通信在神不知鬼不觉的情况下被篡改了
如果在这种情况下
还要继续生成会话密钥
其实会生成不同的会话密钥
一边是你和中间人的
另一边是中间人和网站的
你和网站之间并没有直接生成任何会话密钥
中间人可以把通信内容说改就改
因此前面非对称和对称加密了个寂寞
这就是没有HTTP
第二个缺点
保证不了数据的完整
有可能被更改
问题就在于这里的公钥
我们不能确定收到的这把公钥
是网站的还是中间人的
这个时候就像西游记里
孙悟空与六耳猕猴的争执
两只猴子都说自己才是真正的美猴王
直到第三方如来佛祖的出现才有结果
我们的网络通信也需要第三方
来解决公钥的信任问题
这个第三方简称CA
于是刚才的流程就发生了变化
你在发送神秘字符之前
网站需要先把用来给你加密的公钥
放到大家都信任的第三方CA那里
CA根据这把公钥以及其他信息
生成了数字证书
数字证书
相当于让这把公钥和该网站绑定起来了
如果回到刚才的流程
网站在与你进行加密协商之前
就可以先把数字证书发给你
你看到数字证书是属于信任的ca
于是从数字证书里面取出公钥
这样就可以愉快地生成最后的会话密钥了
听起来很合理
是不好
像是也好像不是
我们如何相信数字证书就是有信任的ca颁发的呢? 数字证书上有ca的签名就可以了
这和我们真实生活中的签名十分相似
比如老师让家长给孩子检查作业
为了确保孩子们的作业被家长检查了
会要求在作业上签写家长的大名
在网络通信中并不适用签字笔来签名
而是用数字签名给数字证书签名
我们不妨再次进行时光倒流
当ca在收到网站的信息以及公钥以后
会对这些信息以及公钥进行哈希运算
得到一串较短的哈希字符
听到这里你们可能会觉得奇怪
为什么要进行哈希运算呢
简单来说
哈希运算就是把一段内容变成特定的
很短的字符
这样大大压缩掉需要传输的信息
而且这串字符等会还要进行加密和解密
如果要计算的字符很大
会消耗掉非常多的时间
另外如果内容有哪怕一个字符的修改
最终生成的短字符都会不一样
不一样的内容会生成不一样的哈希字符
这串短字符相当于家长检查作业后给出的分数
对全部内容进行一个总结
回到刚才的步骤
哈希运算以后
ca自己也生成一对专门用于数字证书
公钥和私钥
然后用这把私钥给哈希字符加密
注意用的是私钥
这算加密后的字符就是数字签名了
注意进行哈希运算并非进行了加密运算
因此这里要对哈希字符进行加密
现在ca就可以把含有ca数字签名的证书
发给网站了
虽然数字证书里的网站信息都是明文的
但是核心就在于ca的数字签名了
如果证书里的内容被篡改了
或者公钥被修改了
生成的哈希值会不一样
最终的数字签名就会变成另外的一串字符
当你访问网站的时候
网站会把还有ca数字签名的数字证书发给你
为了证明没有中间人更改过公钥
你需要用到ca签名时候生成的公钥
并且用这把ca公钥
给数字证书里面的数字签名解密
这样会得到一串哈希字符
毕竟数字签名加密钱就是一串哈希字符串哈
希字符先放着
接着你对收到的数字证书内容
进行同样的哈希运算
也得到一串哈希字符
如果前后两串哈希字符一致
说明数字证书是靠谱的
没有被篡改
我们现在假设中间人修改了数字证书的内容
但是由于中间人没有原本生成数字证书的私钥
因此你收到的数字签名会和数字证书不匹配
除非中间人把数字证书和数字签名
同时改的匹配
才这种情况
也只能是拥有私钥才行
没问题的话
就可以继续生成绘画密钥的步骤了
看到这里你们可能感到奇怪
一下子私钥加密
一下子公钥加密
我是不是在扯淡
这就和可乐既可以用来喝
还可以用来冲马桶是差不多的道理
虽然听着反人类
但事实就是如此
千万不要被一些字面意思束缚住
不管是公钥加密还是私钥加密
背后的数学原理
就是你用了一把进行加密
另一把就只能用来解密
由于运用场景的不同
导致了他们在用法上的不同
前面说的公钥加密
私钥解密
虽然理论上谁都可以加密
但是加密后只能是拥有私钥的人才能解密
因此用来加密信息就很好
数字签名则是私要先加密公钥再解密
也就是常说的私钥签名,公钥验签只能是拥有私钥的人才能加密
但理论上谁都能解密
用来验证身份就很好
但是刚才还遗留了个问题
我们如何安全的拿到信任ca的公钥呢?
我们不妨再次让时光倒流
当网站向第三方ca申请证书的时候
ca会生成专门给这个网站颁发证书的一对公钥和私钥
并且用自己的私钥给证书签名
网站公钥和私钥用来生成最终的绘画密钥
我们是知道了
ca私钥用来给证书签名
我们也知道了
就剩下ca的公钥像孤儿一样被丢在一边了
其实ca也需要数字证书来证明自己的身份
因此会把这把公钥放在自己的数字证书里面
按照数字证书的生成原理
这份数字证书同样也需要一把私钥来进行签名
这就需要再加一层了
也就是跟ca网站申请证书的这个ca则是中间ca
跟ca同样需要生成一对专用的公钥和私钥
并且用这把私钥为中间ca的证书签名
跟ca竟然有这把弓钥
也就是说跟ca也有自己的证书
但是跟ca的证书由谁来签名呢
会不会是地球ca呢
如果是就没完没了了
更ca需要为自己的证书签名
然后在用户的操作系统和浏览器里面
预先安装更系列的证书
这样就可以闭合这一整条"证书链"了
这里的核心就是
用顶层的私钥给下层的证书签名
验证的时候
用顶层的公钥来检验下层的签名
你们可能觉得奇怪
网站可以直接和更ca申请证书的呀
没有中间商赚差价多好呀
其实我们只需要把这里的结构
想象为一棵树就好
如果中间有一根树枝断了
也不至于连根拔起
跟ca可以避免与广大的网站服务器直接接触
直接交给中间CA进行接触
如果其中有一家中间ca的私钥被破解了
也不至于影响到全局
因此跟ca私钥的管理十分重要
为了让大家理解这一过程
我们来看看使用了HTTPS
华盛顿大学网站有什么不同
没错
华盛顿大学提供了HTTP和HTTPS两种方式访问网站
浏览器在进行加密之前
收到网站服务器发过来的证书
证书上面有串重要的字段
颁发者也就是谁颁发了这份数字证书
这里有个很重要的缩写
CN不是china的缩写
意思是common name公用名
但是我的电脑里面并没有这家ca的证书
其实网站是可以把整个证书链浏览器的
也有可能网站服务器不发送中间证书
导致有些浏览器可能需要从缓存中找这些证书
或者自行下载中间证书
继续刚才的步骤
浏览器查看这份中间证书的颁发者
发现这里的公用名是USERTrust RSA Certification Authority
此时就需要找找电脑里面有没有他的证书
最后成功找到这份根证书
并且提取里面的公钥来验证中间证书的签名
没问题
再用中间证书的那份公钥
来验证网站证书的签名都没问题
说明网站的证书没有被篡改
但是没有被篡改
也还是证明不了这份证书就是属于该网站的
其实浏览器还会查看主题背景的公用名
是否和域名一致
很明显这里是一致的
因此证明这份证书是和该域名绑定的
这里也说明了没有用HTTPS的第三个缺点
没有用HTPS你很难确定访问的是不是官网
毕竟第三方ca在颁发证书之前
是会进行网站信息的检查
当然我们经常会看到网站域名和公用名CN不一致
因此浏览器还会查看扩展程序里的证书
主题背景的备用名称
接着浏览器还需要检查证书的有效期
用俗话说就是证书到期了
记得续费
现实就是这么残酷
这里还有个问题
如果网站服务器的私钥泄露了
并且已经向ca申请证书的吊销
浏览器如何知道这种事呢
此时就要靠CA的证书吊销列表了
我们可以在扩展程序的CRL分发点里查看
访问这个网址
可以下载这份文件
当我们用命令来查看这份文件内容的时候
就可以看到被吊销证书对应的序列号
当然有些浏览器不会去检查这个列表
导致了安全隐患
另外这个证书吊销列表可能不是实时的
因此就有了在线证书状态协议OCSP作为替补
这样浏览器可以向专门的服务器
查看某个证书是否被吊销
来弥补前面那种方法时效性的问题
不过这个协议也出现了隐私泄露的问题
虽然浏览器还会继续为证书进行身体检查
但是核心的部分你们已经了解了
我们下次分享见
