剖析 HTTPS 的設計思路

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer ，安全的超文本傳輸協議），是以安全爲目標的HTTP通道。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。這個系統的最初研發由 Netscape 進行。

現在，HTTPS 已經漸漸成爲主流，不少大型網站都已經全站 HTTPS 化。那麼有了 HTTP 後爲何還須要有 HTTPS 呢？——爲了解決 HTTP 的不足。

HTTP 的不足之處

• 通訊內容使用明文——內容可能被竊聽
• 不驗證通訊方的身份——可能遭遇假裝
• 沒法驗證報文的完整性——報文有可能已遭篡改

如今來看看通常的明文通訊都存在什麼問題。

使用明文傳輸內容存在的問題

在理想的信息流動狀況下，信息可以安全達到目的地且未受到任何攻擊。

咱們平時生活中所說的「攻擊」，更多地有」主動「的意義。可是這裏的攻擊，囊括了主動和被動兩層意義。根據 ITU-T 的 X.800 推薦標準（OSI 安全框架），攻擊分爲如下幾類：

• 被動攻擊
  • 竊聽：一個非受權方介入系統的攻擊，獲取了傳輸的信息，破壞保密性。
  • 流量攻擊：監聽流量來判斷通訊的性質。
• 主動攻擊
  • 假裝/冒充：個實體僞裝成另一個實體。
  • 僞造/篡改：將僞造的客體插入系統中，破壞真實性。
  • 重放：獲取有效數據段以重播的方式獲取對方信任。
  • DoS / DDoS：致使合法用戶不可以訪問正常網絡服務的行爲都算是拒絕服務攻擊。

通常的明文網絡訪問，沒法防止上面所述的攻擊方式。經過應用密碼學的知識，通常能夠阻止上面多數的攻擊。（可是密碼學對流量攻擊、重放和 (D)DoS 還作不了太多。防止重放攻擊還須要在更高的應用層作一些處理。）

下面，咱們用密碼學來解決它能夠解決的風險：

1. 竊聽風險：黑客能夠獲知通訊內容。 —— 保證數據的隱私性
2. 篡改風險：黑客能夠修改通訊內容。 —— 保證數據的完整性
3. 冒充風險：黑客能夠冒充他人身份參與通訊。 —— 保證身份正確。

解決竊聽風險：加密

一、對稱加密 。有流式、分組兩種，加密和解密都是使用的同一個密鑰。 例如：DES、AES 等

二、非對稱加密 。加密使用的密鑰和解密使用的密鑰是不相同的，分別稱爲：公鑰、私鑰，公鑰和算法都是公開的，私鑰是保密的。非對稱加密算法性能低，可是安全性超強，因爲其加密特性，非對稱加密算法能加密的數據長度也是有限的。 例如：RSA、DSA。

非對稱加密是最安全的。可是在頻繁大量的網絡數據傳輸過程當中，非對稱加密算法的性能限制會成爲整個系統的瓶頸。若是須要長時間且頻繁地傳輸信息，全程使用非對稱加密是萬萬不能夠的。

Client->Server:  I want to talk with you.
Server->Client:  It's my public key.
Client->Server:  Message encoded by public key.
Note: The hacker knows nothing.
Note: Server knows this messgae.
複製代碼

只要算法和密鑰選擇得當，使用對稱加密算法能夠獲得一樣安全的加密效果。可是使用對稱加密密鑰也有它本身的問題：通訊雙方如何商定出密鑰。通訊雙方共享同一個對稱密鑰，若是雙方已經知道這一密鑰，以後的信息使用這一密鑰進行加密徹底沒有問題。 可是，不一樣的客戶端、服務器數量龐大，因此雙方都須要維護大量的密鑰，維護成本很高，密鑰極易泄露。所以，對稱密鑰必須動態生成。但問題就在於，密鑰如何安全的分享出去。密鑰鑰若是泄漏，加密就失去了意義。

咱們能夠將對稱加密和非對稱加密聯合起來來解決這個問題。

對於沒有見過面的雙方，第一次請求通訊的時候，S 先發出本身的公鑰，C 記下 S 的公鑰。以後 S 和 C 協商得出一個對稱密鑰。由於是通訊非對稱加密後的，監聽者僅憑他們之間的通訊內容是難以破譯出它們協商出的對稱密鑰的。以後，S、C 使用對稱密鑰進行正式的通訊，監聽者不知道他們的密鑰，因此也沒法破譯他們之間的通訊內容。

看起來很完美。

如何防止中間人：認證

考慮下面的狀況：中間人代理了 S、C 之間的全部流量。

C -> H: 請求公鑰
H -> S: 請求公鑰
S -> H: 返回真實公鑰
Note: 僞造密鑰對
H -> C: 返回僞造的公鑰
Note: 用僞造公鑰加密明文
C -> H: 密文
Note: 解密獲得明文
Note: 用真實公鑰加密明文
H -> S: 密文
Note: 用私鑰解密得明文
Note: 無感知
Note: 無感知
複製代碼

中間人經過僞造公鑰私鑰對，假裝成 S，同時 C、S 雙方對此毫無感知。其實即便不僞造密鑰對，只要中間人監聽到了公鑰，就足以把 S 發給 C 的消息給解密出來。這裏的問題是：如何確認 」S「 是真實的而不是中間人 」H「，如何保證公鑰的準確 。

爲了保證公鑰的真實性，引入了認證這一手段。

數字簽名

數字簽名基於公鑰私鑰體制，將一段文本經過哈希（hash）和私鑰加密處理後生成數字簽名。接收者用發送者的公共密鑰對簽名解密，並將之與收到的信息「指紋」進行比較，以肯定其真實性。只要簽名者的私鑰不被泄漏，數字簽名就是可信的。

