推廣 HTTPS 的道路從來都不是一帆風順的，國外的網際網路大頭貌似都在飛快地推行著而且基本都已經實現全站了，國內推廣的速度反而像蝸牛一樣。BAT 也就阿里上了全站 HTTPS，百度也開始逐步邁向 HTTPS 的行列，像百度圖片還沒有。我也就不噴國內某大型社交網站登陸賬號用的是 HTTP + GET 的方式請求了，雖然加了校驗，但是還是有風險。

上全站 HTTPS 的流程大概是這樣的：

買證書啊

中國的一個叫 WoSign 的 CA 之前給一個

schrauger。github。com

生成了一個 *。

http：//

github。com

的 SSL，然後還有一個月內生成了幾百個相同

序列號

的證書。Firefox 腦袋一拍，決定從 2016 年 10月份把它從信任 CA 列表中除名。對 WoSign 感興趣？這裡：

CA：WoSign Issues

，你也可以點上面那個 github 的地址，第一篇就是：The story of how WoSign gave me an SSL certificate for

http：//

GitHub。com

。

所以你需要考慮到底是用國內的還是國外的。就安全性來說當然是 GeoTrust 是最靠譜的，但是貴呀。如果你的企業有一定的背景，說不定還不讓用國外的產品。

So。。。 如果你網管不小心配錯了證書，但是你又開了 HTTPS 的埠，會這樣：

或者這樣：

證書夠裝逼才行

說到證書，你會發現它有很多種型別的，最裝逼的當然是 twitter 這樣的啦：

這類證書叫做：EV 證書。如果你公司名字比較長可能會比較蛋疼，譬如會變成這樣：

在最新版的 Chrome 下已經不顯示名字了，只有 Safari 才顯示。Chrome 下和普通證書顯示一樣，只有一個綠色的鎖。

這個證書麻煩在於不支援通配，譬如只能 “twitter。com” 或者 “

http：//www。

twitter。com

” ，而不能 “*。twitter。com”，維護成本特別高。

所以大家一般都會選擇支援 “*。twitter。com” 的 wildcard 證書。或者同時支援 “

taobao。com

” 和 “alipay。com” 這樣的 SAN 證書。

上全量 CDN 的 HTTPS 啊

買證書的錢其實還好，服務端的加密解密消耗的伺服器其實也還好。最大的頭其實來自 CDN，動態內容上了 HTTPS，所有靜態內容也要跟著上，都是錢啊貴著呢！去看看 HTTPS 和 HTTP 的價格，差好幾倍啊。

不然你的頁面會變成這樣，這特麼不是和 HTTP 一毛一樣麼！甚至還變差了！

SNI 支援

預設情況下，在客戶端和服務端建立好連線之後。服務端會把預設的 SSL 證書發過去給客戶做 SSL 校驗。但是隨著伺服器效能逐漸變強，一臺伺服器會部署多個 SSL 證書服務多個站點（CDN 是最典型的）。服務端需要客戶端先告知正準備訪問的網站域名（Header 中 Host 欄位），然後服務端才能傳送正確的 SSL 證書資訊和客戶端來 SSL 握手。

如果在上之前沒有調研過這個東西，上線之後可能會收到一堆 Windows XP 的使用者的反饋。國內不乏有大量古董級使用者，用著 windows XP + IE6。如果你上了 HTTPS 他們將永遠上不去你的網站了。因為 Windows XP 不支援 SNI。如果你只有一個證書，同時只有一個入口，那麼你的

動態請求

就不會有問題。但是像 CDN 這類第三方服務，人家不可能只為你服務（好吧只要你有錢你也是可以的）。

SSL 加解密

軟體扛 HTTPS 流量現在主要用 HAProxy 或者 Nginx。如果配置正確加上合理的最佳化，一臺 24 核的 HAProxy 是可以輕鬆扛下 10，000 qps 的量。

關於 SSL 的版本，有：SSL 1。0、SSL 2。0、SSL 3。0、 TLS 1。0、TLS 1。1、TLS 1。2。前面三個協議因為發現有漏洞，已經廢棄了。HAProxy 和 Nginx 的 SSL Protocol 預設都是 TLS 的三個。

——————

好了文章終於可以進入正文了！說到 HTTPS，涉及 2 個概念。

怎麼保證我和真實服務端的通訊是安全的。

怎麼證明我的拿到的請求是真實服務端發我的。

