HTTPS协议原理

HTTPS

HTTPS是什么

HTTPS 也是⼀个应⽤层协议，HTTPS（全称：Hypertext Transfer Protocol Secure）是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTP 协议内容都是按照⽂本的⽅式明⽂传输的. 这就导致在传输过程中出现⼀些被篡改的情况，HTTPS避免了这种情况。

改进目标

HTTPS 协议是由 HTTP 加上 TLS/SSL 协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。设计目标主要有三个。

• 数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么。
• 数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收。
• 身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方。

什么是加密、解密

加密：把明文（要传输的内容）进行一系列变换，生成密文。

解密：把密文进行一系列变换，还原成明文。

为什么要加密

• 数据在客户端和服务器之间传输，数据从服务器应用层从上往下依次封装、传输，然后从服务器的物理层传输到客户端的物理层进而客户端能拿到数据，其中要经过交换机、路由器等中间设备，才能发送到客户端。若使用的是HTTP协议的明文传输，黑客在中间进行网络嗅探，很容易就能对数据进行攻击。因此需要給HTTP的明文进行加密，黑客就算在中间拿到了数据无法解密，就无法进行数据攻击。

常见的加密方式

对称加密

• 采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密。
• 特征：加密和解密所⽤的密钥是相同的。
• 特点：算法公开、计算量⼩、加密速度快、加密效率⾼。
• 常见对称加密算法：DES、3DES、AES、TDEA等。

例如一个简单的对称加密：按位异或

明文a=1234,密匙key=8888,密钥对明文进行加密：a^key得到密文a`=9834。

同理用同一个密钥对密文进行解密：a`^key得到明文a=1234。

对称加密场景

有三个好朋友tom、jerry和hook。tom想告诉Jerry一个密码，但又不想被hook知道，因此tom就和jerry约定好一个加密解密的条件：

将话语的字符在字母表上的位置+1的行为定义为加密，将话语的字符在字母表上的位置-1的行为定义为解密。密钥就是在字母表上前后移动字符的步数1。

例如tom想根jerry说：

i like eating apple
1

tom将这句话的每一个字符都在字母表上的位置+1，得到

j mjlf fbujoh bqqmf
1

然后将上面加密过的话告诉jerry和hook，由于Jerry知道密钥，因此Jerry知道tom在说什么，hook不知道密钥就不知道这句话是什么意思。

缺点：密钥的传递就成了问题。在最初，tom告诉Jerry密钥的同时不能保证不被hook窃听到。因此就要对密钥进行加密。但对密钥进行加密，对方并不知道密钥加密需要用到的密匙，解密需要密钥，解密后才能得到密钥，这就是一个先有鸡还是先有蛋的问题。

非对称加密

• 需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥 （private key，简称私钥）。
• 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快。
• 常⻅⾮对称加密算法：RSA，DSA，ECDSA等。
• 通过公钥对明文加密形成密文，就需要通过私钥对该密文进行解密还原得到明文。
• 同理通过私钥对明文加密形成密文，就需要通过公钥对该密文进行解密还原得到明文。
• 即公钥加密，私钥解密；或者私钥加密，公钥解密；二者必须一一配对，因此要求算法非常复杂，导致运算速度非常慢，这比对称加密慢很多。

非对称加密场景

由于在对称加密场景中，tom无法在告诉jerry密钥的时候避免被hook知道，因此这次使用非对称加密。

1. 需要双方交换公钥。tom发送公钥t給jerry，jerry发送公钥j給tom。
2. 用私钥对信息进行加密之后，将密文发送給对方。例如tom用私钥t`对信息加密形成密文，将密文发送給jerry。因为jerry有公钥t，因此jerry可以用公钥t对密文解密得到信息。同理，jerry用私钥j`对信息加密形成密文，将密文发送給tom。因为tom有公钥j，因此tom可以用公钥j对密文解密得到信息。

缺点：

