Linux网络编程——https的协议及其加密解密方式-EW帮帮网

这是因为，我们通过网络传输的任何数据，都会经过运营商的一系列网络设备（路由器、交换机等）传输。使用http协议以明文的形式传输数据. 在下载软件的时候, 如果运营商发现服务器响应回来的数据是某个软件(可能是特定的软件)的下载链接, 那运营商可能就会劫持此响应, 然后把响应数据设置为另外一个软件的下载链接. 然后用户下载的就是其他软件

像这样信息在传输过程中被劫持，传输的内容完全暴露. 劫持者还可以篡改传输的信息且不被双方察觉这实际是 中间人攻击, 这种情况是很可怕的. 所以才需要对传输的数据进行加密

中间人泛指在通信的两个节点之间插入自己的设备或程序，以窃取、篡改或监控通信数据的攻击者。

所以绝大多数的网页都是用https协议来传输数据. 那么我们怎么知道有没有加密呢？

实际上对于没有加密的http请求来说，它绑定的是80端口，而对于加密的https来说其绑定的是443端口号，也就是说我们完全可以通过端口号来区分是否加密

常见的加密方式

1、对称加密

对称加密是使用相同的密钥(一个密钥)进行数据的加密和解密过程，即单密钥加密。这意味着发送者和接收者必须共享同一个密钥，并保证这个密钥的安全性，以确保通信的安全。对称加密算法速度快、效率高，适合处理大量数据的加密工作。然而，其主要挑战在于密钥分发：如何安全地将密钥从一方传递给另一方。

对称加密的工作原理

密钥生成：首先，需要生成一个密钥。这个密钥是随机产生的，并且需要保密。
加密过程：发送者使用这个密钥对原始数据（明文）进行加密，生成加密后的数据（密文）。
密文传输：加密后的数据通过网络或其他方式传送给接收者。
解密过程：接收者使用与发送者相同的密钥对收到的密文进行解密，恢复出原始数据（明文）。

常见的对称加密算法

AES (Advanced Encryption Standard)：目前最常用的加密算法之一，支持128, 192, 和256位密钥长度，广泛应用于保护敏感数据。
DES (Data Encryption Standard)：一种早期的数据加密标准，使用56位密钥。由于密钥长度较短，容易被暴力破解，现在已较少使用。
3DES (Triple DES)：为了解决DES密钥长度不足的问题，采用三重DES加密，即对每个数据块应用三次DES加密算法。
RC4：一种流加密算法，曾经广泛应用于如SSL/TLS协议中，但由于存在安全漏洞，现已不推荐使用。

2、非对称加密

非对称加密，也称为公钥加密，是一种使用一对密钥来进行加密和解密的加密技术：一个公钥和一个私钥。这两个密钥在数学上是相关的，但是根据公钥推导出私钥在计算上是不可行的。这种加密方式解决了对称加密中密钥分发的问题，因为它允许任何人使用公钥加密信息，但只有持有相应私钥的人才能解密这些信息。

例如你有一个保险箱，这个保险箱有两个钥匙：一个是锁门的钥匙（公钥），另一个是开门的钥匙（私钥）。任何人都可以用锁门的钥匙将东西锁进保险箱里，但是只有拥有开门钥匙的人才能打开保险箱取出里面的东西。在这个比喻中，锁门的钥匙相当于公钥，可以公开分享；而开门的钥匙则是私钥，需要严格保密。这样，你就能够安全地接收来自他人的重要文件或物品，同时确保除了你自己之外没有人能访问这些内容。

非对称加密的工作原理

密钥生成：首先需要生成一对密钥，包括一个公钥和一个私钥。公钥可以公开给所有人，而私钥则必须保密。
加密过程：发送者使用接收者的公钥对数据进行加密。
传输加密数据：加密后的数据通过网络或其他途径传送给接收者。
解密过程：接收者使用自己的私钥对收到的加密数据进行解密，恢复原始信息。

常见的非对称加密算法

RSA：最广泛使用的公钥加密算法之一，基于大整数分解问题的难度。
DSA (Digital Signature Algorithm)：主要用于数字签名，确保消息的真实性和完整性。
ECC (Elliptic Curve Cryptography)：基于椭圆曲线离散对数问题，相比RSA能够在提供相同安全级别的条件下使用更短的密钥长度，因此效率更高。

