HTTPS的原理

三四年前还在上学的时候就看了HTTPS，只知道个大概，脑子里的概念比较模糊。最近在B站上看到一个讲的比较清楚的视频，趁着空闲就又理了一遍，并且重新整理了以下以前的笔记。

HTTP的安全性

HTTP在传输过程中使用明文传输，其安全性是无法保障的。这里的安全性主要指两点：

• 数据必须是正确的，未被篡改的

• 数据内容私密，不可被他人截取查看

HTTP的安全性的保证在许多场景下是必要的，比如购物、网上银行等等。http的安全问题，可描述为三种：

• 窃听风险

• 篡改风险

• 冒充风险

所以出现了 HTTPS，他会将报文进行加密，然后传输，从而解决安全问题：

什么是HTTPS

HTTP，Hyper Text Transfer Protocol over Secure Socket Layer，是以安全为目标的HTTP通道，即安全的HTTP。实现原理是在HTTP下加入SSL（ Secure Socket Layer）层，SSL层负责将报文进行加密解密。

TLS 是SSL的加强版。

与HTTP的区别

• HTTPS协议需要申请CA证书，大部分需要收费。

• HTTP是明文传输，HTTPS则是由HTTP和SSL或者TSL协议构建的可以进行加密传输、身份认证的协议，比HTTP协议安全。

• HTTPS端口号为443，而HTTP则是80端口，并且他们的连接方式不同(因为TCP上方需要进行加密)。

SSL是如何加密的？

常用的加密方式分为两种：

• 对称加密

• 非对称加密

对称加密

• 对称加密算法是公开的

• 其安全性是依赖密钥的

• 对数据进行对称加密，需要使用一个密钥，解密时，需要相同的密钥解密

** 对称加密 **

假设对称加密算法为 f1()， 对称解密算法为 f2()，密钥为key，数据为 data，加密后数据为 datax
那么就有

f1(key, data) = x // 加密
f2(key, x) = data // 解密

对称加密的优点:

• 计算量小，加密于解密速度较快，适合加解密较大的数据

对称加密的缺点：

• 密钥传输容易泄漏，一个用户需要对应一个密钥，服务器密钥管理较为复杂

常见的对称加密算法有：

• DES（强度低，易破解）

• 3DES（仍易破解，在DES的基础上又进行了三次DES）

• AES （强度相对较高，破解难度大）

假设使用对称加密，我们来看传输流程：

使用对称加密有如下几个问题：

1. 服务端为每个客户端提供不同的key，这样做key的存储和管理是很困难的，并且key有被劫持的风险

2. 如果采用同一个key，那么黑客也会拿到Key，进行非法操作

所以对称加密不安全。

非对称加密

• 非对称加密算法也是公开的

• 他的加密算法包含两个密钥，一个为公钥（public key），一个为私钥（private key）

• 使用公钥加密、私钥解密； 如果使用私钥加密、只有公钥解密

• 因为加解密使用不同的密钥，所以称为非对称加密

** 非对称加密 **

假设非对称加解密算法为T， 公钥为SK，私钥为PK，数据为 data，加密后数据为 datax
那么就有

T1(PK, data) = datax  // 私钥加密
T2(SK, datax) = data // 公钥解密
---
T1(PK, data) = datax  // 私钥加密
T2(SK, datax) = data // 公钥解密

即：私钥加密，公钥解密。

非对称加密的优点：

• 加密和解密采用不同的钥匙，可以传输公钥，数据传输相对安全

非对称加密的缺点：

• 计算量大，加密解密的速度较慢

常见的非对称加密算法如下：

• RSA

RSA加密算法过程：

假设采用非对称加密，我们来看请求流程：

上述流程在客户端向服务端发送时，是没有明显问题的，因为黑客拿不到私钥，所以，黑客就不能对数据解密，而在服务端向客户端发送数据时，则有明显的问题：

• 步骤6，由于客户端使用公钥解密数据，而公钥的信息是公开的

• 所以黑客也拥有公钥，所以黑客可以截获数据，然后加密伪造信息发给服务器

• 非对称加密的加密效率远低于对称加密，对于稍大的数据进行非对称加密，会非常耗时

所以非对称加密也不安全。

对称和非对称结合

从上面的分析来看，单独使用对称加密或者非对称加密很难满足需求。对称加密在加密效率上有着较高的优势，但其缺点主要在于不能给每个用户设立一个唯一的key，如果可以则对称加密就安全了。假设不考虑key的存储问题，为每个客户端提供一个不同的key，如下：

1571122922962

如果密钥传输是绝对安全的，这种传输方式就是绝对安全的。但是步骤1和2的密钥获取的步骤，同样会有可能被黑客篡改。这样问题就从数据安全性的问题，转移到了 对称加密的密钥安全传输的问题。

为了保证对称加密的密钥传输的安全性，如果我们继续使用对称加密，则陷入了死循环 ，永远解决不了安全问题。如果使用非对称加密对密钥进行加密：

1571139545132

• 假设非对称加密是安全的，那么对称密钥的发送就是安全的

• 但是，非对称加密的传输同样也不是安全的

• 在步骤1中，如果客户端请求公钥时，被黑客截获

• 黑客存储服务端的公钥，并返回自己的公钥钥给客户端

• 客户端使用错误的公钥发送隐私数据给服务端，黑客再次接获数据

• 黑客将内容解密（因为使用的是黑客的公钥），然后修改数据，再使用正确的公钥加密，发送给服务端

• 这样就完成了伪装篡改的目的

上述问题是典型的中间人问题。

CA和证书

为了解决中间人问题，引入了CA证书。中间人问题出现的原因主要因为是网站公钥的获取，client端获取的公钥有可能是中间人伪造的假的公钥。为了保证公钥的准确性，出现了一个CA机构。CA机构负责存储各个网站的公钥，只有CA机构认证过的公钥，才是合法公钥。

CA机构会使用非对称加密通过CA的私钥对网沾的公钥进行加密，加密后的内容就是证书。所以证书内容主要是公钥。客户端在请求公钥时，不再请求公钥，而是去请求证书。客户端得到证书后，需要得到CA的公钥才能解密证书，得到想要的网站公钥。

如果客户端通过网络从CA机构获取CA机构的私钥，这样仍然不安全，仍然会有中间人问题。所以CA机构的公钥，是存储在各大浏览器本地中，而不是通过网络获取。

具体流程

1. C访问S，告知S，C所支持的SSL版本、使用的非对称加密算法、以及随机数 1 （标记此次请求）

2. S响应C，告知即将通讯的SSL版本、非对称加密算法、随机数2（标记此次响应）、以及证书（内容是网站公钥）

3. C端接受到证书，对证书进行认证

4. C访问S，生成随机数3，并将使用hash算法对随机数1, 随机数2进行签名，将签名值xx传给S

5. S收到请求，比对签名，确认是刚刚那个C端。通过特殊算法对随机数1、2、3进行处理，生成数字 k

6. S响应C，将随机数 1、2、3 进行签名，返回给C端

7. C接受响应后，同样对1、2、3进行签名，比对服务端的签名值。如果签名比较成功，那么C端也生成了数字k。这个k就是C端所需要的对称加密密钥。