前言

HTTP 具有非常優秀和方便的一面，然而，HTTP 并非一個安全的協議。大家平常瀏覽網頁的時候應該也能注意到，使用 HTTP 協議的網站，瀏覽器都會認定這是一個不安全的網站，提醒用戶注意防范（即便這是我們學校的選課系統）。

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

那么為了克服 HTTP 的缺點，確保 Web 的安全，HTTPS 就應用而生了。可以看見，使用 HTTPS 協議的網頁，地址欄前面都會有把小鎖，表示這是一個加密安全的網站，你的信息發送到此站點時是保密的。而且 Google、Baidu 等搜索引擎巨頭對于 HTTPS 網站都會給到更好的搜索排名。

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

?

1. 不安全的 HTTP

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

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

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

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

?當然，這些問題不僅在 HTTP 上出現，其他未加密的協議中也存在類似問題?

下面我們詳細分析下上述問題出現的原因。

① 內容被竊聽

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

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

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

② 身份被偽裝

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

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

1）客戶端發送的 HTTP 請求報文可能到達的并非真正的目的服務器，可能是已偽裝的服務器

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

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

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

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

③ 報文被篡改

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

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

舉個例子，你從某個使用 HTTP 的非正規網站上下載微信 APP，存放在服務器上的文件確實是微信 APP，但是，在你下載的過程當中，攻擊者攻擊了這個網站，你正在傳輸的文件內容被篡改成了其他文件，而在這個過程中，你是完全察覺不到的。

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

?

2. 安全的 HTTPS

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

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

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

另外，SSL 是獨立于 HTTP 協議的，所有運行在應用層的協議都可以配合 SSL 協議使用。可以說，SSL 協議是當今世界上應用最為廣泛的網絡安全技術。

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

① 加密

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

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

共享密鑰加密

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

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

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

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

公開密鑰加密

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

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

舉個例子：客戶端（瀏覽器）想要給網站服務器發送消息

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

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

• 網站服務器收到后，使用這個公鑰對應的私鑰進行解密

利用這種方式，不需要發送解密需要的私鑰，也就不必擔心私鑰被攻擊者盜走

混合加密方式

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

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

• 瀏覽器向網站服務器請求，服務器把公鑰 A1 明文給傳輸瀏覽器

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

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

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

② 數字證書

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

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

• 瀏覽器向網站服務器請求，服務器把公鑰 A1 明文給傳輸瀏覽器

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

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

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

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

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

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

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

對應的，互聯網中也有這么一個公信機構，「數字證書認證機構 Certificate Authority, CA」。所謂公信機構，就是客戶端和瀏覽器都信賴的第三方機構。

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

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

③ 數字簽名

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

• 認證服務器的公開密鑰的是真實有效的數字證書認證機構

• 服務器的公開密鑰是值得信賴的

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

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

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

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

1）「CA 頒發數字證書給網站的過程」：

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

• 網站申請數字證書，并發送自己的公開密鑰 A

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

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

• 將數字簽名和網站的公開密鑰 A 放進數字證書發放給網站

2）「瀏覽器客戶端驗證網站數字證書的過程」：

• 瀏覽器客戶端接收到網站服務器發來的數字證書，得到網站的公鑰 A 和數字簽名 S1

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

• 用數字證書里說明的 Hash 算法對網站的公鑰 A 進行 Hash 得到 A2。

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

?

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

回到文章標題，既然 HTTPS 安全可靠，那為什么不所有的 Web 網站都使用 HTTPS 呢？

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

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

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

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

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

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

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

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。