一文读懂 HTTPS 协议及其工作流程

背景：HTTP（HyperText Transfer Protocol）是一种应用层通信协议，主要用于客户端与服务器之间的数据传输，是 Web 系统中最基础的协议之一。HTTP 采用明文方式传输数据，虽然实现简单、性能开销较小，但在通信过程中缺乏必要的安全保护机制，无法防止数据被窃听、篡改或冒充。随着互联网应用逐渐涉及用户账号、隐私信息以及交易数据，这种安全缺陷变得越来越突出，也正是在这样的背景下，引入加密、身份认证和完整性校验机制的 HTTPS 协议应运而生，用以弥补 HTTP 在安全性方面的不足。

HTTPS 相较于 HTTP 的核心优势，主要来源于其在传输层引入了 TLS/SSL 安全机制 。通过对称加密 与非对称加密 相结合的方式，HTTPS 能够在通信过程中对数据内容进行加密，防止信息被窃听；同时借助数字证书 与证书链 机制，实现对服务器身份的验证，避免中间人攻击；此外，HTTPS 还通过消息完整性校验机制，确保数据在传输过程中未被篡改。正是这些加密、认证与完整性保护技术的共同作用，使 HTTPS 在安全性和可信性方面显著优于传统的 HTTP 协议。

1.对称/非对称加密

在现代网络安全通信中，加密机制是保障数据机密性和通信安全的核心技术基础。根据密钥使用方式的不同，加密算法通常可以分为对称加密 和非对称加密两大类，它们在安全性特征和应用场景上各有侧重。

1.1 对称加密

对称加密是指通信双方使用同一把密钥对数据进行加密和解密。该类加密算法计算复杂度较低，执行效率高，适合用于大规模数据的高速传输。然而，对称加密的安全性高度依赖于密钥的安全分发，一旦密钥在传输或存储过程中泄露，通信内容将面临被完全破解的风险。

python 复制代码

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

def aes_gcm_encrypt(key: bytes, plaintext: bytes, aad: bytes = b""):
    """
    AES-GCM 对称加密
    key: 16/24/32 字节(分别对应 AES-128/192/256)
    aad: 附加认证数据(可选，不加密但参与完整性校验)
    """
    aesgcm = AESGCM(key)
    nonce = os.urandom(12)  # GCM 推荐 12 字节随机 nonce
    ciphertext = aesgcm.encrypt(nonce, plaintext, aad)
    return nonce, ciphertext  # ciphertext 内部已包含 tag

def aes_gcm_decrypt(key: bytes, nonce: bytes, ciphertext: bytes, aad: bytes = b""):
    aesgcm = AESGCM(key)
    plaintext = aesgcm.decrypt(nonce, ciphertext, aad)
    return plaintext

if __name__ == "__main__":
    key = AESGCM.generate_key(bit_length=256)  # 32 字节
    msg = b"Hello, symmetric crypto (AES-GCM)!"
    aad = b"header-metadata"

    nonce, ct = aes_gcm_encrypt(key, msg, aad)
    pt = aes_gcm_decrypt(key, nonce, ct, aad)

    print("nonce:", nonce.hex())
    print("ciphertext:", ct.hex())
    print("decrypted:", pt.decode())

1.2 非对称加密

非对称加密采用一对相互关联的密钥，即公钥和私钥。其中，公钥可以公开用于数据加密或身份验证，而私钥仅由密钥持有者保存并用于解密或签名操作。非对称加密有效解决了密钥分发问题，并可用于身份认证和安全密钥协商，但其计算开销较大，不适合直接用于大规模数据的加密传输。

python 复制代码

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes

def rsa_generate_keypair():
    private_key = rsa.generate_private_key(
        public_exponent=65537,
        key_size=2048  # 常用 2048/3072
    )
    public_key = private_key.public_key()
    return private_key, public_key

def rsa_encrypt(public_key, plaintext: bytes) -> bytes:
    ciphertext = public_key.encrypt(
        plaintext,
        padding.OAEP(
            mgf=padding.MGF1(algorithm=hashes.SHA256()),
            algorithm=hashes.SHA256(),
            label=None
        )
    )
    return ciphertext

def rsa_decrypt(private_key, ciphertext: bytes) -> bytes:
    plaintext = private_key.decrypt(
        ciphertext,
        padding.OAEP(
            mgf=padding.MGF1(algorithm=hashes.SHA256()),
            algorithm=hashes.SHA256(),
            label=None
        )
    )
    return plaintext

if __name__ == "__main__":
    sk, pk = rsa_generate_keypair()
    msg = b"Hello, asymmetric crypto (RSA-OAEP)!"

    ct = rsa_encrypt(pk, msg)
    pt = rsa_decrypt(sk, ct)

    print("ciphertext:", ct.hex())
    print("decrypted:", pt.decode())

