应用层协议：HTTPS

目录

HTTPS：超文本传输安全协议

1、概念

2、通信过程及关键技术

2.1 通信过程

1> TLS握手协商（建立安全通道）

2> 加密数据传输

2.2 关键技术

1> 对称加密算法

2> 非对称加密

3> 对称加密和非对称加密组合

4> 数字证书

5> 数字签名

3、作用

---

HTTPS：超文本传输安全协议

1、概念

概念：HTTPS（Hypertext Transfer Protocol Secure）是 HTTP 的安全版本，是身披SSL/TLS外壳的HTTP。其核心目标是在客户端（如浏览器）和服务器之间建立一个加密的通信通道，确保传输数据的机密性、完整性和身份真实性，防止数据在传输过程中被窃听、篡改或冒充。默认端口是443。

核心目标：

• 保密性/加密： 数据在传输过程中是加密的，即使被截获，攻击者也无法轻易读懂内容。

• 数据完整性： 确保数据在传输过程中没有被第三方篡改或破坏。

• 身份认证： 用户访问的网站服务器确实是它声称的那个服务器，而不是一个冒名顶替的钓鱼网站。

解决方案：

• 所有的信息都是加密传输的，第三方无法窃听
• 具有校验机制，一旦被篡改，通信双方会立刻发现
• 配备身份验证（服务端程序），防止身份被冒用

SSL/TLS是一种加密通道的规范，TLS（Transport Layer Security，传输层安全协议），其前身是 SSL（Secure Sockets Layer）。现在通常统称为 TLS/SSL 或直接说 TLS。

TLS协议构成：

• 握手协议（TLS handshake Protocol）：由TLS Change Ciper Spec Protocol（密码规格变更协议）和TLS Alert Protocol（警告协议）组成，负责在客户端和服务器之间协商决定密码算法和共享密钥。实现身份认证。
  • 密码规格变更协议：负责向通信对象传达变更密码方式的信号，当协议中途发生错误时，就会通过警告协议传达给对方。
  • 警告协议：是TLS握手协议负责在发送错误时将错误传达给对方。
• 记录协议（TLS Record protocol）：位于TLS握手协议的下层，是负责使用对称密码对消息进行加密通信的部分，保证数据完整性和隐私性。
  • 加密使用的密钥是通过握手协议在服务器和客户端之间协商决定的

2、通信过程及关键技术

2.1 通信过程

HTTPS通信过程大致可以分为两个主要阶段：

1> TLS握手协商（建立安全通道）

• 客户端问候： 你的浏览器（客户端）连接到服务器的 443 端口（HTTPS 默认端口），发送支持的 TLS 版本、支持的加密算法套件列表、一个随机数（Client Random）等信息。

• 服务器问候： 服务器选择双方都支持的最强的 TLS 版本和加密算法套件（对称加密算法），发送自己的数字证书（包含公钥、颁发机构等信息）、一个随机数（Server Random）以及确认信息给浏览器。

• 证书验证： 浏览器收到服务器的证书后，会进行严格的验证（合法性验证）：

  • 验证证书链： 检查证书是否由浏览器信任的证书颁发机构签发。CA 是公认的、负责验证网站身份并签发数字证书的第三方机构（如 DigiCert, Let's Encrypt, GlobalSign 等）。

  • 验证域名： 检查证书中声明的域名是否与你正在访问的网站域名一致。

  • 验证有效期： 检查证书是否在有效期内。

  • 验证吊销状态： 通过 OCSP 或 CRL 等方式检查证书是否已被 CA 吊销。

• 生成会话密钥：

  • 如果证书验证通过，浏览器会生成另一个随机数（Pre-Master Secret）。

  • 浏览器用服务器证书中包含的公钥加密这个 Pre-Master Secret，发送给服务器。

  • 服务器用自己的私钥解密得到 Pre-Master Secret（非对称加密算法）。

  • 客户端和服务器现在都拥有了三个随机数：Client Random、Server Random 和 Pre-Master Secret。它们使用双方协商好的算法，独立计算出相同的会话密钥。这个会话密钥是对称密钥，用于后续实际数据传输的加密和解密。

• 完成握手： 双方交换使用会话密钥加密的完成消息，验证握手过程是否成功且未被篡改。至此，安全的 TLS 通道建立完成。

2> 加密数据传输

• 握手完成后，后续所有的 HTTP 请求和响应数据都会通过这个已建立的 TLS 安全通道进行传输。

