当前位置：首页 > news >正文

【Linux网络编程】HTTPS协议原理

news 来源：原创 2025/7/20 5:13:39

一，HTTPS是什么？

1，什么是加密？

2，为什么需要加密？

3，常见的加密方式

对称加密

非对称加密

4，数据摘要&&数据指纹

二，HTTPS协议加密方案

方案一：只使用对称加密

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

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

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

上述四种方案存在安全问题的原因——中间人攻击

理解数据签名

理解证书以及CA机构

方案五：非对称加密+对称加密+证书认证

总结

一，HTTPS是什么？

概念：HTTPS（HyperText Transfer Protocol Sercure）是HTTP的安全版本，通俗地讲，HTTPS就是在HTTP的基础上做了加密，保证用户数据的安全。它通过SSL/TLS协议对数据进行加密，确保数据在传输过程中的安全性。

HTTPS也是一个应用层协议，是在HTTP协议的基础之上引入了一个加密层。

HTTP协议的内容都是按照明文传输的，这就导致在传输过程中可能会存在数据被篡改的情况。

所以，HTTPS广泛应用于需要保护用户隐私和数据安全的场景，如在线支付，登录认证等，都需要对用户的数据进行加密保护处理。

1，什么是加密？

加密就是把明文（要传输的信息）进行一系列变换，生成密文。

解密就是把密文，经过一系列的变换，还原成明文。

在这个加密和解密的过程中，往往需要一个或者多个中间数据，来辅助这一过程的完成，这样的数据称作密钥。

2，为什么需要加密？

如果使用HTTP协议，不对传输的数据进行加密，由于我们通过网络传输的数据都会经过运营商的网络设备（如路由器，交换机等等），那么运营商的网络设备就可以解析出你传输的数据内容，并进行篡改了。举个栗子：

因为HTTP的内容都是明文传输的，明文数据会经过路由器，wifi热点，通信服务运营商，代理服务器等多个网络节点，如果信息在传输过程中被劫持，传输的信息就全都暴露了。劫持者还可以篡改传输的信息，并且服务器和客户端都不知情。中间部分的运营商叫做中间人！！

所以，在互联网中，明文传输是比较危险的事情！！！

HTTPS就是HTTP的基础之上进行了加密，进一步的来保证用户的信息安全。

3，常见的加密方式

对称加密

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

常见算法：DES，3DES，AES，TDEA等等。

特点：算法公开，计算量小，加密速度快，加密效率高。

对称加密，其实就是通过一个密钥，可以讲明文转换成密文，也可以讲密文转换成明文。

举个栗子：

一个简单的对称密钥：按位异或

假设明文a=1234，密钥key=1111。

则加密a后得到的密文b为：a^key=133。

然后针对密文b，进行解密，转换成明文b^key，得到的就是原来的明文1234。

key就是一把密钥。

当然HTTPS使用的不是异或运算。

非对称加密

需要有两个密钥来进行加密和解密。这两个密钥分别是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。

公钥，顾名思义，是所有人可以获取到的；而私钥，就只有一个人持有。

常见非对称加密算法：RSA，DSA，ECDSA等。

特点：算法强度复杂，安全性依赖于算法与密钥。但是由于其算法的复杂，使得加密解密速度没有对称加密的速度快。

非对称加密要用到两个密钥，一个叫做"公钥"，一个叫做"私钥"。

公钥和私钥是配对使用的，最大的缺点就是运行速度非常慢，比对称加密要慢得多。

使用如下：

通过公钥对密文加密，通过私钥对密文解密。
也可以反着使用：
通过私钥对密文加密，通过公钥对密文加密。

4，数据摘要&&数据指纹

数据摘要（数据指纹）：其基本原理是利用单向散列函数（Hash哈数），生成一个固定长度的字符串。数据指纹并不是一种加密机制，但是可以用来判断数据是否被篡改。

一段文本，假设通过一个Hash函数映射得到的结果是XXXXXYYYY。

如果该文本的数据发生了篡改，改动一点点，通过同样的Hash哈数映射得到的摘要，就会变化很大。此时通过判断得到摘要是否相同，就可以判断出数据是否被篡改过了。

常见算法：MD5，SHA1，SHA256，SHA512等。算法把无限的数据映射成有限的数据，因此可能会存在碰撞（两个不同的摘要，映射出的结果相同，但是概率非常低）。

摘要的特征：和加密算法的区别，摘要严格意义不是加密。因为没有解密的过程，没有说从摘要通过Hash函数又映射到原数据，从摘要很难推出原信息。

二，HTTPS协议加密方案

既然要保证数据安全，就需要对数据进行加密。