2.数字证书与证书链

在 HTTPS 通信中，仅依靠加密机制并不足以完全保证通信安全，还需要解决通信实体身份可信性的问题。为此，HTTPS 引入了数字证书与证书链机制，用于在开放网络环境中实现对服务器身份的可靠验证。

2.1 🏛 CA 是什么？

CA（Certificate Authority，证书颁发机构）是一种被广泛信任的第三方机构，负责为网络通信实体颁发数字证书。CA 的核心作用是通过自身的公信力，为某一实体的身份与其公钥之间建立可信绑定关系，即证明"某个公钥确实属于某个特定主体（如某个网站）"。在实际应用中，主流 CA 的根证书通常预先内置在操作系统或浏览器中，从而构成整个信任体系的基础。

2.2 🧾 数字证书包含了什么？

数字证书可以理解为由权威机构签发的电子"身份证"，用于证明公钥的归属和通信实体的合法身份。浏览器在建立 HTTPS 连接时，会使用本地内置的 CA 公钥对服务器发送的数字证书进行验证，以确保证书来源可信且未被篡改。

一份标准的数字证书通常包含以下核心信息：

服务器的公钥，用于后续加密通信或密钥协商；
服务器的身份信息，如域名、组织名称等，用于标识证书的所属主体；
证书签名，由 CA 使用其私钥对证书内容进行签名，客户端可使用对应的 CA 公钥进行验证，从而确保证书的真实性与完整性。

2.3 🔗 证书链与信任传递机制

在实际部署中，服务器证书通常并非直接由根 CA 签发，而是通过一系列中间 CA 逐级签发，从而形成一条完整的证书链。客户端在验证证书时，会沿着证书链逐级向上验证签名，最终追溯到本地信任的根证书。只要整条证书链上的签名均验证通过，客户端即可确认服务器身份的可信性。

3.消息完整性校验机制

在 HTTPS 通信中，除了对数据内容进行加密，还需要确保数据在传输过程中未被篡改，这就是消息完整性校验机制的主要作用。该机制的核心思想是：让接收方能够判断收到的数据是否与发送方发出的数据完全一致。

消息完整性校验通常基于密码学哈希算法，并结合共享密钥生成消息认证码（Message Authentication Code，MAC）。在发送数据时，发送方会根据消息内容和密钥计算出对应的校验值，并随加密数据一同发送；接收方在解密数据后，使用相同的密钥和算法重新计算校验值，并与接收到的结果进行比对，从而判断数据是否在传输过程中被修改。

在 TLS 协议中，完整性保护通常通过 HMAC 或具备认证功能的加密模式（如 AES-GCM）来实现。其中，AES-GCM 等 AEAD 模式能够在完成数据加密的同时自动生成完整性校验信息，使机密性与完整性保护在同一过程中完成。一旦接收端在校验过程中发现不一致，TLS 会立即终止通信，以防止被篡改的数据继续被使用。

正是依靠这一消息完整性校验机制，HTTPS 能够有效抵御中间人攻击中的数据篡改行为，确保通信内容在传输过程中的可靠性和可信性。

4.TLS/SSL 安全机制

TLS（Transport Layer Security）及其前身 SSL（Secure Sockets Layer）是一种用于保障网络通信安全的传输层安全协议。HTTPS 正是基于 TLS/SSL 构建的安全通信机制，其目标是在不可信的网络环境中，为客户端与服务器之间的数据传输提供安全保障。

TLS/SSL 的安全设计主要围绕 机密性、完整性和身份认证 三个核心目标展开，下面分别进行说明。

4.1 身份认证机制（Authentication）

在 HTTPS 通信中，客户端首先需要确认通信对方的身份是否合法。TLS 通过 数字证书与证书链机制实现服务器身份认证。

服务器在 TLS 握手阶段向客户端发送由 CA（证书颁发机构）签发的数字证书。客户端并不会直接信任服务器，而是利用浏览器或操作系统中预置的 根证书（CA 公钥） 对服务器证书的数字签名进行验证。若验证通过，则说明服务器证书可信，服务器身份得到确认；若验证失败，连接将被直接中断。

通过这种方式，TLS 能够有效防止中间人伪造服务器身份，保障通信对象的可信性。

4.2 密钥协商与加密机制（Key Exchange & Encryption）

在身份认证完成后，TLS 进入密钥协商阶段。该阶段通过非对称加密技术安全地协商出会话密钥所需的关键材料。

客户端与服务器分别生成随机数（Client Random 和 Server Random），客户端还会生成第三个随机数（Pre-Master Secret），并使用服务器证书中的公钥对其进行加密后发送给服务器。随后，双方使用相同的伪随机函数（PRF），基于这三个随机数独立计算出完全一致的 会话密钥（Session Key）。