HTTPS 怎麼保證通訊安全

怎麼保證我和真實服務端的通訊是安全的呢？這個問題就好像你和你女朋友想聊一些很羞羞的話題不希望別人知道。其實很簡單。這個時候就需要用到非對稱加密演算法了，簡單來說就是一個公鑰和一個私鑰：

公鑰加密的內容私鑰可以解密

私鑰解密

的內容公鑰可以解密

公鑰是公開給每個人的，私鑰是隻有服務端自己持有

你拿著私鑰，然後把公鑰遞給你的女朋友。你們每次傳送之前都做一次加密就完事了。

但是你會想到另外一個問題：怎麼證明和我聊天的就是我的女朋友呢，或者說你的女朋友怎麼知道正在聊天的那個就是你呢？說不定在第一次遞交

公鑰

的時候就已經被人冒充拿走了！這怎麼行！

這就是第二個問題：怎麼證明我的拿到的請求是真實服務端發我的。聰明的你想到一個辦法，你找了一個第三方公正。你和公正說：公正，你也生成一對金鑰吧。然後你用你的私鑰把我的公鑰給加密了。

然後你把這個被公正加密過的公鑰給了你女朋友，你女朋友會嘗試用公正的公鑰（公鑰都是公開的）去解密，發現解密成功，說明這個公鑰真的是你的。就可以安心的聊羞羞話題了。

所以流程是：服務端（你自己）生成一對金鑰，找 CA （公正）讓它用私鑰把你的公鑰加密，然後客戶（你女朋友）在訪問你的時候嘗試用 CA 的公鑰解密你的公鑰，解密成功表示你是可信任的。

聰明的你又想到一個問題，如果 CA 的公鑰也被冒充了怎麼辦？感覺進入死迴圈了。所以，所有瀏覽器都會內建一系列 CA 公鑰。這樣就完全隔離了網路了。但是這樣也有缺陷，會導致更新 CA 不及時，證書不能實時撤銷的問題。

而我們經常說到的 GeoTrust，以及國內被黑的很慘的 WoSign 就是 CA 機構。同樣，一旦他們的私鑰洩漏了，這就意味著這家公司可以做

破產清算

了，同時很多網際網路公司都可能會出現資料洩漏或者賬號被竊的風險。

HTTPS 通訊到底用了多少種演算法

非對稱加密演算法無非是網際網路安全通訊最重要的協議之一，奠定了整個網際網路安全架構。但是 RSA 演算法本身計算量特別大，如果把所有資料都透過 RSA 加密解密會特別消耗計算能力，所以 HTTPS 並不是一直都是用非對稱演算法的：

HTTPS 在做 SSL 握手的時候是非對稱加密

握手成功之後使用

對稱加密

傳輸資料

同時還用到 Hash 演算法校驗資料的一致性

所以前面的舉例其實並不妥當，應該是你女朋友和你握手完了之後協商了一個

對稱金鑰

，然後用這個對稱金鑰加密通訊的。

HTTPS 握手流程

所有鋪墊都已說明，那麼，我們來說 SSL 到底是怎麼建立的，我們現在只討論基於 RSA 的加密方式。

所有的包都被封裝為 Record Layer 結構體裡面，可以是一個，也可以是多個，這樣可以減少包的數量，裡面包括：

Content Type：表示這是什麼型別的包，握手階段都是 Handshake

Version：表示是用什麼 SSL 協議，較新的瀏覽器都會使用 TLS 1。2

Length：包的內容的長度，指的是 Fragment 的長度，不是整個包的長度。

Fragment：和包的型別相關，譬如在握手階段就是 Handshake Protocol 的結構體，連線連線後的傳輸過程，這裡就是 Encrypted Application Data 的結構體。

Client Hello

在客戶端和服務端完成了 TCP 握手建立了連線之後，

客戶端

會發送 Client Hello 包，其中包括 4 個重要的欄位需要說明一下：

Random：由時間戳和 28 bytes 的

隨機數

組成，將用於後面生成 Master Secret。

SessionID：用來標記是否複用之前的連線。

Cipher Suites：用於告知客戶端自己支援的 Cipher Suites。可以在伺服器上執行

openssl ciphers -V

檢視自己電腦支援的 Cipher Suites。

譬如

0xC0，0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1。2 Kx=ECDH Au=RSA Enc=AESGCM（256） Mac=AEAD

