聊聊HTTPS和SSL/TLS協議

本文轉自：http://www.techug.com/post/https-ssl-tls.html

 

要說清楚 HTTPS 協議的實現原理，至少須要以下幾個背景知識。
1. 大體瞭解幾個基本術語（HTTPS、SSL、TLS）的含義
2. 大體瞭解 HTTP 和 TCP 的關係（尤爲是「短鏈接」VS「長鏈接」）
3. 大體瞭解加密算法的概念（尤爲是「對稱加密與非對稱加密」的區別）
4. 大體瞭解 CA 證書的用途

考慮到不少技術菜鳥可能不瞭解上述背景，俺先用最簡短的文字描述一下。若是你自認爲不是菜鳥，請略過本章節，直接去看「HTTPS 協議的需求」。

先澄清幾個術語——HTTPS、SSL、TLS

1. 「HTTP」是幹嗎用滴？

首先，HTTP 是一個網絡協議，是專門用來幫你傳輸 Web 內容滴。關於這個協議，就算你不瞭解，至少也據說過吧？好比你訪問俺的博客的主頁，瀏覽器地址欄會出現以下的網址

http://www.techug.com/

俺加了粗體的部分就是指 HTTP 協議。大部分網站都是經過 HTTP 協議來傳輸 Web 頁面、以及 Web 頁面上包含的各類東東（圖片、CSS 樣式、JS 腳本）。

2. 「SSL/TLS」是幹嗎用滴？

SSL 是洋文「Secure Sockets Layer」的縮寫，中文叫作「安全套接層」。它是在上世紀90年代中期，由網景公司設計的。（順便插一句，網景公司不光發明了 SSL，還發明瞭不少 Web 的基礎設施——好比「CSS 樣式表」和「JS 腳本」）
爲啥要發明 SSL 這個協議捏？由於原先互聯網上使用的 HTTP 協議是明文的，存在不少缺點——好比傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是爲了解決這些問題。
到了1999年，SSL 由於應用普遍，已經成爲互聯網上的事實標準。IETF 就在那年把 SSL 標準化。標準化以後的名稱改成 TLS（是「Transport Layer Security」的縮寫），中文叫作「傳輸層安全協議」。
不少相關的文章都把這二者並列稱呼（SSL/TLS），由於這二者能夠視做同一個東西的不一樣階段。

3. 「HTTPS」是啥意思？

解釋完 HTTP 和 SSL/TLS，如今就能夠來解釋 HTTPS 啦。我們一般所說的 HTTPS 協議，說白了就是「HTTP 協議」和「SSL/TLS 協議」的組合。你能夠把 HTTPS 大體理解爲——「HTTP over SSL」或「HTTP over TLS」（反正 SSL 和 TLS 差很少）。

再來講說 HTTP 協議的特色

做爲背景知識介紹，還須要再稍微談一下 HTTP 協議自己的特色。HTTP 自己有不少特色，考慮到篇幅有限，俺只談那些和 HTTPS 相關的特色。

1. HTTP 的版本和歷史

現在我們用的 HTTP 協議，版本號是 1.1（也就是 HTTP 1.1）。這個 1.1 版本是1995年末開始起草的（技術文檔是 RFC2068），並在1999年正式發佈（技術文檔是 RFC2616）。
在 1.1 以前，還有曾經出現過兩個版本「0.9 和 1.0」，其中的 HTTP 0.9 【沒有】被普遍使用，而 HTTP 1.0 被普遍使用過。
另外，聽說明年（2015）IETF 就要發佈 HTTP 2.0 的標準了。俺拭目以待。

2. HTTP 和 TCP 之間的關係

簡單地說，TCP 協議是 HTTP 協議的基石——HTTP 協議須要依靠 TCP 協議來傳輸數據。

在網絡分層模型中，TCP 被稱爲「傳輸層協議」，而 HTTP 被稱爲「應用層協議」。

有不少常見的應用層協議是以 TCP 爲基礎的，好比「FTP、SMTP、POP、IMAP」等。
TCP 被稱爲「面向鏈接」的傳輸層協議。關於它的具體細節，俺就不展開了（不然篇幅又失控了）。你只需知道：傳輸層主要有兩個協議，分別是 TCP 和 UDP。TCP 比 UDP 更可靠。你能夠把 TCP 協議想象成某個水管，發送端這頭進水，接收端那頭就出水。而且 TCP 協議可以確保，先發送的數據先到達（與之相反，UDP 不保證這點）。

3. HTTP 協議如何使用 TCP 鏈接？

