詳談 HTTPS SSL/TLS 協(xié)議原理

協(xié)議安全和加密越來越引起人們的重視和關(guān)注，今天就跟大家分享一點(diǎn)協(xié)議加密方面的知識。要說清楚 HTTPS 協(xié)議的實(shí)現(xiàn)原理，至少需要如下幾個(gè)背景知識。

• 大致了解幾個(gè)基本術(shù)語(HTTPS、SSL、TLS)的含義

• 大致了解 HTTP 和 TCP 的關(guān)系(尤其是 “短連接”VS“長連接”)

• 大致了解加密算法的概念(尤其是 “對稱加密與非對稱加密” 的區(qū)別)

• 大致了解 CA 證書的用途

一、先澄清幾個(gè)術(shù)語——HTTPS、SSL、TLS。

1. “HTTP” 是干嘛用滴？

首先，HTTP 是一個(gè)網(wǎng)絡(luò)協(xié)議，是專門用來幫你傳輸 Web 內(nèi)容滴。關(guān)于這個(gè)協(xié)議，就算你不了解，至少也聽說過吧？比如你訪問俺的博客的主頁，瀏覽器地址欄會出現(xiàn)如下的網(wǎng)址http://www.xxx.com/

俺加了粗體的部分就是指 HTTP 協(xié)議。大部分網(wǎng)站都是通過 HTTP 協(xié)議來傳輸 Web 頁面、以及 Web 頁面上包含的各種東東(圖片、CSS 樣式、JS 腳本)。

2. “SSL/TLS” 是干嘛用滴？

SSL 是洋文 “Secure Sockets Layer” 的縮寫，中文叫做 “安全套接層”。它是在上世紀(jì) 90 年代中期，由網(wǎng)景公司設(shè)計(jì)的。(順便插一句，網(wǎng)景公司不光發(fā)明了 SSL，還發(fā)明了很多 Web 的基礎(chǔ)設(shè)施——比如“CSS 樣式表” 和“JS 腳本”) 為啥要發(fā)明 SSL 這個(gè)協(xié)議捏？因?yàn)樵然ヂ?lián)網(wǎng)上使用的 HTTP 協(xié)議是明文的，存在很多缺點(diǎn)——比如傳輸內(nèi)容會被偷窺(嗅探)和篡改。發(fā)明 SSL 協(xié)議，就是為了解決這些問題。

到了 1999 年，SSL 因?yàn)閼?yīng)用廣泛，已經(jīng)成為互聯(lián)網(wǎng)上的事實(shí)標(biāo)準(zhǔn)。IETF 就在那年把 SSL 標(biāo)準(zhǔn)化。標(biāo)準(zhǔn)化之后的名稱改為 TLS(是 “Transport Layer Security” 的縮寫)，中文叫做“傳輸層安全協(xié)議”。

很多相關(guān)的文章都把這兩者并列稱呼(SSL/TLS)，因?yàn)檫@兩者可以視作同一個(gè)東西的不同階段。

3. “HTTPS” 是啥意思？

解釋完 HTTP 和 SSL/TLS，現(xiàn)在就可以來解釋 HTTPS 啦。咱們通常所說的 HTTPS 協(xié)議，說白了就是 “HTTP 協(xié)議” 和“SSL/TLS 協(xié)議”的組合。你可以把 HTTPS 大致理解為——“HTTP over SSL”或“HTTP over TLS”(反正 SSL 和 TLS 差不多)。

二、再來說說 HTTP 協(xié)議的特點(diǎn)

作為背景知識介紹，還需要再稍微談一下 HTTP 協(xié)議本身的特點(diǎn)。HTTP 本身有很多特點(diǎn)，考慮到篇幅有限，俺只談那些和 HTTPS 相關(guān)的特點(diǎn)。

1. HTTP 的版本和歷史

如今咱們用的 HTTP 協(xié)議，版本號是 1.1(也就是 HTTP 1.1)。這個(gè) 1.1 版本是 1995 年底開始起草的(技術(shù)文檔是 RFC2068)，并在 1999 年正式發(fā)布(技術(shù)文檔是 RFC2616)。

