Linux网络基础：HTTPS 网络传输协议

HTTPS 网络传输协议

HTTP 协议是通过明文传输的，这个数据明文在网络传输过程时，每个人都可以查看到，甚至可以进行修改。

为了解决数据传输安全问题，提出了 HTTPS 安全的网络传输协议。

在 HTTP 协议的基础上加入了 SSL 或 TLS 协议层来提供加密通信和身份验证。保护在客户端（如网页浏览器）和服务器之间传输的数据不被窃听和篡改，同时确保通信双方的身份真实性。

加密

加密/解密，就是在原本的数据之上，添加一个或多个中间数据，辅助进行加密/解密过程（多添加的数据就是 密钥）。

• 加密就是把明文(要传输的信息)进行一系列变换，文成密文
• 解密就是把密文再进行一系列变换，还原成明文

常见的加密方式（对称/非对称加密）

• 对称加密：使用一个密钥就可以同时进行加密和解密
• 非对称加密：需要用到两个密钥，公开密钥（公钥）、私有密钥（私钥）

公钥对明文加密，变成 密文； 私钥对密文解密，变成 明文

数据摘要、数字签名

• 数据摘要：也被称为哈希值，将任意长度的数字信息通过特定算法压缩成较短的字符串的过程

这个短字符串通常被称为数字指纹或哈希值，它唯一地代表了原始数据的内容。

在数据库中，为了保证数据的安全性。用户的输入的密码就是通过 数据摘要 的方式存储在表中。等下次用户输入密码时，通过输入的密码再次生成 数据摘要 对比数据库表中的数据，来验证密码的正确性。

常见的生成数据摘要的算法：MD5、SHA系列…

• 数字签名：使用发送者的私钥对数据摘要后的数据进行再加密，生成的密文就是数字签名

HTTPS 加密过程探索的方案

前面提到，HTTP传输数据是不安全的。为了保证数据安全，网络传输就不能再进行明文传输，要对明文进行加密处理。

HTTPS 网络传输协议并不是一蹴而就定下来的。为了使用更好的加密方式，在此期间提出了几个加密的方案，我们来看看：

只使用对称加密（效率低下、不安全）

使用对称加密，需要自身和对方都拥有相同的密钥。这个密钥只有双方才知道，双方通信的安全是可以得到保证的，前提是密钥密钥被破解。

来看看这样的一张图解：

使用了对称加密，即使是获取了请求数据，没有对应的解密方法，也就获取不到数据的内容。

但是，只使用对称加密就是好的吗？

服务器是为客户端进行服务的，客户可以有多个，但是服务器只有一台。就形成了 一对多 的关系。

一个客户端一个密钥，有多少客户，服务器就要维护多少个密钥，并且 维护数据是需要成本的。
这样就会导致，服务器工作效率低下。

如果使用的还是相同的密钥，那就太容易扩散了，别忘了黑客也是用户，黑客也能拿到相同的密钥。

所以只使用对称加密的方式是不行的。

只使用非对称加密（不靠谱、不安全）

基于非对称加密的机制，客户端与服务端使用非对称加密方式如下：

1. 服务器将公钥发给客户端，客户端通过公钥对数据加密后传给服务器，服务器通过私钥解密获得数据
2. 服务器通过私钥对数据进行加密，发送给客户端后，客户端可以通过公钥进行解密

乍一看，好像没有问题。客户端加密后将数据发给服务器这条路是安全的。

但是仔细想想，服务器将数据发送给客户端这条路是安全的吗？公钥从服务器发送给客户端时，是明文传输的，数据容易被抓包截获，别人也可以使用这个公钥，对服务器发送的数据进行篡改。

反过来，如果服务器使用私钥加密数据的话，客户端是不能进行解密的。所以，只使用非对称加密是不靠谱的。

双方都使用非对称加密（效率低下、不安全）

双方都使用非对称加密，客户端与服务器传输数据加密过程如下：

服务器拥有公钥S、私钥S’; 客户端拥有公钥C、私钥C’；

1. 开始前协商，相互交换公钥。客户端获取服务器的公钥S，服务器获取客户端的公钥C
2. 客户端先用S公钥对发送的数据加密，再发送给服务端，发送的数据只能由服务器解密
3. 同样的，服务端先用C公钥对发送的数据加密，再发送给客户端，发送的数据只能由客户端解密

看上去还行，数据被捕获的基本问题好像解决了。但是这样做有一个不好的地方，双方都采用非对称加密的话，会导致传输速率变得很慢。

本来开开心心的网上冲浪，搜索个资源慢的要死。忍不了一点，耐心都消耗完了。非对称加密算法本来就耗时耗力，一方采用还行，双方都采用，直接拉低的网络数据传输效率。

都使用非对称加密的话，也防不住另一个安全问题：中间人攻击

讲完第四种方案后，再来仔细讲讲中间人攻击，这里先跳过。

使用非对称加密+对称加密（不安全）

上面提到，双方都使用非对称加密的方法不是不行，但是传输的效率不好。

非对称加密则使用公钥和私钥进行加密和解密，其加密和解密的过程复杂。对称加密使用相同的密钥进行加密和解密，加密和解密的速度较快。

专家就提出，使用 非对称加密 和 对称加密 进行网络数据传输。可以有效减少加密解密的时间。

具体过程如下：

服务器拥有公钥 S、私钥 S’； 客户端生成对称加密的密钥 X