+---------------------+
| A digital signature |            +---------+              +--------+
|(not to be confused  |----Hash--->| 消息摘要 |---私鑰加密--->| 數字簽名 |
|with a digital       |            +---------+              +--------+
+---------------------+
複製代碼

數字證書

數字證書，是由一個官方的證書頒發機構（CA）簽發的一組數據。這種證書很難僞造，用於使用者的身份證實。

數字證書包含如下內容：

• 對象名稱（人、服務器、組織、公司等）
• 對象的公開密鑰
• 其它擴展信息
• = = = = = = = = = = = = = = = = = = = = =
• 附上證書頒發機構的數字簽名

使用證書，正常的通訊流程是這樣子的：

1. S 會把本身的數字證書下發給 C

2. C 經過證書中「證書頒發機構的數字簽名」來驗證證書的來源和完整性。

   具體作法是使用 CA 的公鑰解密並對比。

3. 一旦證書被認證經過，C 就從證書中取出 「對象的公開密鑰」，以後就用這個公鑰來加密數據。

CA 的私鑰僅它本身知道，所以黑客沒法僞造 CA 的簽名，也不能獲得合法的證書。只要證書認證經過，它的公鑰就是可信的。

到這裏，這整個過程纔算是無懈可擊的。

HTTPS 具體是怎麼作的

HTTPS 的通訊過程和上面描述的基本一致。

-> 客戶端向服務端發送請求
-> 服務端返回數字證書
-> 客戶端用本身的CA[主流的CA機構證書通常都內置在各個主流瀏覽器中]公鑰去解密證書,若是證書有問題會提示風險
-> 若是證書沒問題客戶端會生成一個對稱加密的隨機祕鑰而後再和剛剛解密的服務器端的公鑰對數據進行加密,而後發送給服務器端
-> 服務器端收到之後會用本身的私鑰對客戶端發來的對稱祕鑰進行解密
-> 以後雙方就拿着這個對稱加密祕鑰來進行正常的通訊`
複製代碼

整個過程當中，HTTPS 證書使用的是 X.509 證書標準。

X.509 是密碼學裏公鑰證書的格式標準。 X.509 證書己應用在包括TLS/SSL 在內的衆多網絡協議裏。

X.509 是由國際電信聯盟（ITU-T）制定的數字證書標準。爲了提供公用網絡用戶目錄信息服務， ITU 於 1988 年制定了 X.500 系列標準。其中 X.500 和 X.509 是安全認證系統的核心， X.500 定義了一種區別命名規則，以命名樹來確保用戶名稱的惟一性； X.509 則爲 X.500 用戶名稱提供了通訊實體鑑別機制，並規定了實體鑑別過程當中普遍適用的證書語法和數據接口， X.509 稱之爲證書。

HTTPS協議使用的是 SSL 證書，它聽從了 X.509 標準。

• 證書格式版本號
• 證書序列號
• 過時時間
• 證書辦法機構
• 證書使用的簽名算法
• 過時時間
• 對象名稱（人、服務器、組織、公司等）
• 對象的公開密鑰
• 其它擴展信息
• = = = = = = = = = = = = = = = = = = = = =
• 附上證書頒發機構的數字簽名

在瀏覽器中，查看證書內容很是容易。

X.509 證書的信任鏈

到如今，還有一個問題沒有被解決。使用證書認證的前提是 C 知道 S 的公鑰，但是S 的公鑰不能在不安全的網絡中直接發送給 C。

此時就引入了證書頒發機構（Certificate Authority，簡稱CA），世界上CA數量並很少。C 預先擁有全部受信任CA的證書。若是 S 想要一個證書，它先向 CA 申請，CA 使用它本身的私鑰對 S 的證書進行簽名。接下來，C 和 S 要相互通訊的時候，S 將它的證書發給 C。 C 擁有全部 CA 的可信公鑰，因此 C 能夠驗證證書的真實性。

如此一來，C 信任 CA，CA信任 S 使得 C 信任 S，信任鏈（Chain Of Trust）就是這樣造成的。

事實上，客戶端 C 內置的是 CA的根證書(Root Certificate)，HTTPS協議中服務器會發送證書鏈（Certificate Chain）給客戶端。

如上圖，「Wikipedia」的證書的證書鏈以下。這裏，C 必定是信任 根證書 Root CA 的，因而 C 最終信任 "Wikimedia Foundation, Inc" 。這裏有一個細節，根證書是由根證書本身來簽名和頒發的。

證書	證書頒發者
GlobalSign Root CA（根證書）	GlobalSign Root CA（自簽名）
GlobalSign Organization Validation CA - SHA256 - G2	GlobalSign Root CA
"Wikimedia Foundation, Inc."	GlobalSign Organization Validation CA

最終，C 只要內置世界上僅有的幾個根證書就能夠自行校驗全部的 HTTPS 證書了。S 的證書必須通過某一個 CA 的簽名。可是如今的操做系統和瀏覽器也容許用戶自行添加本身的根證書。例如 12306.cn 曾經要求用戶自行下載安裝指定的根證書。

從下圖能夠看到，根證書 「GlobalSign Root CA」 早已經內置到系統內部了。

結語

使用密碼學理論，客戶端和服務器之間實現了信息的保密傳輸。密碼學中對稱加密、非對稱加密和哈希函數在整個通訊創建的過程當中都發揮了做用，而且都缺一不可。密碼學的理論知識已經成爲安全通訊的理論基礎。

如今 HTTPS 已經被普遍運用到各大網站中，它已經成爲咱們平常中用到的技術，而咱們對此並無太大的感知。密碼學提供了不少已經被咱們視爲理所固然的工具，咱們使用的大多數安全通訊工具都仰仗於它。