深入解析HTTPS协议：从加密原理到TLS握手全过程

随着网络安全意识的提升，越来越多的网站已从HTTP迁移至HTTPS协议。作为互联网数据传输的安全基石，HTTPS究竟如何保障我们的信息安全？本文将深入浅出地拆解其背后的核心技术，包括加密算法、完整性摘要、数字证书以及关键的TLS握手流程。理解了这些，你不仅能从容应对面试，更能深刻把握现代Web安全的脉络。更多关于网络协议与系统安全的深度讨论，欢迎访问云栈社区的技术板块。

1. 不安全的HTTP

近年来，越来越多的网站使用HTTPS协议进行数据传输，原因在于HTTPS相较于HTTP能够提供更加安全的服务。

许多浏览器会对使用HTTP协议的网站加上“警告”标志，提示数据传输不安全；而对于使用HTTPS协议的网站，则会显示一把“锁”标志，表示连接是安全的。

那么，HTTP协议具体存在哪些安全隐患呢？主要表现在以下三个方面：

• 容易被窃听：HTTP传输的数据是明文。攻击者很容易通过嗅探技术截获网络报文，由于数据没有经过任何加密，其内容可以被直接读取和理解。
  • 举个例子：如果用户在网上输入密码进行取款操作，攻击者一旦窃听到此密码，后果不堪设想。
• 容易被篡改：攻击者在截获HTTP报文后，可以对其进行修改，然后再转发到目的地。
  • 举个例子：如果用户想要转账给家人，而攻击者将收款人修改成了自己，将直接导致用户的经济损失。
• 容易被伪造身份：攻击者可以伪造HTTP响应，伪装成用户真正想要访问的网站，从而与用户进行通信。
  • 举个例子：如果用户想要访问淘宝购物，而攻击者冒充淘宝网站，用户就可能在这个假冒网站上泄露个人信息和支付信息。

HTTPS是如何解决以上这些安全性问题的呢？其核心方法如下：

• 数据加密：HTTPS传输的不再是明文，而是采用加密算法传输密文。攻击者即使截获了报文，也无法理解其内容。
• 完整性摘要：HTTPS通过摘要算法为报文生成一个“指纹”（摘要）。如果数据在传输中被篡改，接收方重新计算出的摘要将发生变化，通过比对即可发现数据已被破坏。
• 数字证书：HTTPS通过数字证书来验证通信实体的真实身份。攻击者因为没有权威机构颁发的合法证书，其冒充行为会被轻易识破。

2. 加密算法

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

为了防止传输数据被窃听，客户端与服务器之间需要对数据进行加解密处理。

发送方使用加密算法将明文转换为密文，而接收方使用相应的解密算法将密文还原为明文。攻击者只能看到无法理解的密文，从而无法获取有效信息。其过程如下图所示：

加密算法主要分为两大类：对称加密和非对称加密。

• 对称加密：加密和解密使用同一把密钥，即上图中的密钥A等于密钥B。
• 非对称加密：加密和解密使用不同的密钥，即上图中的密钥A不等于密钥B。

（1）对称加密

在对称加密算法中，加密和解密的钥匙是同一把，称之为密钥。

凯撒密码是一种简单的对称加密算法，用于对文本进行加解密。其核心思想是：将明文中的每个字母按照字母表顺序右移K位，得到密文（超出字母表则回绕）。

例如，设密钥 K = 2，那么明文中的字母 “a” 会被替换为 “c”，字母 “z” 会被替换为 “b”。

这种简单替换的缺点在于：每个字母的密文是唯一的，攻击者通过收集大量密文进行统计分析，就可能破解加密方式。

改进的方法是采用多个不同的K值轮询加密。例如，对奇数位置的字母使用K=2加密，对偶数位置的字母使用K=3加密。

然而凯撒密码只能处理字母，为了加密所有类型的数据（在计算机中都是0/1比特），可以采用分组加密。

分组加密的主要思想是：将待加密的报文划分为固定长度（如K比特）的分组，每个分组通过一个预定义的映射表进行替换加密。

例如，设分组长度K=3，并使用下图中的映射表，那么报文 010110001111 将被加密为 101000111001。这里的映射表就是对称加密的密钥。

同样，为了增加破解难度，实际应用中会使用多个复杂的映射表进行轮换加密。计算机网络中常用的对称加密算法，如 DES、3DES、AES 等，都属于分组加密算法。

（2）非对称加密

非对称加密算法使用一对密钥：公钥和私钥。其特点是：