非对称加密中, 明文可以分别通过公钥或私钥加密生成密文, 对应的密文也需要分别通过密钥和公钥解密还原明文.

但是, 如果明文通过公钥加密, 那么生成的密文就只能通过私钥解密

相反的 如果明文通过私钥加密, 那么生成的密文就只能通过公钥解密

可以将 公钥与私钥之间的关系看作互为钥匙互为锁. 但是, 公钥是可以公开的, 私钥是不能公开的.

非对称加密最大的缺点就是: 运算速度慢, 比对称加密的运算速度要慢得多.

非对称加密的特点: 算法强度复杂、安全性依赖于算法与密钥

无论是对称加密或是非对称加密还是其他加密, 唯一的目的就是 防止中间人窃取或篡改数据, 使数据在网络中更加安全的传输

3、数字指纹

数字指纹(数据摘要)，其基本原理是利用单项散列函数（Hash）对信息进行运算，生成一串固定长度的数字摘要。这个摘要就是该数据的指纹，但是数字指纹并不是一种加密方式，因为加密通常对应着解密，而数字指纹很难反向推导出原始数据内容，这也是很多的加密哈希函数的重要特性之一。

虽然谈不上是一种加密方式，但是我们通过比较数字指纹可以很容易的检查出数据是否被篡改过。理想情况下，不同的输入数据应产生不同的指纹。但实际上由于输出空间有限（指纹长度固定），理论上存在不同的输入数据产生相同指纹的情况，这被称为碰撞。

它有着很多的应用场景如：

在下载软件时，提供者通常会同时提供软件的哈希值（如MD5, SHA-256等），用户可以通过对比自己计算的哈希值与提供的哈希值来确认下载的文件是否完整且未被修改。
为了保护用户的密码，网站通常不会直接存储密码本身（万一数据库被攻击容易造成泄露），而是存储密码的哈希值（即一种形式的数字指纹）。当用户登录时，系统会对输入的密码进行同样的哈希处理，并与之前存储的哈希值进行比对以验证身份。

3、数字签名

数字签名是基于非对称加密的生成的, 是对数据指纹的加密生成的

上面介绍了两种加密方式，那么HTTPS 究竟是什么方式加密的？

HTTPS 的加密方式是 先非对称加密之后再对称加密

我们先分析一下各种加密方式的各种情况

1. 只用对称加密

对称加密是指只是用单一密钥的加密方式.

那么, 只要通信双方(一般是客户端和服务器)都保存有此密钥, 并且不泄露不破解的情况下, 双方的安全是可以保证的.

因为, 即使有中间人获取到了加密数据, 但不知道密钥是什么, 也是无法获取数据具体的内容的

但是事实上并没有这么简单，服务器一般是负责服务多客户端的. 不同客户端与服务器之间的密钥必须是不同的, 所以服务器需要维护好各个客户端与对应密钥之间的联系, 以保证可以正常的提供服务.这是非常麻烦的，难道要提前给每个客户端分配好密钥吗, 这肯定是不现实的。

比较理想的做法是, 在此次客户端与服务器建立连接的时候, 双方协定此次通信的密钥:

难道这个时候中间人不管不顾吗？

所以在协商密匙的时候 密钥也是需要加密传输的。但是服务器还不知道密钥，客户端此时加密传输了服务器拿什么解密？所以此时是行不通的。

2、只用单一的非对称加密

非对称加密的特点: 双密钥, 一个公钥一个私钥. 即使公钥明文传输也没有问题, 因为公钥是可以公开的.所以要使用非对称加密，是要这么协商的：

客户端先问服务器要公钥, 然后服务器以明文的方式把公钥给客户端. 在之后的通信中, 客户端使用公钥加密, 服务器使用私钥解密就可以了.

公钥加密需要使用私钥解密, 所以好像即使中间人获取了公钥, 也没法对客户端加密的数据进行解密:

如果使用公钥对数据加密, 解密这需要私钥. 中间人确实无法解密客户端加密的数据.

但是, 中间人获取到公钥之后, 可以对服务器使用私钥加密的数据进行解密.

也就是说, 如果只用单一的非对称加密, 公钥加密发送的数据无法被中间人解密, 而使用私钥加密发送的数据是可以被中间人解密获取的.

