HTTPS 基本過程
HTTPS 即 HTTP over TLS，是一種在加密信道進行 HTTP 內容傳輸的協議。
TLS 的早期版本叫做 SSL。SSL 的 1.0, 2.0, 3.0 版本均已經被廢棄，出於安全問題考慮廣大瀏覽器也不再對老舊的 SSL 版本進行支持了，因此這裏我們就統一使用 TLS 名稱了。
TLS 的基本過程如下（取自 what-happens-when-zh_CN）：
- 客戶端發送一個 ClientHello 消息到服務器端，消息中同時包含了它的 Transport Layer Security (TLS) 版本，可用的加密算法和壓縮算法。
- 服務器端向客戶端返回一個 ServerHello 消息，消息中包含了服務器端的 TLS 版本，服務器所選擇的加密和壓縮算法，以及數字證書認證機構（Certificate Authority，縮寫 CA）簽發的服務器公開證書，證書中包含了公鑰。客戶端會使用這個公鑰加密接下來的握手過程，直到協商生成一個新的對稱密鑰。證書中還包含了該證書所應用的域名範圍（Common Name，簡稱 CN），用於客戶端驗證身份。
- 客戶端根據自己的信任 CA 列表，驗證服務器端的證書是否可信。如果認爲可信（具體的驗證過程在下一節講解），客戶端會生成一串僞隨機數，使用服務器的公鑰加密它。這串隨機數會被用於生成新的對稱密鑰
- 服務器端使用自己的私鑰解密上面提到的隨機數，然後使用這串隨機數生成自己的對稱主密鑰
- 客戶端發送一個 Finished 消息給服務器端，使用對稱密鑰加密這次通訊的一個散列值
- 服務器端生成自己的 hash 值，然後解密客戶端發送來的信息，檢查這兩個值是否對應。如果對應，就向客戶端發送一個 Finished 消息，也使用協商好的對稱密鑰加密
- 從現在開始，接下來整個 TLS 會話都使用對稱祕鑰進行加密，傳輸應用層（HTTP）內容
從上面的過程可以看到，TLS 的完整過程需要三個算法（協議），密鑰交互算法，對稱加密算法，和消息認證算法（TLS 的傳輸會使用 MAC(message authentication code) 進行完整性檢查）。
我們以 Github 網站使用的 TLS 爲例，使用瀏覽器可以看到它使用的加密爲TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。其中密鑰交互算法是 ECDHE_RSA，對稱加密算法是 AES_128_GCM，消息認證（MAC）算法爲 SHA256。
大家可能都聽說過 HTTPS 協議之所以是安全的是因爲 HTTPS 協議會對傳輸的數據進行加密，而加密過程是使用了非對稱加密實現。但其實：HTTPS 在內容傳輸的加密上使用的是對稱加密，非對稱加密只作用在證書驗證階段。
① 證書驗證階段：
1）瀏覽器發起 HTTPS 請求；
2）服務端返回 HTTPS 證書；
3）客戶端驗證證書是否合法，如果不合法則提示告警。
② 數據傳輸階段：
1）當證書驗證合法後，在本地生成隨機數；
2）通過公鑰加密隨機數，並把加密後的隨機數傳輸到服務端；
3）服務端通過私鑰對隨機數進行解密；
4）服務端通過客戶端傳入的隨機數構造對稱加密算法，對返回結果內容進行加密後傳輸。
TLS 證書機制
HTTPS 過程中很重要的一個步驟，是服務器需要有 CA 頒發的證書，客戶端根據自己的信任 CA 列表驗證服務器的身份。現代瀏覽器中，證書驗證的過程依賴於證書信任鏈。
所謂證書信任鏈，即一個證書要依靠上一級證書來證明自己是可信的，最頂層的證書被稱爲根證書，擁有根證書的機構被稱爲根 CA。
還是以 Github 爲例，在瀏覽器中我們可以看到它的證書信任鏈如下：
DigiCert High Assurance EV Root CA -> DigiCert SHA2 Extended Validation Server CA -> Github.com
從上到下即 Root CA -> 二級 CA -> 網站。
前面提到，證書當中包括 CN(Common Name)，瀏覽器在驗證證書的同時，也會驗證 CN 的正確性。即不光需要驗證“這是一個合法的證書”，還需要驗證“這是一個用於 Github.com 的證書”。
既然所有的信任，最終要落到根 CA 上，根證書本身又是怎麼獲得的呢？答案也很簡單，根證書一般是操作系統自帶的。不管是桌面系統 Windows，macOS 還是移動端系統 Android, iOS 都會內置一系列根證書。隨着操作系統本身的升級，根證書也會隨着升級進行更新。
對瀏覽器而已，瀏覽器當然也有選擇信任某個根證書的權利。Chrome 瀏覽器一般是跟隨系統根證書信任的。Firefox 瀏覽器通常是使用自帶的一套證書信任機制，不受系統證書的影響。
在使用 curl 等工具時，我們還可以自行選擇證書進行信任。
有權威的信任，最終都要落到一個單點信任，不管是 Root CA，還是微軟，蘋果，谷歌等操作系統廠商。
中間人攻擊
HTTPS 的過程並不是密不透風的，HTTPS 有若干漏洞，給中間人攻擊（Man In The Middle Attack，簡稱 MITM）提供了可能。
所謂中間人攻擊，指攻擊者與通訊的兩端分別建立獨立的聯繫，並交換其所收到的數據，使通訊的兩端認爲他們正在通過一個私密的連接與對方直接對話，但事實上整個會話都被攻擊者完全控制。在中間人攻擊中，攻擊者可以攔截通訊雙方的通話並插入新的內容。
SSL 剝離
SSL 剝離即阻止用戶使用 HTTPS 訪問網站。由於並不是所有網站都只支持 HTTPS，大部分網站會同時支持 HTTP 和 HTTPS 兩種協議。用戶在訪問網站時，也可能會在地址欄中輸入 http:// 的地址，第一次的訪問完全是明文的，這就給了攻擊者可乘之機。通過攻擊 DNS 響應，攻擊者可以將自己變成中間人。
DNS 作爲基於 UDP 的協議是相當不安全的，爲了保證 DNS 的安全可以使用 DNS over TCP 等機制，這裏不贅述了。
HSTS
爲了防止上面說的這種情況，一種叫做 HSTS 的技術被引入了。HSTS（HTTP Strict Transport Security）是用於強制瀏覽器使用 HTTPS 訪問網站的一種機制。它的基本機制是在服務器返回的響應中，加上一個特殊的頭部，指示瀏覽器對於此網站，強制使用 HTTPS 進行訪問：
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
可以看到如果這個過期時間非常長，就是導致在很長一段時間內，瀏覽器都會強制使用 HTTPS 訪問該網站。
HSTS 有一個很明顯的缺點，是需要等待第一個服務器的影響中的頭部才能生效，但如果第一次訪問該網站就被攻擊呢？爲了解決這個問題，瀏覽器中會帶上一些網站的域名，被稱爲 HSTS preload list。對於在這個 list 的網站來說，直接強制使用 HTTPS。
僞造證書攻擊
HSTS 只解決了 SSL 剝離的問題，然而即使在全程使用 HTTPS 的情況下，我們仍然有可能被監聽。
假設我們想訪問 www.google.com，但我們的 DNS 服務器被攻擊了，指向的 IP 地址並非 Google 的服務器，而是攻擊者的 IP。當攻擊者的服務器也有合法的證書的時候，我們的瀏覽器就會認爲對方是 Google 服務器，從而信任對方。這樣，攻擊者便可以監聽我們和谷歌之前的所有通信了。
可以看到攻擊者有兩步需要操作，第一步是需要攻擊 DNS 服務器。第二步是攻擊者自己的證書需要被用戶信任，這一步對於用戶來說是很難控制的，需要證書頒發機構能夠控制自己不濫發證書。
2015 年 Google 稱發現賽門鐵克旗下的 Thawte 未經同意簽發了衆多域名的數千個證書，其中包括 Google 旗下的域名和不存在的域名。當年 12 月，Google 發佈公告稱 Chrome、Android 及其他 Google 產品將不再信任賽門鐵克旗下的"Class 3 Public Primary CA"根證書。
2016 年 Mozilla 發現沃通 CA 存在嚴重的信任問題，例如偷籤 github.com 的證書，故意倒填證書日期繞過瀏覽器對 SHA-1 證書的限制等，將停止信任 WoSign 和 StartCom 簽發的新證書。
HPKP
HPKP 技術是爲了解決僞造證書攻擊而誕生的。
HPKP（Public Key Pinning Extension for HTTP）在 HSTS 上更進一步，HPKP 直接在返回頭中存儲服務器的公鑰指紋信息，一旦發現指紋和實際接受到的公鑰有差異，瀏覽器就可以認爲正在被攻擊：
Public-Key-Pins: pin-sha256=“base64==”; max-age=expireTime [; includeSubDomains][; report-uri=“reportURI”]
和 HSTS 類似，HPKP 也依賴於服務器的頭部返回，不能解決第一次訪問的問題，瀏覽器本身也會內置一些 HPKP 列表。
HPKP 技術仍然不能阻止第一次訪問的攻擊問題，部署和配置 HPKP 相當繁瑣，一旦網站配置錯誤，就會導致網站證書驗證失敗，且在過期時間內無法有效恢復。HPKP 的機制也引來了一些安全性問題。Chrome 67 中廢除了對 HPKP 的支持，在 Chrome 72 中 HPKP 被徹底移除。
本文小結
Q: HTTPS 爲什麼安全？
A: 因爲 HTTPS 保證了傳輸安全，防止傳輸過程被監聽、防止數據被竊取，可以確認網站的真實性。
Q: HTTPS 的傳輸過程是怎樣的？
A: 客戶端發起 HTTPS 請求，服務端返回證書，客戶端對證書進行驗證，驗證通過後本地生成用於改造對稱加密算法的隨機數，通過證書中的公鑰對隨機數進行加密傳輸到服務端，服務端接收後通過私鑰解密得到隨機數，之後的數據交互通過對稱加密算法進行加解密。
Q: 爲什麼需要證書？
A: 防止”中間人“攻擊，同時可以爲網站提供身份證明。
Q: 使用 HTTPS 會被抓包嗎？
A: 會被抓包，HTTPS 只防止用戶在不知情的情況下通信被監聽，如果用戶主動授信，是可以構建“中間人”網絡，代理軟件可以對傳輸內容進行解密。
好了，迴歸到本文標的問題，我們來總結回顧一下。
Q: HTTPS用的是對稱加密還是非對稱加密？
Q: HTTPS 在內容傳輸的加密上使用的是對稱加密，非對稱加密只作用在證書驗證階段。
