本文章默认读者已经了解Https和http的层级架构,加密算法的概念,如果不知道,需要读者自行搜索下
要说明白Https,需要先看下Https要解决的问题,也就是Http存在哪些问题需要改进
1.http传输面临的3个问题
- 信息明文传输,容易被窃取
- 无法验证服务器身份,容易被伪装的服务器骗取信息
- 没有验证消息完整性,信息可能被篡改
2. https解决明文传输的方法
这个过程用到的加密,加密分为对称加密和非对称加密,区别就是对称加密,加密和解密用同一个密钥, 非对称加密使用不同密钥,这里不过多赘述。
对称加密版本
- 浏览器发送支持的加密方法和一个客户端随机数
- 服务器返回要用的加密方法和一个服务器随机数
- 客户端和服务端都是用随机数和加密方法生成密钥
- 后续数据使用密钥加密
这种方式的问题是这些随机数都可以被黑客拦截,那他就拥有了密钥,就不存在加密了。
非对称加密版本
使用非对称加密,不发送随机数了,我服务器直接算好公钥,私钥,直接把公钥发给你客户端,客户端公钥直接加密,服务器私钥解密
但是这样也会有问题
- 非对称加密效率低,针对大量传输的信息可能会严重影响响应速率
- 只能保证客户端发送信息不被解密,服务器发送只能私钥加密信息,但黑客有机会获取到公钥,直接可以解密服务器发的信息
所以后续改进的方向是数据加密需要使用对称加密,避免效率问题,那么要解决的就是如何保证对称密钥的安全性。
终极版本:对称和非对称混合
对称密钥加密和解密数据,非对称加密和解密"对称密钥",这样来保证对称密钥不被破解,后续用对称密钥加密和解密数据就做到了安全性和效率的平衡
- 浏览器发送支持的加密方法和客户端随机数
- 服务端返回要是用的加密方法,服务端随机数和公钥(非对称加密的)
- 客户端再生成一个随机数,然后利用非对称加密的公钥加密这个随机数
- 服务端利用私钥解密随机数
- 客户端和服务端利用3个随机数和加密方法生成对称密钥
- 客户端和服务端使用密钥加密和解密
上述就是Https加密和解密的主体思路和方案
但是细心的网友也可以想到,那我伪装成服务器和你浏览器对话,伪装服务器走这一套流程就可以套取客户端的信息,于是就来到Https需要解决的第二个问题,验证服务端身份,解决方案就是借用数字证书
3. Https解决服务端身份验证
看下包含数字证书的过程
可以发现变化不大,区别在于
- 服务器返回的不是公钥而是证书
- 客户端要去验证证书
数字证书里面有什么东西,客户端如何验证证书
- 公钥,也就是非对称加密的公钥
- 证书信息:有超时时间,颁发机构信息,签名算法
- 数字签名:对公钥和证书信息做hash生成的摘要
网友们可以随便点开一个https的网站,在地址栏左边按钮可以查看到他的证书,看下里面有啥东西,这里不过多赘述,可以搜一下查看方法
上面的图也是客户端验证证书的过程,第二步的CA公钥解密,这个CA公钥哪来的,一般情况下是服务器在前面的协商过程一起发下来的,服务器没部署的话,客户端会通过下载获取
客户端通过解密数字签名获取摘要,和公钥,证书信息hash算的摘要做对比,相同就认为合法,同时客户端要验证证书是否被吊销,是否超过有效期,证书是否是合法机构颁发,这样来验证服务器的合法性
4. Https保证信息完整性
这一步其实类似证书验证,每次信息传输,会对信息正常一个摘要,(这个摘要算法就是类似MD5,sha-2的东西,能对不同长度信息生成固定长度的身份字符串,细微的信息变化也会导致生成的身份字符串不一样),发送的时候将摘要一起发送,收到信息后重新对信息进行摘要计算,如果摘要相等就说明信息是完整的
针对数字证书是怎么颁发,数字证书又怎么保证合法性的详细过程,可以参考以下文章,本人的这篇文章也是参考写的,由于他们图做的太好了就直接用了
https:加密过程 segmentfault.com/a/119000002…
数字证书相关 www.cnblogs.com/bala/p/1626…