前言

HTTP 具有非常優(yōu)秀和方便的一面，然而，HTTP 并非一個安全的協(xié)議。大家平常瀏覽網(wǎng)頁的時候應(yīng)該也能注意到，使用 HTTP 協(xié)議的網(wǎng)站，瀏覽器都會認(rèn)定這是一個不安全的網(wǎng)站，提醒用戶注意防范（即便這是我們學(xué)校的選課系統(tǒng)）。

當(dāng)然，這個不安全的含義指的是你在該網(wǎng)頁輸入的信息可能會被外界攻擊者以非正常手段竊取，而不是說會被這個網(wǎng)頁的開發(fā)者獲取，畢竟瀏覽器咋能判斷這個網(wǎng)頁開發(fā)者是否存有異心，這個需要用戶自行判斷（手動滑稽 ????）

那么為了克服 HTTP 的缺點，確保 Web 的安全，HTTPS 就應(yīng)用而生了?？梢钥匆?#xff0c;使用 HTTPS 協(xié)議的網(wǎng)頁，地址欄前面都會有把小鎖，表示這是一個加密安全的網(wǎng)站，你的信息發(fā)送到此站點時是保密的。而且 Google、Baidu 等搜索引擎巨頭對于 HTTPS 網(wǎng)站都會給到更好的搜索排名。

本文會先解釋 HTTP 為什么是不安全的，然后講解 HTTPS 為了保證 Web 的安全提供了哪些手段，最后再揭曉謎底，為什么更安全的 HTTPS 協(xié)議在互聯(lián)網(wǎng)上沒有被全面采用。

?

1. 不安全的 HTTP

通過上面那張圖我們已經(jīng)知道，對于使用 HTTP 的網(wǎng)站，瀏覽器就會提醒我們請勿在此網(wǎng)站上輸入任何敏感信息，否則可能會被攻擊者竊取。沒錯，這就是 HTTP 協(xié)議不安全的表現(xiàn)，而且，僅僅是其中之一，HTTP 的不安全性體現(xiàn)在很多方面，例舉如下：

• 通信使用明文（不加密），內(nèi)容可能被「竊聽」

• 不驗證通信對方的身份，因此有可能遭遇「偽裝」

• 無法證明報文的完整性，所以有可能被「篡改」

?當(dāng)然，這些問題不僅在 HTTP 上出現(xiàn)，其他未加密的協(xié)議中也存在類似問題?

下面我們詳細(xì)分析下上述問題出現(xiàn)的原因。

① 內(nèi)容被竊聽

所謂互聯(lián)網(wǎng)，是由能連接到全世界的網(wǎng)絡(luò)組成的，萬物互聯(lián)，無論世界哪個角落的服務(wù)器在和客戶端進行通信時，在此通信線路上的網(wǎng)絡(luò)設(shè)備、光纜、計算機都可能會遭到惡意窺視行為。也就是說，互聯(lián)網(wǎng)上的任何角落都存在通信內(nèi)容被竊聽的風(fēng)險。

而由于 「HTTP 本身不具備加密的功能」，所以也無法做到對 HTTP 請求和響應(yīng)報文進行加密。

但是！「即使是加密過的通信內(nèi)容，也會被窺視到，這點和未加密的通信是相同的」。只能說經(jīng)過加密后的內(nèi)容，即便被攻擊者窺視到，他也可能無法破解其中的含義罷了，但是加密處理后的報文信息本身還是會被看到的，這點大家不要混淆了。加密后的內(nèi)容尚且如此，更別說未加密的了。

② 身份被偽裝

「HTTP 的請求和響應(yīng)不會對通信方進行確認(rèn)」，也就是說任何人都可以發(fā)起請求，而服務(wù)器對請求者來者不拒，只要接收到請求，就會返回一個響應(yīng)。

顯然，正是由于 HTTP 的這種簡單性，導(dǎo)致了如下隱患：

1）客戶端發(fā)送的 HTTP 請求報文可能到達(dá)的并非真正的目的服務(wù)器，可能是已偽裝的服務(wù)器

2）服務(wù)器返回的 HTTP 響應(yīng)報文可能也并沒有被正確的客戶端所接收，可能是已偽裝的客戶端

3）無法確定正在通信的對方是否具備訪問權(quán)限

4）無法判定請求來自何方，出自誰手

5）即使是無意義的請求也會照單全收

③ 報文被篡改

「HTTP 無法證明報文的完整性」，所謂完整性就是指信息的準(zhǔn)確度。若無法證明完整性，在 HTTP 請求或響應(yīng) 送出之后直到對方接收的這段時間內(nèi)，即使請求或響應(yīng)的內(nèi)容遭到攻擊者篡改，也沒有辦法獲悉。

通俗來說，「HTTP 沒有辦法確認(rèn)發(fā)送出去的請求和接收到的請求是否一致」。

