你在咖啡店 Wi-Fi 登入網站、送出密碼或傳送訊息時，資料必須穿過許多網路設備才會抵達伺服器。如果只是裸的 HTTP，中途能觀察流量的人可能看見內容，甚至修改它。
HTTPS（HTTP Secure）就是把 HTTP 放進 TLS 保護的連線裡。它主要處理三件事：加密、完整性，以及伺服器身分驗證。
一句話先記住：HTTP 規定「怎麼交換 Web 資料」；TLS 負責「讓這段交換不容易被偷看、竄改或冒充」。HTTPS 是兩者一起使用。
HTTPS 保護的三件事
Confidentiality 讓傳輸內容被加密；Integrity 讓雙方能偵測資料是否遭到修改；Authentication 則讓瀏覽器確認自己連到的伺服器至少持有該網域有效憑證所對應的金鑰。
TLS handshake 在做什麼？
真正開始大量交換 HTTP 資料以前，client 與 server 會先進行 TLS handshake。雙方協商 TLS 版本與加密參數，server 提供 certificate，接著建立這次連線使用的 shared session keys。
現代 TLS 不會把每一段網站資料都直接拿伺服器的 public key 加密。公開金鑰密碼學主要協助驗證與建立秘密；真正的大量資料傳輸通常使用效率更高的 symmetric encryption。
Certificate 到底證明什麼？
TLS certificate 會包含網域名稱、公鑰、有效期限、簽發者等資訊。瀏覽器會檢查憑證鏈是否能連到受信任的 Certificate Authority，也會確認目前造訪的 hostname 是否包含在憑證允許的名稱中。
因此憑證主要證明的是「這條 TLS 連線與這個網域之間的身分關係」，而不是替網站內容、公司信用或商品品質背書。
鎖頭不代表網站一定可信
釣魚網站一樣可以申請合法 TLS certificate。HTTPS 可以保護你和釣魚網站之間的傳輸，但如果你本來就連錯網站，它不會自動判斷頁面上的說法是真是假。
HTTPS 解決的是連線安全，不是內容可信度。
為什麼不能只用 public key 一路加密？
Asymmetric cryptography 很適合解決陌生雙方如何建立信任與共享秘密，但計算成本比 symmetric cryptography 高。TLS 因此把兩者結合：先安全地建立 session keys，再用對稱式加密處理大量資料。
DNS 在 HTTPS 前面還是後面？
一般瀏覽網站時，client 通常先透過 DNS 找到目標位址，接著建立 TCP 或 QUIC 連線，再完成 TLS，之後才傳送受保護的 HTTP 資料。
所以 DNS、TLS、HTTP 是不同層次的工作。DNS 回答「去哪裡」；TLS 建立受保護的通道；HTTP 才定義 Web request 與 response。
HTTPS 能藏住整個網址嗎？
不是所有連線資訊都會消失。HTTPS 會保護 HTTP request 裡的 path、query、headers 與 body，但建立連線本身仍需要網路層資訊；DNS 查詢是否加密，也取決於是否使用 DoH、DoT 等機制。實際可被觀察到的 metadata 還與 TLS 版本及網路環境有關。
Certificate 過期會發生什麼？
如果 certificate 已過期、hostname 不符、簽章鏈無法被信任，瀏覽器通常會顯示明顯警告。這不是「HTTPS 整個壞掉」的單一原因，而是身分驗證中的某項檢查沒有通過。
網站有 HTTPS，資料庫就安全了嗎？
沒有。HTTPS 只保護資料在 client 與 TLS endpoint 之間的傳輸。資料抵達應用後怎麼儲存、密碼是否正確雜湊、權限是否設定好、server 是否有漏洞，都屬於其他安全問題。
把整個流程串起來
當瀏覽器開啟一個 HTTPS 網址，它先找到伺服器、建立連線，透過 TLS handshake 驗證憑證並建立 session keys，最後才在加密通道裡送出 HTTP request。這個「S」不是另一套 HTTP，而是 HTTP 多了一層傳輸保護。
你現在應該能分清楚
- HTTP：Web request / response 的應用層協定。
- HTTPS：透過 TLS 保護的 HTTP。
- TLS：提供加密、完整性與身分驗證的協定。
- Certificate：把網域身分與 public key 等資訊綁在一起的可驗證文件。
- Session key：連線建立後用來高效率保護資料的對稱式金鑰。
理解 HTTPS 後，再看 DNS、CDN、reverse proxy 或 API，就比較不會把「網站在哪裡」「資料怎麼傳」「誰處理 request」混成同一件事。