即时通讯安全篇（九）：为什么要用 HTTPS？深入浅出，探密短连接的安全性

2022 年 5 月 13 日
本文字数：5550 字
阅读完需：约 18 分钟

本文由 ELab 技术团队分享，原题“探秘 HTTPS”，有修订和改动。

1、引言

对于 IM 开发者来说，IM 里最常用的通信技术就是 Socket 长连接和 HTTP 短连接（通常一个主流 im 会是这两种通信手段的结合）。从通信安全的角度来说，Socket 长连接的安全性，就是基于 SSL/TLS 加密的 TCP 协议来实现的（比如微信的 mmtls，见《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》）；而对于 HTTP 短连接的安全性，也就是 HTTPS 了。

到底什么是 HTTPS？为什么要用 HTTPS？今天就借此机会，跟大家一起深入学习一下 HTTPS 的相关知识，包括 HTTP 的发展历程、HTTP 遇到的问题、对称与非对称加密算法、数字签名、第三方证书颁发机构等概念。

学习交流：

- 移动端 IM 开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK

（本文已同步发布于：http://www.52im.net/thread-3897-1-1.html）

2、系列文章

本文是 IM 通讯安全知识系列文章中的第 9 篇，此系列总目录如下：

3、写在前面

说到 HTTPS，那就得回到 HTTP 协议。

对于 HTTP 协议，大家肯定都熟得不能再熟了。那么 HTTPS 和 HTTP 的区别大家了解吗？

对于这个经典的面试题，大部分人会这么回答：

1）HTTPS 比 HTTP 多了一个 S(Secure)：也就是说 HTTPS 是安全版的 HTTP；
2）端口号不同：HTTP 使用 80 端口，HTTPS 使用 443 端口；
3）加密算法：HTTPS 用的是非对称加密算法。

上面的回答能给几分？等看完本文我们可以再回头来看下这个回答。

那么，HTTPS 是如何实现安全的短连接数据传输呢？想彻底搞明白这个问题，还是要从 HTTP 的发展历程说起 ......

4、HTTP 协议回顾

4.1 基础常识

HTTP 是 Hypertext Transfer Protocal 的缩写，中文全称是超文本传输协议（详见《深入浅出，全面理解HTTP协议》）。

通俗了解释就是：

1）超文本是指包含但不限于文本外的图片、音频、视频等多媒体资源；
2）协议是通信双方约定好的数据传输格式以及通信规则。

HTTP 是 TCP/IP 协议簇的最高层——应用层协议：

▲ 上图引用自《深入浅出，全面理解HTTP协议》

浏览器和服务器在使用 HTTP 协议相互传递超文本数据时，将数据放入报文体内，同时填充首部（请求头或响应头）构成完整 HTTP 报文并交到下层传输层，之后每一层加上相应的首部（控制部分）便一层层的下发，最终由物理层将二进制数据以电信号的形式发送出去。

HTTP 的请求如下图所示：

▲ 上图引用自《深入浅出，全面理解HTTP协议》

HTTP 报文结构如下：

4.2 发展历程

HTTP 的发展历程如下：

由 HTTP 的发展历程来看，最开始版本的 HTTP(HTTP1.0)在每次建立 TCP 连接后只能发起一次 HTTP 请求，请求完毕就释放 TCP 连接。

我们都知道 TCP 连接的建立需要经过三次握手的过程，而每次发送 HTTP 请求都需要重新建立 TCP 连接，毫无疑问是很低效的。所以 HTTP1.1 改善了这一点，使用长连接的机制，也就是“一次 TCP 连接，N 次 HTTP 请求”。

HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如 Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

PS：对于 IM 开发者来说，为了与 Socket 长连接通道区分，通常认为 HTTP 就是“短连接”（虽然这个“短连接”不一定真的“短”）。

HTTP1.0 若要开启长连接，需要加上 Connection: keep-alive 请求头。有关 HTTP 协议的详细发展历程可阅读《一文读懂HTTP协议的历史演变和设计思路》一文。

4.3 安全问题

随着 HTTP 越来越广泛的使用，HTTP 的安全性问题也逐渐暴露。

回忆一下多年前遍地都是的运营商劫持，当你访问一个本来很正常的网页，但页面上却莫名其妙出现了一些广告标签、跳转脚本、欺骗性的红包按钮，甚至有时候本来要下载一个文件，最后下载下来却变成了另外一个完全不同的东西，这些都是被运营商劫持了 HTTP 明文数据的现象。

