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 校驗 防止參數被篡改；通過 證書驗證 確保通信對象身份真實。這三重機制共同保障了參數傳遞的安全性，但需注意其保護范圍僅限于“傳輸過程”，完整的安全體系還需結合服務器端和客戶端的其他防護措施。



閱讀原文：原文鏈接