HTTPS 协议为什么是安全的？

date

Jan 28, 2023

slug

why-https-secure

status

Published

HTTP 协议为什么不安全？

HTTPS 协议的相对安全，是相对于 HTTP 协议而言的，那么，HTTP 协议为什么不安全呢？主要基于以下三个原因：

容易被窃听：HTTP 使用明文进行数据传输，黑客很容易通过监听技术获取报文的内容，由于数据没有加密，一旦报文被黑客获取，传输的内容就一览无遗了。

容易被篡改：黑客通过监听获取到 HTTP 报文后，通过分析，很容易对报文的内容进行修改，再将修改后的内容发送至原目标地址。比如，用户 A 发起了一个转账给用户 B，用户 C 监听并修改了报文，将 B 用户的 ID 修改为自己的 ID，此时，B 用户应该收到的转账最终会被转到 C 用户的账户内。

容易被伪造：黑客通过监听并修改 HTTP 报文后，可以将目标地址 A 改变为目标地址 B，从而造成用户的财产损失。比如，一些钓鱼网站伪造成购物平台，引导用户进入、付款。

HTTPS 是如何解决以上安全性问题的呢？主要基于以下三点：

数据加密：HTTPS 在数据传输前，会使用加密算法对报文进行加密，黑客即使监听并获取了报文，也无法理解内容。

完整性检测：HTTPS 会通过消息摘要算法对报文的内容进行完整性检测，如果重新生成的摘要与报文中摘要的内容不一致，接收方就可以断定——数据被篡改了。

安全证书：HTTPS 会通过数字证书来验证通信者的真实身份，伪造的网站因为没有相应的证书，一旦冒充，就会被识破。

加密算法

加密算法用于解决 HTTP 传输数据时被窃听的问题。

一般来说，加密算法分为两大类，对称加密和非对称加密。

对称加密：又称为对称加密、私钥加密、共享密钥加密，是密码学中的一类加密算法。这类算法在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。

非对称加密：又称公开密钥密码学，它需要两个密钥，一个是公开密钥，另一个是私有密钥；公钥用作加密，私钥则用作解密。使用公钥把明文加密后所得的密文，只能用相对应的私钥才能解密并得到原本的明文，最初用来加密的公钥不能用作解密。公钥可以公开，可任意向外发布；私钥不可以公开，必须由用户自行严格秘密保管，绝不透过任何途径向任何人提供，也不会透露给被信任的要通信的另一方。

对称加密

计算机网络中常用的对称加密算法有：DES、3DES、IDEA、RC4、AES 等，除了 RC4（流加密算法），都属于分组加密算法。什么是分组加密呢？

首先，我们来看一种较为简单的对称加密算法——凯撒密码。这种算法只能对英语文本进行加解密，其主要思想是将明文中的每一个字母按照字母表所在的位置移动 N 位（允许回绕），得到密文。例如，N 为 2，原文为 hello world经过加密后，就变成了 jgnnq yqtnf这种方式的缺点在于，每个字母经过加密后只有唯一的密文表示，如果黑客收集了大量数据进行分析，很有可能找到规律，对密文进行破解。

接下来，我们来看分组加密算法，这种算法不限制文本的类型，无论是英文还是中文，都可以转化为二进制后，将要加密的报文处理为 N 比特一组（不足 N 时进行补全），每个分组通过一对一映射表进行加密。这种方式，相比于凯撒密码，增加了破解的难度。

非对称加密

OpenSSL（一个开放源代码的软件库包）一共实现了四种非对称加密算法，包括 DH 算法、RSA 算法、DSA 算法和椭圆曲线算法（EC）。其中，使用最广泛的是 RSA 算法。

非对称加密往往需要密码学安全伪随机数生成器的协助来产生一对密钥，其中，可以随便公开的，称为公钥；另一个不能公开的，称为私钥。在数据传输的过程中，使用公钥进行加密，使用私钥可以解密，且只有私钥可以解密。

非对称加密相对于对称加密，因为解密的私钥不发往任何用户，只在本地进行保存，因此，安全性更高。但由于公钥加密的复杂度较高，性能也会相对降低。

混合加密

混合加密，实际上就是非对称加密和对称加密的结合。