网络传输中不能直接传输明文了，而是加密之后的密文。

加密的方式有很多，但是整体可以分成对称加密和非对称加密。

方案一：只使用对称加密

如果通信双方都各自持有同一个密钥，并且没有别人知道，那么此时的通信就是安全的。

现在的服务器端有一个密钥X，而客户端没有这个密钥。就需要先将该密钥给客户端发送过去，如果直接传输密钥，密钥可能会被中间人获取。因此密钥的传输也需要加密传输！！！

但是要想对密钥进行加密，此时就需要“密钥的密钥”，这就成了“先有鸡还是现有蛋”的问题。

所以，只使用对称加密的方式就行不通了。

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

使用非对称加密，含有两把密钥，一个公钥，一个密钥。

1，浏览器向服务器端发送数据过程

如果服务器先将公钥以明文传输的方式，传输给浏览器，之后浏览器向服务器发送数据，就先使用公钥对数据进行加密再发送，到达服务器端，服务器使用对应的私钥进行解密，就可以拿到原本发送的数据了。过程如下图：

此时的中间人，虽然可以获取到公钥p，但是只有使用私钥p'才能实现解密，而私钥p'只有服务器有，所以中间人无法获取用户发送的数据是什么。可以认为，这种非对称加密，保证了浏览器端向服务器端发送数据时的数据安全。

2，再看看服务器端向浏览器发送数据的过程：

由于服务器端传输公钥的时候，是明文传输的，所以中间人是可以获取到的。

当服务器端发送数据的时候，使用私钥进行加密，那么此时中间人，就可以通过公钥成功解密，获取到服务器端发送的数据，就可以完成篡改数据。

所以，这种加密方式，在服务器对客户端发送数据的时候，可能会存在数据被中间人篡改的问题。

总结：只使用非对称加密的话，貌似可以保证单向传输数据的安全，比如上述的例子。同时，还有一个缺点，非对称加密的算法复杂，造成加密和解密速度较慢。（其实这里的单向传输也是不安全的，后面会讲）。

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

在方案二中，使用一个非对称加密，可以保证单向的数据传输安全。

那么如果双方都使用非对称加密，是否能够保证双向传输数据的安全？？？

客户端和服务器端都持有各自的非对称密钥：

假设客户端的非对称密钥为：公钥C，密钥C'

服务器端的非对称密钥为：公钥P，公钥P'

首先进行交换公钥，客户端和服务器端都拿到对方的公钥，这个过程是明文传输的。中间人可以获取，但是公钥不能进行解密，所以中间人不能解析密文，不能篡改我们发送的数据。

1，客户端向服务器端发送数据的时候

使用对方的公钥S对数据进行加密形成密文，密文对于中间人是安全的，无法被解析。到达服务器端，服务器使用私钥进行解密，得到原数据。

2，服务器端向客户端发送数据的时候

同样使用对方的公钥C进行加密形成密文，中间人无法解析。到达客户端后，客户端使用私钥进行解密，得到原数据。

总结：这种方法现在看起来是没有问题的，保证数据的传输安全。但事实上是不安全的，和方案二一样。而且还有一个问题，就是效率问题，两个对称密钥，频繁的进行加密和解密，肯定会导致效率低下的问题。

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

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

客户端具有对称密钥C

过程如下图：在服务器端获取到客户端的对称密钥后，双方就开始使用对称密钥进行通信了。

这样可以大大提高通信的效率。

至此，上述的方案中，方案四最优，解决了效率慢的问题，但是同时还是存在安全问题。就选哟使用接下的方案。

上述四种方案存在安全问题的原因——中间人攻击

以方案四为例，因为方案四是这些中最优的，如果方案四存在问题，那么其他几个也必然会有问题。

上述的中间人在进行攻击的时候，都是在客户端和服务器端握手建立连接好后，进行攻击的，此时是安全的。但是如果中间人在一开始握手建立连接的时候就进行攻击，那么就会存在数据安全问题。

服务器具有非对称密钥：公钥S和私钥S'

中间人具有对称密钥：C

同时中间人也有自己的对称密钥：公钥M和私钥M'

双方刚开始建立连接时，中间人可以获取到公钥S，将其掉包成自己的公钥M，再发送给客户端，客户端无法判断该公钥是否有效。
所以客户端使用改公钥M，加密密钥C，传输的时候，再次被中间人获取，那么此时中间人就可以解析出对称密钥C。
然后为了防止服务器端识别不出来，就使用服务器端的公钥进行加密，再发送给服务器端。
至此，中间人在双方都不知情的情况下，获取到了双方通信的对称密钥。那么之后的数据传输，相当于中间人来说就是明文传输。因此这种情况，是存在数据安全问题的。