舉個例子，你從某個使用 HTTP 的非正規(guī)網(wǎng)站上下載微信 APP，存放在服務(wù)器上的文件確實是微信 APP，但是，在你下載的過程當(dāng)中，攻擊者攻擊了這個網(wǎng)站，你正在傳輸?shù)奈募?nèi)容被篡改成了其他文件，而在這個過程中，你是完全察覺不到的。

像這樣的在請求或響應(yīng)在傳輸途中，遭受攻擊者攔截并篡改內(nèi)容的攻擊稱為「中間人攻擊」（Main-in-the-Middle attack, MITM）。

?

2. 安全的 HTTPS

HTTPS 協(xié)議并非應(yīng)用層的一個新協(xié)議，只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協(xié)議代替而已。

通常 HTTP 是直接和 TCP 進行通信的，當(dāng)使用 SSL 時，則演變成先和 SSL 通信，再由 SSL 和 TCP 進行通信。簡而言之。「所謂 HTTPS，就是身批 SSL 協(xié)議外殼的 HTTP」。

在采用 SSL 后，HTTP 就擁有了加密、證書和完整性保護等功能，而這些功能正是用來解決我們上述所說的 HTTP 不安全問題的。

另外，SSL 是獨立于 HTTP 協(xié)議的，所有運行在應(yīng)用層的協(xié)議都可以配合 SSL 協(xié)議使用?？梢哉f，SSL 協(xié)議是當(dāng)今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)。

那么，針對上述 HTTP 的三個安全性問題，我們來看看 HTTPS 或者說 SSL 到底提供了哪些解決方案。

① 加密

這個上文也提到了，既然無法阻止被竊聽，那么我就把我的內(nèi)容加密起來，讓你無法破解。那么，既然發(fā)送方對通信內(nèi)容進行了加密，接收方接收到這個被加密過的內(nèi)容，一定要知道對應(yīng)的解密手段。

在講解下述的幾種加密方法之前，我們先理解「密鑰」的概念。所謂密鑰，就是鑰匙，加密方有一把密鑰，用來上鎖，解密方也擁有一把密鑰，用來解鎖。而且加密方和解密方使用的密鑰不一定是同一把。

共享密鑰加密

「加密和解密使用同一密鑰」的方式稱為「共享密鑰加密」（Common Key crypto system），也稱做「對稱密鑰加密」（這個更好理解）。

「以共享密鑰加密時必須將密鑰也發(fā)送給對方」。顯然，如果通信雙方都各自持有同一個密鑰，且沒有別人知道，則兩方的通信安全是可以被保證的（除非密鑰被破解）。

那么，最大的問題就是如何保證這個密鑰的安全傳輸，不被外部攻擊者知道。如果由服務(wù)器生成一個密鑰并傳輸給瀏覽器，這個傳輸過程中密鑰被攻擊者劫持，那么之后攻擊者就能用這把密鑰解開雙方傳輸?shù)娜魏蝺?nèi)容。

發(fā)送密鑰就有被竊聽的危險，但不發(fā)送，對方就不能解密。怎么樣才能安全的發(fā)送密鑰？解決這個問題，我們就需要公開密鑰加密（非對稱密鑰加密）。

公開密鑰加密

公開密鑰加密很好的解決了共享密鑰加密的困難。

公開密鑰加密需要「一組非對稱的密鑰對」，分別是「公鑰」 public key 和「私鑰」 private key。顧名思義，公鑰可以隨意發(fā)布，任何人都可以獲得，而私鑰不能讓除通信雙方外的其他任何人知道。這兩個密鑰是成對出現(xiàn)的，「公鑰加密的內(nèi)容需要對應(yīng)的私鑰解密」。

舉個例子：客戶端（瀏覽器）想要給網(wǎng)站服務(wù)器發(fā)送消息

• 首先，網(wǎng)站服務(wù)器持有一組公鑰和私有，它會把自己的公鑰明文傳輸給客戶端

• 客戶端利用這個公鑰給自己的消息進行加密，然后傳輸給服務(wù)器，這時候就算被攻擊者截獲，由于攻擊者沒有對應(yīng)的私鑰也無法解密該內(nèi)容

• 網(wǎng)站服務(wù)器收到后，使用這個公鑰對應(yīng)的私鑰進行解密

利用這種方式，不需要發(fā)送解密需要的私鑰，也就不必?fù)?dān)心私鑰被攻擊者盜走

混合加密方式

上述公開密鑰加密的方式雖然安全，但是相比于不那么安全的共享密鑰加密方式來說，其處理速度要慢很多。HTTPS 綜合這兩種加密方式的優(yōu)勢，「使用共享密鑰加密要發(fā)送的信息，使用公開密鑰加密這個共享密鑰」，這樣就減少了公開加密的次數(shù)。舉個例子：