HTTP 對 TCP 鏈接的使用，分爲兩種方式：俗稱「短鏈接」和「長鏈接」（「長鏈接」又稱「持久鏈接」，洋文叫作「Keep-Alive」或「Persistent Connection」）
假設有一個網頁，裏面包含好多圖片，還包含好多【外部的】CSS 文件和 JS 文件。在「短鏈接」的模式下，瀏覽器會先發起一個 TCP 鏈接，拿到該網頁的 HTML 源代碼（拿到 HTML 以後，這個 TCP 鏈接就關閉了）。而後，瀏覽器開始分析這個網頁的源碼，知道這個頁面包含不少外部資源（圖片、CSS、JS）。而後針對【每個】外部資源，再分別發起一個個 TCP 鏈接，把這些文件獲取到本地（一樣的，每抓取一個外部資源後，相應的 TCP 就斷開）
相反，若是是「長鏈接」的方式，瀏覽器也會先發起一個 TCP 鏈接去抓取頁面。可是抓取頁面以後，該 TCP 鏈接並不會當即關閉，而是暫時先保持着（所謂的「Keep-Alive」）。而後瀏覽器分析 HTML 源碼以後，發現有不少外部資源，就用剛纔那個 TCP 鏈接去抓取此頁面的外部資源。

在 HTTP 1.0 版本，【默認】使用的是「短鏈接」（那時候是 Web 誕生初期，網頁相對簡單，「短鏈接」的問題不大）；
到了1995年末開始制定 HTTP 1.1 草案的時候，網頁已經開始變得複雜（網頁內的圖片、腳本愈來愈多了）。這時候再用短鏈接的方式，效率過低下了（由於創建 TCP 鏈接是有「時間成本」和「CPU 成本」滴）。因此，在 HTTP 1.1 中，【默認】採用的是「Keep-Alive」的方式。
關於「Keep-Alive」的更多介紹，能夠參見維基百科詞條（在「這裏」）

談談「對稱加密」和「非對稱加密」的概念

1. 啥是「加密」和「解密」？

通俗而言，你能夠把「加密」和「解密」理解爲某種【互逆的】數學運算。就比如「加法和減法」互爲逆運算、「乘法和除法」互爲逆運算。
「加密」的過程，就是把「明文」變成「密文」的過程；反之，「解密」的過程，就是把「密文」變爲「明文」。在這兩個過程當中，都須要一個關鍵的東東——叫作「密鑰」——來參與數學運算。

2. 啥是「對稱加密」？

所謂的「對稱加密技術」，意思就是說：「加密」和「解密」使用【相同的】密鑰。這個比較好理解。就比如你用 7zip 或 WinRAR 建立一個帶密碼（口令）的加密壓縮包。當你下次要把這個壓縮文件解開的時候，你須要輸入【一樣的】密碼。在這個例子中，密碼/口令就如同剛纔說的「密鑰」。

3. 啥是「非對稱加密」？

所謂的「非對稱加密技術」，意思就是說：「加密」和「解密」使用【不一樣的】密鑰。這玩意兒比較難理解，也比較難想到。當年「非對稱加密」的發明，還被譽爲「密碼學」歷史上的一次革命。
因爲篇幅有限，對「非對稱加密」這個話題，俺就不展開了。有空的話，再單獨寫一篇掃盲。

4. 各自有啥優缺點？

看完剛纔的定義，很顯然：（從功能角度而言）「非對稱加密」能幹的事情比「對稱加密」要多。這是「非對稱加密」的優勢。可是「非對稱加密」的實現，一般須要涉及到「複雜數學問題」。因此，「非對稱加密」的性能一般要差不少（相對於「對稱加密」而言）。
這二者的優缺點，也影響到了 SSL 協議的設計。

CA 證書的原理及用途

關於這方面，請看俺4年前寫的《數字證書及CA的掃盲介紹》。這裏就再也不重複嘮叨了，省得篇幅太長。

HTTPS 協議的需求是啥？

花了好多口水，終於把背景知識說完了。下面正式進入正題。先來講說當初設計 HTTPS 是爲了知足哪些需求？
不少介紹 HTTPS 的文章一上來就給你講實現細節。我的以爲：這是很差的作法。早在2009年開博的時候，發過一篇《學習技術的三部曲：WHAT、HOW、WHY》，其中談到「WHY 型問題」的重要性。一上來就給你講協議細節，你充其量只能知道 WHAT 和 HOW，沒法理解 WHY。俺在前一個章節講了「背景知識」，在這個章節講了「需求」，這就有助於你理解：當初

爲何

要設計成這樣？——這就是 WHY 型的問題。

兼容性

