【网络协议】HTTPS相关知识详细梳理

目录

[1. 何为HTTPS？](#1. 何为HTTPS？)

[2. 了解加密/解密](#2. 了解加密/解密)

[3. 常见的加密方式](#3. 常见的加密方式)

3.1对称加密

[3.2 非对称加密](#3.2 非对称加密)

[4. 数据摘要（数据指纹）/ 数字签名](#4. 数据摘要（数据指纹）/ 数字签名)

[5. HTTPS协议原理及由来](#5. HTTPS协议原理及由来)

[5.1 方案讨论](#5.1 方案讨论)

[5.2 中间人攻击](#5.2 中间人攻击)

[5.3 CA证书](#5.3 CA证书)

[5.4 最终方案：非对称加密 + 对称加密 + 证书认证](#5.4 最终方案：非对称加密 + 对称加密 + 证书认证)

---

1. 何为HTTPS？

HTTPS是属于 应用层 的 网络协议。

它基于HTTP协议，引入了一个加密层。

至于为何要加密，是因为HTTP协议是按照文本方式进行明文传输的协议，这会导致信息的泄露和篡改。

2. 了解加密/解密

在正式介绍HTTPS协议之前，首先我们要了解加密/解密的概念。

首先是 加密：

加密就是把 明文(要传输的信息)进行一系列变换, 生成 密文。

然后是 解密：

解密就是把 密文再进行一系列变换, 还原成 明文。

还有 密钥：

在 加密 和 解密 的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这
样的数据称为 密钥。
加密解密如今俨然成为一门学科：密码学 ，其中密码学的奠基人，正是艾伦 ·麦 席森 · 图灵。
大名鼎鼎的 图灵奖正是以它的名字命名。

3. 常见的加密方式

3.1对称加密

采用单钥****密码系统 加密 ：同一个****密钥可以同时用作信息的加密和解密，这 种加密方法称为对称加密，也称为单密钥加密，

对称加密就是通过同一个密钥，将明文加密成密文，再把密文解密成明文。

++重点 ：加密和解密所用的密钥是相同。++

特点：算法公开、计算量小、加密速度快、加密效率高。
常见对称加密算法： DES、3DES、AES、TDEA、Blowfish、RC2 等

3.2 非对称加密

区别于对称加密，需要两个密钥 来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥） 和私有密钥（private key，简称私钥）。
公钥和私钥是配对的：
可以
通过公钥对明文加密，变成密文，
通过私钥对密文解密，变成明文。
也可以反过来
通过私钥对明文加密，变成密文，
通过公钥对密文解密，变成明文。
常见的非对称算法：RSA，DSA，ECDSA。
特点：安全性基于 "数学难题"，破解难度极高。加密解密速度慢，不适合大文件传输。

4. 数据摘要（数据指纹）/ 数字签名

为了使下面的原理讲解更加顺畅，还需简要了解 数据摘要 和 数据签名 的概念。

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

5. HTTPS协议原理及由来

5.1 方案讨论

首先为了保证数据安全，数据传输不能以明文形式传输，必须进行加密。

由此引申出了几种加密方案：

方案一：只使用对称加密

如果通信双方各自持有同一个密钥X，并且别人不知道，双方通信的安全可以保证。

引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密, 无法获知真实信息。
但是这个方法最大的弊端是，实际情况中服务端不只向一个客户端提供服务。

如果所有的客户端都用同一个密钥，那就不再安全了，那么服务器必然要为每一个客户端维护一个不同的密钥关系，为此较为理想的方式是在客户端和服务端建立连接的时候，双方对密钥进行协商。

但如果把密钥协商的过程直接明文传输，黑客也能获取密钥

所以说密钥协商也必须加密传输！但是这就指向了一个严重的问题，要对一个密钥进行加密，就需要先进行密钥协商获得一个密钥，但是这个密钥协商又用谁来加密呢？这个问题就好比"先有鸡还是先有蛋"。此时密钥传输采用对称加密是行不通的。

方案二：只有服务端使用非对称加密

鉴于非对称加密的机制，服务器要先把公钥以明文方式传输给客户端，之后客户端

向服务器传数据前都先用这个公钥加密好再传，从客户端到服务器信道似乎是安全的

(并非安全)，因为只有服务器有相应的私钥能解开公钥加密的数据。

但是服务器到客户端的通路就无法保证安全了。

如果服务器用它的私钥加密数据传给浏览器，那么客户端用公钥可以解密它，而这个

公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用

该公钥解密服务器传来的信息。

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

1. 服务端拥有公钥 S 与对应的私钥 S'，客户端拥有公钥 C 与对应的私钥 C'。
2. 客户和服务端交换公钥
3. 客户端给服务端发信息：先用 S 对数据加密，再发送，只能由服务器解密，因为
4. 只有服务器有私钥 S'
5. 服务端给客户端发信息：先用 C 对数据加密，在发送，只能由客户端解密，因为
6. 只有客户端有私钥 C'

这样看似很合理了，但是还是有问题：

• 效率太低

• 依旧有安全问题

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

服务端具有非对称公钥 S 和私钥 S'

1. 客户端发起 https 请求，获取服务端公钥 S
2. 客户端在本地生成对称密钥 C, 通过公钥 S 加密, 发送给服务器.

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

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

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

看似方案四很稳，实则依旧有问题。

方案二，三，四都有一个同样的问题，如果在最开始，中间人攻击就开始了呢？

那么，针对上面的方案，中间人如何展开攻击呢？

5.2 中间人攻击

Man-in-the-MiddleAttack ，简称"MITM 攻击 "。
在方案 2/3/4 中，客户端获取到公钥 S 之后，对客户端形成的对称密钥 X 并 用服务端给客户端的公钥 S 进行加密，此时中间人即使窃取到了数据也无法解密，因为只有服务器持有私钥 S'。
但如果中间人的攻击，如果在最开始握手协商的时候就进行了，那就不一定了
假设：
黑客在最开始 已经成功成为中间人

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 进行对称加密，进行通信。但是此时中间人也拿到了密钥X，劫持
   数据，进行窃听甚至修改都不在话下 。
   

产生上述问题的关键就在于客户端无法确定收到的数据有没有遭到篡改。
由此引入了新的解决办法：

5.3 CA证书

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

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

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

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

1. CA机构拥有非对称加密的私钥A和公钥A'
2. CA机构对服务端申请的证书明文数据进行hash，形成数据摘要
3. 然后对数据摘要用CA私钥A'加密，得到数字签名S
   服务端申请的证书明文和数字签名S 共同组成了数字证书，这样一份数字证书就可以
   颁发给服务端了。
   

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

在客户端和服务器刚一建里连接的时候, 服务器给客户端返回一个 证书 ，证书包含了
之前服务端的公钥,也包含了网站的身份信息。

客户端获取到证书后，会对证书进行校验（防止伪造）

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

1. ++此时中间人可能篡改证书不被发现吗？++

中间人并没有 CA 机构的私钥，无法对数据进行 hash 后用私钥进行加密形成客户端可以解密的签名（CA公钥内置在客户端系统中），也就无法篡改的证书后形成匹配的签名。

如若中间人强行篡改，客户端收到该证书后也会发现明文的数据摘要和解密后的签名不符，发现证书已经被篡改，不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

2. ++那中间人掉包整个证书呢？++

• 因为中间人没有CA私钥，所以无法制作假的证书。
• 所以中间人只能向CA申请真证书，然后用自己申请的证书进行掉包。
• 就算中间人能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端信息，如若客户端发现证书中的域名信息和访问的域名不一，同样会发现证书被篡改。

最后补充一些问题：

为什么摘要内容在网络传输的时候一定要加密形成签名 ?

为了防止数据内容和摘要同时被中间人篡改，导致客户端校验成功，误以为证书安全，必须要加密摘要让中间人无法修改证书内容。

为什么签名不直接加密，而是要先 hash 形成摘要 ?

缩小签名密文的长度,加快数字签名的验证签名的运算速度。