淺談 HTTPS 和 SSL/TLS 協議的背景與基礎

linux.cn發表於2015-04-02

相關背景知識

要說清楚 HTTPS 協議的實現原理,至少需要如下幾個背景知識。

  1. 大致瞭解幾個基本術語(HTTPS、SSL、TLS)的含義
  2. 大致瞭解 HTTP 和 TCP 的關係(尤其是“短連線”VS“長連線”)
  3. 大致瞭解加密演算法的概念(尤其是“對稱加密與非對稱加密”的區別)
  4. 大致瞭解 CA 證書的用途

考慮到很多技術菜鳥可能不瞭解上述背景,俺先用最簡短的文字描述一下。如果你自認為不是菜鳥,請略過本章節,直接去看“HTTPS 協議的需求”。

淺談 HTTPS 和 SSL/TLS 協議的背景與基礎

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

1. “HTTP”是幹嘛用滴?

首先,HTTP 是一個網路協議,是專門用來幫你傳輸 Web 內容滴。關於這個協議,就算你不瞭解,至少也聽說過吧?比如你訪問俺的部落格的主頁,瀏覽器位址列會出現如下的網址 http://program-think.blogspot.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)

小結

以上就是設計 SSL 協議時,必須兼顧的各種需求。後面聊協議的實現時,俺會拿 SSL 協議的特點跟前面的需求作對照。看看這些需求是如何一一滿足滴。

設計 HTTPS 協議的主要難點

設計 HTTPS 這個協議,有好幾個難點。俺個人認為最大的難點在於“金鑰交換”。

在傳統的密碼學場景中,假如張三要跟李四建立一個加密通訊的渠道,雙方事先要約定好使用哪種加密演算法?同時也要約定好使用的金鑰是啥?在這個場景中,加密演算法的【型別】讓旁人知道,沒太大關係。但是金鑰【千萬不能】讓旁人知道。一旦旁人知道了金鑰,自然就可以破解通訊的密文,得到明文。

好,現在回到 HTTPS 的場景。

當你訪問某個公網的網站,你的瀏覽器和網站的伺服器之間,如果要建立加密通訊,必然要商量好雙方使用啥演算法,啥金鑰。——在網路通訊術語中,這個過程稱之為“握手/handshake”。在握手階段,因為加密方式還沒有協商好,所以握手階段的通訊必定是【明文】滴!既然是明文,自然有可能被第三方偷窺到。然後,還要考慮到雙方之間隔著一個網際網路,什麼樣的偷窺都可能發生。

因此,在握手的過程中,如何做到安全地交換金鑰資訊,而不讓周圍的第三方看到。這就是設計 HTTPS 最大的難點。

結尾

本文費這麼多口水,來介紹 HTTPS 的“需求”和“難點”,為啥捏?因為只有當你瞭解這些,後面介紹 SSL/TLS 的實現原理時,你才能理解——當初為啥要把協議設計成這個樣子。

相關文章