1. 黑客在中间获取到了公钥，那么之后的密文都相当于明文。由于公钥是明文传输，一开始tom和jerry交换公钥时hook在中间获取到了公钥，那么后面用私钥加密的密文hook也能够轻易解开，相当于明文传输！
2. 非对称加密解密时间久，若每次传输信息都使用非对称加密，那么传输效率太低。

对称加密联合非对称加密场景

现用客户端和服务器通信作为场景

1. 客户端向服务发起请求，请求获取公钥。
2. 服务器响应公钥s。
3. 客户端形成一个对称密钥c，用公钥s对对称密钥c进行加密形成密文x。然后将密文x发送給服务器。
4. 服务器收到密文x后用私钥s`对密文x进行解密获取到密钥c。
5. 之后服务器和客户端发送的明文都用密钥c进行加密、解密。由于密文c是对称密钥，因此加密解密速度快。

优点：

• 用公钥s加密的密钥c，中间人没有私钥s`，因此无法获取公钥c。后续通信用密钥c对信息加密，因为中间人没有密钥c，因此无法对密文解密。
• 交换密钥后，进入通信环节，由于通信的信息是用的对称加密，因此加密解密速度快，效率高。

缺点：

• 中间人在交换密钥环节没有获取到密钥c的话（如图红色圈圈内），后续通信环节就无法对其攻击了。但只要中间人能够介入圈圈环节，就能够对其进行窃取。

中间人介入对称加密联合非对称加密场景

1. 客户端向服务器发起请求，请求公钥，被中间人拦截，然后中间人代理客户端向服务器发起请求。
2. 服务器响应公钥s，被中间人拦截，此时中间人拥有公钥s，然后中间人自己搭配一套公钥m，私钥m`,然后响应客户端公钥m。
3. 客户端误以为公钥m是服务器发来的，因此用公钥m对对称密钥c进行加密形成密文x，然后发送給服务器。
4. 中间人收到客户端发来的密文x，用私钥m`对密文x解密获取到对称密钥c，然后用公钥s对对称密钥c加密形成密文y，将密文y发送給服务器。
   1. 服务器误以为密文y是客户端发来的。服务器用私钥s`对密文y解密获取到公钥c。此后服务器发送的信息都用密钥c加密形成密文后发送給客户端。
5. 中间人获取到服务器响应的密文，用密钥c对其解密得到真实信息，然后用密钥c对虚假信息加密形成密文发送給客户端。
6. 客户端收到中间人发送来的密文，用密钥c对其解密获取到虚假信息。

• 可以看到中间人只需要在一开始交换密钥时介入发动网络嗅探进行密钥窃取并获取到密钥，此后的通信中间人可以随意控制，随意获取信息。

其本质问题在于客户端无法确定收到的含有公钥的数据报文，是目标服务器发过来的。

引入证书

数据摘要\数字指纹

• 数据摘要(数字指纹),其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的数字摘要。数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被窜改。
• 特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常⽤来进⾏数据对⽐。

• 常⻅算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞。（两个不同的信息，算出的摘可能相同，但是概率⾮常低）
• 在上传云盘的场景中，可能出现妙传的现象，其原因在于上传的资源的数字摘要与云盘中存在的某份资源的数字摘要相同，云盘识别到后不需要本地上传了。当从云盘下载该资源时，只需要根据数据摘要匹配到相同的资源，然后将该资源下载下来即可。例如上传电影《白日梦想家》到云盘，服务器根据电影进行hash形成一份数据摘要，然后去库中匹配这份数据摘要，找到同一份数据摘要了意味着这部电影已经被别人上传到该云盘，于是这边就不需要从本地上传到云盘了，即显示秒传。当我要从云盘下载这部电影来看时，服务器将库中别人的同样的电影发送过来。

数字签名

• 存在一对非对称加密密钥，对数据摘要进行私钥加密后形成数字签名，因此也能通过公钥对数字签名进行解密得到数据摘要。

CA认证

服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性。

证书可以理解为一个结构化的字符串，证书内包含信息：

1. 证书发布的机构
2. 证书有效期
3. 公钥
4. 证书所有者
5. 签名
6. …

• 申请证书时，需要去到特定的平台生成一对密钥对即公钥a和私钥a`,这对密钥用来网络通信进行明文加密及数据签名的。其中公钥随着csr文件一起发给CA进行权威认证，私钥留着为后续进行通信。

