第七章 確保Web安全的HTTPS
7.1 HTTP的缺點
7.2 HTTP+加密+認證+完整性保護 = HTTPS

心得：
網絡安全的簡單內容，可以了解到HTTPS是什么，這個通信機制可以有效的防止什么問題。
HTTP的三個問題：傳輸的內容被竊聽，服務器無法確定，客戶端無法確定。
通常，HTTP 直接和 TCP 通信。當使用 SSL時，則演變成HTTP先和 SSL通信，再由 SSL和 TCP 通信了。采用 SSL后，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。SSL是獨立于 HTTP 的協議，所以不光是 HTTP 協議，其他運行在應用層的 SMTP 和 Telnet 等協議均可配合 SSL協議使用。
HTTPS如何進行加密呢？ 比如兩把密鑰加密機制、混合加密機制
那HTTPS加密造成的一些不足是什么呢？HTTPS響應比HTTP慢

7.1 HTTP的缺點

HTTP主要的不足有如下：

• 通信使用明文（不加密），內容可能會被竊聽。
• 不驗證通信方的身份，因此有可能遭遇偽裝
• 無法證明報文的完整性，所以有可能已遭篡改
• …

**7.1.1 通信使用明文可能被竊聽 **
由于HTTP本身不具有加密的功能，所以無法做到對通信整體（使用HTTP協議通信的請求和響應的內容）進行加密。即，HTTP報文使用明文（指未經過加密的報文）方式發送。

• TCP/IP可能被監聽
  如果要問為什么通信時不加密是一個缺點 ，那就是可能被竊聽（即使是被加密的信息也可能被竊聽）。如果通信經過加密，就有可能讓人無法破解報文信息的含義，但加密處理后的報文信息本身還是會被看到的。竊聽相同段上的通信并非難事。只需要收集在互聯網上流動的數據包（幀）就行了。對于收集來的數據包的解析工作，可交給那些抓包（Packet Capture）或嗅探器（Sniffer）工具。

• 通信的加密
  HTTP通過和SSL(安全套接層)或TLS(安全層傳輸協議)的組合使用，加密HTTP的通信內容。用SSL建立安全通信線路之后，可以在這條線路上進行HTTP通信。和SSL組合的HTTP就成為HTTPS(HTTP Secure,超文本傳輸安全協議)或HTTP over SSL。
  

• 內容的加密
  直接對參與通信的內容本身加密的方式。由于HTTP協議里沒有加密機制，那就把HTTP報文里所含的內容進行加密處理即可。由于該方式不同于 SSL或 TLS 將整個通信線路加密
  處理，所以內容仍有被篡改的風險。
  
  7.1.2 不驗證通信方的身份可能遭遇偽裝
  HTTP 協議中的請求和響應不會對通信方進行確認。也就是說存在“服務器是否就是發送請求中 URI 真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端”等類似問題。

• 任何人都可能發起請求
  在HTTP協議通信時，由于不存在確定通信方的處理步驟，任何人都可以發起請求。另外，服務器收到請求不論對方身份都會返回響應。因此存在一下隱患：

無法確定請求發送至目標Web服務器是否按照真實意圖返回響應的服務器，可能是已偽裝的Web服務器。
無法確定響應返回到的客戶端是否按照真實的意圖接受響應的那個客戶端，可能是已偽裝的客戶端。
無法確定正在通信的對方是否具有訪問權限。
即使是無意義的請求也會被接受，無法阻止海量請求下的DoS(Denial of Service,拒絕服務攻擊)。
無法判斷請求是來自何方，出自誰手。

• 查明對手的證書
  雖然使用HTTP協議無法確定通信方，但是使用SSL可以。SSL不僅提供加密處理，而且使用被稱為證書的手段確認通信方。
  證書由值得信任的第三方機構頒發，用以證明服務器和客戶端是存在的。（偽造證書從技術兒說很難） 通過使用證書，以證明通信方就是意料中的服務器。這對使用者個人來講，也減少了個人信息泄露的危險性。另外，客戶端持有證書即可完成個人身份的確認，也可用于對Web 網站的認證環節。

7.1.3 無法證明報文完整性，可能已遭到篡改
所謂完整性就是信息的準確度。若無法證明完整性，通常以為無法判斷信息是否準確

• 接收到內容可能有誤‘
  由于HTTP協議無法證明通信的報文完整性，因此，在請求或響應送出之后直到對方接受之前的時間，請求遭到篡改也無法獲悉。像這樣，請求或響應在傳輸途中，遭攻擊者攔截并篡改內容的攻擊稱為中間人攻擊（Man-in-the-Middle attack，MITM）。
  

