TLS 把明文連線變成加密會話

我拆 TLS 的握手、憑證檢查和可直接複製的設定模板，讓你能把它真的用在服務裡。

我碰 TLS 很久了，老實說它最煩的地方不是加密本身，是大家都把它當 checkbox。開 HTTPS、丟個憑證、瀏覽器綠鎖一亮，就以為收工。結果一進 production，才開始分不清楚到底是憑證鏈壞了、cipher suite 不合、client 太舊，還是 server 自己配了一套「我覺得安全」的規則。這種感覺我太熟了：TLS 表面上像一層透明包裝，實際上是滿地尖刺的協商流程。

我後來會看懂它，是因為我不再聽那些 folklore，而是回頭看原始說明。這次我主要拆的是 Transport Layer Security，外加 RFC 8446（TLS 1.3）跟 RFC 5246（TLS 1.2）。這些文件很硬，但它們至少不會騙你：TLS 不是「HTTPS 的外殼」，它是 client 和 server 在任何資料傳出去之前，先談好怎麼互相信任的流程。

我現在看 TLS 的方式很簡單：它不是「把資料加密」而已，它是先談判、再建立共享狀態、最後才開始傳資料。你只要把這個順序搞懂，很多平常被罵成「TLS 很不穩」的問題，會突然變得很有跡可循。這篇我就照這個順序拆，最後給你一段可以直接抄去你服務設定裡的模板。

TLS 不是加密而已，它先在談判

"The protocol is designed to provide communications security over a computer network."

白話翻譯就是：TLS 的重點不是「把東西蓋起來」，而是先決定這條連線值不值得蓋。client 和 server 不會一上來就直接加密資料，它們先談版本、談演算法、談怎麼驗證對方、談用哪個 shared secret。談不攏，連線就不成立。

我以前最常看到有人把 TLS 叫成「port 443 上的加密」。這句話不是全錯，但很沒用。真正有價值的部分是 handshake。因為 handshake 會決定這條連線到底有沒有 confidentiality、integrity、authentication。你如果只記得「有 HTTPS」，卻不知道它怎麼握手，那你在 debug 的時候只是在猜。

我現在看一個服務的 TLS 設定，第一個問題不是「有沒有開」，而是「它到底保證了什麼」。是只加密？還是也驗證 server 身分？有沒有 client auth？有沒有防 tampering？這三件事其實是分開的，TLS 只是把它們塞進同一個協商流程裡。

實操寫法很簡單：你在設計或 review 服務時，先把三個問題寫出來，再去看設定。

• 我到底要保密什麼資料？
• 我要驗證誰的身分？server、client，還是兩邊都要？
• 如果有人改包，我怎麼知道？

如果這三題答不出來，先別急著談 cipher。你連目標都沒定，談加密只是裝忙。

握手流程才是 TLS 的主場

TLS 最像工程現場的地方，就是 handshake。client 先送自己支援的版本和 cipher suites，server 挑一個能接受的組合，接著 server 丟出 certificate，client 去驗證，最後雙方再建立 session keys。RFC 8446 把這個流程寫得很清楚，TLS 1.3 甚至把很多老包袱砍掉，讓握手更乾淨。

翻譯一下就是：TLS 不是「有沒有加密」的二元問題，而是一連串選擇。版本不合，掛。cipher 沒交集，掛。憑證鏈不對，掛。key exchange 算不出共同秘密，還是掛。這些不是 bug，這些是 protocol 在告訴你：這條線不值得信。

我之前在一個 service mesh 專案裡踩過這種坑。應用團隊一直說 network 沒問題，因為 packet 看起來有到。結果一看 handshake log，真相很直白：client 和 server 互看得到，但根本談不攏安全參數。TLS 不在乎你 packet 有沒有送到，它只在乎你有沒有成功協商出一條可用的安全連線。

實操寫法：把 handshake failure 跟 application failure 分開記錄。不要把它們混成「連線失敗」四個字，這樣你只會在事故時候多一層霧。

