HTTPS协议

什么是HTTPS

在http协议一文，我们理解了这个应用层协议的报文、特性等

但说到底，它依旧是在用明文的方式传送数据，很容易被中间人窃取和篡改，安全性很差

于是，我们在http层和tcp层之间放一个加密层

先前，我们直接将http报文交付给TCP层进行网络传输；

这里，我们在交付前先通过一道密码通信的框架（SSL/TLS），再将加密后的数据交给TCP，这样的HTTP+SSL/TLS的组合就是HTTPS

• HTTPS协议公认的端口号是443；
• HTTP则是80号端口

到达对端后即可判断是否要进行解密

概念准备

在讲解https之前，我们需要一些加密相关概念的铺垫

常见的加密方式

一般加密过程我们需要考虑三样东西

• 加密算法
• 密钥
• 数据

一段数据借助某种加密算法，通过加密密钥可以生成密文，密文通过解密密钥还原成原数据

这里加密密钥和解密密钥可以相同也可以不同，根据它们是否相同可以区分出两类加密方式

• 对称加密：两个密钥相同
• 非堆成加密：两个密钥不同

对称加密

也称单密钥加密

常见的加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等

特点：算法公开、计算量小、加密速度快、加密效率高

一个简单对称加密算法案例：按位异或

假设明文a = 1234，密钥key = 8888

加密：a ^ key得到密文b = 9834

然后针对密⽂9834再次进⾏运算b^key,得到的就是原来的明⽂1234.

当然,按位异或只是最简单的对称加密.HTTPS中并不是使⽤按位异或.

非对称加密

需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（publickey，简称公钥）和私有密钥（privatekey，简称私钥）。

常⻅⾮对称加密算法：RSA，DSA，ECDSA

特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快

⾮对称加密要⽤到两个密钥,⼀个叫做"公钥",⼀个叫做"私钥".

公钥和私钥是配对的.最⼤的缺点就是运算速度⾮常慢，⽐对称加密要慢很多.

• 通过公钥对明⽂加密,变成密⽂
• 通过私钥对密⽂解密,变成明⽂

也可以反着⽤

• 通过私钥对明⽂加密,变成密⽂
• 通过公钥对密⽂解密,变成明⽂

数据摘要

数据摘要（数字指纹），其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的数字摘要。数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被窜改。

转化是单向的，我们可以通过原文映射出摘要，但无法从摘要还原出原文。

算法把无限映射成有限，因此有可能发生碰撞（两个不同的信息得到的摘要相同），但是只要算法合适，这种情况发生的概率极低。

如上，我们仅更改了文本的一个字符，但是它的数字摘要却发生了巨大的变化

摘要常见算法：MD5、SHA1、SHA256、SHA512等

摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，通常⽤来进⾏数据对⽐

数字签名

将摘要进行加密就会得到数字签名（后面细说）

HTTPS的工作过程探究

方案1：只使用对称加密

如果通信双⽅都各⾃持有同⼀个密钥X，且没有别⼈知道，这两⽅的通信安全当然是可以被保证的（除⾮密钥被破解）

引⼊对称加密之后,即使数据被截获,由于⿊客不知道密钥是啥,因此就⽆法进⾏解密,也就不知道请求的真实内容是啥了.

但事情没这么简单.服务器同⼀时刻其实是给很多客⼾端提供服务的.这么多客⼾端,每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了,⿊客就也能拿到了).因此服务器就需要维护每个客⼾端和每个密钥之间的关联关系,这也是个很⿇烦的事情~

⽐较理想的做法,就是能在客⼾端和服务器建⽴连接的时候,双⽅协商确定这次的密钥是啥~

但是如果直接把密钥明⽂传输,那么⿊客也就能获得密钥了~~此时后续的加密操作就形同虚设了.
因此密钥的传输也必须加密传输!
但是要想对密钥进⾏对称加密,就仍然需要先协商确定⼀个"密钥的密钥".这就成了"先有鸡还是先有蛋"的问题了.此时密钥的传输再⽤对称加密就⾏不通了.

方案2：只使用非对称加密

鉴于⾮对称加密的机制，如果服务器先把公钥以明⽂⽅式传输给浏览器，之后浏览器向服务器传数据前都先⽤这个公钥加密好再传，从客⼾端到服务器信道似乎是安全的(有安全问题)，因为只有服务器有相应的私钥能解开公钥加密的数据。

但是服务器到浏览器的这条路怎么保障安全？

如果服务器⽤它的私钥加密数据传给浏览器，那么浏览器⽤公钥可以解密它，⽽这个公钥是⼀开始通过明⽂传输给浏览器的，若这个公钥被中间⼈劫持到了，那他也能⽤该公钥解密服务器传来的信息了

方案3：双⽅都使⽤⾮对称加密

1. 服务端拥有公钥S与对应的私钥S’，客⼾端拥有公钥C与对应的私钥C’
2. 客⼾和服务端交换公钥
3. 客⼾端给服务端发信息：先⽤S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥S’

服务端给客⼾端发信息：先⽤C对数据加密，在发送，只能由客⼾端解密，因为只有客⼾端有私钥C’

这样貌似也⾏啊，但是

• 效率太低（对大段的数据进行非对称加密非常耗时）
• 依旧有安全问题

方案4：非对称加密 + 对称加密

先解决方案3的效率问题

• 服务端具有非对称的公钥S和私钥S`
• 客户端发起https请求，获取服务端的公钥S

此时，客户端拿着公钥，服务端拿着私钥

• 客户端在本地生成对称密钥C，通过公钥S进行加密，发给服务端
• 由于中间的网路设备没有私钥，即使获取到了数据，也无法还原出原文，也无法获取到对称密钥（实际还有漏洞）
• 服务器通过私钥S`解密，还原出客户端发送的对称密钥C，今后双方就用这个对称密钥进行加密通讯了