TLS 在后续的数据传输阶段使用该会话密钥进行 对称加密通信。相比非对称加密，对称加密具有更高的计算效率，能够在保证安全性的同时减少性能开销。

4.3 消息完整性校验机制（Integrity Protection）

为防止数据在传输过程中被篡改，TLS 引入了消息完整性校验机制。该机制通常基于密码学哈希算法，并结合共享密钥生成消息认证码（MAC）。

在现代 TLS 版本中，常采用具备认证功能的加密模式（如 AES-GCM），在对数据进行加密的同时生成完整性校验信息。一旦接收方在校验过程中发现数据不一致，通信将被立即终止，从而有效抵御中间人篡改和重放攻击。

4.4 加密通信阶段（Secure Data Transmission）

当 TLS 握手流程完成后，客户端与服务器会发送 ChangeCipherSpec 和 Finished 消息，确认切换至加密通信状态。此后，所有应用层数据（如 HTTP 请求与响应）均在 TLS 层进行加密和完整性保护后再传输。

这一阶段实现了 HTTPS 相较于 HTTP 的本质差异，使 Web 通信在开放网络环境中具备可靠的安全保障。

TLS/SSL 通过数字证书实现身份认证，通过非对称加密安全协商会话密钥，并结合高效的对称加密和完整性校验机制，实现了安全性与性能之间的平衡。正是这些安全机制的协同作用，使 HTTPS 成为当前互联网中最主流、最可靠的安全通信协议。

5.https完整传输流程

第一步：TCP 三次握手（建立可靠连接）

在进行 TLS 握手之前，客户端与服务器需要先通过 TCP 三次握手 建立底层连接。

客户端首先向服务器发送 SYN 请求，服务器返回 SYN-ACK ，客户端再发送 ACK 进行确认。至此，TCP 连接建立完成，为后续 TLS 握手提供可靠的数据传输通道。

第二步：ClientHello（客户端发起 TLS 握手）

TCP 连接建立后，客户端发送 ClientHello 消息，正式开始 TLS 握手。

该消息中包含客户端支持的 TLS 版本、加密套件列表以及一个随机数 Client Random，用于后续会话密钥的生成。

第三步：ServerHello + Certificate（服务器响应）

服务器收到 ClientHello 后，返回 ServerHello 消息，选择双方都支持的 TLS 版本和加密套件，并发送服务器随机数 Server Random 。

随后，服务器将自己的 数字证书（Certificate） 发送给客户端，用于证明服务器身份，并在最后通过 ServerHelloDone 表示该阶段消息发送完毕。

第四步：客户端验证服务器证书

客户端收到服务器证书后，会使用浏览器或操作系统中预置的 CA 公钥（根证书） 对证书签名进行验证。

如果验证通过，说明该证书确实由可信 CA 签发，服务器身份可信；若验证失败，TLS 握手将被终止。

第五步：ClientKeyExchange（生成共享密钥材料）

证书验证通过后，客户端生成第三个随机数 Pre-Master Secret ，并使用服务器证书中的公钥对其加密后发送给服务器（ClientKeyExchange）。

由于只有服务器持有对应的私钥，因此只有服务器能够成功解密该随机数。

第六步：生成会话密钥（Session Key）

至此，客户端和服务器都已拥有 Client Random、Server Random 和 Pre-Master Secret 。

双方分别使用相同的伪随机函数（PRF），基于这三个随机数 独立计算出完全一致的会话密钥（Session Key），而该密钥本身不会在网络中直接传输。

第七步：ChangeCipherSpec + Finished（切换加密通信）

客户端发送 ChangeCipherSpec 消息，通知服务器后续通信将使用协商好的会话密钥进行加密，并发送 Finished 消息验证握手完整性。

服务器随后也发送自己的 ChangeCipherSpec 和 Finished 消息。至此，TLS 握手过程全部完成。

第八步：加密数据传输

TLS 握手完成后，客户端与服务器之间的所有应用层数据（如 HTTP 请求和响应）都将使用会话密钥进行 对称加密通信，同时结合完整性校验机制，确保数据的机密性和完整性。

总体而言，HTTPS 通过在原有 Web 通信模型中引入系统化的安全设计，使网络传输从"仅能通信"提升为"可信通信"。该协议在连接建立阶段完成身份可信性的确认，并在数据传输阶段对通信内容进行保护，从而有效抵御窃听、伪造和篡改等常见安全威胁。这种在安全性与性能之间取得平衡的设计，使 HTTPS 能够在开放网络环境中提供稳定、可靠的通信保障，也促使其逐渐取代 HTTP，成为现代互联网应用的基础协议。