HTTPS协议原理

一、什么是HTTPS

        HTTP协议是用于超文本传输的应用层协议，但是HTTP协议在数据传输时，内容都是文本式的明文传输，这就导致传输一些用户个人信息时可能会造成信息泄露。HTTPS协议就是在HTTP协议的基础上添加了一个加密层（TLS（传输层安全）和SSL（安全套接字层）），这个加密层也属于应用层，在进行数据传输时需要先将数据进过加密层进行加密，在发送给对方，对方接收到数据再进过加密层进行解密，就得到了对应的信息。

二、了解加密

2.1 为什么要加密

        我们以运营商劫持为例，比如我们在浏览器要下载一个音乐软件，我们就需要向该软件的服务器发送http请求，其服务器收到请求后，在将下载的链接添加到报文中发送给我们，由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等), 那么运营商的网络设备就可以解析出你传输的数据内容, 并进行篡改，这样造成的结果可能就是传给我们的下载链接变成了一个未知的软件。

        造成上诉结果的根本原因就是http协议在进行数据传输时是明文传输，所以我们需要将我们的数据进行加密处理，这样就可以避免类似这样的中间人攻击。

2.2 常见的加密方式

2.2.1对称加密

• 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的
• 常见对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2 等
•  特点：算法公开、计算量小、加密速度快、加密效率高， 对称加密其实就是通过同一个 "密钥" ，把明文加密成密文，并且也能把密文解密成明文

一个简单的对称加密, 按位异或 假设 明文 a = 1234, 密钥 key = 8888 则加密 a ^ key 得到的密文 b 为 9834. 然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234. (对于字符串的对称加密也是同理, 每一个字符都可以表示成一个数字) 当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使用按位异或.

2.2.2非对称加密

• 需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
• 常见非对称加密算法(了解)：RSA，DSA，ECDSA
• 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。
• 非对称加密要用到两个密钥, 一个叫做 "公钥", 一个叫做 "私钥". 公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多.
• 公钥不怕泄露但是私钥一定不能泄露

1. 通过公钥对明文加密, 变成密文
2. 通过私钥对密文解密, 变成明文

也可以反着用

1. 通过私钥对明文加密, 变成密文
2. 通过公钥对密文解密, 变成明文

2.2.3数据摘要 && 数据指纹

• 数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash 函数)对信息进行运算, 生成一串固定长度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被篡改。
• 摘要常见算法：有 MD5、SHA1、SHA256、SHA512 等，算法把无限的映射成 有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）
• 摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比

        张三在网上找了一个电影的资源，想要把这个资源传到百度网盘中，百度网盘的服务器收到请求后就将资源保存到了张三的账号中，而李四也想将这个电影的资源上传到百度网盘，由于是同一份资源，百度网盘为了节约成本不想再将资源重复加载一遍，百度网盘就想到了一个方法，在张三将资源下载到网盘以后，网盘将这个资源利用散列函数生成一个数据摘要，在将这个数据摘要在后台保存起来，当李四向下载资源时网盘会将他要下载的资源以同样的散列函数生成一个数据摘要，并进行遍历，如果后台存在相同的摘要，就可以直接将张三的资源同步给李四就好了，这就是为什么我们在向网盘传输数据时有时候可以秒传

三、HTTPS的工作过程探究

使用对称加密和非对称加密就可以保证数据传输的安全了吗？接下来我们探讨一下如下几种方案

方案一：只使用对称加密

如果服务端和客户端有着相同的密钥，那只要密钥不被第三个人知道，即使数据被抓取他没有密钥就无法进行解密，那一定是安全的，但是事情并没有这么简单，服务器一定是给许多客户端提供服务的，与每个客户端通信的密钥必须是不同的，那么服务器后台就必须维护与每个客户端的密钥信息，这是个很麻烦的事情，比较理想的情况是服务器与客户端进行通信时首先协商好密钥，但是这里存在一个问题，我们使用密钥是因为要保护数据的安全，而密钥也一定要通过网络传输发送给对方，那密钥也一定需要加密，这就形成了"先有鸡还是先有蛋的问题"，光使用对称加密是行不通的

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

如果服务端将自己的公钥通过明文传输的方式发送给客户端，那么当客户端要发送数据时，使用接收到的公钥进行加密发送给服务器，由于只有服务器的私钥才能对数据进行解密，这个过程似乎是安全的（实际是有问题的，原因到方案四讲）。但是服务器到客户端的数据传输如何保证呢？服务器用自己的私钥对数据进行加密发送给客户端，客户端可以使用自己的公钥对数据进行解密，但是由于服务器的公钥是明文传输的，如果黑客截取到了公钥的内容，那他也可以对服务器发送的内容进行解密，所以这个方案也是不行的。