• 如何防止篡改
  雖然有使用 HTTP 協議確定報文完整性的方法，但事實上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校驗的方法，以及用來確認文件的數字簽名方法。
  提供文件下載服務的 Web 網站也會提供相應的以 PGP（Pretty Good Privacy，完美隱私）創建的數字簽名及 MD5 算法生成的散列值。PGP 是用來證明創建文件的數字簽名，MD5 是由單向函數生成的散列值。不論使用哪一種方法，都需要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。瀏覽器無法自動幫用戶檢查。
  為了有效防止這些弊端，有必要使用 HTTPS。SSL提供認證和加密處理及摘要功能。

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

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

使用HTTPS進行通信的時候，使用https://。另外，當瀏覽器訪問 HTTPS 通信有效的 Web 網站時，瀏覽器的地址欄內會出現一個帶鎖的標記。對 HTTPS 的顯示方式會因瀏覽器的不同而有所改變。
7.2.2 HTTPS的通信過程
通常，HTTP 直接和 TCP 通信。當使用 SSL時，則演變成HTTP先和 SSL通信，再由 SSL和 TCP 通信了。采用 SSL后，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。SSL是獨立于 HTTP 的協議，所以不光是 HTTP 協議，其他運行在應用層的 SMTP 和 Telnet 等協議均可配合 SSL協議使用。

7.2.3 相互交換密鑰的公開加密技術
SSL采用一種叫做公開密鑰加密（Public-key cryptography）的加密處理方式。近代的加密方法中加密算法是公開的，而密鑰卻是保密的。通過這種方式得以保持加密方法的安全性。如果密鑰被攻擊者獲得，那加密也就失去了意義。

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

以共享密鑰方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？

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

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

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

正準備和某臺服務器建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原本預想的那臺服務器發行的公開密鑰。或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了？
公開密鑰加密的方式存在一些問題，無法證明公開密鑰本身就是貨真價實的公開密鑰。使用由數字證書認證機構（Certificate Authority）和其他機關頒發的公開密鑰證書。
數字證書認證機構處于客戶端和服務器雙方都可信賴的第三方機構的立場上。

服務器的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份之后，會對已申請的公開密鑰做數字簽名，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公鑰證書后綁定在一起。

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

客戶端接到證書認證機構的公開密鑰，對證書的數字簽名進行認證，一旦驗證通過，客戶端可以認證兩件事：一是認證服務器的公開密鑰是正是有效的數字證書認證機構；二是服務器的公開密鑰是值得信賴的。

和證書相關知識：

可證明服務器后的組織真實性的EV SSL證書
證書的一個作用是用來證明作為通信一方的服務器是否規范，另外一個作用是可確認對方服務器背后運營的企業是否真實存在。擁有該特性的證書就是 EV SSL證書（Extended Validation SSL Certificate）。
EV SSL證書是基于國際標準的認證指導方針頒發的證書。其嚴格規定了對運營組織是否真實的確認方針，因此，通過認證的Web 網站能夠獲得更高的認可度。

用以確認客戶端的客戶端證書
HTTPS 中還可以使用客戶端證書。以客戶端證書進行客戶端認證，證明服務器正在通信的對方始終是預料之內的客戶端，其作用跟服務器證書如出一轍。
但是仍有的問題：客戶端證書只是證明客戶端的計算機可靠，但是機器的使用者不一定是真實用戶。

認證機構信譽第一
SSL機制中介入認證機構之所以可行，是因為建立在其信用絕對可靠這一大前提下的。然而，2011 年 7 月，荷蘭的一家名叫DigiNotar 的認證機構曾遭黑客不法入侵，頒布了 google.com 和twitter.com 等網站的偽造證書事件。這一事件從根本上撼動了SSL的可信度。
雖然存在可將證書無效化的證書吊銷列表（Certificate Revocation List，CRL）機制，以及從客戶端刪除根證書頒發機構（Root Certificate Authority，RCA）的對策，但是距離生效還需要一段時間，而在這段時間內，到底會有多少用戶的利益蒙受損失就不得而知了。

由自認證機構辦法的證書稱為自簽名證書
獨立構建的認證機構叫做自認證機構，由自認證機構頒發的“無用”證書也被戲稱為自簽名證書。由自認證機構頒發的服務器證書之所以不起作用，是因為它無法消除偽裝的可能性。

7.2.5 HTTPS的安全通信機制

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

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

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

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

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

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

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

服務器同樣發送Change Cipher Spec報文。

服務器發送Finished報文

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

應用層協議通信，即發送HTTP響應

最后由客戶端斷開連接。斷開連接時，發送 close_notify 報文。

之后再發送 TCP FIN 報文來關閉與 TCP的通信。

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

CBC 模式（Cipher Block Chaining）又名密碼分組鏈接模式。在此模式下，將前一個明文塊加密處理后和下一個明文塊做 XOR 運算，使之重疊，然后再對運算結果做加密處理。對第一個明文塊做加密時，要么使用前一段密文的最后一塊，要么利用外部生成的初始向量（initial vector，IV）。

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

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

總結

以上是生活随笔為你收集整理的《图解HTTP》第七章个人学习的全部內容，希望文章能夠幫你解決所遇到的問題。

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