• 使用握手阶段协商好的对称加密算法（如 AES）和会话密钥对数据进行加密。

• 接收方使用相同的会话密钥对数据进行解密。

• 同时，使用握手阶段协商好的消息认证码算法（如 HMAC）来保证数据的完整性，防止传输中被篡改。

2.2 关键技术

1> 对称加密算法

概念：用于实际数据传输。加密和解密使用同一个密钥（会话密钥）。相比非对称加密，速度更快，效率更高。常见的算法有 AES（Advanced Encryption Standard）、ChaCha20。

工作过程：对称加密通常使用的是相对较小的密钥，一般小于256 bit。因为密钥越大，加密越强，但加密与解密的过程越慢。如果你只用1 bit来做这个密钥，那黑客们可以先试着用0来解密，不行的话就再用1解；但如果你的密钥有1 MB大，黑客们可能永远也无法破解，但加密和解密的过程要花费很长的时间。密钥的大小既要照顾到安全性，也要照顾到效率。

例如：AES128和AES256主要区别是密钥长度不同（分别是128bits,256bits)、加密处理轮数不同（分别是10轮，14轮），后者强度高于前者。

加密：明文 + 密钥 -> 密文

解密：密文 + 密钥 -> 明文

优点：算法公开、计算量小、加密速度快、加密效率高。
缺点：相对来说不算特别安全，只有一把钥匙，密文如果被拦截，且密钥也被劫持，那么，信息很容易被破译。

2> 非对称加密

概念：非对称加密算法需要两个密钥：公开密钥(public key) 和私有密(private key)，公开密钥和私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密。如果用私有密钥对数据进行加密，只有用对应的公开密钥才能解密。服务器持有私钥（必须严格保密），公开分发公钥（包含在证书中）。常见的算法有 RSA、ECC（椭圆曲线密码学）。

优点：安全性比对称加密高

缺点：算法复杂，加密、解密速度没有对称加密解密的速度快。公钥是公开的，如果被黑客截获，其可以使用公钥进行解密，获取其中的内容。

3> 对称加密和非对称加密组合

先通过非对称加密，传送对称加密的密钥（防止密钥被破解）；之后通过密钥，进行对称加密传输数据（防止因非对称加密公钥暴露造成的数据被破解）。

存在的缺陷：

• 通信方身份可能被伪装--->解决：数字证书
• 报文可能遭篡改--->解决：数字签名

4> 数字证书

核心作用：

• 身份绑定：将服务器的公钥与其身份信息（主要是域名）进行强关联。

• 信任传递：通过可信第三方的签名，证明该绑定的有效性。客户端只需预置少量根证书，即可信任全球数百万网站。

• 安全分发公钥：为客户端提供可信的服务器公钥，用于后续加密和签名验证。防止中间人攻击者伪造公钥（例如，攻击者声称自己的公钥属于 bank.com）。

证书的主要组成结构：签名算法、颁发者、有效期、主体（域名、组织等）、主体的公钥（公钥算法、服务器公钥）、数字签名、序列号（由 CA 分配的唯一标识符，用于追踪和撤销证书）

证书的生命周期：

1、生成密钥对：服务器生成非对称加密密钥对，私钥严格保密

2、证书签名请求：服务器创建CSR文件（包含主体信息、公钥、用私钥对CSR内容签名）

3、CA验证与签发：CA验证信息真实性，审核通过后，CA用自己的私钥对CSR中的信息签名，生成数字证书

4、部署证书：服务器安装证书（通常与私钥一起配置在 Web 服务器如 Nginx/Apache）

5、客户端检验（TLS握手）：客户端检查证书中的域名、有效期、通过证书链验证CA签名（详见下文）、检查撤销状态（通过 CRL 或 OCSP），全部验证通过后，信任证书中的公钥。

6、撤销与更新：若私钥泄露，CA 将证书加入撤销列表（CRL/OCSP）；证书到期前需重新申请（自动化工具如 Certbot 可自动续签）。

信任链：客户端不直接信任服务器证书，而是信任一个层级化的信任链

根证书（Root CA） → 中间证书（Intermediate CA） → 服务器证书（End-Entity）

• 根证书：由CA自己签发，预设在操作系统/浏览器中，严格离线存储，根密钥泄漏风险低
• 中间证书：由根证书签发，可设置多层，必须与服务器证书一起发送给客户端（否则链不完整），用于实际签发服务器证书
• 验证过程（客户端逐级验证签名）：

  • 用根证书的公钥验证中间证书的签名。

  • 用中间证书的公钥验证服务器证书的签名。

  • 任一环节失败即终止连接（如浏览器显示 NET::ERR_CERT_AUTHORITY_INVALID）