服务器向CA申请证书过程

• 服务器发送证书明文給CA，CA对证书明文做Hash处理形成一份数据摘要，CA自己有一对密钥：公钥C，私钥C`。用私钥C`对该数据摘要进行加密形成一份数字签名。然后将数字签名和已经验证过的证书打包成一份带数字签名的证书返回給服务器。

客户端验证服务器发来的证书过程

• 客户端的操作系统中内嵌了受信任的证书发布机构，即拥有这些机构的公钥。
• 客户端拿到证书后，会对证书进行校验

1. 用内嵌的公钥C对数字签名进行解密得到数据摘要k。
2. 对证书做Hash形成一份数据摘要k`。
3. 将数据摘要k和数据摘要k`进行对比验证，若二者相同则数字签名有效，证书有效。

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

• 中间人篡改了证书，那么在客户端验证期间，其证书通过Hash形成的数据摘要和数字签名解密得到的数据摘要不相符。
• 客户端OS中内嵌了受信任机构的公钥。中间人没有CA的私钥，在篡改了证书的基础上，无法使用CA私钥对数据摘要加密形成相符合的数字签名，即中间人用自己的私钥加密数据摘要形成的数字签名无法用客户端内的公钥解密。

为什么不直接对证书明文加密形成签名，⽽是要先hash形成摘要，再对摘要加密形成签名？

常见的摘要算法：MD5和SHA

以MD5为例：

• 定⻓: ⽆论多⻓的字符串, 计算出来的 MD5 值都是固定⻓度 (16字节版本或者32字节版本)
• 分散: 源字符串只要改变⼀点点, 最终得到的 MD5 值都会差别很⼤
• 不可逆: 通过源字符串⽣成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的
• 正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同

而固定长度的数据摘要注定长度不会太大，其长度远远小于大文件的证书明文。加快了数字签名的验证摘要的运算速度。

中间⼈整个掉包证书？

• 中间人没有CA的私钥，因此无法制作假的证书。服务器发来的证书携带着数字签名。该数据签名需要用客户端认证的机构的公钥去解密获得数据摘要，这注定着该数字签名只能由CA的私钥加密。
• 若中间人用申请好的CA证书进行掉包，该证书内含有域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。
• 因此中间人没有CA的私钥，是无法对任何证书进行合法修改的。

如何成为中间⼈

• ARP欺骗：在局域⽹中，hacker经过收到ARP Request⼴播包，能够偷听到其它节点的 (IP, MAC) 地址。例， ⿊客收到两个主机A, B的地址，告诉B (受害者) ，⾃⼰是A，使得B在发送给A 的数据包都被⿊客截取。
• ICMP攻击：由于ICMP协议中有重定向的报⽂类型，那么我们就可以伪造⼀个ICMP信息然后发送给 局域⽹中的客⼾端，并伪装⾃⼰是⼀个更好的路由通路。从⽽导致⽬标所有的上⽹流量都会发送到 我们指定的接⼝上，达到和ARP欺骗同样的效果。
• 假wifi && 假⽹站等。

具有证书的场景

1. 客户端向服务器请求证书，服务器响应一个数字证书，客户端对该证书进行校验，若证书非法则直接退出通信。
2. 客户端对服务器发来的数字证书校验合法后，形成一个对称密钥c，证书明文内含服务器的公钥s，用该公钥加密对称密钥c形成密文x，将该密文x发送給服务器。
3. 服务器收到密文x后，用私钥s`进行解密得到密钥c，往后，服务器和客户端通信的明文都用该密钥c进行加密后通信。

总结一下：

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

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