下面來聊聊與安全相關的 HTTPS、SSL、TLS，我們曾經談到過 HTTP 的一些缺點，其中的無狀態在加入 Cookie 后得到了解決，而另兩個缺點——明文 和 不安全 僅憑 HTTP 自身是無力解決的，需要引入新的 HTTPS 協議。
為什么要有 HTTPS？
簡單的回答是 因為 HTTP 不安全，由於 HTTP 天生明文的特點，整個傳輸過程完全透明，任何人都能夠在鏈路中截獲、修改或者偽造請求 / 響應報文，數據不具有可信性。比如，上面說過的代理服務，它作為 HTTP 通信的中間人，在數據上下行的時候可以添加或刪除部分頭字段，也可以使用黑白名單過濾 body 里的關鍵字，甚至直接發送虛假的請求、響應，而瀏覽器和源服務器都沒有辦法判斷報文的真偽。
這對於網絡購物、網上銀行、證券交易等需要高度信任的應用場景來說是非常致命的。如果沒有基本的安全保護，使用互聯網進行各種電子商務、電子政務就根本無從談起。對於安全性要求不那么高的新聞、視頻、搜索等網站來說，由於互聯網上的惡意用戶、惡意代理越來越多，也很容易遭到流量劫持的攻擊，在頁面里強行嵌入廣告，或者分流用戶，導致各種利益損失。對於普通網民來說，HTTP 不安全的隱患就更大了，上網的記錄會被輕易截獲，網站是否真實也無法驗證，黑客可以偽裝成銀行網站，盜取真實姓名、密碼、銀行卡等敏感信息，威脅人身安全和財產安全。總的來說，今天的互聯網已經不再是早期的田園牧歌時代，而是進入了黑暗森林狀態。上網的時候必須步步為營、處處小心，否則就會被不知道埋伏在哪里的黑客所獵殺。
什么是安全？
既然 HTTP 不安全，那什么樣的通信過程才是安全的呢？
通常認為，如果通信過程具備了四個特性，就可以認為是安全的，這四個特性是：機密性、完整性，身份認證和不可否認。
機密性（Secrecy/Confidentiality）是指對數據的保密，只能由可信的人訪問，對其他人是不可見的秘密，簡單來說就是不能讓不相關的人看到不該看的東西。比如小明和小紅私下聊天，但隔牆有耳，被小強在旁邊的房間里全偷聽到了，這就是沒有機密性。抓包工具 Wireshark 實際上也是利用了 HTTP 的這個特點，捕獲了傳輸過程中的所有數據。
完整性（Integrity，也叫一致性）是指數據在傳輸過程中沒有被竄改，不多也不少，完完整整地保持着原狀。機密性雖然可以讓數據成為秘密，但不能防止黑客對數據的修改，黑客可以替換數據，調整數據的順序，或者增加、刪除部分數據，破壞通信過程。比如，小明給小紅寫了張紙條：明天公園見。小強把公園划掉，模仿小明的筆跡把這句話改成了明天廣場見。小紅收到后無法驗證完整性，信以為真，第二天的約會就告吹了。
身份認證（Authentication）是指確認對方的真實身份，也就是 "證明你真的是你"，保證消息只能發送給可信的人。如果通信時另一方是假冒的網站，那么數據再保密也沒有用，黑客完全可以使用冒充的身份套出各種信息，加密和沒加密一樣。比如，小明給小紅寫了封情書：我喜歡你，但不留心發給了小強。小強將錯就錯，假冒小紅回復了一個白日做夢，小明不知道這其實是小強的話，誤以為是小紅的，后果可想而知。
第四個特性是不可否認（Non-repudiation/Undeniable），也叫不可抵賴，意思是不能否認已經發生過的行為，不能說話不算數、耍賴皮。使用前三個特性，可以解決安全通信的大部分問題，但如果缺了不可否認，那通信的事務真實性就得不到保證，有可能出現老賴。比如，小明借了小紅一千元，沒寫借條，第二天矢口否認，小紅也確實拿不出借錢的證據，只能認倒霉。另一種情況是小明借錢后還了小紅，但沒寫收條，小紅於是不承認小明還錢的事，說根本沒還，要小明再掏出一千元。
所以，只有同時具備了機密性、完整性、身份認證、不可否認這四個特性，通信雙方的利益才能有保障，才能算得上是真正的安全。
什么是 HTTPS？
說到這里，終於輪到今天的主角 HTTPS 出場了，它為 HTTP 增加了剛才所說的四大安全特性。
HTTPS 其實是一個非常簡單的協議，RFC 文檔很小，只有短短的 7 頁，里面規定了新的協議名 https，默認端口號 443，至於其他的什么請求 - 響應模式、報文結構、請求方法、URI、頭字段、連接管理等等都完全沿用 HTTP，沒有任何新的東西。也就是說，除了協議名 http 和端口號 80 這兩點不同，HTTPS 協議在語法、語義上和 HTTP 完全一樣，優缺點也照單全收（當然要除去明文和不安全）。
你可能要問了，既然沒有新東西，HTTPS 憑什么就能做到機密性、完整性這些安全特性呢？秘密就在於 HTTPS 名字里的 S，它把 HTTP 下層的傳輸協議由 TCP/IP 換成了 SSL/TLS，由 HTTP over TCP/IP 變成了 HTTP over SSL/TLS，讓 HTTP 運行在了安全的 SSL/TLS 協議上，收發報文不再使用 Socket API，而是調用專門的安全接口。
所以說，HTTPS 本身並沒有什么驚世駭俗的本事，全是靠着后面的 SSL/TLS 撐腰，只要學會了 SSL/TLS，HTTPS 自然就手到擒來。
SSL/TLS
現在我們就來看看 SSL/TLS，它到底是個什么來歷。SSL 即安全套接層（Secure Sockets Layer），在 OSI 模型中處於第 5 層（會話層），由網景公司於 1994 年發明，有 v2 和 v3 兩個版本，而 v1 因為有嚴重的缺陷從未公開過。
SSL 發展到 v3 時已經證明了它自身是一個非常好的安全通信協議，於是互聯網工程組 IETF 在 1999 年把它改名為 TLS（傳輸層安全，Transport Layer Security），正式標准化，版本號從 1.0 重新算起，所以 TLS1.0 實際上就是 SSLv3.1。到今天 TLS 已經發展出了三個版本，分別是 2006 年的 1.1、2008 年的 1.2 和 2018 的 1.3，每個新版本都緊跟密碼學的發展和互聯網的現狀，持續強化安全和性能，已經成為了信息安全領域中的權威標准。
TLS 由記錄協議、握手協議、警告協議、變更密碼規范協議、擴展協議等幾個子協議組成，綜合使用了對稱加密、非對稱加密、身份認證等許多密碼學前沿技術。瀏覽器和服務器在使用 TLS 建立連接時需要選擇一組恰當的加密算法來實現安全通信，這些算法的組合被稱為密碼套件（cipher suite，也叫加密套件）。
那么 SSL/TLS 協議是如何保證通信是安全的呢？
混合加密 的方式實現信息的 機密性，解決了竊聽的風險摘要算法 的方式來實現 完整性，它能夠為數據生成獨一無二的「指紋」，指紋用於校驗數據的完整性，解決了篡改的風險將服務器公鑰放入到 數字證書 中，解決了冒充的風險
1. 混合加密
通混合加密的方式可以保證信息的機密性，解決了竊聽的風險。
HTTPS 采用的是對稱加密和非對稱加密結合的「混合加密」方式：
在通信建立前采用非對稱加密的方式交換「會話秘鑰」，后續就不再使用非對稱加密在通信過程中全部使用 對稱加密 的「會話秘鑰」的方式加密明文數據
采用「混合加密」的方式的原因：
對稱加密只使用一個密鑰，運算速度快，密鑰必須保密，無法做到安全的密鑰交換非對稱加密使用兩個密鑰：公鑰和私鑰，公鑰可以任意分發而私鑰保密，解決了密鑰交換問題但速度慢
2. 摘要算法
摘要算法 用來實現完整性，能夠為數據生成獨一無二的「指紋」，用於校驗數據的完整性，解決了篡改的風險。
客戶端在發送明文之前會通過摘要算法算出明文的「指紋」，發送的時候把「指紋 + 明文」一同 加密成密文后，發送給服務器，服務器解密后，用相同的摘要算法算出發送過來的明文，通過比較客戶端攜帶的「指紋」和當前算出的「指紋」做比較，若「指紋」相同，說明數據是完整的。
3. 數字證書
客戶端先向服務器端索要公鑰，然后用公鑰加密信息，服務器收到密文后，用自己的私鑰解密。這就存在些問題，如何保證公鑰不被篡改和信任度？所以這里就需要借助第三方權威機構 CA（數字證書認證機構），將服務器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的。
通過數字證書的方式保證服務器公鑰的身份，解決冒充的風險。
OpenSSL
說到 TLS，就不能不談到 OpenSSL，它是一個著名的開源密碼學程序庫和工具包，幾乎支持所有公開的加密算法和協議，已經成為了事實上的標准，許多應用軟件都會使用它作為底層庫來實現 TLS 功能，包括常用的 Web 服務器 Apache、Nginx 等。
OpenSSL 是從另一個開源庫 SSLeay 發展出來的，曾經考慮命名為 OpenTLS，但當時（1998 年）TLS 還未正式確立，而 SSL 早已廣為人知，所以最終使用了 OpenSSL 的名字。OpenSSL 目前有三個主要的分支，1.0.2 和 1.1.0 都將在今年（2019）年底不再維護，最新的長期支持版本是 1.1.1，我們的實驗環境使用的 OpenSSL 是 1.1.0j。由於 OpenSSL 是開源的，所以它還有一些代碼分支，比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL，這些分支在 OpenSSL 的基礎上刪除了一些老舊代碼，也增加了一些新特性，雖然背后有 大金主，但離取代 OpenSSL 還差得很遠。
HTTPS 是如何建立連接的？其間交互了什么？
SSL/TLS 協議基本流程：
客戶端向服務器索要並驗證服務器的公鑰雙方協商生產「會話秘鑰」雙方采用「會話秘鑰」進行加密通信
前兩步也就是 SSL/TLS 的建立過程，也就是握手階段。SSL/TLS 的「握手階段」涉及四次通信，可見下圖：
SSL/TLS 協議建立的詳細流程：
1. ClientHello
首先，由客戶端向服務器發起加密通信請求，也就是 ClientHello 請求。在這一步，客戶端主要向服務器發送以下信息：
客戶端支持的 SSL/TLS 協議版本，如 TLS 1.2 版本。客戶端生產的隨機數（Client Random），后面用於生產「會話秘鑰」。客戶端支持的密碼套件列表，如 RSA 加密算法。
2. ServerHello
服務器收到客戶端請求后，向客戶端發出響應，也就是 SeverHello。服務器回應的內容有如下內容：
確認 SSL/ TLS 協議版本，如果瀏覽器不支持，則關閉加密通信。服務器生產的隨機數（Server Random），后面用於生產「會話秘鑰」。確認的密碼套件列表，如 RSA 加密算法。服務器的數字證書。
3. 客戶端回應
客戶端收到服務器的回應之后，首先通過瀏覽器或者操作系統中的 CA 公鑰，確認服務器的數字證書的真實性。如果證書沒有問題，客戶端會從數字證書中取出服務器的公鑰，然后使用它加密報文，向服務器發送如下信息：
一個隨機數（pre-master key）。該隨機數會被服務器公鑰加密。加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時把之前所有內容的發生的數據做個摘要，用來供服務端校驗。
上面第一項的隨機數是整個握手階段的第三個隨機數，這樣服務器和客戶端就同時有三個隨機數，接着就用雙方協商的加密算法，各自生成本次通信的「會話秘鑰」。
4. 服務器的最后回應
服務器收到客戶端的第三個隨機數（pre-master key）之后，通過協商的加密算法，計算出本次通信的「會話秘鑰」。然后，向客戶端發生最后的信息：
加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時把之前所有內容的發生的數據做個摘要，用來供客戶端校驗。
至此，整個 SSL/TLS 的握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的 HTTP 協議，只不過用「會話秘鑰」加密內容。
所以 HTTPS 連接大致上可以划分為兩個部分：第一個是建立連接時的非對稱加密握手，第二個是握手后的對稱加密報文傳輸。
也正因為 HTTPS 比 HTTP 增加了一個 TLS 握手的步驟，這個步驟最長可以花費兩個消息往返，也就是 2-RTT；以及產生用於密鑰交換的臨時公私鑰對（ECDHE）、驗證證書時訪問 CA 獲取 CRL 或者 OCSP、非對稱加密解密處理 Pre-Master，導致 HTTPS 會比 HTTP 要慢一些，因為 HTTPS 為了保證安全要做一些額外的工作。但這些情況已經是過去式了，現在已經有了很多行之有效的 HTTPS 優化手段，運用得好可以把連接的額外耗時降低到幾十毫秒甚至是零，比如：硬件優化、軟件優化、協議優化、證書優化、會話復用、預共享密鑰等等。
HTTP 與 HTTPS 有哪些區別？
HTTP 是超文本傳輸協議，信息是明文傳輸，存在安全風險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網絡層之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸。HTTP 連接建立相對簡單， TCP 三次握手之后便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之后，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸。HTTP 的端口號是 80，HTTPS 的端口號是 443。HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證服務器的身份是可信的。