在浏览器如何查看证书：

5> 数字签名

核心目的：

• 身份认证：证明客户端正在通信的服务器确实是它声称的那个实体（例如 www.example.com），而不是一个中间人伪造的服务器。

• 数据完整性： 确保在握手过程中传输的关键信息（特别是服务器的公钥和证书信息）没有被篡改。

工作原理（以服务器向客户端证明身份为例）：

1、证书申请与签发

2、TLS握手：服务器发送证书

3、客户端验证签名（核心步骤）：

• 客户端（浏览器）收到服务器的证书。

• 提取信息： 客户端从证书中提取出：

  • TBS：待签名的核心数据部分（包含服务器域名、公钥、有效期等）。

  • 签名算法：CA 使用的签名算法（例如 sha256WithRSAEncryption）。

  • 签名值：CA 对该证书的签名结果。

• 获取 CA 公钥：

  • 客户端操作系统和浏览器内置了一个受信任根证书存储库，里面包含了各大受信任 CA 的根证书及其公钥。

  • 客户端根据证书中的 Issuer 字段找到对应的根证书（或中间证书链，最终追溯到根证书）。

  • 客户端从根证书（或链中已验证的上级证书）中提取出该 CA 的公钥。

• 验证签名：

  • 客户端使用 CA 的公钥对证书中的 签名值 进行解密操作（非对称加密的特性：私钥加密只能用对应的公钥解密）。

  • 解密得到的结果是 CA 当初对 TBS 数据进行哈希计算后得到的摘要（Digest）。

  • 客户端自己使用证书中指定的哈希算法（如 SHA-256）对收到的 TBS 数据进行哈希计算，得到一个新的摘要。

  • 关键比对： 客户端将解密得到的摘要与自己计算出的摘要进行比对。

    • 匹配： 验证成功！这意味着：

      1. 证书确实是由该 CA 用其私钥签发的（身份来源可信）。

      2. 证书中的核心信息 (TBS) 自签发以来没有被篡改过（数据完整）。

    • 不匹配： 验证失败！客户端会发出严重警告（如浏览器显示红色锁、证书错误页面），阻止用户继续访问，因为这可能意味着：

      1. 证书是伪造的。

      2. 证书在传输过程中被篡改。

      3. 签发证书的 CA 不受客户端信任（根证书不存在或不受信任）。

4、后续信任建立：

• 一旦客户端成功验证了服务器证书的签名，它就信任该证书中包含的服务器的公钥是真实有效的。

• 客户端会使用这个服务器的公钥进行后续操作：

  • 在 RSA 密钥交换中：加密生成一个预主密钥发送给服务器（只有拥有对应私钥的服务器才能解密）。

  • 在 ECDHE 密钥交换中：验证服务器发送的 ECDHE 参数（公钥）的签名（服务器用其私钥签名，客户端用刚验证过的公钥验证），确保参数未被篡改。

• 双方基于交换的密钥材料生成最终用于加密 HTTP 数据的会话密钥。

数字签名的生成：

将要发送的数据先用Hash算法（摘要算法、散列算法）生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文一起传送给接收者。

数字签名的校验：

接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

3、作用

• 保护用户隐私： 防止登录凭证、信用卡号、个人信息、聊天记录、浏览历史等敏感数据在传输中被窃听（如在不安全的公共 Wi-Fi 上）。

• 防止数据篡改： 确保用户看到的网页内容、下载的文件没有被中间人植入恶意代码或广告。

• 验证网站身份： 帮助用户确认访问的是真正的银行、购物网站等，而不是钓鱼网站，防止中间人攻击。

• 建立信任： 浏览器地址栏显示的锁图标和 "HTTPS" 字样是重要的信任标识，用户会更放心地使用该网站进行敏感操作。

• 现代 Web 功能要求： 许多新的 Web API（如地理位置、Service Workers、Web Push、HTTP/2 和 HTTP/3 的许多优化特性）都要求网站部署 HTTPS。

• SEO 优势： 谷歌等搜索引擎明确表示 HTTPS 是搜索排名的一个正面信号。

• 合规性要求： 许多行业法规（如支付卡行业数据安全标准 PCI DSS、GDPR）强制要求使用 HTTPS 保护用户数据。