學習筆記 | 確保Web安全的HTTPS

• 在HTTP協議中有可能存在信息竊聽或身份僞裝等安全問題。

---

目錄 | 第7章 確保Web安全的HTTPS

7.1 HTTP的缺點
7.1.1 通信使用明文可能會被竊聽
7.1.2 不驗證通信方的身份就可能遭遇僞裝
7.1.3 無法證明報文完整性，可能已遭篡改
7.2 HTTP+加密+認證+完整性保護 = HTTPS
7.2.1 HTTP加上加密處理和認證以及完整性保護後即是HTTPS
7.2.3 HTTPS是身披SSL外殼的HTTP
7.2.4 證明公開祕鑰正確性的證書
7.2.5 HTTPS的安全通信機制

---

7.1 HTTP的缺點

7.1.1 通信使用明文(不加密)可能會被竊聽

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

• 互聯網上的任何角落都存在通信內容被竊聽的風險。
  
• 抓包工具Wireshark可以獲取HTTP協議的請求和響應的內容，並對其解析。

加密處理防止被竊聽

通信的加密

• HTTP協議中沒有加密機制，但可以通過和SSL(Secure Socket Layer，安全套接層)或TLS(Transport Layer Security，安全傳輸層協議)的組合使用，加密HTTP的通信內容。
• 用SSL建立安全通信線路之後，就可以在這條線路上進行HTTP通信了。與SSL組合使用的HTTP被稱爲HTTPS(HTTP Secure，超文本傳輸安全協議)或HTTP over SSL。
  
  內容的加密
• 客戶端需要對HTTP報文進行加密處理後再發送請求。
  
• 誠然，爲了做到有效的內容加密，前提是要求客戶端和服務器同時具備加密和解密機制。主要應用在Web服務中。
• 有一點必須引起注意，由於該方式不同於SSL或TLS將整個通信線路加密處理，所以內容仍有被篡改的風險。

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

任何人都可發起請求

• 服務器只要接收到請求，不管對方是誰都會返回一個響應（但也僅限於發送端的IP地址和端口號沒有被Web服務器設定限制訪問的前提下）。

因此不確認通信方，會存在以下各種隱患。

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

查明對手的證書

• 雖然使用HTTP協議無法確定通信方，但如果使用SSL則可以。SSL不僅提供加密處理，而且還使用了一種被稱爲證書的手段，可用於確定方。證書由值得信任的第三方機構頒發，用以證明服務器和客戶端是實際存在的。另外，僞造證書從技術角度來說是異常困難的一件事。所以只要能夠確認通信方（服務器或客戶端）持有的證書，即可判斷通信方的真實意圖。
• 通過使用證書，以證明通信方就是意料中的服務器。這對使用者個人來講，也減少了個人信息泄露的危險性。
• 另外，客戶端持有證書即可完成個人身份的確認，也可用於對Web網站的認證環節。

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

接收到的內容可能有誤

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

如何防止篡改

• 雖然有使用HTTP協議確定報文完整性的方法，但事實上並不便捷、可靠。其中常用的是MD5和SHA-1等散列值校驗的方法，以及用來確認文件的數字簽名方法。
• 提供文件下載服務的Web網站也會提供相應的以PGP（Pretty Good Privacy，完美隱私）創建的數字簽名及MD5算法生成的散列值。PGP是用來證明創建文件的數字簽名，MD5是由單向函數生成的散列值。不論使用哪一種方法，都需要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。瀏覽器無法自動幫用戶檢查。
• 可惜的是，用這些方法也依然無法百分百保證確認結果正確。因爲PGP和MD5本身被改寫的話，用戶是沒有辦法意識到的。

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

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

7.2.3 HTTPS是身披SSL外殼的HTTP

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

7.2.5 HTTPS的安全通信機制