HTTPS协议讲解

1、前言

http是非常常见的应用层协议，是超文本传输协议的简称，其传输的内容都是明文的。如果你给你的用户两个选择：
（1）通讯数据明文传输，速度快；
（2）通讯数据加密传输，但是速度可能会稍微慢一点.

https的存在就具备了合理性，https中的s表示SSL或者TLS，就是在原http的基础上加上一层用于数据加密、解密、身份认证的安全层。

HTTPS讲解比较好的视频参考
https://www.bilibili.com/video/BV1w4411m7GL?from=search&seid=13634207797360648683

HTTPS的安全性实现是基于 对称加密+非对称加密+Hash+CA构成

2、HTTPS讲解

https通信完整流程图：

CA是什么？
CA认证，即电子认证服务 ，是指为电子签名相关各方提供真实性、可靠性验证的活动。
证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

假如我们要实现一个功能：一个用户A给一个用户B发消息，但是要保证这个消息的内容只能被A和B知道，由于消息不想被其他人看到，所以我们自然而然就会想到为消息加密，并且只有A和B才有解密的密钥。这里需要考虑几点：
（1）使用什么加密方式？
（2）密钥怎么告知对方？

1、客户端： 我要发起HTTPS请求，麻烦给我一个非对称加密的公钥；
2、服务器： (生成一对非对称加密的密钥对，然后把公钥发给客户端)，接着，这是公钥；
3、客户端：（收到公钥，生成一个随机数，作为上图中那一把密钥，用刚才收到的公钥加密这个密钥，然后发给服务器）这是我刚生成的加密过的密钥；
4、服务器：（收到加密后的密钥，用本地的第一步自己生成的非对称加密的私钥解密，得到真正的密钥）;
5、现在，客户端和服务器都知道了这把密钥，就能愉快地用这个密钥对称加密数据...

分析一下上面步骤的可行性：

• 上述步骤中最终用于加密数据的密钥是客户端生成并且用公钥加密之后传给服务器的，因为私钥只有服务器才有，所以也就只有服务器才能解开客户端上报的密钥；

• 要保证传输的密钥只能被服务器解密，就得保证用于加密密钥的公钥一定是服务器下发的，绝对不可能被第三方篡改过；

因为还可能存在一种"中间人攻击"的情况，如下图：

这种情况下，客户端和服务器之间通信的数据就完全被坏人破解了。

从上一层可以知道，要保证数据的安全，就必须得保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥。那怎么保证呢？

数字证书

那就得引入数字证书了，数字证书是服务器主动去权威机构申请的，证书中包含了上一个图中的加密过的A公钥和权威机构的信息，所以服务器只需要给客户端下发数字证书即可。现在流程图如下：

那数字证书中的A公钥是如何加密的呢？

答案是非对称加密，只不过这里是使用只有权威机构自己才有的私钥加密。

等一下，既然A公钥被权威机构的私钥加密了，那客户端收到证书之后怎么解密证书中的A公钥呢?需要有权威机构的公钥才能解密啊！那这个权威机构的公钥又是怎么安全地传输给客户端的呢？感觉进入了鸡生蛋，蛋生鸡的悖论了~~

别慌，答案是权威机构的公钥不需要传输，因为权威机构会和主流的浏览器或操作系统合作，将他们的公钥内置在浏览器或操作系统环境中。客户端收到证书之后，只需要从证书中找到权威机构的信息，并从本地环境中找到权威机构的公钥，就能正确解密A公钥。

这样就绝对安全了吗？既然权威技能能给服务器签发数字证书，那为什么就不可能给中间人签发数字证书呢?毕竟赚钱的生意权威机构也不会拒绝的呀。

试想一下：

服务器给客户端下发数字证书时证书被中间人劫持了，中间人将服务器的证书替换成自己的证书下发给客户端，客户端收到之后能够通过权威机构的公钥解密证书内容（因为中间人的证书也是权威机构私钥加密的），从而获取公钥，但是，这里的公钥并不是服务器原本的A公钥，而是中间人自己证书中的B公钥。从第二层可知，如果不能保证客户端收到的公钥是服务器下发的，那整个通信数据的安全就没法保证。简单总结就是证书被调包~

