寫在前面：本文僅供個人學習使用，如有侵權，請聯系刪除。文章中所用圖片絕大多數來源于《圖解HTTP》，請讀者支持原版。

文章目錄

• • 7.1 HTTP的缺點
  • • 7.1.1 通信明文可能被竊聽
    • • TCP/IP是可能被竊聽的網絡
      • 加密處理防止被竊聽
    • 7.1.2 不驗證通信方的身份就可能遭遇偽裝
    • • 任何人都可發起請求
      • 查明對手的證書
    • 7.1.3 無法證明報文完整性，可能已遭篡改
    • • 接收到的內容可能有誤
      • 如何防止篡改
  • 7.2 HTTP+加密+認證+完整性保護=HTTPS
  • • 7.2.1 HTTP加上加密處理和認證以及完整性保護后即是HTTPS
    • 7.2.2 HTTPS是身披SSL外殼的HTTP
    • 7.2.3 相互交換密鑰的公開密鑰加密技術
    • • 共享密鑰加密的困境
      • 使用兩把密鑰的公開密鑰加密
      • HTTPS采用混合加密機制
    • 7.2.4 證明公開密鑰正確性的證書
    • • 可證明組織真實性的EV SSL證書
    • 7.2.5 HTTPS的安全通信機制
    • • SSL和TLS
      • SSL速度慢嗎？

7.1 HTTP的缺點

HTTP有好也有壞，主要有以下不足:

• 通信明文可能被竊聽
• 不驗證通信方的身份就可能遭遇偽裝
• 無法證明報文完整性，可能已遭篡改

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

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

7.1.1 通信明文可能被竊聽

由于HTTP本身不具備加密的功能，所以也無法做到對通信整體進行加密。即，HTTP報文使用明文（指未經過加密的報文）方式發送。

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

如果要問為什么通信時不加密是一個缺點，這是因為，按TCP/IP協議族的工作機制，通信內容在所有的通信線路上都有可能遭到窺視。

即使已經過加密處理的通信，也會被窺視到通信內容，這點和未加密的通信是相同的。只是說如果通信經過加密，就有可能讓人無法破解報文信息的含義，但是加密處理后的報文信息本身還是會被看到的。

竊聽相同段上的通信并非難事。只需要收集在互聯網上流動的數據包（幀）就行了。對于收集來的數據包的解析工作，可交給那些抓包（Packet Capture）或嗅探器(Sniffer)工具。

下面的圖片實例就是被廣泛使用的抓包工具Wireshark。它可以獲取HTTP協議的請求和響應的內容，并對其進行解析。

像使用GET方法發送請求、響應返回了200 OK，查看HTTP響應報文的全部內容等一系列事情都可以做到。

加密處理防止被竊聽

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

通信的加密

一種方式就是將通信加密。HTTP協議中沒有加密機制，但可以通過和SSL（Secure Socket Layer，安全套接層） 或TLS(Tranport Layer Security，安全傳輸層協議) 的組合使用，加密HTTP的通信內容。

用SSL建立安全通信線路后，就可以在這條線路上就行HTTP通信了。與SSL組合使用的HTTP被稱為HTTPS(HTTP Secure，超文本傳輸安全協議)或 HTTP over SSL。

內容的加密

還有一種將參與通信的內容本身加密的方式。由于HTTP協議中沒有加密機制，那么就對HTTP協議傳輸的內容本身加密。即把HTTP報文里所含有的內容進行加密處理。

在這種情況下，客戶端需要對HTTP報文進行加密處理后再發送請求。

誠然，為了做到有效的內容加密，前提是要求客戶端和服務器同時具備加密和解密機制。主要應用在Web服務中。有一點必須引起注意，由于該方式不同于SSL和TLS將整個通信線路加密處理，所以內容仍有被篡改的風險。

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

HTTP協議中的請求和響應不會對通信方進行確認。也就是說存在“服務器是否就是發送請求中URI真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端”等類似問題。

任何人都可發起請求

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

HTTP協議的實現本身非常簡單，不論是誰發送過來的請求都會返回響應，因此不確認通信方，會存在以下各種隱患。

• 無法確定請求發送至目標的Web服務器是否是按真實意圖返回響應的那臺服務器。 有可能是已偽裝的Web服務器。
• 無法確定相應返回到的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已偽裝的客戶端。
• 無法確定正在通信的對方是否具備訪問權限。因為某些Web服務器上保存著重要的信息，只想發給特定用戶通信的權限。
• 無法判定請求是來自何方、出自誰手。
• 即使是無意義的請求也會照單全收。無法阻止海量請求下的Dos攻擊(Denial of Service,拒絕服務攻擊)。

查明對手的證書

雖然使用HTTP協議無法確定通信方，但如果使用SSL則可以。SSL不僅提供加密處理，而且還使用了一種被稱為證書的手段，可用于確定通信方。

證書由值得信任的第三方機構頒發，用以證明服務器和客戶端是實際存在的。另外，偽造證書從技術角度來說是異常困難的一件事。所以只要能夠確認通信方（服務器或客戶端）持有的證書，即可判斷通信方的真實意圖。

通過使用證書，以證明通信方就是意料中的服務器。這對使用者個人來講，也減少了個人信息泄露的危險性。

另外，客戶端持有證書即可完成個人身份的確認，也可用于對Web網站的認證環節。

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

所謂完整性是指信息的準確度。若無法證明其完整性，通常也就意味著無法判斷信息是否準確。

接收到的內容可能有誤

由于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的相關內容。

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

7.2.1 HTTP加上加密處理和認證以及完整性保護后即是HTTPS

如果在HTTP協議通信過程中使用未經加密的明文，比如在Web頁面中輸入信用卡號，如果這條通信線路遭到竊聽，那么信用卡號就暴露了。

