《圖解HTTP》讀后筆記03

1、確保 Web 安全的 HTTPS

到現在為止，我們已了解到 HTTP 具有相當優秀和方便的一面，然而 HTTP 并非只有好的一面，事物皆具兩面性，它也是有不足之處的。 HTTP 主要有這些不足，例舉如下。

（1）通信使用明文（不加密），內容可能會被竊聽

（2）不驗證通信方的身份，因此有可能遭遇偽裝

（3）無法證明報文的完整性，所以有可能已遭篡改

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

除此之外，HTTP 本身還有很多缺點。而且，還有像某些特定的 Web 服務器和特定的 Web 瀏覽器在實際應用中存在的不足（也可以說成是脆弱性或安全漏洞）另外，用 Java 和 PHP 等編程語言開發的 Web 應用也可能存在安全漏洞。

TCP/IP 是可能被竊聽的網絡

如果要問為什么通信時不加密是一個缺點，這是因為，按 TCP/IP 協議族的工作機制，通信內容在所有的通信線路上都有可能遭到窺視。所謂互聯網，是由能連通到全世界的網絡組成的。無論世界哪個角落的服務器在和客戶端通信時，在此通信線路上的某些網絡設備、光纜、計算機等都不可能是個人的私有物，所以不排除某個環節中會遭到惡意窺視行為。即使已經過加密處理的通信，也會被窺視到通信內容，這點和未加密的通信是相同的。只是說如果通信經過加密，就有可能讓人無法破解報文信息的含義，但加密處理后的報文信息本身還是會被看到的。

竊聽相同段上的通信并非難事。只需要收集在互聯網上流動的數據包（幀）就行了。對于收集來的數據包的解析工作，可交給那些抓包（Packet Capture）或嗅探器（Sniffer）工具。 下面的圖片示例就是被廣泛使用的抓包工具 Wireshark。它可以獲取 HTTP 協議的請求和響應的內容，并對其進行解析。 像使用 GET 方法發送請求、響應返回了 200 OK，查看 HTTP 響應報文的全部內容等一系列的事情都可以做到。

加密處理防止被竊聽

在目前大家正在研究的如何防止竊聽保護信息的幾種對策中，最 為普及的就是加密技術。加密的對象可以有這么幾個。

（1）通信的加密

一種方式就是將通信加密。HTTP 協議中沒有加密機制，但可以通過和 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全層傳輸協議）的組合使用， 加密 HTTP 的通信內容。 用 SSL 建立安全通信 線路之后，就可以在這條線路上進行 HTTP 通信了。與 SSL 組合使用的 HTTP 被稱為 HTTPS（HTTP Secure，超文本傳輸安全協議）或 HTTP over SSL。

（2）內容的加密

還有一種將參與通信的內容本身加密的方式。由于 HTTP 協議中沒有加密機制，那么就對 HTTP 協議傳輸的內容本身加密。即把 HTTP 報文里所含的內容進行加密處理。 在這種情況下，客戶端需要對 HTTP 報文進行加密處理后再發送請求。

2、不驗證通信方的身份就可能遭遇偽裝

在 HTTP 協議通信時，由于不存在確認通信方的處理步驟，任何人都可以發起請求。另外，服務器只要接收到請求，不管對方是誰都會返回一個響應（但也僅限于發送端的 IP 地址和端口號沒 有被 Web 服務器設定限制訪問的前提下）。

（1）無法確定請求發送至目標的 Web 服務器是否是按真實意 圖返回響應的那臺服務器。有可能是已偽裝的 Web 服務 器。

（2）無法確定響應返回到的客戶端是否是按真實意圖接收響 應的那個客戶端。有可能是已偽裝的客戶端。

（3）無法確定正在通信的對方是否具備訪問權限。因為某些 Web 服務器上保存著重要的信息，只想發給特定用戶通信的權限。

（4）無法判定請求是來自何方、出自誰手。即使是無意義的請求也會照單全收。無法阻止海量請求 下的 DoS 攻擊（Denial of Service，拒絕服務攻擊）