表示用 RSA 演算法驗證證書，用 AES256 加密資料，用 SHA384 驗證資料一致性。

Server Name（擴充套件）：告知服務端正在訪問的是什麼域名，因為 SNI 是後面才補充進去 RFC 的，所以放在了

擴充套件欄位

裡面。注意如果你的客戶端不支援 SNI，將不會帶上這個欄位，這個時候伺服器就會傳回預設的 SSL 證書了。

Server Hello

服務端收到客戶端發來的 Client Hello 之後，會傳回 Server Hello 包，其中包括：

Random：由時間戳和 28 bytes 的隨機陣列成，將用於後面生成 Master Secret。

SessionID：一個 32 bytes 的隨機數，如果下次客戶端想複用這個連線，在 Client Hello 中帶上即可。

Cipher Suite：服務端會根據客戶端傳來的 Cipher Suites 從中選擇一個用於加密。

Certificate

在服務端傳送完 Server Hello 之後，會馬上繼續發一個 2464 bytes 大小的包，裡面包括了服務端的公鑰。

Server key Exchange Message & Server Hello Done

如果傳送完 Certificate 之後還需要補充一些其他的資訊，譬如加密演算法相關的，會額外補充一個 Server key Exchange 的包，最後會統一發送一個 Server Hello Done 的包表示傳輸結束。

Verify Certificate and Signatures

客戶端收到服務端發來的證書檔案之後，必須檢驗：

證書的 Common Name 是否符合我們訪問的域名，如果不符合，會彈出警告框讓使用者選擇是否繼續

證書的時間，不能早於證書上的 “not before”，也不能晚於 “not after”

使用 CA 的公鑰驗證服務端公鑰是未被篡改的，同樣，如果發現 CA 校驗不正確，瀏覽器也會彈出警告

驗證過程涉及到 RSA 演算法，如果感興趣可以看阮一峰的這篇文章：RSA演算法原理（一） - 阮一峰的網路日誌

Client Key Exchange Message

客戶端在驗證服務端發來的證書是可靠的之後，會生成一個 48 bytes 的隨機數，我們稱之為 Pre-Master Secret。然後使用服務端的公鑰對這個 Pre-Master Secret 加密，傳回服務端。不同的加密方法可能會加上位數填充等手段增加其安全性。

Change Cipher Spec

這是客戶端傳送的最後一個明文包，告訴服務端我們之後所有的請求都會透過協商好的加密方法進行通訊。同樣，服務端也會傳回一個 Change Cipher Spec 告知客戶端收到了。這裡有一點注意，這個 Change Cipher Spec 是可以和前面的 Client Key Exchange Message，或者其他包共用同一個 TCP 包的。SSL Record Layer 裡面也允許這樣做，而且大部分瀏覽器也是這樣做的，可以有效減少 TCP 包的包量。

Master Secret

雙方並不是只依賴 Pre-Master Secret 來加密解密傳輸資料，最後會生成一個 Master Secret 用來加解密，函式為：

master_secret = PRF（pre_master_secret，

“master secret”，

ClientHello。random + ServerHello。random）

［0。。47］；

這裡終於用到了最開始提到的兩個 random。取前面 48 bytes，後面全部截斷。

剩下的就是用對稱演算法對內容進行加密了，部分演算法涉及到生成多個 key pair，在此就不展開了，想了解可以看這裡：The TLS Protocol Version 1。0。

同樣在加密之後，會對內容做一次 HASH，譬如這樣：

verify_data

=

PRF

（

master_secret

，

“client finished”

，

MD5

（

handshake_messages

）

+

SHA

-

1

（

handshake_messages

）

）

［

12

］

這裡假設使用的是 MD5 的校驗方法。

Application Layer

恭喜你，你終於完成了 SSL 握手，進入了應用層。

彙總

最後我們來看一看抓包的截圖

後續

如果大家對 HTTPS 希望瞭解的更深，可以看看這篇文章：The First Few Milliseconds of an HTTPS Connection 非常詳細的介紹了整個過程。文章結尾還有一個小程式描述整個 SSL 握手的過程。

————-

參考文獻：

The TLS Protocol Version 1。0

Transport Layer Security （TLS） Extensions

The First Few Milliseconds of an HTTPS Connection

Understanding SSL\HTTPS

HTTPS and the TLS handshake protocol。

RSA演算法原理（一） - 阮一峰的網路日誌

RSA演算法原理（二） - 阮一峰的網路日誌