另外，對于HTTP來說，服務器也好，客戶端也好，都是沒有辦法確認通信方的。因為很有可能并不是和原本預想的通信方在實際通信。并且還需要考慮到接收到的報文在通信途中已經遭到篡改這一可能性。

為了統一解決上述這些問題，需要在HTTP上再加入加密處理和認證等機制。我們把添加了加密及認證機制的HTTP稱為HTTPS(HTTP Secure)。

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

7.2.2 HTTPS是身披SSL外殼的HTTP

HTTPS并非是應用層的一種新協議。只是HTTP通信接口部分用SSL（Secure Socket Layer，安全套接層）和TLS(Tranport Layer Security，安全傳輸層協議)協議代替而已。

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

在采用SSL后，HTTP就擁有了HTTPS的加密、證書和完整性這些功能。

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

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

在對SSL進行講解之前，我們先來了解一下加密方法。SSL采用一種叫做公開密鑰加密（Public-key cryptography） 的加密處理方式。

近代的加密方法中機密算法是公開的，而密鑰卻是保密的。通過這種方式得以保持加密方法的安全性。

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

共享密鑰加密的困境

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

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

使用兩把密鑰的公開密鑰加密

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

公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰(private key)，另一把叫做公開密鑰(public key).顧名思義，私有密鑰不能讓其他人知道，而公開密鑰則可以隨意發布，任何人都可以獲得。

使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息后，再使用自己的私有密鑰進行解密。利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走。

另外，要想根據密文和公開密鑰，恢復到信息原文是異常困難的，因為解密過程就是在對離散對數進行求值，這并非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數做到快速地因式分解，那么密碼破解還是存在希望的。但就目前的技術來看是不太現實的。

HTTPS采用混合加密機制

HTTPS采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制。若密鑰能夠實現安全交換，那么有可能會考慮僅使用公開密鑰加密來通信。但是公開密鑰加密和共享密鑰加密相比，其處理速度要慢。

所以應充分利用兩者各自的優勢，將多種方法組合起來用于通信。在交換密鑰環節使用公開密鑰加密方式，之后的建立通信交換報文階段則使用共享密鑰加密方式。

7.2.4 證明公開密鑰正確性的證書

遺憾的是，公開密鑰加密方式還是存在一些問題的。那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。比如，正準備和某臺服務器建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原本預想的那臺服務器發行的公開密鑰。或許在公開密鑰的傳輸過程中，真正的公開密鑰已經被攻擊者替換掉了。

為了解決上述問題，可以使用由數字證書認證機構(CA,Certificate Authority) 和其相關機關頒發的公開密鑰證書。

數字證書認證機構處于客戶端與服務器雙方都可信賴的第三方機構的立場上。威瑞信(VeriSign) 就是其中一家非常著名的數字證書認證機構。我們來介紹一下數字證書認證機構的業務流程。首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明申請者的身份后，會對已申請的公開密鑰做數字簽名，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公鑰證書后綁定在一起。

服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通信。公鑰證書也可叫做數字證書或直接稱為證書。

接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：一，認證服務器的公開密鑰的是真實有效的數字證書認證機構。二，服務器的公開密鑰是值得信賴的。

此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通信方式時，如何安全轉交是一件很困難的事，因此，多數瀏覽器開發商發布版本時，會事先在內部植入常用認證機關的公開密鑰。

Edge瀏覽器如何查看證書？

打開設置- 隱私、搜索與服務—安全性（在接近最后的位置）–管理證書

可證明組織真實性的EV SSL證書

證書的一個作用是用來證明作為通信一方的服務器是否規范，另外一個作用是可確認對方服務器背后運營的企業是否真實存在。持有該特性的證書就是 EV SSL證書(Extended Validation SSL Certificate).

EV SSL證書是基于國際標準的認證指導方針頒發的證書。其嚴格規定了對運營組織是否真實的確認方針，因此，通過認證的Web網站能夠獲得更高的認可度。

持有EV SSL證書的Web網站的瀏覽器地址欄處的背景色是綠色的，而且在地址欄的左側顯示了SSL證書中記錄的組織名稱以及頒發證書的認證機構的名稱。

上述機制的原意圖是為了防止用戶被釣魚攻擊(Phishing)，但就效果上來講，還得打一個問號。很多用戶可能不了解EV SSL證書相關的知識，因此也不太會留意它。

7.2.5 HTTPS的安全通信機制

為了更好地理解HTTPS，我們來觀察一下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通信的整個過程。

SSL和TLS

HTTPS使用SSL（Secure Socket Layer，安全套接層）和TLS(Tranport 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.

SSL速度慢嗎？

HTTPS也存在一些問題，那就是當使用SSL時，它的處理速度會變慢。

SSL的慢分為兩種。 一種是指通信慢。另一種是指由于大量消耗CPU及內存等資源，導致處理速度變慢。

和使用HTTP相比，HTTPS可能會慢2到100倍。除去和TCP連接、發送HTTP請求·響應時間外，還必須進行SSL通信，因此整體上處理通信量不可避免會增加。

另一點是SSL必須進行加密處理。在服務器和客戶端都需要進行加密和解密的運算處理。因此從結果上來講，比起HTTP會更多地消耗服務器和客戶端的硬件資源，導致負載增強。

針對速度變慢這一問題，并沒有根本性的解決方案，我們會使用SSL加速器這種（專用服務器）硬件來改善該問題。該硬件為SSL通信專用硬件，相對軟件來講，能夠提高數倍SSL的計算速度。僅在SSL處理時發揮SSL加速器的功效，以分擔負載。

總結

以上是生活随笔為你收集整理的《图解HTTP》读书笔记--第7章 确保Web安全的HTTPS的全部內容，希望文章能夠幫你解決所遇到的問題。

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