在 1.1 之前，還有曾經(jīng)出現(xiàn)過兩個(gè)版本 “0.9 和 1.0”，其中的 HTTP 0.9 沒有被廣泛使用，而 HTTP 1.0 被廣泛使用過。另外，2015年IETF 就要發(fā)布 HTTP 2.0 的標(biāo)準(zhǔn)了。

2. HTTP 和 TCP 之間的關(guān)系

簡單地說，TCP 協(xié)議是 HTTP 協(xié)議的基石——HTTP 協(xié)議需要依靠 TCP 協(xié)議來傳輸數(shù)據(jù)。在網(wǎng)絡(luò)分層模型中，TCP 被稱為 “傳輸層協(xié)議”，而 HTTP 被稱為 “應(yīng)用層協(xié)議”。

有很多常見的應(yīng)用層協(xié)議是以 TCP 為基礎(chǔ)的，比如 “FTP、SMTP、POP、IMAP” 等。

TCP 被稱為 “面向連接” 的傳輸層協(xié)議。關(guān)于它的具體細(xì)節(jié)，俺就不展開了(否則篇幅又失控了)。你只需知道：傳輸層主要有兩個(gè)協(xié)議，分別是 TCP 和 UDP。TCP 比 UDP 更可靠。你可以把 TCP 協(xié)議想象成某個(gè)水管，發(fā)送端這頭進(jìn)水，接收端那頭就出水。并且 TCP 協(xié)議能夠確保，先發(fā)送的數(shù)據(jù)先到達(dá)(與之相反，UDP 不保證這點(diǎn))。

3. HTTP 協(xié)議如何使用 TCP 連接？

HTTP 對 TCP 連接的使用，分為兩種方式：俗稱 “短連接” 和“長連接”(“長連接”又稱 “持久連接”，洋文叫做“Keep-Alive” 或“Persistent Connection”) 假設(shè)有一個(gè)網(wǎng)頁，里面包含好多圖片，還包含好多外部的CSS 文件和 JS 文件。在 “短連接” 的模式下，瀏覽器會先發(fā)起一個(gè) TCP 連接，拿到該網(wǎng)頁的 HTML 源代碼(拿到 HTML 之后，這個(gè) TCP 連接就關(guān)閉了)。然后，瀏覽器開始分析這個(gè)網(wǎng)頁的源碼，知道這個(gè)頁面包含很多外部資源(圖片、CSS、JS)。

然后針對每一個(gè)外部資源，再分別發(fā)起一個(gè)個(gè) TCP 連接，把這些文件獲取到本地(同樣的，每抓取一個(gè)外部資源后，相應(yīng)的 TCP 就斷開) 相反，如果是 “長連接” 的方式，瀏覽器也會先發(fā)起一個(gè) TCP 連接去抓取頁面。但是抓取頁面之后，該 TCP 連接并不會立即關(guān)閉，而是暫時(shí)先保持著(所謂的“Keep-Alive”)。然后瀏覽器分析 HTML 源碼之后，發(fā)現(xiàn)有很多外部資源，就用剛才那個(gè) TCP 連接去抓取此頁面的外部資源。

在 HTTP 1.0 版本，默認(rèn)使用的是 “短連接”(那時(shí)候是 Web 誕生初期，網(wǎng)頁相對簡單，“短連接” 的問題不大)；到了 1995 年底開始制定 HTTP 1.1 草案的時(shí)候，網(wǎng)頁已經(jīng)開始變得復(fù)雜(網(wǎng)頁內(nèi)的圖片、腳本越來越多了)。這時(shí)候再用短連接的方式，效率太低下了(因?yàn)榻?TCP 連接是有 “時(shí)間成本” 和“CPU 成本”滴)。

所以，在 HTTP 1.1 中，默認(rèn)采用的是 “Keep-Alive” 的方式。關(guān)于 “Keep-Alive” 的更多介紹，可以參見維基百科詞條。

三、談?wù)?“對稱加密” 和“非對稱加密”的概念

1. 啥是 “加密” 和“解密”？

通俗而言，你可以把 “加密” 和“解密”理解為某種互逆的數(shù)學(xué)運(yùn)算。就好比 “加法和減法” 互為逆運(yùn)算、“乘法和除法”互為逆運(yùn)算。

“加密”的過程，就是把 “明文” 變成 “密文” 的過程；反之，“解密”的過程，就是把 “密文” 變?yōu)椤懊魑摹薄Ｔ谶@兩個(gè)過程中，都需要一個(gè)關(guān)鍵的東東——叫做“密鑰”——來參與數(shù)學(xué)運(yùn)算。