所以，还得保证客户端收到的证书就是服务器下发的证书，没有被中间人篡改过。

第四层（安全传输证书）
这一层，我们的任务是：保证客户端收到的证书是服务器下发的证书，没有被中间人篡改过。

所以，这里就有两个需求:

• 证明证书内容没有被第三方篡改过；

• 证明证书是服务器下发的；

其实这些问题，数字证书本身已经提供方案了，数字证书中除了包含加密之后的服务器公钥，权威机构的信息之外，还包含了证书内容的签名(先通过Hash函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名)，签名计算方法以及证书对应的域名。这样一来，客户端收到证书之后：

• （篡改证书的内容，但是中间人无法对篡改的证书进行加密，只有CA机构才能加密）使用权威机构的公钥解密数字证书，得到证书内容（服务器的公钥）以及证书的数字签名，然后根据证书上描述的计算证书签名的方法计算一下当前证书的签名，与收到的签名作对比，如果一样，表示证书一定是服务器下发的，没有被中间人篡改过。因为中间人虽然有权威机构的公钥，能够解析证书内容并篡改，但是篡改完成之后中间人需要将证书重新加密，但是中间人没有权威机构的私钥，无法加密，强行加密只会导致客户端无法解密，如果中间人强行乱修改证书，就会导致证书内容和证书签名不匹配。所以证书签名就能判断证书是否被篡改

• （中间人将证书进行掉包，但是每一个证书对应的域名唯一的）再考虑证书被掉包的情况：中间人同样可以向权威机构申请一份证书，然后在服务器给客户端下发证书的时候劫持原证书，将自己的假证书下发给客户端，客户端收到之后依然能够使用权威机构的公钥解密证书，并且证书签名也没问题。但是这个时候客户端还需要检查证书中的域名和当前访问的域名是否一致。如果不一致，会发出警告！

客户端在接受到服务端发来的SSL证书时，会对证书的真伪进行校验，以浏览器为例说明如下：

（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验

（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发

（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。

（4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密

（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比

（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充

（7）此时浏览器就可以读取证书中的公钥，用于后续加密了

加密算法：

1、对称加密

有流式、分组两种，加密和解密都是使用的同一个密钥。

例如：DES、AES-GCM、ChaCha20-Poly1305等

2、非对称加密

加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。

例如：RSA、DSA、ECDSA、 DH、ECDHE

3、哈希算法

将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等

4、数字签名

签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。

SSL加密过程

根据密钥类型不同将现代密码技术分为两类：对称加密算法（秘密钥匙加密）和非对称加密算法（公开密钥加密）。

对称钥匙加密系统是加密和解密均采用同一把秘密钥匙，而且通信双方都必须获得这把钥匙，并保持钥匙的秘密。

非对称密钥加密系统采用的加密钥匙（公钥）和解密钥匙（私钥）是不同的。

假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。

• A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。

• B：我们用DES－RSA－SHA这对组合好了。这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。

• A：（查看证书上B的名字是否无误，并通过手头早已有的数字的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）

• A:我生成了一份对称加密使用的密钥，并用你的公钥加密了，给你（把ClientKeyExchange发给B）

注意，下面我就要用加密的办法给你发消息了！

（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）

[我说完了]

B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）

注意，我也要开始用加密的办法给你发消息了！

[我说完了]

A: [我的秘密是...]

B: [其它人不会听到的...]

从上面的过程可以看到，SSL协议是如何用非对称密码算法来协商密钥，并使用密钥加密明文并传输的。还有以下几点补充：

• 1.B使用数字证书把自己的公钥和其他信息包装起来发送A，A验证B的身份，下面会谈到A是如何验证的。

• 2.A生成了了加密密钥、加密初始化向量和hmac密钥是双方用来将明文摘要和加密的。加密初始化向量和hmac密钥首先被用来对明文摘要（防止明文被篡改），然后这个摘要和明文放在一起用加密密钥加密后传输。

• 3.由于只有B有私钥，所以只有B可以解密ClientKeyExchange消息，并获得之后的通信密钥。

• 4.事实上，上述过程B没有验证A的身份，如果需要的话，SSL也是支持的，此时A也需要提供自己的证书，这里就不展开了。在设置IIS的SSL Require的时候，通常默认都是igore client certification的。