• 如果用公钥加密，则只能用对应的私钥解密（公钥不能解密）。
• 如果用私钥加密，则只能用对应的公钥解密（私钥不能解密）。
• 公钥是对外公开的，任何人都可以获得；私钥必须严格保密，不能泄露。

既然有了对称加密，为什么还需要非对称加密呢？

关键在于对称加密的前提——通信双方需要提前协商出一个共同的密钥。而这个“协商密钥”的过程本身是通过明文传输的！如果这个初始密钥被攻击者截获，那么后续所有用该密钥加密的通信都将被破解。

非对称加密的“公钥加密，仅私钥可解”特性完美解决了这个问题。通信双方可以直接交换公钥（即使被攻击者知道也无妨）。当一方用对方的公钥加密信息后，只有拥有对应私钥的另一方才能解密，攻击者截获密文也无计可施。

计算机网络中常用的非对称加密算法有：RSA、ECDHE 等。这些算法涉及复杂的数学原理，如果感兴趣可以查阅相关资料深入学习，例如阮一峰关于RSA算法的系列文章。

（3）混合加密

我们已经知道，对称加密的弱点在于密钥协商过程不安全；而非对称加密虽然安全，但其计算复杂，加密速度非常慢，通常比对称加密慢100到10000倍！

那么，能否结合两者优点呢？答案是肯定的。HTTPS采用的就是混合加密方式。

思路很巧妙：利用非对称加密的安全性来传输一个临时的“会话密钥”，然后利用对称加密的高效率来传输实际的业务数据。

• 会话密钥通过非对称加密传输，确保密钥交换过程安全。
• 大量数据通过对称加密传输（只需一次密钥交换），保证了数据传输的高效。

3. 摘要算法

摘要算法用于解决HTTP传输数据容易被篡改的问题。

摘要算法也称为哈希算法，其输入可以是任意长度的数据，输出是一个固定长度的字符串（称为摘要或哈希值）。主要特点如下：

• 不可逆：无法从输出（摘要）反推出输入（原始数据）。
• 确定性：相同的输入必然产生相同的输出。
• 抗碰撞性：不同的输入极大概率会产生不同的输出。
• 固定长度：无论输入数据多长，输出的摘要长度固定不变。

一个简单的摘要算法例子：将数据的比特流每8比特分组，然后将所有分组进行按位异或运算，结果就可以作为一个摘要。

如果两个不同的输入产生了相同的摘要，这被称为哈希碰撞。一个强大的摘要算法出现碰撞的概率极低。计算机网络中常用的摘要算法有：MD5、SHA-1、SHA-256 等。

为了防止数据被篡改，发送方在发送数据时，会利用摘要算法计算出数据的一个摘要，并一并发送。
接收方收到数据后，用同样的算法重新计算摘要，并与发送方传来的摘要进行比对。如果一致，说明数据完好；如果不一致，则说明数据在传输中被篡改了。

细心的读者可能发现了漏洞：如果攻击者同时篡改了数据和摘要，接收方不就无法察觉了吗？

确实如此。为了防止这种情况，通信双方需要共享一个攻击者不知道的秘密信息，比如一个专门的鉴别密钥。在计算摘要时，将原始数据和鉴别密钥组合在一起作为输入。由于攻击者不知道密钥，他就无法伪造出正确的摘要。

这种“数据+密钥”经过摘要算法生成的产物，有一个专门的名称——报文鉴别码，简称 MAC。

实际上，为了进一步提升安全性，在HTTPS中，客户端和服务器会使用不同的密钥对，通常包括四个密钥：

1. 用于加密客户端到服务器数据的会话密钥。
2. 用于加密服务器到客户端数据的会话密钥。
3. 用于生成客户端到服务器数据MAC的鉴别密钥。
4. 用于生成服务器到客户端数据MAC的鉴别密钥。

4. 数字证书

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

前面提到HTTPS采用非对称加密传输会话密钥。通常流程是服务器公布其公钥，客户端用此公钥加密会话密钥后发送，服务器再用自己的私钥解密。但这里存在一个根本问题：客户端如何确信自己收到的公钥真的来自目标服务器，而不是一个中间攻击者？

这就是经典的中间人攻击场景：

1. 攻击者劫持客户端的请求（如通过DNS欺骗）。
2. 攻击者伪装成目标服务器，将自己的公钥发给客户端，并向真正的服务器索取公钥。
3. 客户端使用攻击者的公钥加密信息，攻击者可以轻松解密并窥探或篡改内容，再用真实服务器的公钥转发（或修改后的）信息。
4. 至此，客户端与服务器之间的通信在攻击者面前已无秘密可言。