• 記錄 client hello 版本和 server choice。
• 記錄憑證驗證失敗原因。
• 記錄 cipher overlap 不足的情況。

再來，supported cipher list 別貪多。列表很長不代表你很強，通常只代表你還沒決定自己要什麼。

憑證不是裝飾，是 trust chain

憑證這件事，很多人嘴上懂，實際上還是當成貼紙。TLS 文件會說 server 通常會提供 digital certificate，裡面有 server name、trusted CA、public key。這句話看起來很乾，其實意思很重：憑證是 server 對自己身分的主張，而 CA 是第三方替這個主張背書。

也就是說，TLS 的 authentication 不是 server 自己喊「信我」。它是拿一個簽過名的物件給 client 驗，client 再對照 trust store。name 不對、chain 斷掉、CA 不在信任清單裡，client 就應該擋下來。這不是麻煩，這就是設計本意。根憑證、中繼憑證、站點憑證這一整條鏈，少一環都不行。

我看過不少團隊對著瀏覽器吐槽：「為什麼我們內網服務明明是自己架的，還一直報憑證錯？」我每次都想回一句：對啊，因為你沒有把 trust model 做完。你如果要 browser 或 client 相信你，就得給它能驗證的 chain，還得讓 hostname 對得上 endpoint。想跳過這些，就別說你在用 TLS，你只是把驗證關掉而已。

實操寫法：把憑證管理當成部署基礎設施，不要當一次性雜務。

• 自動續期，不要靠人記憶。
• 在 staging 測 hostname mismatch。
• 把 expiry alert 設在真的來得及處理的窗口。

如果你有 internal PKI，請把 trust chain 寫進文件。沒人應該靠猜來理解你的安全邊界。

forward secrecy 才是值得保的底線

我現在 review TLS，最在意的不是「有沒有加密」，而是「過去的流量會不會被未來的 key 反查」。這就是 forward secrecy。RFC 8446 用的 key exchange 只保留提供 forward secrecy 的做法，這點我很買單，因為它把風險切得比較乾淨。

白話翻譯：如果有人今天把你的 server private key 偷走，最好不要順便把上個月錄下來的流量也一起解開。沒有 forward secrecy 的話，一把長期 key 可能就變成整包歷史流量的萬能鑰匙。那種 blast radius 很難看。

我以前 review 過一個對外 API，團隊一直以為「TLS 就是 TLS」。結果一挖，config 還留著舊式 key exchange，因為沒人整理過。修法一點都不性感，就是把 legacy 選項砍掉、測 client、再上線。可是安全姿勢差很多。

實操寫法：如果能用 TLS 1.3，就優先用。真的還卡在 TLS 1.2，也至少要把 forward-secret 的 key exchange 排前面，別讓舊模式混進來當預設。

• 優先 TLS 1.3。
• TLS 1.2 只留必要的相容性。
• 把長期 key 外洩後的影響範圍想清楚。

這不是學術潔癖，這是 incident response 的基本常識。

DTLS 是給不是 stream 的世界用的

TLS 的親戚叫 DTLS，也就是 Datagram Transport Layer Security。它是給 UDP、SCTP、SRTP 這種 datagram 世界用的。這件事很重要，因為不是所有應用都適合 TCP 那種「看起來很穩」的 stream 假象。

翻譯一下就是：如果你的資料會亂序、會遺失、會重送，安全層也要懂這個現實。DTLS 不是把 TLS 原封不動搬過去，而是把安全屬性留著，然後適配底層 transport 的混亂程度。這才是正確的想法。

我比較常在即時通訊、VPN、語音影像這類場景看到 DTLS。重點不是「DTLS 比 TLS 高級」，而是你不能拿 stream 的腦袋去套 packet 的世界。很多系統後來會痛，就是因為一開始選錯 transport，後面再補安全層，整個架構就卡住了。

實操寫法：先選 transport，再選安全層，不要反過來。

• TCP 場景多半用 TLS。
• UDP 場景考慮 DTLS。
• 不要把熟悉的工具硬塞到不對的協定上。