这样又是行不通的。

3、双方都使用非对称加密

如果是双方都是用非对称加密呢?

也就是说, 客户端拥有公钥A和私钥A, 客户端将公钥A发给服务器, 让服务器响应数据时用公钥A加密

而 服务器拥有公钥B和私钥B, 服务器将公钥B发给客户端, 让客户端发送请求时用公钥B加密

这样, 都是用公钥对向外发送的数据加密 的. 中间人即使获取了两个公钥, 也无法获取到数据内容:

这样做还存在着问题：

密钥管理复杂性增加，每个用户都需要生成并安全地存储一对公钥和私钥。同时，还需要一个可靠的机制来验证公钥的真实性（例如通过证书颁发机构或Web of Trust），以防止中间人攻击。
性能问题非对称加密算法相比对称加密算法计算上更加复杂，处理速度较慢。如果所有数据传输都直接使用非对称加密，尤其是对于大数据量的情况，会导致显著的性能下降。
数字签名与加密混淆在实践中，非对称加密通常用于两个目的：加密（保证保密性）和数字签名（保证身份验证和数据完整性）。如果这两者之间的使用不清晰或者被混淆，可能会导致误解和潜在的安全风险。
中间人攻击的风险即使双方都使用非对称加密，如果没有有效的认证机制（如PKI，公共密钥基础设施），攻击者仍然可以通过中间人攻击替换双方的公钥，从而解密和篡改通信内容。

4、非对称加密+对称加密

先非对称加密协商公钥, 再通过公钥加密对称密钥将加密的密钥发送给私钥持有者.

然后使用私钥将加密的对称密钥解密出来, 之后的通信中都只使用对称加密的方式来进行加密.

也就是说, 只在协商阶段使用非对称加密, 之后的通信都使用对称加密,

这样效率的问题解决了. 好像也不存在安全问题了吧.

如果, 客户端与服务器已经非对称加密协商完成了. 即使中间人获取了公钥, 后面的数据内容也就无法获取了

但是, 如果中间人在非对称加密协商未完成的时候, 获取到了公钥, 然后做了手脚又会有什么情况呢?所以还会存在安全问题。

上面介绍的4中加密方法, 除了第一种方式用不了一点.

后面的三种方式都在一定程度上守护了数据安全:

第二种方式, 守护了从客户端发送给服务器的数据安全
第三种方式, 守护了双方的数据安全, 但是效率太慢
第四种方式, 则在守护了双方的数据安全的同时, 还保证了以后正常通信的效率

但这三种方法可以做到守护了数据安全的前提是, 中间人没在协商的时候动手脚

思考一下, 如果 在服务器给客户端发送公钥的时候, 中间人截取数据, 把发给客户端的服务器公钥换成自己的公钥并存储服务器的公钥. 会发生什么事呢?

如果中间人这样做了, 那么

客户端就会以为中间人的公钥是服务器的公钥.
客户端会用中间人的公钥加密数据, 并发送给服务器
然后中间人可以对客户端发送的数据进行截取
又因为客户端实际使用中间人的公钥加密数据, 所以中间人可以用自己的私钥解密获取客户端发送的数据.
然后中间人再用服务器的公钥加密获取到的客户端发送的数据
再将加密好的数据发送给服务器.
服务器可以用自己私钥解密.

这就会导致, 客户端和服务器都认为双方是在安全的通信, 但实际上, 数据已经被中间人获取了.

整个过程就像这样(假设协商用第四种方式加密):

所以这也是个安全问题，那么这个问题该怎么解决呢？

因为客户端不知道公钥已经被掉包了, 客户端无法识别收到的包含公钥的数据是否是来自服务器的.

如果 让客户端可以识别包含公钥的数据是否直接来自服务器 就可以解决这个问题.

证书

上面介绍的HTTPS协议可能使用的加密方法都不安全, 因为在沟通加密方式时, 客户端不能确定公钥是否正确来自服务器.

CA证书（Certificate Authority Certificate），即证书颁发机构证书，是由证书颁发机构（CA, Certificate Authority）签发的一种数字证书。它主要用于验证网络通信中实体的身份（如网站、服务器或个人），并保证通过互联网传输的信息是加密的，从而确保数据的安全性和隐私性，他会会包含一些信息, 比如: 证书持有者相关信息、持有者公钥、域名、证书有效期等.