从方案1到方案4，我们似乎已经得到了一个完全的方案

中间人攻击

Man-in-the-MiddleAttack，简称“MITM攻击”

下面我们尝试作为一个中间人破解方案4

1. 服务器具有⾮对称加密算法的公钥S，私钥S’

2. 中间⼈具有⾮对称加密算法的公钥M，私钥M’

3. 客户端具有对称加密算法密钥C

4. 客户端像服务器发起请求，服务器将公钥明文传送给客户端

5. 中间人劫持到数据报文，提取公钥S并保存好，然后将劫持到报文中的S换成自己的公钥M，将伪造报文发给客户端

6. 客户端收到报文，提取公钥M(浑然不知已经被人改了)，将对称密钥C用M加密后形成报文发送给服务器

7. 中间人劫持后，直接用自己的私钥M’进行解密，得到通讯密钥C，再用曾经保存的服务器公钥S加密后发送给服务器

8. 服务器拿到报文，用自己的S’解密，得到通讯密钥C

9. 至此，双方便开始用C进行对称加密，进行通讯.但是一切都在中间人的掌控之中，劫持数据，进行窃听甚至修改

上面的攻击方案，也同样试用方案2、3

问题的本质出在那里?客户端无法确定收到的含有公钥的数据报文，就是目标服务器发来的！

引入证书

CA认证

服务端在使用HTTPS服务前，需要向CA机构申领一份数字证书，数字证书里包含了申请者的信息、公钥信息等。服务器把证书传送给浏览器，浏览器就可以给从证书中获取公钥

如果用这个证书代替方案4中的服务器发出的公钥

那么，只要保证服务器和客户端通讯过程中，这个证书无法被修改或者替换，即可杜绝中间人攻击的发生。

接下来我们就看看证书是如何保证的

这个证书可以理解成是⼀个结构化的字符串,⾥⾯包含了以下信息:

• 证书发布机构
• 证书有效期
• 公钥
• 证书所有者
• 数字签名
• …

其中，数字签名起到了重要做作用

理解数字签名

签名的形成基于非对称加密算法

• CA机构手里拿着一对公钥(A)-私钥(A`)对，且公钥会被内置到用户的操作系统

• 收到服务端的申请信息、公钥信息等明文进行核验，并添加发布机构、有效期等信息，组成一个明文证书

• 然后获取明文证书的数据摘要

• 再用私钥A`对数据摘要进行加密得到数字签名

• 最后将明文证书与数字签名组成数字证书，颁发给服务器端

证书申请过程

申请的时候，需要在特定平台⽣成CSR，会同时⽣成⼀对密钥对，即公钥和私钥。这对密钥对就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。 其中公钥会随着CSR⽂件，⼀起发给CA进⾏权威认证，私钥服务端⾃⼰保留，⽤来后续进⾏通信（其实主要就是⽤来交换对称秘钥）

可以使⽤在线⽣成CSR和私钥：https://myssl.com/csr_create.html

形成CSR之后，后续就是向CA进⾏申请认证，不过⼀般认证过程很繁琐，⽹络各种提供证书申请的服务商，⼀般真的需要，直接找平台解决就⾏

方案5：证书如何保证安全

在客⼾端和服务器刚⼀建⽴连接的时候,服务器给客⼾端返回⼀个证书，证书包含了之前服务端的公钥,也包含了⽹站的⾝份信息.

客户端进行认证

当客户端获取到这个证书，会对证书进行校验（防止证书是伪造的）

• 判断证书是否过期
• 判断证书的发布机构是否受信任（操作系统内置的受信任的证书颁发机构）
• 证书是否被篡改：从系统中拿到该证书发布机构的公钥，对签名解密，得到一个hash值（数据摘要），设为hash1，然后计算整个证书的hash值，设为hash2.对比hash1和hash2是否相等。如相等，则表明证书没有被篡改过。

中间⼈有没有可能篡改该证书？

• 中间⼈篡改了证书的明⽂
• 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后
  的证书形成匹配的签名
• 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈

中间⼈整个掉包证书？

• 因为中间⼈没有CA私钥，所以⽆法制作假的证书(为什么？)
• 所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包
• 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。
• 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的

查看浏览器的授信证书发布机构

Edge浏览器,点击右上⻆的

选择"设置",搜索"证书管理",即可看到以下界⾯

总结

完整流程：

HTTPS⼯作过程中涉及到的密钥有三组.

• 第⼀组(⾮对称加密):⽤于校验证书是否被篡改.服务器持有私钥(私钥在形成CSR⽂件与申请证书时获
  得),客⼾端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥).服务器在客
  ⼾端请求是，返回携带签名的证书.客⼾端通过这个公钥进⾏证书验证,保证证书的合法性，进⼀步保
  证证书中携带的服务端公钥权威性。
• 第⼆组(⾮对称加密):⽤于协商⽣成对称加密的密钥.客⼾端⽤收到的CA证书中的公钥(是可被信任的)
  给随机⽣成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥.
• 第三组(对称加密):客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密

其实⼀切的关键都是围绕这个对称加密的密钥.其他的机制都是辅助这个密钥⼯作的.

• 第⼆组⾮对称加密的密钥是为了让客⼾端把这个对称密钥传给服务器.
• 第⼀组⾮对称加密的密钥是为了让客⼾端安全拿到第⼆组⾮对称加密的公钥.