总结：这种问题产生的关键原因在于客户端无法判断获取到的公钥是否有效。

需要解决这个问题，首先需要知道几个前置知识：签名，证书以及CA机构。

理解数据签名

签名的形成时基于非对称加密算法的。

数据签名的过程如下：

签名者含有非对称密钥：公钥和私钥，私钥自己保存，只有自己知道。公钥分给别人，比如张三，李四，王五等，持有公钥。
现在需要传输一份数据，先将该数据通过散列函数映射成散列值，再对散列值使用私钥进行加密，
形成签名。再将签名与原数据拼接再一起，得到包含数字签名的数据。最后，将这个数据发送给张三，李四，王五等。
张三，李四，王五接受到数据后，就需要对数据进行验证，判断数据是否被篡改过。判断过程：
先将数据与签名进行分离，对数据使用同样的散列函数得到一个散列值，对于签名使用公钥进行解密，得到一个散列值。判断这两个散列值是否相等，如果相等，说明数据没有被篡改过。

上述过程中，只有签名者持有私钥，意味着只有签名者可以对数据进行加密，也就是只有签名者具有签名的能力。其他人也可以进行加密，但是用户只会使用签名者的公钥进行解密。所以，如果数据被篡改了，用户是可以识别出来的。这里的签名者其实就是 CA机构。而张三，李四，王五等就是客户端或浏览器。

理解证书以及CA机构

当客户端第一次向服务器发起请求时，服务器发送的不是一个公钥，而是一个 “证书”。

证书就是一份明文数据，携带了签名。其中在数据部分就包含一个公钥，该公钥就是服务器发送给客户端的公钥。

那么该证书服务器端是从哪里来的？这时就需要引入CA机构了。

CA机构内部包含非对称密钥：公钥A，私钥A'

注：客户端和服务器一般都内置了可信的CA机构或授权过的子结构的公钥A

当我们写好一个服务器，想要上线该服务器，使用HTTPS协议，就需要去当地的CA机构，申请认证一份CA证书。
服务器需要将自己的域名以及公钥交给CA机构，CA机构先进行信息的审核，审核通过后，对数进行签名，就会形成一份证书，包含数据和签名。
将该证书签发给服务器，此时服务器就可以直接将该证书发送给客户端（或浏览器）.
客户端（或浏览器）在收到证书后，就需要进行验证验证。将证书的数据和签名部分进行分离，数据部分经过相同的散列函数得到一个散列值。签名部分通过内置的公钥进行解密，得到散列值，对比这两个散列值是否相等，就可以识别出该证书是否被篡改过。这样客户端就可以安全的获取到服务器发送的公钥。

方案五：非对称加密+对称加密+证书认证

完整过程：

服务器端首先需要提供自己的域名，和自己的公钥，向CA机构申请认证证书。
客户端连接时，首先将证书发送给客户端，其中包含着自己的公钥S。
客户端在收到证书后，首先验证证书是否有效。验证成功后，就可以从数据部分提取出服务器的公钥S。
客户端适应服务器的公钥S，对密钥C进行加密，将加密后的数据发送给服务器端。
服务器端收到后，使用私钥S'进行解密，得到对称密钥C，此后，双方通信使用对称密钥传输数据

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

由于他没有 CA 机构的私钥，所以无法形成签名，那么也就没办法对篡改后的证书形成匹配的签名
如果强行篡改，客户端收到该证书后会发现明文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人

中间人能否整个掉包证书？？

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

为什么签名不直接加密，还要生成摘要？？

由于数据可能很大，而这里的加密算法使用的是非对称加密算法，算法复杂度高。所以先对数据形成摘要，再进行签名，可以加快数字签名的验证速度。同时也就可以提高验证数字签名的速度。

总结

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

第一组(非对称加密): 用于校验证书是否被篡改。 CA机构持有私钥，客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥)。服务器在客户端请求时，返回携带签名的证书。客户端通过这个公钥进行证书验证, 保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。

第⼆组(非对称加密): 用于协商生成对称加密的密钥。客户端用收到的 CA 证书中的公钥
(是可被信任的)给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解
密获取到对称加密密钥。
第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密。

一，HTTPS是什么？

1，什么是加密？

2，为什么需要加密？

3，常见的加密方式

对称加密

非对称加密

4，数据摘要&&数据指纹

二，HTTPS协议加密方案

方案一：只使用对称加密

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

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

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

上述四种方案存在安全问题的原因——中间人攻击

理解数据签名

理解证书以及CA机构

方案五：非对称加密+对称加密+证书认证

总结

相关文章：