为了解决身份认证问题，数字证书应运而生。它就像服务器的“网络身份证”，由受信任的第三方机构——认证中心颁发。

申请和验证数字证书的过程大致如下：

1. 服务器生成公私钥对，将包含域名、申请者、公钥等信息的文件提交给CA。
2. CA核实信息后，使用摘要算法计算该文件的摘要，再用CA自己的私钥对该摘要进行加密，生成数字签名。证书包含原始信息及数字签名。
3. 服务器将证书发送给客户端。
4. 客户端验证证书：用内置的CA公钥解密签名得到摘要1，同时自己计算证书中明文信息的摘要2。对比摘要1和摘要2，如果一致，则证明证书合法，里面的公钥可信。

那么，客户端如何获得CA的公钥呢？为了防止无限追溯（套娃），主流操作系统和浏览器都会预先内置了权威CA的根证书和公钥。因此，我们无需担心CA公钥本身被伪造。

当浏览器检测到网站证书无效（如过期、域名不匹配、签发机构不受信任）时，会明确警告用户。

5. SSL/TLS握手

现在让我们做个总结：HTTPS通过混合加密防窃听，需要协商会话密钥；通过摘要算法防篡改，需要协商鉴别密钥；通过数字证书防身份伪造，需要验证服务器证书。

这些关键步骤是在什么时候完成的呢？答案就是在SSL/TLS协议握手阶段。HTTPS中多出的那个“S”，指的就是SSL/TLS协议。

在建立TCP连接后，HTTPS并不会立即传输应用数据，而是先进行一个TLS握手过程，以协商密钥、验证证书，为后续的安全通信铺平道路。

下面我们通过Wireshark抓包，具体解析TLS 1.2协议的四次握手过程。

第一次握手：Client Hello

客户端发起加密通信请求，主要内容包括：

1. 支持的TLS协议版本（如TLS 1.2）。
2. 客户端生成的随机数1（Client Random），用于后续密钥生成。
3. 支持的密码套件列表。每个套件按顺序指定了：
   • 密钥交换算法（如RSA, ECDHE）
   • 身份认证算法（通常与密钥交换算法一致）
   • 对称加密算法（如AES_128_CBC）
   • 摘要算法（如SHA256）
     格式为：TLS_密钥交换算法_身份认证算法_对称加密算法_摘要算法，后两者常合并简写。

第二次握手：Server Hello

服务器响应客户端的请求，主要内容包括：

1. 确认使用的TLS版本。
2. 服务器生成的随机数2（Server Random）。
3. 从客户端列表中选择的一个密码套件（如TLS_RSA_WITH_AES128_CBC_SHA）。
4. 服务器的数字证书。

第三次握手：Client Key Exchange 等

客户端收到响应后：

1. 验证服务器证书的合法性（使用CA公钥校验签名）。
2. 若证书合法，则生成第三个随机数——前主密钥，并用服务器证书中的公钥加密后发送。
3. 客户端根据随机数1、随机数2和前主密钥，计算生成主密钥，进而衍生出会话密钥和鉴别密钥。
4. 发送Change Cipher Spec通知，告知服务器后续消息将用协商好的密钥加密。
5. 发送Encrypted Handshake Message，这是对之前所有握手报文的摘要，并用刚生成的会话密钥加密，供服务器校验握手过程的完整性。

第四次握手：Server Finished

服务器收到客户端消息后：

1. 用自己的私钥解密得到前主密钥。
2. 使用同样的算法（随机数1 + 随机数2 + 前主密钥）生成主密钥及会话/鉴别密钥。
3. 发送Change Cipher Spec通知。
4. 发送自己的Encrypted Handshake Message（握手报文摘要），供客户端校验。

至此，TLS握手完成，安全通道建立，双方可以开始使用对称加密密钥进行加密的应用数据通信。

深入思考

• 为什么第三、四次握手要发送所有握手报文的加密摘要？
  这是为了防止握手信息被篡改。例如，客户端支持的加密套件列表是明文发送的，攻击者可能将其修改为只包含弱加密算法。通过校验整个握手过程的摘要，可以确保双方最终协商出的加密参数是未经篡改的。
• 为什么不直接传递主密钥，而要由三个随机数生成？
  主要是为了防止连接重放攻击。如果主密钥直接由客户端生成并加密发送，攻击者虽然不知道内容，但可以完整地重放这个加密包给服务器，从而建立一个新的连接（例如重复下单）。引入客户端和服务器各自的随机数后，每次握手生成的密钥都不同，重放的旧数据将无法通过解密和完整性校验。

最后，用一张完整的流程图来总结TLS四次握手的过程。