這句聽起來很廢，但真的很多事故都是這樣來的。

大多數 TLS 問題其實是配置問題

很多人一談 TLS 就想到攻擊名詞：downgrade、Heartbleed、POODLE。那些當然重要，但對大部分團隊來說，真正出事的原因通常沒那麼戲劇化。比較常見的是舊版本、爛預設、庫升級沒跟上、reverse proxy 設定亂掉。

也就是說，問題通常不是「TLS 不夠神」，而是你沒有把版本、cipher、憑證、library、proxy 行為當成一整套系統在管。你只要其中一層比其他層弱，整個安全性就會被拖下去。

我很常被問：「我們不是已經用了 TLS 嗎？」我通常會反問：你是用哪個版本？哪些 cipher？憑證從哪裡來？誰負責 renew？load balancer 會不會偷偷改行為？這些問題答不出來，就別急著說自己有安全。

實操寫法：把 TLS policy 當成 API compatibility policy 來管。

• 定義允許的 protocol versions。
• 列出禁止的 legacy ciphers。
• 寫明 renewal 流程和 deprecation 路線。

然後在 CI 或 staging 直接測，不要等到 outage 才知道某個老 client 還活著。

把 TLS 當成協商系統，而不是 checkbox

如果我要把整篇壓成一句話，我會說：TLS 不是裝飾性的加密開關，它是 negotiated trust system。client 和 server 先談好身份、能力、秘密，然後才開始傳資料。你只要把這個順序搞懂，很多看似玄學的問題就會變得很工程。

這個框架也很適合拿去跟非密碼學背景的同事溝通。你不用解釋每個數學細節，只要講清楚它要保證什麼、在哪裡會失敗、失敗時誰會看到什麼錯誤。這就夠了。真的夠了。

實操寫法：每個服務的文件都應該至少寫出這四件事。

• TLS 版本
• 憑證來源與 renewal 方式
• client 相容性
• 失敗時的 log 位置

如果你寫不出來，通常不是文件能力差，是你自己的 TLS 設定還沒整理好。

可抄的模板

# TLS service playbook（可直接貼進你的 repo / runbook）

## 1) 這條服務要保證什麼
- Confidentiality: yes/no
- Integrity: yes/no
- Server authentication: yes/no
- Client authentication: yes/no

## 2) 協定選擇
- TLS version(s): TLS 1.3, TLS 1.2 only if legacy clients require it
- DTLS needed: yes/no
- Forward secrecy required: yes

## 3) 憑證政策
- Certificate source: internal CA / public CA
- Hostname(s) covered:
- Renewal method:
- Expiration alert window:
- Trust store location:

## 4) Cipher / key exchange 政策
- Allowed cipher suites:
- Disallowed legacy suites:
- Key exchange preference:
- Compression disabled: yes
- Renegotiation policy:

## 5) 操作檢查
- Handshake failure logging enabled: yes
- Certificate expiry monitoring enabled: yes
- Staging test for hostname mismatch: yes
- Staging test for expired cert: yes
- Staging test for protocol downgrade: yes

## 6) Client 相容性
- Browsers:
- Mobile apps:
- API clients:
- Explicitly unsupported old clients:

## 7) 事故處理
- What to rotate if a private key leaks:
- Whether old sessions remain protected by forward secrecy:
- Where to revoke or replace trust anchors:

## 8) 對外說明句
This service uses TLS to negotiate identity, key exchange, and encryption before application data flows.
We require forward-secret key exchange where supported and reject expired, mismatched, or untrusted certificates.
TLS failures are treated as security failures, not transport noise.

這段我刻意寫得很樸素，因為它不是要拿來炫技，是要拿來讓團隊對齊。你可以直接把它貼進 README、runbook，或是部署 checklist。重點不是字漂亮，是你真的有把 TLS 當成一個可操作的系統。

原始拆解主要來自 Wikipedia 的 Transport Layer Security、RFC 8446，以及 RFC 5246。我這篇的白話整理、判讀方式和模板是我自己整理的；協定名詞、流程與定義則是衍生自上述來源。