2. 啥是 “對稱加密”？

所謂的 “對稱加密技術(shù)”，意思就是說：“加密” 和“解密”使用相同的密鑰。這個(gè)比較好理解。就好比你用 7zip 或 WinRAR 創(chuàng)建一個(gè)帶密碼(口令)的加密壓縮包。當(dāng)你下次要把這個(gè)壓縮文件解開的時(shí)候，你需要輸入同樣的密碼。在這個(gè)例子中，密碼 / 口令就如同剛才說的“密鑰”。

3. 啥是 “非對稱加密”？

所謂的 “非對稱加密技術(shù)”，意思就是說：“加密” 和“解密”使用不同的密鑰。這玩意兒比較難理解，也比較難想到。當(dāng)年 “非對稱加密” 的發(fā)明，還被譽(yù)為 “密碼學(xué)” 歷史上的一次革命。

4. 各自有啥優(yōu)缺點(diǎn)？

看完剛才的定義，很顯然：(從功能角度而言)“非對稱加密”能干的事情比 “對稱加密” 要多。這是 “非對稱加密” 的優(yōu)點(diǎn)。但是 “非對稱加密” 的實(shí)現(xiàn)，通常需要涉及到 “復(fù)雜數(shù)學(xué)問題”。所以，“非對稱加密” 的性能通常要差很多(相對于 “對稱加密” 而言)。這兩者的優(yōu)缺點(diǎn)，也影響到了 SSL 協(xié)議的設(shè)計(jì)。

四、HTTPS 協(xié)議的需求是啥？

花了好多口水，終于把背景知識說完了。下面正式進(jìn)入正題。先來說說當(dāng)初設(shè)計(jì) HTTPS 是為了滿足哪些需求？

很多介紹 HTTPS 的文章一上來就給你講實(shí)現(xiàn)細(xì)節(jié)。個(gè)人覺得：這是不好的做法。早在 2009 年開博的時(shí)候，發(fā)過一篇<學(xué)習(xí)技術(shù)的三部曲：WHAT、HOW、WHY>，其中談到 “WHY 型問題” 的重要性。一上來就給你講協(xié)議細(xì)節(jié)，你充其量只能知道 WHAT 和 HOW，無法理解 WHY。

俺在前一個(gè)章節(jié)講了“背景知識”，在這個(gè)章節(jié)講了“需求”，這就有助于你理解：當(dāng)初為什么要設(shè)計(jì)成這樣？——這就是 WHY 型的問題。

兼容性

因?yàn)槭窍扔?HTTP 再有 HTTPS。所以，HTTPS 的設(shè)計(jì)者肯定要考慮到對原有 HTTP 的兼容性。這里所說的兼容性包括很多方面。比如已有的 Web 應(yīng)用要盡可能無縫地遷移到 HTTPS；比如對瀏覽器廠商而言，改動要盡可能小；基于 “兼容性” 方面的考慮，很容易得出如下幾個(gè)結(jié)論:

• HTTPS 還是要基于 TCP 來傳輸(如果改為 UDP 作傳輸層，無論是 Web 服務(wù)端還是瀏覽器客戶端，都要大改，動靜太大了)。

• 單獨(dú)使用一個(gè)新的協(xié)議，把 HTTP 協(xié)議包裹起來 (所謂的 “HTTP over SSL”，實(shí)際上是在原有的 HTTP 數(shù)據(jù)外面加了一層 SSL 的封裝。HTTP 協(xié)議原有的 GET、POST 之類的機(jī)制，基本上原封不動)。

• 打個(gè)比方：如果原來的 HTTP 是塑料水管，容易被戳破；那么如今新設(shè)計(jì)的 HTTPS 就像是在原有的塑料水管之外，再包一層金屬水管。一來，原有的塑料水管照樣運(yùn)行；二來，用金屬加固了之后，不容易被戳破。

可擴(kuò)展性

前面說了，HTTPS 相當(dāng)于是 “HTTP over SSL”。如果 SSL 這個(gè)協(xié)議在 “可擴(kuò)展性” 方面的設(shè)計(jì)足夠牛逼，那么它除了能跟 HTTP 搭配，還能夠跟其它的應(yīng)用層協(xié)議搭配。豈不美哉？