下图就是似曾相识的运营商劫持效果图：

PS：关于运营商劫持问题，可以详细阅读《全面了解移动端DNS域名劫持等杂症：原理、根源、HttpDNS解决方案等》。

HTTP 主要有以下 3 点安全性问题：

归纳一下就是：

1）数据保密性问题：因为 HTTP 无状态，而且又是明文传输，所有数据内容都在网络中裸奔，包用户括身份信息、支付账号与密码。这些敏感信息极易泄露造成安全隐患；
2）数据完整性问题：HTTP 数据包在到达目的主机前会经过很多转发设备，每一个设备节点都可能会篡改或调包信息，无法验证数据的完整性；
3）身份校验问题：有可能遭受中间人攻击，我们无法验证通信的另一方就是我们的目标对象。

因此，为了保证数据传输的安全性，必须要对 HTTP 数据进行加密。

5、常见的加密方式

5.1 基本情况

常见的加密方式分为三种：

1）对称加密；
2）非对称加密；
3）数字摘要。

前两种适合数据传输加密，而数字摘要不可逆的特性常被用于数字签名。

接下来，我们逐一简要学习一下这三种常见的加密方法。

5.2 对称加密

对称加密也称为密钥加密或单向加密，就是使用同一套密钥来进行加密和解密。密钥可以理解为加密算法。

对称加密图示如下：

广泛使用的对称加密有：

对称加密算法的优缺点和适用场景：

1）优点：算法公开、简单，加密解密容易，加密速度快，效率高；
2）缺点：相对来说不算特别安全，只有一把钥匙，密文如果被拦截，且密钥也被劫持，那么，信息很容易被破译；
3）适用场景：加解密速度快、效率高，因此适用于大量数据的加密场景。由于如何传输密钥是较为头痛的问题，因此适用于无需进行密钥交换的场景，如内部系统，事先就可以直接确定密钥。

PS：可以在线体验对称加密算法，链接是：http://www.jsons.cn/textencrypt/

小知识：base64 编码也属于对称加密哦！

5.3 非对称加密

非对称加密使用一对密钥（公钥和私钥）进行加密和解密。

非对称加密可以在不直接传递密钥的情况下，完成解密，具体步骤如下：

1）乙方生成两把密钥（公钥和私钥）。公钥是公开的，任何人都可以获得，私钥则是保密的；
2）甲方获取乙方的公钥，然后用它对信息加密；
3）乙方得到加密后的信息，用私钥解密。

以最典型的非对称加密算法 RSA 为例，举个例子：

想要彻底搞懂 RSA，需要了解数论的知识，全部推导过程RSA加密算法。简单介绍思路：使用两个超大质数以及其乘积作为生成公钥和私钥的材料，想要从公钥推算出私钥是非常困难的（需要对超大数因式分解为两个很大质数的乘积）。目前被破解的最长 RSA 密钥是 768 个二进制位。也就是说，长度超过 768 位的密钥，还无法破解（至少没人公开宣布）。因此可以认为，1024 位的 RSA 密钥基本安全，2048 位的密钥极其安全。

非对称加密算法的优缺点和适用场景：

1）优点：强度高、安全性强于对称加密算法、无需传递私钥导致没有密钥泄露风险；
2）缺点：计算量大、速度慢；
3）适用场景：适用于需要密钥交换的场景，如互联网应用，无法事先约定密钥。

实践应用过程中，其实可以与对称加密算法结合：

1）利用非对称加密算法安全性较好的特点来传递对称加密算法的密钥。
2）利用对称加密算法加解密速度快的特点，进行数据内容比较大的加密场景的加密（如 HTTPS）。

PS：对于 IM 开发者来说，《探讨组合加密算法在IM中的应用》一文值得一读。

5.4 如何选择？

1）如果选择对称加密：

HTTP 请求方使用对称算法加密数据，那么为了接收方能够解密，发送方还需要把密钥一同传递到接收方。在传递密钥的过程中还是可能遭到嗅探攻击，攻击者窃取密钥后依然可以解密从而得到发送的数据，所以这种方案不可行。

2）如果选择非对称加密：

接收方保留私钥，把公钥传递给发送方。发送方用公钥来加密数据，接收方使用私钥解密数据。攻击者虽然不能直接获取这些数据（因为没有私钥），但是可以通过拦截传递的公钥，然后把自己的公钥传给发送方，再用自己的私钥对发送方发送数据进行解密。