方案三：双方都使用非对称加密

1. 服务端拥有公钥 S 与对应的私钥 S'，客户端拥有公钥 C 与对应的私钥 C'

2. 客户和服务端交换公钥

3. 客户端给服务端发信息：先用 S 对数据加密，再发送，只能由服务器解密，因为 只有服务器有私钥 S'

4. 服务端给客户端发信息：先用 C 对数据加密，在发送，只能由客户端解密，因为只有客户端有私钥 C' 

5.这样貌似也可以，但是效率太低了，并且他也是有问题的，原因和方案二类似

方案四：非对称加密和对称加密

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

2. 客户端在本地生成对称密钥 C, 通过公钥 S 加密, 发送给服务器.

3. 由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就 无法获取到对称密钥(真的吗？)

4. 服务器通过私钥 S'解密, 还原出客户端发送的对称密钥 C. 并且使用这个对称密钥 加密给客户端返回的响应数据.

5. 后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务 器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义.

6. 由于对称加密的效率比非对称加密⾼很多, 因此只是在开始阶段协商密钥的时候使 用非对称加密, 后续的传输仍然使用对称加密. 虽然上面已经比较接近答案了，但是依旧有安全问题,因为如果中间人如果刚开始就进行攻击呢？

中间人攻击（针对上述场景）

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

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

2. 中间人具有非对称加密算法的公钥 M，私钥 M'

3. 客户端向服务器发起请求，服务器明文传送公钥 S 给客户端

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

5. 客户端收到报文，提取公钥 M(自己当然不知道公钥被更换过了)，自己形成对称 秘钥 X，用公钥 M 加密 X，形成报文发送给服务器

6. 中间人劫持后，直接用自己的私钥 M'进行解密，得到通信秘钥 X，再用曾经保存 的服务端公钥 S 加密后，将报文推送给服务器

7. 服务器拿到报文，用自己的私钥 S'解密，得到通信秘钥 X

8. 双方开始采用 X 进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的

造成上述结果的根本原因是客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送过来的！为了解决上述的问题我们需要了解以下的内容

四、引入证书

4.1 CA认证

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

4.2 数据签名

当服务端申请 CA 证书的时候，CA 机构会对该服务端进行审核，并专⻔为该网站形成 数字签名，过程如下：

1. CA 机构拥有非对称加密的私钥 A 和公钥 A'

2. CA 机构对服务端申请的证书明文数据进行 hash，形成数据摘要

3. 然后对数据摘要用 CA 私钥 A'加密，得到数字签名 S ，服务端申请的证书明文和数字签名 S 共同组成了数字证书，这样一份数字证书就可以颁发给服务端了

4.3 最终方案：非对称加密 + 对称加密 + 证书认证

1. 客户端在访问服务器时，服务器首先会将证书发送给客户端

2. 客户端在收到证书后首先会对证书进行校验

3. 检查证书是否过期

4. 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)

5. 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一 个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对 比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的.

6. 如果证书没有被修改过，说明证书中的服务器公钥也没有被修改过，客户端就可以使用服务器的公钥对自己形成的对称密钥进行加密，发送给服务器。

7.服务器收到客户端发送的对称密钥数据后，使用自己的私钥进行解密，这样客户端与服务器就可以安全的进行通信了

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

        不行。假设中间人截取到了证书，他想改变证书中服务器的公钥和签名信息，由于客户端只认CA机构的公钥，那中间人只能用CA机构的私钥进行对数据进行加密在发送给客户端，但是中间人是拿不到CA机构的私钥的，如果他拿自己生成的非对称密钥进行加密，那客户端拿CA机构的公钥也是无法解密的。

中间人有没有可能调包整个证书？

        因为中间人没有 CA 私钥，所以无法制作假的证书， 所以中间人只能向 CA 申请真证书，然后用自己申请的证书进行掉包 •，这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。中间人没有 CA 私钥，所以对任何证书都无法进行合法修改，包括自己的

如何成为中间人 - 了解

1. ARP 欺骗：在局域网中，hacker 经过收到 ARP Request广播包，能够偷听到其 它节点的 (IP, MAC)地址。例， 黑客收到两个主机 A, B 的地址，告诉 B (受害者) ，自 己是 A，使得 B 在发送给 A 的数据包都被黑客截取

2. ICMP 攻击：由于 ICMP 协议中有重定向的报文类型，那么我们就可以伪造一个 ICMP 信息然后发送给局域网中的客户端，并伪装自己是一个更好的路由通路。从而导 致⽬标所有的上网流量都会发送到我们指定的接口上，达到和 ARP 欺骗同样的效果

3. 假 wifi && 假网站等

完整流程

五、总结

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

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

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

第一组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥.

第⼆组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.