現(xiàn)在看來，當(dāng)初設(shè)計(jì) SSL 的人確實(shí)比較牛。如今的 SSL/TLS 可以跟很多常用的應(yīng)用層協(xié)議(比如: FTP、SMTP、POP、Telnet)搭配，來強(qiáng)化這些應(yīng)用層協(xié)議的安全性。

接著剛才打的比方： 如果把 SSL/TLS 視作一根用來加固的金屬管，它不僅可以用來加固輸水的管道，還可以用來加固輸煤氣的管道。

保密性

HTTPS 需要做到足夠好的保密性。說到保密性，首先要能夠?qū)剐崽?行話叫 Sniffer)。所謂的 “嗅探”，通俗而言就是監(jiān)視你的網(wǎng)絡(luò)傳輸流量。如果你使用明文的 HTTP 上網(wǎng)，那么監(jiān)視者通過嗅探，就知道你在訪問哪些網(wǎng)站的哪些頁面。

嗅探是最低級的攻擊手法。除了嗅探，HTTPS 還需要能對抗其它一些稍微高級的攻擊手法——比如 “重放攻擊”。

完整性

除了 “保密性”，還有一個(gè)同樣重要的目標(biāo)是“確保完整性”。關(guān)于“完整性” 這個(gè)概念，在之前的博文<掃盲文件完整性校驗(yàn)——關(guān)于散列值和數(shù)字簽名>中大致提過。健忘的同學(xué)再去溫習(xí)一下。在發(fā)明 HTTPS 之前，由于 HTTP 是明文的，不但容易被嗅探，還容易被篡改。

舉個(gè)例子： 比如咱們天朝的網(wǎng)絡(luò)運(yùn)營商都比較流氓，經(jīng)常有網(wǎng)友抱怨說訪問某網(wǎng)站(本來是沒有廣告的)，竟然會跳出很多廣告。為啥會這樣捏？因?yàn)槟愕木W(wǎng)絡(luò)流量需要經(jīng)過 ISP 的線路才能到達(dá)公網(wǎng)。如果你使用的是明文的 HTTP，ISP 很容易就可以在你訪問的頁面中植入廣告。所以，當(dāng)初設(shè)計(jì) HTTPS 的時(shí)候，還有一個(gè)需求是 “確保 HTTP 協(xié)議的內(nèi)容不被篡改”。

真實(shí)性

在談到 HTTPS 的需求時(shí)，“真實(shí)性”經(jīng)常被忽略。其實(shí) “真實(shí)性” 的重要程度不亞于前面的 “保密性” 和“完整性”。

舉個(gè)例子： 你因?yàn)槭褂镁W(wǎng)銀，需要訪問該網(wǎng)銀的 Web 站點(diǎn)。那么，你如何確保你訪問的網(wǎng)站確實(shí)是你想訪問的網(wǎng)站？(這話有點(diǎn)繞口令) 有些天真的同學(xué)會說：通過看網(wǎng)址里面的域名來確保。

為啥說這樣的同學(xué)是 “天真的”？因?yàn)?DNS 系統(tǒng)本身是不可靠的(尤其是在設(shè)計(jì) SSL 的那個(gè)年代，連DNSSEC 都還沒發(fā)明)。由于DNS 的不可靠(存在“域名欺騙” 和“域名劫持”)，你看到的網(wǎng)址里面的域名未必是真實(shí)滴！所以，HTTPS 協(xié)議必須有某種機(jī)制來確保 “真實(shí)性” 的需求。

性能

再來說最后一個(gè)需求——性能。引入 HTTPS 之后，不能導(dǎo)致性能變得太差。否則的話，誰還愿意用？為了確保性能，SSL的設(shè)計(jì)者至少要考慮如下幾點(diǎn):

• 如何選擇加密算法(“對稱”or“非對稱”)？

• 如何兼顧 HTTP 采用的 “短連接”TCP 方式？

SSL 是在1995 年之前開始設(shè)計(jì)的，那時(shí)候的 HTTP 版本還是 1.0，默認(rèn)使用的是 “短連接” 的 TCP 方式——默認(rèn)不啟用 Keep-Alive)。

來源：朱小廝的博客