服务器在使用HTTPS协议之前, 都需要先向CA申请一份数字证书. 申请到证书之后, 就可以使用HTTPS协议了.

此时客户端和服务器建立通信时, 服务器回向客户端发送网站的证书, 然后客户端验证证书有效性、获取服务器公钥、建立加密…

CA证书的功能就是保证客户端正确获取到服务器正确的公钥.

证书颁发流程

1、服务器创建公、私钥对, 并将公钥与其他申请信息(域名等)生成一个证书请求(.csr文件), 再将证书请求给CA

2、CA进行审核, 并生成证书

证书的生成流程

CA收到证书申请
对申请信息进行审核
生成证书内容:申请者公钥、有效期、证书签名算法、颁发者等（下图的数据），再使用散列函数形成散列值(数字指纹)
CA(签名者)使用自己的私钥, 根据数字指纹，生成唯一的数字签名 (通过对证书内容的数据指纹非对称加密生成)
证书内容与数字签名组成CA证书

最后CA将证书颁发给服务器。

服务器与客户端的证书验证流程

当服务器拥有了CA证书之后, 就可以使用HTTPS协议了

那么, CA证书该如何使用呢? 客户端如何验证服务器公钥确实来自服务器呢?

首先, 我们要了解一个内容: 客户端(浏览器)一般是包含受信任的证书颁发机构(CA)的CA证书的, CA的CA证书里包含有CA的公钥. 操作系统中同样内置受信任CA机构的证书

你可以在浏览器的证书管理中, 查看到相应的内容

那么, 客户端验证的流程就为:

与服务器建立通信, 接收服务器发过来的CA证书
根据服务器CA证书中记录的数据指纹算法, 直接对证书内容使用此算法计算数据指纹
根据证书颁发机构, 对比浏览器中信任的颁发机构的CA证书, 并获取颁发机构的公钥
使用颁发机构的公钥对服务器CA证书的数字签名进行解密, 得到证书内容的数据指纹
对比数字签名解密后得出的数据指纹与直接对证书内容计算得出的数据指纹
如果一致, 则表示服务器的CA证书没被篡改, 其中记录的服务器公钥正确. 反之则不正确

不只客户端需要对CA进行验证, 在服务器首次收到颁发的CA证书时, 也是需要对CA证书进行验证的, 防止CA证书已经被篡改

服务器获取CA机构的公钥, 可以从CA机构提供的地址下载

CA证书能否被篡改?

答案是肯定的, CA证书是可以被篡改的, 甚至可以用自己的密钥对已经被篡改的证书内容生成数字签名, 生成一个新的证书. 但是即使证书被篡改了, 也可以保证安全性.

因为:

如果, CA证书内容被篡改了, 那么数据指纹就会发生变化, 在验证对比解密出的数据指纹时, 就会发生错误. 结果就是被篡改的证书可以被发现发生了篡改

如果, CA证书内容被篡改了, 同时篡改人使用自己的密钥对已经被篡改的内容生成了数字签名, 这样计算出的数据指纹与数字签名内的数据指纹好像是相同的了.(其实这已经算是把证书掉包了)

但实际上是, 客户端根本无法对数字签名进行解密. 因为篡改人的公钥客户端不知道, 即使知道了, 篡改人也不被客户端信任.

因为, 客户端对数字签名进行解密的前提是, 拥有受信任的CA机构的公钥

篡改人的公钥, 明显是不被信任的

所以, 如果CA证书被篡改了, 客户端是可以直接发现的, 也就不会与服务器建立安全连接

5、证书+非对称加密+对称加密

有了证书之后, 客户端和服务器进行通信时加密的流程, 就变成了这样:

服务器给客户端发送CA证书, 客户端验证证书, 成功就获取服务器公钥(失败就提示并且不建立连接), 然后客户端生成对称密钥, 并使用服务器公钥加密发送给服务器

最终客户端和服务器都携带有对称密钥, 实现之后的加密通信

此时, 中间人无法获取对称密钥:

此时, 也就保证了通信的安全. (当然并不绝对) 所以HTTPS协议, 就是使用的证书认证+非对称加密+对称加密的加密方式, 进行加密通信的

感谢阅读！

Linux网络编程——https的协议及其加密解密方式

前言

https协议