由於是先有 HTTP 再有 HTTPS。因此，HTTPS 的設計者確定要考慮到對原有 HTTP 的兼容性。
這裏所說的兼容性包括不少方面。好比已有的 Web 應用要儘量無縫地遷移到 HTTPS；好比對瀏覽器廠商而言，改動要儘量小；……
基於「兼容性」方面的考慮，很容易得出以下幾個結論：
1. HTTPS 仍是要基於 TCP 來傳輸
（若是改成 UDP 做傳輸層，不管是 Web 服務端仍是瀏覽器客戶端，都要大改，動靜太大了）
2. 單獨使用一個新的協議，把 HTTP 協議包裹起來
（所謂的「HTTP over SSL」，其實是在原有的 HTTP 數據外面加了一層 SSL 的封裝。HTTP 協議原有的 GET、POST 之類的機制，基本上原封不動）

打個比方：若是原來的 HTTP 是塑料水管，容易被戳破；那麼現在新設計的 HTTPS 就像是在原有的塑料水管以外，再包一層金屬水管。一來，原有的塑料水管照樣運行；二來，用金屬加固了以後，不容易被戳破。

可擴展性

前面說了，HTTPS 至關因而「HTTP over SSL」。
若是 SSL 這個協議在「可擴展性」方面的設計足夠牛逼，那麼它除了能跟 HTTP 搭配，還可以跟其它的應用層協議搭配。豈不美哉？
如今看來，當初設計 SSL 的人確實比較牛。現在的 SSL/TLS 能夠跟不少經常使用的應用層協議（好比：FTP、SMTP、POP、Telnet）搭配，來強化這些應用層協議的安全性。

接着剛纔打的比方：若是把 SSL/TLS 視做一根用來加固的金屬管，它不只能夠用來加固輸水的管道，還能夠用來加固輸煤氣的管道。

保密性（防泄密）

HTTPS 須要作到足夠好的保密性。
說到保密性，首先要可以對抗嗅探（行話叫 Sniffer）。所謂的「嗅探」，通俗而言就是監視你的網絡傳輸流量。若是你使用明文的 HTTP 上網，那麼監視者經過嗅探，就知道你在訪問哪些網站的哪些頁面。
嗅探是最低級的攻擊手法。除了嗅探，HTTPS 還須要能對抗其它一些稍微高級的攻擊手法——好比「重放攻擊」（後面講協議原理的時候，會再聊）。

完整性（防篡改）

除了「保密性」，還有一個一樣重要的目標是「確保完整性」。關於「完整性」這個概念，在以前的博文《掃盲文件完整性校驗——關於散列值和數字簽名》中大體提過。健忘的同窗再去溫習一下。
在發明 HTTPS 以前，因爲 HTTP 是明文的，不但容易被嗅探，還容易被篡改。
舉個例子：
好比我們天朝的網絡運營商（ISP）都比較流氓，常常有網友抱怨說訪問某網站（原本是沒有廣告的），居然會跳出不少中國電信的廣告。爲啥會這樣捏？由於你的網絡流量須要通過 ISP 的線路才能到達公網。若是你使用的是明文的 HTTP，ISP 很容易就能夠在你訪問的頁面中植入廣告。
因此，當初設計 HTTPS 的時候，還有一個需求是「確保 HTTP 協議的內容不被篡改」。

真實性（防假冒）

在談到 HTTPS 的需求時，「真實性」常常被忽略。其實「真實性」的重要程度不亞於前面的「保密性」和「完整性」。
舉個例子：
你由於使用網銀，須要訪問該網銀的 Web 站點。那麼，你如何確保你訪問的網站確實是你想訪問的網站？（這話有點繞口令）
有些天真的同窗會說：經過看網址裏面的域名，來確保。爲啥說這樣的同窗是「天真的」？由於 DNS 系統自己是不可靠的（尤爲是在設計 SSL 的那個年代，連 DNSSEC 都還沒發明）。因爲 DNS 的不可靠（存在「域名欺騙」和「域名劫持」），你看到的網址裏面的域名【未必】是真實滴！
（不瞭解「域名欺騙」和「域名劫持」的同窗，能夠參見俺以前寫的《掃盲 DNS 原理，兼談「域名劫持」和「域名欺騙/域名污染」》）
因此，HTTPS 協議必須有某種機制來確保「真實性」的需求（至於如何確保，後面會細聊）。

性能

再來講最後一個需求——性能。引入 HTTPS 以後，【不能】致使性能變得太差。不然的話，誰還願意用？爲了確保性能，SSL 的設計者至少要考慮以下幾點：1. 如何選擇加密算法（「對稱」or「非對稱」）？2. 如何兼顧 HTTP 採用的「短鏈接」TCP 方式？（SSL 是在1995年以前開始設計的，那時候的 HTTP 版本仍是 1.0，默認使用的是「短鏈接」的 TCP 方式——默認不啓用 Keep-Alive）