• 某網(wǎng)站服務(wù)器擁有一組用于公開密鑰加密的非對稱密鑰：公鑰 A1、私鑰 A2

• 瀏覽器向網(wǎng)站服務(wù)器請求，服務(wù)器把公鑰 A1 明文給傳輸瀏覽器

• 接收到這把公鑰 A1 后，瀏覽器隨機生成一個用于共享密鑰加密（對稱加密）的密鑰 X，用公鑰 A1 加密后傳給服務(wù)器。這個階段，即便被攻擊者截獲，由于攻擊者沒有對應(yīng)的私鑰也無法解密該內(nèi)容

• 服務(wù)器拿到后用對應(yīng)的私鑰 A2 解密得到密鑰 X（以上這些階段就是公開密鑰加密）

• 這樣雙方就都擁有密鑰 X 了，且別人無法知道它。之后雙方之間所有的數(shù)據(jù)傳輸都使用密鑰 X 進行加密和解密即可（這個階段就是共享密鑰加密）

② 數(shù)字證書

遺憾的是，上述混合加密的方式仍然還是有漏洞的。攻擊者（中間人）的確無法得到瀏覽器生成的對稱密鑰 X，這個密鑰本身被公鑰 A1 加密，只有使用服務(wù)器擁有的私鑰 A2 才能解密。但是！「攻擊者完全不需要拿到服務(wù)器私有的私鑰 A2 就能劫持信息」。舉個例子：

• 某網(wǎng)站服務(wù)器擁有一組用于公開密鑰加密的非對稱密鑰：公鑰 A1、私鑰 A2

• 瀏覽器向網(wǎng)站服務(wù)器請求，服務(wù)器把公鑰 A1 明文給傳輸瀏覽器

• 攻擊者劫持到公鑰 A1，保存下來，把數(shù)據(jù)包中的公鑰 A1 替換成自己偽造的公鑰 B1（它當(dāng)然也擁有公鑰 B1 對應(yīng)的私鑰 B2）

• 瀏覽器隨機生成一個用于對稱加密的密鑰 X，用攻擊者的公鑰 B1（服務(wù)器此時不知道自己的公鑰被替換了）加密后傳給服務(wù)器

• 攻擊者劫持后用自己的私鑰 B2 解密就得到了密鑰 X。然后再用服務(wù)器的公鑰 A1 加密后傳給服務(wù)器

• 服務(wù)器接收到攻擊者用公鑰 A1 加密的信息后，用對應(yīng)的私鑰 A2 解密得到密鑰 X

這樣在客戶端瀏覽器和網(wǎng)站服務(wù)器都沒有發(fā)現(xiàn)異常的情況下，攻擊者得到了對稱密鑰 X。此后客戶端和瀏覽器雙方通過對稱密鑰 X 加密發(fā)送的任何內(nèi)容，攻擊者都可以輕松破解。

上述過程就是典型的中間人攻擊，其根本原因是「瀏覽器客戶端無法確認(rèn)自己收到的公鑰是不是真正的網(wǎng)站服務(wù)器的」。那么下一步就是解決這個問題：? 如何證明瀏覽器客戶端收到的公鑰一定是該網(wǎng)站服務(wù)器的公鑰？防止服務(wù)器和客戶端的身份被偽裝。

其實很簡單，大家想一下在現(xiàn)實生活中，如何證明小明說出的身份證號確實是它自己的，怎么辦？看看小明的身份證就可以了。身份證是由誰頒發(fā)的？政府機構(gòu)。那么這里政府機構(gòu)就起到了「公信」的作用，它本身的權(quán)威可以對一個人的身份信息作出證明。

對應(yīng)的，互聯(lián)網(wǎng)中也有這么一個公信機構(gòu)，「數(shù)字證書認(rèn)證機構(gòu) Certificate Authority, CA」。所謂公信機構(gòu)，就是客戶端和瀏覽器都信賴的第三方機構(gòu)。

網(wǎng)站服務(wù)器在使用 HTTPS 前，需要向 CA 申請頒發(fā)「數(shù)字證書」，數(shù)字證書里有證書持有者、證書持有者的公鑰等信息。服務(wù)器把數(shù)字證書明文傳輸給瀏覽器客戶端，然后瀏覽器從證書里取出服務(wù)器的公鑰就可以了。

然而這里又有一個顯而易見的問題：「證書本身的傳輸過程中，如何防止被篡改」？即如何證明證書本身的真實性？數(shù)字證書怎么防偽呢？

③ 數(shù)字簽名