查明對手的證書

雖然使用 HTTP 協議無法確定通信方，但如果使用 SSL 則可以。 SSL 不僅提供加密處理，而且還使用了一種被稱為證書的手段， 可用于確定方。證書由值得信任的第三方機構頒發，用以證明服務器和客戶端是實際存在的。另外，偽造證書從技術角度來說是異常困難的一件 事。所以只要能夠確認通信方（服務器或客戶端）持有的證書， 即可判斷通信方的真實意圖。

3、無法證明報文完整性，可能已遭篡改

（1）接收到的內容可能有誤

由于 HTTP 協議無法證明通信的報文完整性，因此，在請求或響 應送出之后直到對方接收之前的這段時間內，即使請求或響應的 內容遭到篡改，也沒有辦法獲悉。

換句話說，沒有任何辦法確認，發出的請求/響應和接收到的請求/響應是前后相同的

比如，從某個 Web 網站上下載內容，是無法確定客戶端下載的 文件和服務器上存放的文件是否前后一致的。文件內容在傳輸途 中可能已經被篡改為其他的內容。即使內容真的已改變，作為接收方的客戶端也是覺察不到的。

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

雖然有使用 HTTP 協議確定報文完整性的方法，但事實上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校驗的方法， 以及用來確認文件的數字簽名方法。提供文件下載服務的 Web 網站也會提供相應的以 PGP（Pretty Good Privacy，完美隱私）創建的數字簽名及 MD5 算法生成的散 列值。PGP 是用來證明創建文件的數字簽名，MD5 是由單向函 數生成的散列值。不論使用哪一種方法，都需要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。 瀏覽器無法自動幫用戶檢查。可惜的是，用這些方法也依然無法百分百保證確認結果正確。因 為 PGP 和 MD5 本身被改寫的話，用戶是沒有辦法意識到的。 為了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認證和加密處理及摘要功能。僅靠 HTTP 確保完整性是非常困難的，因此通過和其他協議組合使用來實現這個目標。下節我們介紹 HTTPS 的相關內容。

4、HTTP+ 加密 + 認證 + 完整性保護 =HTTPS

經常會在 Web 的登錄頁面和購物結算界面等使用 HTTPS 通信。使用 HTTPS 通信時，不再用 http://，而是改用 https://。另外，當瀏覽器訪問 HTTPS 通信有效的 Web 網站時，瀏覽器的地址欄內會出現一個帶鎖的標記。對 HTTPS 的顯示方式會因瀏覽器的不同而有所改變。

通常，HTTP 直接和 TCP 通信。當使用 SSL 時，則演變成先和 SSL 通 信，再由 SSL 和 TCP 通信了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的 HTTP。HTTPS 并非是應用層的一種新協議。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代替而已。

通常，HTTP 直接和 TCP 通信。當使用 SSL 時，則演變成先和 SSL 通信，再由 SSL 和 TCP 通信了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的 HTTP。

SSL 是獨立于 HTTP 的協議，所以不光是 HTTP 協議，其他運行在應 用層的 SMTP 和 Telnet 等協議均可配合 SSL 協議使用。可以說 SSL 是當今世界上應用最為廣泛的網絡安全技術。

5、相互交換密鑰的公開密鑰加密技術

在對 SSL 進行講解之前，我們先來了解一下加密方法。SSL 采用一種叫做公開密鑰加密（Public-key cryptography）的加密處理方式。近代的加密方法中加密算法是公開的，而密鑰卻是保密的。通過這種方式得以保持加密方法的安全性。

加密和解密都會用到密鑰。沒有密鑰就無法對密碼解密，反過來說， 任何人只要持有密鑰就能解密了。如果密鑰被攻擊者獲得，那加密也就失去了意義

（1）共享密鑰加密的困境

加密和解密同用一個密鑰的方式稱為共享密鑰加密（Common key crypto system），也被叫做對稱密鑰加密。