前面的内容提到过，非对称加密的复杂度较高，性能较差（大约是非对称加密算法的 100～1000 倍），但相对安全。对称加密的性能较好，但在协商密钥时，可能被黑客监听，窃取密钥，因此，安全性较差。为了兼顾性能和安全，HTTPS 采用混合加密的方式，即采用非对称加密协商出对称加密的密钥后，再使用对称加密进行数据传输。

消息摘要算法

消息摘要算法用于解决 HTTP 在传输过程中，数据容易被篡改的问题。

消息摘要算法有以下四个特点：

不可逆。即无法通过输出反推输入。

长度固定。无论输入的数据有多长，输入数据的长度固定不变。

一致性。相同的输入必定产生相同的输出。

多对一。不同的输入在极小概率下可能会产生相同的输出。

计算机网络中常用的消息摘要算法包括：MD5、SHA-1、SHA-256 等。其中，MD5 算法在 2011 年被 IETF（Internet Engineering Task Force，互联网工程任务组）禁止用作密钥散列消息认证。

为了防止传输数据被黑客篡改，发送发除了发送实际数据外，还会使用摘要算法得到原始数据的摘要，并将摘要一起发送。接收方接收到数据后，先使用密钥对数据进行解密，再使用相同的消息摘要算法得到数据的摘要，与发送方发送的摘要进行对比，如果二者不一致，说明数据被篡改了，反之，数据安全。

值得一提的是，在实际的使用中，为了防止数据和摘要同时被篡改，通信双方还会使用非对称加密协商鉴别密钥，鉴别密钥生成固定长度的识别码（MAC）后，和数据一起进行传输，接收方会同时对数据和识别码进行校验，确保消息的正确性。

数字证书

数字证书用于解决 HTTP 协议中身份容易被伪造的问题。

数字证书的存在，主要是为了解决中间人攻击问题。什么是中间人攻击呢？前面提到过，通信双方通过非对称加密协商对称加密的密钥，此时，公钥是公开的，任何人都可以拿到，如果黑客此时修改了公钥，将原始公钥变更为自己的公钥，客户端是不知道公钥不正确的。

为了避免这个问题，就需要使用数字证书来进行验证公钥的正确性。数字证书有点儿像身份证，客户端拿到数字证书的公钥后，会和计算机系统中内置的合法公钥做对比，如果公钥不合法，就会提醒用户，该证书无效。

一些问题

HTTPS 握手的过程是怎样的？

首先，来回顾一下 HTTP TCP/IP 协议三次握手的过程：

客户端主动发起连接请求，设置 SYN 标志位；

服务端返回 SYN+ACK 报文（此时，客户端能够确认双方的发送能力和接收能力都是没问题的）；

客户端发送 ACK 至服务器，服务端做最后的确认（此时，服务端能够确认客户端的发送能力和接收能力都是没有问题的）。

接着，我们来看看 HTTPS SSL/TLS 协议四次握手的过程：

客户端向服务端发起加密通信请求，协商 SSL/TLS 版本，同时发送用于生成会话密钥和鉴别密钥的随机数 1；

服务端响应请求，确认 SSL/TLS 协议版本，返回服务器的数字证书和用于生成会话密钥和鉴别密钥的随机数 2。

客户端验证服务端数字证书的合法性，如果证书合法，进行第三次握手，生成随机数 3（前主密钥），并根据随机数 1 和随机数 2 生成主密钥（Master Secret，MS），根据主密钥得到会话密钥和鉴别密钥，将数据通过主密钥进行加密，并生成摘要，最后将加密后的数据、摘要、随机数 3 一起发送至服务端。

服务端使用私钥解析出主密钥，根据随机数 1、2、3 计算出主密钥，通过主密钥得到会话密钥和鉴别密钥，进行第四次握手。

HTTPS = HTTP + SSL，在 HTTPS 协议中，当客户端与服务器通过三次握手建立 TCP 连接之后，并不会直接传输数据，而是会经过一个 SSL/TLS 握手的过程，协商出会话密钥、鉴别密钥、验证证书等，最后进行安全的数据传输。

主密钥的生成为什么需要三个随机数？

主要原因是为了防止连接重放。如果没有前面两个随机数，仅仅由客户端生成一个主密钥，并通过服务器公钥加密发送给服务器，黑客就可以使用相同的报文，再次和服务端通信，此时，服务端无法判断报文的有效性和真实性，如果涉及交易的信息，就有可能造成用户的财产损失。而有了三个随机数，即使黑客冒充客户端，发送相同的报文至服务端，由于随机数的存在，重新发送的内容将失效。