數(shù)字證書認(rèn)證機構(gòu) CA 在判明提出申請者的身份之后，會對其申請的公開密鑰做「數(shù)字簽名」，然后將數(shù)字簽名和公開密鑰放入數(shù)字證書。而客戶端在收到服務(wù)器發(fā)送來的數(shù)字證書后，對證書上面的數(shù)字簽名進行驗證，如何這個數(shù)字簽名和證書上的原始公開密鑰 Hash 后的結(jié)果一致，那么客戶端便可明確兩件事情：

• 認(rèn)證服務(wù)器的公開密鑰的是真實有效的數(shù)字證書認(rèn)證機構(gòu)

• 服務(wù)器的公開密鑰是值得信賴的

OK，這么說還不太清楚，我們先來了解什么是數(shù)字簽名？

數(shù)字證書認(rèn)證機構(gòu) CA 把要傳送的明文信息（也就是申請認(rèn)證的網(wǎng)站服務(wù)器的公鑰）通過 Hash 算法得出摘錄信息 MIC（摘錄技術(shù)），再用自己的私鑰對 MIC 值進行加密，就得到了得到數(shù)字簽名。

解釋一下：認(rèn)證機構(gòu)一般會持有一組公鑰 A1 和私鑰 A2，為了確保證書的安全性，「瀏覽器客戶端通常會在內(nèi)部事先植入常用認(rèn)證機構(gòu)的公鑰 A1」，認(rèn)證機構(gòu)在頒發(fā)數(shù)字證書的時候，會用自己的私鑰 A2 對數(shù)字簽名進行加密。而瀏覽器接收到數(shù)字證書后，先利用事先存儲好的公鑰 A1 解密數(shù)字簽名，再對數(shù)字簽名進行驗證。

下面是這個過程的總結(jié)提煉，大家配合圖片直觀理解一下。

1）「CA 頒發(fā)數(shù)字證書給網(wǎng)站的過程」：

• CA 擁有非對稱加密的私鑰和公鑰

• 網(wǎng)站申請數(shù)字證書，并發(fā)送自己的公開密鑰 A

• CA 對網(wǎng)站的公開密鑰 A 進行 Hash 得到摘錄信息 MIC

• 對 MIC 值用 CA 的私鑰加密，繼而得到數(shù)字簽名

• 將數(shù)字簽名和網(wǎng)站的公開密鑰 A 放進數(shù)字證書發(fā)放給網(wǎng)站

2）「瀏覽器客戶端驗證網(wǎng)站數(shù)字證書的過程」：

• 瀏覽器客戶端接收到網(wǎng)站服務(wù)器發(fā)來的數(shù)字證書，得到網(wǎng)站的公鑰 A 和數(shù)字簽名 S1

• 瀏覽器使用事先植入的 CA 機構(gòu)的公鑰對 S1 進行解密，得到 S2

• 用數(shù)字證書里說明的 Hash 算法對網(wǎng)站的公鑰 A 進行 Hash 得到 A2。

• 比較 S2 是否等于 A2，若相等則表示證書可信。于是瀏覽器就可以放心的取出數(shù)字證書中的網(wǎng)站公鑰 A 進行使用

?

3. 為什么 HTTPS 沒有被全面采用

回到文章標(biāo)題，既然 HTTPS 安全可靠，那為什么不所有的 Web 網(wǎng)站都使用 HTTPS 呢？

其中一個原因就是，由于使用了加密通信， 相比于純文本通信的 HTTP 來說，「HTTPS 會消耗掉更多的 CPU 及內(nèi)存資源」，如果每次通信都加密，會消耗掉非常多的資源，平攤到一臺計算機上時，能夠處理的請求數(shù)量必定也會隨之減少。一些國際大型網(wǎng)站比如維基百科等，在啟用 HTTPS 前都會先考慮自己服務(wù)器資源和計算能力是否可以承載 HTTPS。

因此，如果是非敏感信息，使用 HTTP 通信也無妨。只有在涉及個人敏感信息等數(shù)據(jù)時，才需要使用 HTTPS。

另外，開啟 HTTPS 需要申請 SSL 證書，「高額的證書申購費用」會讓很多網(wǎng)站開發(fā)者望而卻步。

看到這里，不知道大家能不能夠理解為什么基本上所有學(xué)校的選課系統(tǒng)全是 HTTP 了：

• 首先，大部分選課系統(tǒng)基本都需要校園網(wǎng)或者 VPN 才能夠登錄，不需要考慮被外界攻擊或者信息泄露問題

• 其次，即便使用的是 HTTP，選課系統(tǒng)開放的初期猛量的高并發(fā)尚且會讓服務(wù)器崩潰，就甭說 HTTPS 了

所以綜合來說，校內(nèi)選課系統(tǒng)完全沒必要增加額外的運行和維護成本來使用 HTTPS。

有道無術(shù)，術(shù)可成；有術(shù)無道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的从崩溃的选课系统，论为什么更安全的 HTTPS 协议没有被全面采用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。