以共享密鑰方式加密時必須將密鑰也發給對方。可究竟怎樣才能 安全地轉交？在互聯網上轉發密鑰時，如果通信被**那么密鑰就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。

（2）使用兩把密鑰的公開密鑰加密

公開密鑰加密方式很好地解決了共享密鑰加密的困難。公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰 （private key），另一把叫做公開密鑰（public key）。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發布，任何人都可以獲得。使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息后，再使用自己的私有密鑰進行解密。利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走。另外，要想根據密文和公開密鑰，恢復到信息原文是異常困難的，因為解密過程就是在對離散對數進行求值，這并非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數做到快速地因式分解，那么密碼破解還是存在希望的。但就目前的技術來看是不太現實的。

（3）HTTPS 采用混合加密機制

HTTPS 采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制。若密鑰能夠實現安全交換，那么有可能會考慮僅使用公開密鑰加密來通信。但是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。所以應充分利用兩者各自的優勢，將多種方法組合起來用于通信。在交換密鑰環節使用公開密鑰加密方式，之后的建立通信交換報文階段則使用共享密鑰加密方式。

（4）證明公開密鑰正確性的證書

遺憾的是，公開密鑰加密方式還是存在一些問題的。那就是無法證明 公開密鑰本身就是貨真價實的公開密鑰。比如，正準備和某臺服務器 建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原 本預想的那臺服務器發行的公開密鑰。或許在公開密鑰傳輸途中，真 正的公開密鑰已經被攻擊者替換掉了。為了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書。數字證書認證機構處于客戶端與服務器雙方都可信賴的第三方機構的 立場上。威瑞信（VeriSign）就是其中一家非常有名的數字證書認證 機構。我們來介紹一下數字證書認證機構的業務流程。首先， 服務器 的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證 機構在判明提出申請者的身份之后，會對已申請的公開密鑰做數字簽 名，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公鑰證書 后綁定在一起。服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通信。公鑰證書也可叫做數字證書或直接稱為證書。接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書 上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事： 一，認證服務器的公開密鑰的是真實有效的數字證書認證機構。二， 服務器的公開密鑰是值得信賴的。此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通信方式 時，如何安全轉交是一件很困難的事，因此，多數瀏覽器開發商發布版本時，會事先在內部植入常用認證機關的公開密鑰。

6、HTTPS 的安全通信機制

步驟 1： 客戶端通過發送 Client Hello 報文開始 SSL 通信。報文中包 含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所 使用的加密算法及密鑰長度等）。

步驟 2： 服務器可進行 SSL 通信時，會以 Server Hello 報文作為應答。和客戶端一樣，在報文中包含 SSL 版本以及加密組件。服務器的 加密組件內容是從接收到的客戶端加密組件內篩選出來的。

步驟 3： 之后服務器發送 Certificate 報文。報文中包含公開密鑰證 書。

步驟 4： 最后服務器發送 Server Hello Done 報文通知客戶端，最初階 段的 SSL 握手協商部分結束。

步驟 5： SSL 第一次握手結束之后，客戶端以 Client Key Exchange 報 文作為回應。報文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。

步驟 6： 接著客戶端繼續發送 Change Cipher Spec 報文。該報文會提 示服務器，在此報文之后的通信會采用 Pre-master secret 密鑰加密。

步驟 7： 客戶端發送 Finished 報文。該報文包含連接至今全部報文的 整體校驗值。這次握手協商是否能夠成功，要以服務器是否能夠正確 解密該報文作為判定標準。

步驟 8： 服務器同樣發送 Change Cipher Spec 報文。

步驟 9： 服務器同樣發送 Finished 報文。

步驟 10： 服務器和客戶端的 Finished 報文交換完畢之后，SSL 連接 就算建立完成。當然，通信會受到 SSL 的保護。從此處開始進行應用 層協議的通信，即發送 HTTP 請求。

步驟 11： 應用層協議通信，即發送 HTTP 響應。

