一、带着问题走进HTTPS
1.看到https首先想到什么:
SSL/TLS、数字证书、安全、加密、密文传输
2.https总共经过几次加密:
2~3次
3.都用了哪几种加密算法:
对称加密、非对称加密、数字签名
4.这几种加密算法都用在了哪里:
验证证书、业务数据传输、传输预主密钥
二、假如没有Https该如何进行安全传输
2.1.这种场景在应用中非常常见,它存在哪些安全隐患?
消息泄漏、消息篡改
2.2.有什么办法可以对以上问题进行防护?
消息加密->对称加密
注:对称加密小知识
对称加密算法:加密和解密用到的密钥是相同的,这种加密方式加密速度非常快,适合经常发送数据的场合,特点:密文长度随明文长度增长而增长。
常见对称加密算法:
DES:
密钥总长64位,56位参与加密运算,其他位充当校验位存在。
原理:将加密原文按64位进行分组,将分组后原文和56位密钥按位替代或交换生成密文
3DES:
三次DES加密算法,由于计算机运算能力的增强,原版DES密码的密钥长度变得容易被暴力破解;3DES即是设计用来提供一种相对简单的方法,即通过增加DES的加密次数避免类似的攻击,而不是设计一种全新的块密码算法
AES:
美国联邦政府采用的一种区块加密标准,首先把明文分成一组一组的,每组长度相等,每次加密一组数据,每一组数据都会经过10+轮以上加密,每一轮都会经历字节代换、行位移、列混合和轮密钥加操作,最终叠加得到完整个密文
2.3.消息经过对称加密后密文传输图如下所示:
疑问一:Client和Server怎么来确定并交换对称密钥?
只能由Server生成密钥推送给Client或Client生成密钥发送给Server,密钥明文传输,适用于服务之间进行消息加密传输。
分析:
不泄露对称密钥?
对Client和Server进行对称密钥协商过程再进行一次对称加密 ,这就会出现加密循环现象,详细情况以下情况:
结论:
继续使用对称算法对对称密钥进行加密肯定会陷入加密死循环,依旧无法解决目前对称密钥安全传输的问题
思考:
有没有加密算法,密钥是公开的,可以让所有人知道?
注:非对称加密小知识
常见非对称RSA加密算法原理:公钥 = 超级大质数p * 超级大质数p (私钥)
详见:http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html
消息再经过非对称加密后密文传输图如下所示:
小疑问大解惑:
既然有非对称加密,直接使用非对称加密后传输就OK了,为何仅使用非对称加密来传输对称密钥?
非对称加密耗性能、慢
公钥对所有Client公开,Server私钥加密后相当于所有Client都能获取使用公钥进行解密,无法解决消息泄漏问题
疑问二:小C和小小C使用同一个对称密钥安全吗?
多个Client使用同一个密钥与Server进行通话,依旧存在消息泄漏的问题。
可以让不同的Client使用不同对称密钥,消息再经过多个客户端使用不同对称密钥改造后传输图如下所示:
问题延伸:怎么做到不同Client使用不同对称密钥?
可以让每个Client在请求时随机生成一个对称密钥,使用Server公钥对密钥加密后,将密文同步给Server服务端,服务端使用私钥解密获得Client生成的对称密钥。
三、真实Https实现方式
3.1.使用非对称加密传输对称密钥流程图(老版本浏览器)
由于Https协议建立在Http协议之上,而Https协议建立在TCP三次握手协议之上,所以真实使用非对称加密算法(RSA)生成随机对称密钥过程如下图所示:
1)客户端生成随机数、加密算法发送发送给服务端
2)服务端接收客户端随机数,并生成服务端随机数和服务器公钥证书返回给客户端
3)客户端接收到服务端随机数和服务器公钥后,会根据客户端、服务端随机数使用PRF函数生成预主密钥,再通过预主密钥+双随机数生成主密钥,再通过主密钥+双随机数生成正式会话密钥
4)客户端使用服务器公钥证书加密预主密钥,将密文传输给服务端
5)服务端接收到预主密钥密文,是有私钥解密,获得预主密钥,再使用预主密钥+双随机数生成主密钥,再通过主密钥+双随机数生成正式会话密钥
6)服务端反馈密钥交换完成,正式使用会话密钥通话
3.2.使用ECDHE函数传输对称密钥流程(新版本浏览器)
ECDHE(DHE)算法比RSA更强大,私钥不参与密钥的协商,故即使私钥泄漏,客户端和服务器之间加密的报文都无法被解密,并且ECDHE每条会话都重新计算一个密钥,故一条会话被解密后,其他会话仍旧安全,使用的是前向保密
1)客户端生成随机数、加密算法发送发送给服务端
2)服务端接收客户端随机数,并生成服务端随机数和服务器公钥证书返回给客户端
3)服务端生成DH参数,使用服务端私钥进行签名,并发给客户端
4)客户端使用服务器公钥证书对服务端DH参数进行验证签名,并在客户端生成DH参数传输给服务端,并在客户端通过服务端DH参数、客户端DH参数算出预主密钥,再通过预主密钥+双随机数生成主密钥,再通过主密钥+双随机数生成会话密钥
5)服务端接收到客户端DH参数,使用服务端DH参数和客户端DH参数计算出预主密钥,再使用预主密钥+双随机数生成主密钥,再通过主密钥+双随机数生成正式会话密钥
注:DH 密钥协商算法小知识
Diffie-Hellman:DH 密钥协商算法,主要用于在不安全的通道生成共享密钥
举例说明:
原理:
与非对称加密算法有所相同,区别在于本次加密是将被除数的幂进行隐藏,其他数字对外暴漏,最终计算出预主密钥
详见:https://www.cnblogs.com/qcblog/p/9016704.html
ECDH ->elliptic curve Diffie-Hellman:基于椭圆曲线函数加密,就是上面的 p 和 g 的值不再固定,在多条曲线中找一条,在曲线上选一个动态的点
四、真实HTTPS实现验证
4.1对应访问 https://yao.jd.com 返回抓包结果如下所示(ECDHE):
4.1.1.对应Client Hellow 请求参数如下所示:
4.1.2.对应Server Hellow 返回参数如下所示:
4.1.3.对应Certificate返回参数如下所示:
4.1.4.对应Client Key Exchange请求参数如下所示:
4.1.5.对应正常数据交互如下所示:
五、其他知识点
5.1.CA证书在Https中充当什么作用?
即使已经存在上面的全部步骤,依旧无法完全保证安全,因为可能会存在客户端与服务端之间安插中间者情况,因此需要借用CA证书机制,防止中间者情况,用于验证服务端公钥证书安全可靠,具体步骤如下所示:
1)服务端向CA机构申请颁发安全证书
2)CA机构使用CA机构私钥对服务端公钥证书文件进行签名,结合有效期、公司信息等参数生成服务端证书
3)CA机构的颁发的证书必须被本地浏览器信任,也就是说本地浏览器中存有CA机构的公钥信息
4)当本地浏览器接收到服务端的证书信息,会使用浏览器中存的CA结构公钥信息对证书文件进行验证签名,并对证书有效期进行校验
5)校验通过后,标识证书合法
5.2.Session Id 和 Session ticket 用来做什么的?
两种都是session复用的优化手段,目的用于会话密钥协商次数,提供通话性能
Session Id:
将会话和会话密钥信息缓存到服务端,在客户端发起请求时校验是否已有会话缓存,存在缓存中直接返回,不再次进行协商,缓存有时间限制。
Session ticket:
将会话核心参数加密成 Session ticket 信息,随客户端请求、服务端响应信息一同传递,哪里也不进行存储。