整个过程通信双方都不知道中间人的存在，但是中间人能够获得完整的数据信息。

3）两种加密方法的混合：

先使用非对称加密算法加密并传递对称加密的密钥，然后双方通过对称加密方式加密要发送的数据。看起来没什么问题，但事实是这样吗？

中间人依然可以拦截公钥的传递，并以自己的公钥作为替换，治标不治本。

想要治本，就要找到一个第三方公证人来证明公钥没有被替换，因此就引出了数字证书的概念，这也是下一节将分享的内容。

6、数字证书

6.1 CA 机构

CA 就是 Certificate Authority，即颁发数字证书的机构。

作为受信任的第三方，CA 承担公钥体系中公钥的合法性检验的责任。

证书就是源服务器向可信任的第三方机构申请的数据文件。这个证书除了表明这个域名是属于谁的，颁发日期等，还包括了第三方证书的私钥。

服务器将公钥放在数字证书中，只要证书是可信的，公钥就是可信的。

下面两图是飞书域名的证书中部分内容的信：

6.2 数字签名

摘要算法：一般用哈希函数来实现，可以理解成一种定长的压缩算法，它能把任意长度的数据压缩到固定长度。这好比是给数据加了一把锁，对数据有任何微小的改动都会使摘要变得截然不同。

通常情况下：数字证书的申请人（服务器）将生成由私钥和公钥以及证书请求文件（Certificate Signing Request，CSR）组成的密钥对。CSR 是一个编码的文本文件，其中包含公钥和其他将包含在证书中的信息（例如：域名、组织、电子邮件地址等）。密钥对和 CSR 生成通常在将要安装证书的服务器上完成，并且 CSR 中包含的信息类型取决于证书的验证级别。与公钥不同，申请人的私钥是安全的，永远不要向 CA（或其他任何人）展示。

生成 CSR 后：申请人将其发送给 CA，CA 会验证其包含的信息是否正确，如果正确，则使用颁发的私钥对证书进行数字签名，然后将签名放在证书内随证书一起发送给申请人。

在 SSL 握手阶段：浏览器在收到服务器的证书后，使用 CA 的公钥进行解密，取出证书中的数据、数字签名以及服务器的公钥。如果解密成功，则可验证服务器身份真实。之后浏览器再对数据做 Hash 运算，将结果与数字签名作对比，如果一致则可以认为内容没有收到篡改。

对称加密和非对称加密是公钥加密、私钥解密，而数字签名正好相反——是私钥加密（签名）、公钥解密（验证），如下图所示。

限于篇幅，关于数字证书的内容本文就不再赘述，想详细了解的可以阅读：

7、为什么要使用 HTTPS

《图解HTTP》一书中提到 HTTPS 就是身披 SSL 外壳的 HTTP。

7.1 SSL

SSL 在 1999 年被更名为TLS。

所以说：HTTPS 并不是一项新的应用层协议，只是 HTTP 通信接口部分由 SSL 和 TLS 替代而已。

具体就是：HTTP 会先直接和 TCP 进行通信，而 HTTPS 会演变为先和 SSL 进行通信，然后再由 SSL 和 TCP 进行通信。

SSL 是一个独立的协议，不只有 HTTP 可以使用，其他应用层协议也可以使用，比如 FTP、SMTP 都可以使用 SSL 来加密。

7.2 HTTPS 请求流程

HTTPS 请求全流程如下图：

如上图所示：

1）用户在浏览器发起 HTTPS 请求，默认使用服务端的 443 端口进行连接；
2）HTTPS 需要使用一套 CA 数字证书，证书内会附带一个服务器的公钥 Pub，而与之对应的私钥 Private 保留在服务端不公开；
3）服务端收到请求，返回配置好的包含公钥 Pub 的证书给客户端；
4）客户端收到证书，校验合法性，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书），如果不通过，则显示 HTTPS 警告信息，如果通过则继续；
5）客户端生成一个用于对称加密的随机 Key，并用证书内的公钥 Pub 进行加密，发送给服务端；
6）服务端收到随机 Key 的密文，使用与公钥 Pub 配对的私钥 Private 进行解密，得到客户端真正想发送的随机 Key；
7）服务端使用客户端发送过来的随机 Key 对要传输的 HTTP 数据进行对称加密，将密文返回客户端；
8）客户端使用随机 Key 对称解密密文，得到 HTTP 数据明文；
9）后续 HTTPS 请求使用之前交换好的随机 Key 进行对称加解密。