1. 客户端发送请求，获得服务器公钥S
2. 客户端通过对称加密，生成密钥X
3. 客户端通过服务器的公钥S，对生成的密钥X进行加密处理，形成报文后发送给服务器
   （中间传输过程，没有私钥解密是不能获取到密钥X的）
4. 服务器通过私钥S’ 解密，还原出客户端发送的对称密钥X。并且在发送数据时，使⽤这个对称密钥X加密数据传输给客户端

此后，客户端与服务器的通信都只用对称加密的密钥X对数据加密传输即可。

图示：

第四种方案解决了方案三效率低下的问题。但是都避免不了 中间人攻击，当然啦，上面提到的4种方案都避免不了。

那么，什么是中间人攻击呢？

中间人攻击

• 中间人攻击：是指攻击者冒充服务器与客户端建立连接，并与双方分别建立非对称加密连接（也就是在三次握手前，就进行攻击）

具体过程如下：

服务器拥有公钥 S、私钥 S’；中间人拥有公钥H、私钥H‘

1. 客户端向服务器发起请求连接，服务器将公钥S以报文的形式发送客户端
2. 中间人劫持报文，将服务器公钥S并且保存起来，重新伪造报文将自己的公钥H发送给客户端
3. 客户端获取到公钥H，通过这个公钥H加密（对称加密）密钥X，形成报文发送给服务器
4. 中间人再次劫持，通过自己的私钥H’解密，获取到密钥X。将上次保存的服务器公钥S对密钥X加密处理，形成报文后发送给服务器
5. 服务器通过私钥S’解密，还原出客⼾端发送的对称密钥X
6. 此后的服务器客户端之间进行的对称加密通信，在中间人看来是毫无作用。密钥X中间人也有，当前面两者进行通信时，中间人直接解密获取对应的数据，甚至修改数据都可以

中间人攻击是发生在 TCP连接之前，所以上面提到的几个方案都不能很好解决这个问题。

如何解决呢？下面先来简单介绍一下 CA认证，了解后就知道解决方案了。

CA认证

关于CA的权威性，大家可以查阅这个连接内容：CA认证

申请数字证书

服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书书含有证书申请者信息、公钥信息等。

证书就如身份证，证明服务端公钥的权威性。

证书的申请流程如下：

申请要求通过审核后，CA会发一个证书，这个证书可以理解成一个结构化的字符串，其中包含以下信息：

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

生成数字证书细节

申请者认证申请通过后，CA机构会对该服务端进⾏审核，并专门为该网站形成 数字签名 (这里采用非对称加密)。过程如下：

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

1. CA机构将数据证书进行 hash 计算，生成一串 数据摘要
2. 再通过 私钥A 对数据摘要进行加密处理，形成数字签名S
   
   最后，将 证书明文 和 数字签名S 合在一起共同构成数字证书，最后颁发给服务器：
   

客户端认证

验证就很简单了，客户端收到服务端发送的数据证书后，将其拆分成 证书明文、数字签名。

客户端会先对证书进行认证（防止证书伪造）：

• 判断证书是否过期
• 验证颁发证书机构是否值得信任（OS内部内置了受信任的证书发布机构）
• 验证证书内容是否被篡改

如何进行验证证书内容是否被篡改呢？

1. 客户端先通过服务器发送证书中的 CA 公钥，对数字签名进行解密获取散列值
2. 过hash函数计算证书明文得到的散列值，与数字签名得到的散列值进行对比是否相等
   

通过上面两个步骤，就可以知道传输内容是不是被修改过。

当内容被修改后，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈。

HTTPS最终确定方案

• 证书认证 + 非对称加密 + 对称加密

HTTPS工作流程：

• 非对称加密（认证）：用于校验证书是否被篡改

服务器持有私钥（私钥在形成CSR⽂件与申请证书时获），客户端持有公钥(OS中包含了可信任的CA认证机构，同时持有对应的公钥)服务器在客户端请求是，返回携带签名的证书。客户端通过这个公钥进行证书验证，保证证书的合法性，进⼀步保证证书中携带的服务端公钥权威性。

• 非对称加密：⽤于协商⽣成对称加密的密钥

客户端用收到的CA证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥。

• 对称加密：客户端和服务器后续传输的数据都通过这个对称密钥加密解密

第二次非对称加密的密钥是为了让客户端把这个对称密钥传给服务器；

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

常见的问题

中间人为什么篡改不了数据

中间人如果篡改了证书的明文，就会造成证书明文生成的散列值与客数字签名的散列值在解密后内容对不上。

那么可以改数字签名的数据吗？答案是改不了，改了也会被发现。

由于中间人没有CA机构的私钥，所以无法hash之后用私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名。

中间人可以掉包证书吗？

• 掉包不了，只有 CA 有私钥，中间人通过公钥解密后，无法进行再加密形成证书

中间⼈不死心，通过向CA申请真证书，然后用自己申请的证书强行进行掉包，这样不是也可以达到目标？

这样不是不可以，但是客户端还是会识别出来。因为证书明⽂中包含了域名等服务端认证信息。

中间⼈没有CA私钥，所以对任何证书都无法进行合法修改、生成

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

可以说是一切为了效率。前面提到过，证书明文一个结构化的字符串。

网络传输讲究的是效率。直接使用原始数据进行加密，传输效率会变低、解密后进行数据对比也会消耗大量的时间。

对此，要需要缩小签名密文的长度，加快数字签名的验证签名的运算速度