HTTPS 并非直接“加密参数”，而是通过一整套加密传输机制，确保客户端与服务器之间所有通信内容（包括 URL 参数、表单数据、Cookie 等）在传输过程中不被窃听、篡改或伪造。其核心安全保障来自以下技术实现：

一、核心加密机制：SSL/TLS 协议

HTTPS = HTTP + SSL/TLS，其中 SSL/TLS 协议是保障传输安全的核心，通过三层握手过程建立加密通道，再通过对称加密传输数据。

1. 握手阶段：协商加密算法与密钥（防窃听）

身份验证：服务器向客户端出示数字证书（由 CA 机构颁发），证书包含服务器公钥和身份信息。客户端验证证书合法性（确保连接的是真实服务器，防“中间人攻击”）。

密钥协商：

• 客户端生成一个随机数，用服务器公钥加密后发送给服务器（只有服务器的私钥能解密）。

• 服务器和客户端基于这个随机数，各自计算出对称加密密钥（会话密钥）。

结果：双方拥有相同的会话密钥，且该密钥未在网络中明文传输（仅通过公钥加密的随机数推导）。

2. 传输阶段：对称加密保护所有数据（防窃听）

握手完成后，客户端与服务器之间的所有通信内容（包括 URL 参数、请求体、响应数据等） 均使用对称加密算法（如 AES）加密：

• 对称加密效率高，适合大量数据传输。

• 由于会话密钥仅双方知晓，即使传输内容被截获，第三方也无法解密。

二、防篡改：数据完整性校验

HTTPS 通过消息认证码（MAC） 确保传输的数据未被篡改：

传输数据时，发送方会生成一个基于数据内容和会话密钥的校验码（如 HMAC 算法），与数据一起发送。

接收方收到后，用相同算法和密钥重新计算校验码，对比是否一致：

• 一致：数据未被篡改。

• 不一致：数据被篡改，接收方会拒绝处理。

三、防伪造：身份验证与不可否认

• 服务器身份验证：通过 CA 证书，客户端可确认服务器身份，避免连接到伪造的钓鱼服务器（例如，用户访问 https://bank.com 时，确保连接的是真实银行服务器）。

  
  

• 客户端身份验证（可选）：某些场景下（如企业内部系统），服务器也可要求客户端提供证书，验证客户端身份。

  
  

• 不可否认：由于私钥仅服务器持有，用私钥签名的数据可证明来自服务器，无法抵赖。

四、对“参数安全”的具体保障

1.URL 参数：

​HTTPS 加密整个 URL（包括 https://domain.com/path?param=xxx 中的 param=xxx），网络传输中不会泄露参数明文。

⚠️ 注意：URL 参数可能被浏览器历史记录、服务器日志等存储，HTTPS 不保护“存储中的参数”，敏感参数建议放在请求体（POST 数据）中。

2.POST 请求体：

表单数据、JSON 参数等请求体内容会被对称加密，传输过程中无法被窃听或篡改。

3.Cookie：

若服务器设置 Secure 属性，Cookie 只会通过 HTTPS 传输，且加密保护；配合 HttpOnly 属性可防止 JS 窃取，进一步提升安全。

五、HTTPS 无法解决的问题（需额外措施）

HTTPS 仅保护传输过程的安全，以下场景需其他手段配合：

• 服务器端安全：若服务器被入侵，存储的参数（如数据库中的用户密码）可能泄露，需通过加密存储（如密码哈希加盐）防护。

• 客户端安全：若客户端（如浏览器）被植入恶意程序，可能在数据加密前/解密后窃取参数（需依赖终端安全防护）。

• 参数本身的合理性：HTTPS 不验证参数合法性，需服务器端做参数校验（如防 SQL 注入、XSS 等）。

总结：

HTTPS 通过 SSL/TLS 握手建立对称加密通道，确保参数在传输中无法被窃听；通过 MAC 校验 防止参数被篡改；通过 证书验证 确保通信对象身份真实。这三重机制共同保障了参数传递的安全性，但需注意其保护范围仅限于“传输过程”，完整的安全体系还需结合服务器端和客户端的其他防护措施。



阅读原文：原文链接