HTTPS 與 TLS 實際運作原理：實用指南
您可能看過瀏覽器中的鎖頭圖示，也知道 HTTPS 代表網站是安全的。但當您造訪 HTTPS 網站時，實際發生了什麼事？瀏覽器和伺服器如何協商加密金鑰？憑證為什麼重要？了解 HTTPS 與 TLS 的運作機制，對開發人員、系統管理員，以及任何建置或保護網路應用程式的人來說都至關重要。
本指南以淺顯易懂的方式說明 TLS 握手、憑證驗證與加密。您將了解 HTTPS 如何保護傳輸中的資料、常見的陷阱，以及確保自身網站設定正確的實用步驟。
HTTPS 的真正含義
HTTPS 是建構在 TLS（Transport Layer Security，傳輸層安全性）之上的 HTTP。它提供三項保證：
- 機密性：用戶端與伺服器之間交換的資料經過加密，竊聽者無法讀取。
- 完整性：資料在傳輸過程中若遭竄改，將被偵測出來。
- 認證性：用戶端可以驗證自己正在與合法的伺服器通訊，而非冒充者。
TLS 是 SSL（Secure Sockets Layer）的後繼者。雖然人們仍常說「SSL 憑證」，但現代系統使用的是 TLS。最新版本 TLS 1.3 簡化了握手流程並提升安全性。
TLS 握手：逐步解析
在任何加密的 HTTP 資料傳輸之前，用戶端與伺服器會先進行握手，以協商加密參數並建立共用金鑰。以下是典型的 TLS 1.3 握手流程：
- Client Hello：用戶端發送訊息，包含支援的 TLS 版本、加密套件，以及一個隨機值（client random）。
- Server Hello：伺服器回應其選擇的 TLS 版本、加密套件，以及自己的隨機值（server random）。同時發送其憑證鏈。
- 金鑰交換：利用伺服器憑證中的公開金鑰（或 TLS 1.3 中的金鑰共享），用戶端與伺服器推導出共用密鑰。在 TLS 1.3 中，這個過程只需一個來回。
- Finished：雙方發送以推導金鑰加密的 Finished 訊息，以驗證握手完整性。
握手完成後，應用程式資料（HTTP 請求和回應）會使用從共用密鑰推導出的對稱金鑰進行加密。
憑證驗證
伺服器的憑證將其公開金鑰與其身分（網域名稱）綁定。用戶端透過以下方式驗證憑證：
- 檢查憑證是否由受信任的憑證授權單位（CA）簽署。
- 驗證網域名稱是否與請求的主機相符。
- 確保憑證在有效期限內且未被撤銷。
若驗證失敗，瀏覽器會顯示警告。在正式環境中絕不要繞過這些警告——它們表示可能存在中間人攻擊。
TLS 中的加密：對稱與非對稱
TLS 同時使用非對稱（公開金鑰）與對稱加密。非對稱加密用於握手期間安全地交換金鑰。對稱加密（如 AES 或 ChaCha20）則用於大量資料，因為速度快得多。
在 TLS 1.3 中，金鑰交換通常使用臨時 Diffie-Hellman（ECDHE），提供前向保密：即使伺服器的私密金鑰日後外洩，過去的會話仍保持安全。
常見 HTTPS 陷阱與避免方法
即使啟用了 HTTPS，錯誤的設定仍可能削弱安全性。請留意以下事項：
- 憑證過期：設定監控與自動續約（例如 Let's Encrypt）。
- 混合內容：在 HTTPS 頁面載入 HTTP 資源會破壞安全性。使用相對 URL 或全面採用 HTTPS。
- 弱加密套件：停用過時的協定（TLS 1.0/1.1）與弱加密演算法。使用 SSL Labs 等工具進行測試。
- 缺少 HSTS：HTTP 嚴格傳輸安全性（HSTS）強制瀏覽器使用 HTTPS。加入
Strict-Transport-Security標頭。
實例：檢查 TLS 設定
您可以使用 OpenSSL 檢視伺服器的 TLS 設定。例如，查看憑證鏈與協商後的協定：
openssl s_client -connect example.com:443 -servername example.com在輸出中尋找協定版本與加密套件。若要測試 TLS 1.3 支援：
openssl s_client -connect example.com:443 -tls1_3定期稽核您的設定並保持軟體更新。
常見問題
HTTPS 與 TLS 有何不同？
HTTPS 是 HTTP 的安全版本，而 TLS 是為 HTTPS 提供加密與認證的協定。換句話說，HTTPS = HTTP + TLS。
內部服務需要憑證嗎？
是的，即使是內部服務，使用 TLS 憑證也能防止網路內的竊聽與中間人攻擊。您可以使用內部 CA 或自簽憑證，但請確保用戶端信任它們。
憑證應該多久更新一次？
憑證的有效期限由 CA 設定。許多組織使用 90 天憑證並自動續約。監控到期日並自動化續約，以避免服務中斷。
想要快速分析 Nginx 存取記錄中的可疑活動或效能問題嗎？試試我們的 Nginx 記錄分析器，幾秒鐘內就能解析並視覺化記錄資料。