你有沒有注意過，有些網站的網址開頭是 http://，有些則是 https://？
多出來的那個 s，其實代表了一整套加密機制，保護你在網路上傳輸的所有資料。
這篇文章會先帶你快速了解 HTTP 和 HTTPS 的差異，然後深入拆解背後的核心：SSL/TLS 加密到底是怎麼運作的。
什麼是 HTTP？
HTTP 的全名是 Hypertext Transfer Protocol（超文字傳輸協定）。
簡單來說，它就是瀏覽器和伺服器之間「溝通的語言」。
當你在瀏覽器輸入 http://google.com，HTTP 協定會幫你把這個請求送到 Google 的伺服器，然後把網頁內容傳回來給你看。
HTTP 的特性
資料用明文傳輸
你送出去的資料、收到的資料，全部都是「看得懂的文字」，沒有任何加密。
這代表什麼？
假設你在咖啡廳用公共 Wi-Fi 連上一個 HTTP 的網站，有人在同一個網路上「監聽」，他就能直接看到你輸入的所有內容，包括帳號、密碼。
屬於 OSI 第七層（應用層）協定
如果你聽過 OSI 模型，它把網路通訊分成七層。
HTTP 位在最頂端的第七層「應用層」，也就是最接近使用者的那一層。
輕量、效能好
因為沒有加密解密的過程，HTTP 的傳輸速度比較快。
預設使用 Port 80
伺服器預設在 80 號埠口監聽 HTTP 的請求。
什麼是 HTTPS？
HTTPS 就是 HTTP + SSL/TLS 加密。
你可以把它想成：HTTPS 是 HTTP 的「加強版」，多了一層 SSL（Secure Socket Layer）或 TLS（Transport Layer Security）的保護。
HTTPS 的特性
資料經過加密傳輸
你送出的資料會先被加密，變成一堆看不懂的亂碼，到了伺服器端才會被解密。
這樣就算有人在中間監聽，也只能看到亂碼，無法知道你傳了什麼。
瀏覽器會顯示鎖頭圖示
當你打開一個 HTTPS 的網站，瀏覽器網址列旁邊會出現一個鎖頭圖示，代表這是一個安全的連線。
屬於 OSI 第四層（傳輸層）協定
和 HTTP 不同，HTTPS 的加密機制運作在更底層的傳輸層。
比 HTTP 稍重一些
因為多了加密和解密的步驟，HTTPS 的效能會比 HTTP 稍微慢一點。
預設使用 Port 443
伺服器預設在 443 號埠口監聽 HTTPS 的請求。
HTTP 與 HTTPS 的比較
看完這張表，接下來的關鍵問題是：HTTPS 背後的 SSL/TLS 加密，到底是怎麼運作的？
SSL 和 TLS 是什麼關係？
SSL 的全名是 Secure Socket Layer（安全通訊端層）。
TLS 的全名是 Transport Layer Security（傳輸層安全性協定）。
簡單來說，TLS 就是 SSL 的「接班人」。
SSL 的誕生
SSL 最早是由 Netscape（網景公司）在 1990 年代開發的。
當時網路才剛開始普及，越來越多人在網路上購物、輸入信用卡號，大家意識到：資料在網路上傳輸如果沒有保護，太危險了。
於是 Netscape 開發了 SSL 協定，讓瀏覽器和伺服器之間的通訊可以被加密。
最早的 SSL 1.0 因為有嚴重的安全問題，從來沒有公開發布過。
真正被使用的是 SSL 2.0（1995 年）和 SSL 3.0（1996 年）。
從 SSL 到 TLS
SSL 3.0 用了好一陣子，但隨著時間推移，研究人員陸續發現了一些安全漏洞。
其中最知名的是 2014 年被揭露的 POODLE 攻擊，這個漏洞讓攻擊者可以利用 SSL 3.0 的設計缺陷，解密被加密的資料。
在這之前，業界其實已經開始推動新版本了。
1999 年，IETF（網際網路工程任務組）以 SSL 3.0 為基礎，設計了一個改良版本，但因為主導權從 Netscape 轉移到了公開的標準組織，他們決定改名，叫做 TLS 1.0。
之後陸續推出了 TLS 1.1（2006 年）、TLS 1.2（2008 年）、TLS 1.3（2018 年）。
每一個新版本都修補了前一版的安全問題，同時也改善了效能。
現在的狀況
目前主流使用的是 TLS 1.2 和 TLS 1.3。
SSL 2.0 和 SSL 3.0 早已被正式淘汰，TLS 1.0 和 TLS 1.1 也在 2020 年之後被各大瀏覽器停止支援。
如果你現在打開一個網站看到鎖頭圖示，背後跑的幾乎都是 TLS 1.2 或 TLS 1.3。
那為什麼大家還是叫「SSL」？
因為「SSL」這個名字太深入人心了。
從 1990 年代就開始用的名詞，已經變成一種習慣用語。
像是「SSL 憑證」、「SSL 加密」這些說法，其實背後跑的都是 TLS 協定，但大家還是習慣用 SSL 來稱呼。
在這篇文章裡，我會用「SSL/TLS」來統稱，你只要知道它們是同一件事的新舊版本就好。
SSL/TLS 加密的兩種方式
SSL/TLS 的加密機制，核心是兩種加密方式的組合：非對稱加密和對稱加密。
要理解整個加密流程怎麼運作，你得先搞懂這兩種加密各自的特性。
非對稱加密（Asymmetric Encryption）
非對稱加密有兩個東西：公鑰（Public Key）和私鑰（Private Key）。
它的核心概念是：上鎖不需要鑰匙，但解鎖需要。
怎麼理解？想像伺服器寄了一個「開口鎖」給你，這個開口鎖就是公鑰。
這種鎖的特性是：任何人都能直接把它「啪」一聲扣上，不需要鑰匙。
但一旦扣上了，只有伺服器手上那把對應的鑰匙能打開——這把鑰匙就是私鑰。
所以流程就是：伺服器把公鑰（開口鎖）公開給所有人，你拿到之後，把資料放進箱子、扣上鎖、寄回去，中間任何人攔截到這個箱子都打不開，因為私鑰（鑰匙）只有伺服器有。
因為上鎖和解鎖的機制完全不同，安全性很高，但運算量也比較大，金鑰長度通常是 1024 位元或 2048 位元。
對稱加密（Symmetric Encryption）
對稱加密只有一個東西：一把共用金鑰（Symmetric Key），加密和解密都靠它。
你可以把它想成一把「萬能鑰匙」——伺服器和瀏覽器各持有一把一模一樣的鑰匙，發送方用它把資料鎖上，接收方用同一把鑰匙打開。
跟非對稱加密最大的差別是：這裡不存在「開口鎖」那種「誰都能扣上」的設計，你必須有鑰匙才能上鎖，也必須有鑰匙才能解鎖。
因為只有一把鑰匙，運算比較輕量，金鑰長度通常是 128 位元或 256 位元。
但缺點是：這把鑰匙必須想辦法「安全地交到對方手上」，如果在傳遞過程中被攔截、被複製了一把，資料就不安全了。
兩種加密方式的比較
看到這裡你可能會想：那直接全部用非對稱加密不就好了？
答案是不行，因為它太慢了。
所以 SSL/TLS 的做法是：把兩種組合在一起用。
SSL/TLS 的加密流程：交握（Handshake）
這是整篇最重要的部分。
SSL/TLS 用非對稱加密來「安全地把鑰匙交給對方」，交換完之後，再用對稱加密來進行實際的資料傳輸。
整個流程叫做 SSL/TLS 交握（Handshake），分成四個步驟：
第一步：伺服器把公鑰送給瀏覽器
當你打開一個 HTTPS 網站，伺服器會先把自己的公鑰傳給你的瀏覽器。
但這裡有一個問題：瀏覽器怎麼知道這個公鑰真的是那台伺服器的？
如果有人在中間攔截，偷偷把公鑰換成自己的，你就會把資料鎖進錯誤的箱子裡，寄給攻擊者而不是真正的伺服器。
為了解決這個「信任」問題，伺服器不會直接丟一把公鑰給你，而是會送一份叫做 SSL 憑證的東西過來，公鑰就附在這份憑證裡面。
這份憑證就像伺服器的「身分證」，上面寫了：這個網站是誰、公鑰是什麼、這份證明是誰發的。
而「誰發的」這個角色，叫做憑證機構（Certificate Authority, CA），例如 Let’s Encrypt、DigiCert 這些組織。
瀏覽器內建了一份「受信任的 CA 清單」，收到憑證後會去比對：這份憑證是不是由清單上的 CA 簽發的？
如果驗證通過，瀏覽器就信任這個公鑰，繼續進行下一步。
如果驗證失敗，瀏覽器就會跳出「不安全」的警告，阻止你繼續連線。
（關於 SSL 憑證的更多細節，後面會有專門的段落說明。）
第二步：瀏覽器產生 Session Key，用公鑰加密後送出
瀏覽器會在本地產生一把對稱式的 Session Key（工作階段鑰匙）。
然後用第一步拿到的公鑰，把這組 Session Key「鎖起來」，送回給伺服器。
因為是用公鑰鎖上的，就算中間有人攔截到，沒有私鑰也打不開。
第三步：伺服器用私鑰解密，拿到 Session Key
伺服器收到被鎖住的 Session Key 後，用自己的私鑰把它解開。
到這一步，瀏覽器和伺服器雙方就都持有同一組 Session Key 了。
第四步：雙方開始用 Session Key 加密通訊
從這一步開始，所有來回的資料都用這組 Session Key 進行對稱加密。
既安全（因為 Session Key 是透過非對稱加密安全傳遞的），又有效率（因為實際傳輸用的是對稱加密）。
這組 Session Key 只在這次連線有效，關掉瀏覽器或下次再連線，就會重新走一次交握流程，產生新的 Session Key。
為什麼要組合兩種加密？
回頭整理一下這個設計的邏輯：
非對稱加密很安全，但很慢——不適合拿來加密大量資料。
對稱加密很快，但有風險——那把鑰匙要怎麼安全地交到對方手上是個問題。
SSL/TLS 的解法就是：用非對稱加密來解決「鑰匙怎麼安全傳遞」的問題，傳完之後就切換成對稱加密來處理實際的資料傳輸。
這樣兩種加密方式各取所長，既保證了安全性，又兼顧了效率。
SSL 憑證是什麼？
前面提到伺服器會把公鑰附在「SSL 憑證」裡送給瀏覽器，那這個憑證到底是什麼？
SSL 憑證是一份數位身分證，用來證明「這個網站真的是它自己說的那個網站」。
為什麼需要它？因為如果伺服器直接丟一把公鑰給你，你根本無法確認這把公鑰是不是真的來自你想連線的伺服器，還是某個偽裝的攻擊者。
SSL 憑證就是用來解決這個信任問題的。
憑證裡面有什麼？
一份 SSL 憑證包含了：網域名稱（這份憑證是發給哪個網站的）、伺服器的公鑰、簽發者是哪個 CA、有效期限，以及一段數位簽章（由 CA 用自己的私鑰簽名，證明這份憑證沒有被竄改過）。
誰來發這張身分證？
憑證機構（Certificate Authority, CA）就是負責「發身分證」的可信任第三方。
它的角色就像現實生活中的「戶政事務所」——你不會相信一個人自己印的身分證，但如果是政府機關發的，你就會信任。
網站管理者向 CA 提出申請，CA 驗證你確實擁有這個網域之後，就會簽發一份 SSL 憑證給你。
常見的 CA 包括 Let’s Encrypt（免費）、DigiCert、GlobalSign 等。
瀏覽器怎麼驗證？
瀏覽器出廠時就內建了一份受信任的 CA 清單。
收到憑證後，瀏覽器會檢查：簽發者是不是清單上的 CA、網域名稱跟你訪問的網站是否一致、憑證有沒有過期、數位簽章有沒有被竄改。
全部通過，瀏覽器就會顯示鎖頭圖示。
只要有任何一項沒通過，瀏覽器就會跳出「不安全」的警告。
下次打開一個 HTTPS 網站時，你可以點一下網址列旁邊的鎖頭圖示，就能看到這個網站的 SSL 憑證資訊。
補充：SSL/TLS 不是百分之百無敵
雖然 SSL/TLS 讓網路傳輸安全了非常多，但它並不是完全不可破解的。
舉例來說，有一種攻擊叫做 SSL Stripping（SSL 剝離攻擊），攻擊者會在你和伺服器之間「插一腳」，把原本應該走 HTTPS 的連線，偷偷降級成沒有加密的 HTTP。
你以為自己在安全的加密連線上，其實資料已經在用明文傳輸了。
所以在使用公共 Wi-Fi 時，還是要特別注意瀏覽器有沒有顯示鎖頭圖示，確保連線真的有經過 SSL/TLS 加密。
小結
這篇文章的重點整理：
SSL 和 TLS 是同一件事的新舊版本，現在實際上用的都是 TLS，但習慣上還是統稱 SSL/TLS。
SSL/TLS 加密有兩種方式：非對稱加密（像開口鎖，任何人能扣上但只有持鑰匙的人能打開，安全但慢）和對稱加密（同一把鑰匙上鎖解鎖，快但鑰匙傳遞有風險）。
SSL/TLS 交握的流程是：先用非對稱加密安全地交換 Session Key，之後再用對稱加密來傳輸實際資料，兼顧安全與效率。
SSL 憑證就像伺服器的身分證，由受信任的憑證機構簽發，瀏覽器會驗證這張憑證來決定是否信任這個連線。