深入浅出Https

一、带着问题走进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 信息，随客户端请求、服务端响应信息一同传递，哪里也不进行存储。