步驟 12： 最后由客戶端斷開連接。斷開連接時，發送 close_notify 報 文。上圖做了一些省略，這步之后再發送 TCP FIN 報文來關閉與 TCP 的通信。

在以上流程中，應用層發送數據時會附加一種叫做 MAC（Message Authentication Code）的報文摘要。MAC 能夠查知報文是否遭到篡 改，從而保護報文的完整性。

下面是對整個流程的圖解。圖中說明了從僅使用服務器端的公開密鑰 證書（服務器證書）建立 HTTPS 通信的整個過程。

7、SSL 和 TLS

HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security）這兩個協議。 SSL 技術最初是由瀏覽器開發商網景通信公司率先倡導的，開發 過 SSL3.0 之前的版本。目前主導權已轉移到 IETF（Internet Engineering Task Force，Internet 工程任務組）的手中。 IETF 以 SSL3.0 為基準，后又制定了 TLS1.0、TLS1.1 和 TLS1.2。TSL 是以 SSL 為原型開發的協議，有時會統一稱該協議 為 SSL。當前主流的版本是 SSL3.0 和 TLS1.0。 由于 SSL1.0 協議在設計之初被發現出了問題，就沒有實際投入 使用。SSL2.0 也被發現存在 問題，所以很多瀏覽器直接廢除了 該協議版本。

8、SSL 速度慢嗎

另一點是 SSL 必須進行加密處理。在服務器和客戶端都需要進行 加密和解密的運算處理。因此從結果上講，比起 HTTP 會更多地 消耗服務器和客戶端的硬件資源，導致負載增強。針對速度變慢這一問題，并沒有根本性的解決方案，我們會使用 SSL 加速器這種（專用服務器）硬件來改善該問題。該硬件為 SSL 通信專用硬件，相對軟件來講，能夠提高數倍 SSL 的計算速 度。僅在 SSL 處理時發揮 SSL 加速器的功效，以分擔負載。 HTTPS 比 HTTP 要慢 2 到 100 倍 SSL 的慢分兩種。一種是指通信慢。另一種是指由于大量消耗 CPU 及內存 等資源，導致處理速度變慢。 和使用 HTTP 相比，網絡負載可能會變慢 2 到 100 倍。除去和 TCP 連接、發送 HTTP 請求 ? 響應以外，還必須進行 SSL 通信， 因此整體上處理通信量不可避免會增加。另一點是 SSL 必須進行加密處理。在服務器和客戶端都需要進行 加密和解密的運算處理。因此從結果上講，比起 HTTP 會更多地 消耗服務器和客戶端的硬件資源，導致負載增強。針對速度變慢這一問題，并沒有根本性的解決方案，我們會使用 SSL 加速器這種（專用服務器）硬件來改善該問題。該硬件為 SSL 通信專用硬件，相對軟件來講，能夠提高數倍 SSL 的計算速 度。僅在 SSL 處理時發揮 SSL 加速器的功效，以分擔負載。

9、為什么不一直使用 HTTPS

既然 HTTPS 那么安全可靠，那為何所有的 Web 網站不一直使用 HTTPS ？

其中一個原因是，因為與純文本通信相比，加密通信會消耗更多的 CPU 及內存資源。如果每次通信都加密，會消耗相當多的資源，平 攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少。因此，如果是非敏感信息則使用 HTTP 通信，只有在包含個人信息 等敏感數據時，才利用 HTTPS 加密通信。 特別是每當那些訪問量較多的 Web 網站在進行加密處理時，它們 所承擔著的負載不容小覷。在進行加密處理時，并非對所有內容都 進行加密處理，而是僅在那些需要信息隱藏時才會加密，以節約資源。

除此之外，想要節約購買證書的開銷也是原因之一。

要進行 HTTPS 通信，證書是必不可少的。而使用的證書必須向認 證機構（CA）購買。證書價格可能會根據不同的認證機構略有不同。通常，一年的授權需要600人民幣。那些購買證書并不合算的服務以及一些個人網站，可能只會選擇采用 HTTP 的通信方式。

HTTP TCP/IP

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。