圖解HTTP----確定Web安全的HTTPS

一、概述

在HTTP協定中有可能存在資訊竊聽或身份僞裝等安全問題。使用HTTPS通信機制可以有效地防止這些問題。

二、HTTP的缺點

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

（2）不驗證通信方的身份，是以有可能遭遇僞裝。

（3）無法證明封包的完整性，是以有可能已遭篡改。

• 通信使用明文可能會被竊聽

（1）由于HTTP本身不具備加密的功能，是以也無法做到對通信整體（使用HTTP協定通信的請求和響應的内容）進行加密。即HTTP封包使用明文（指未經過加密的封包）方式發送。

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

1）按TCP/IP協定族的工作機制，通信内容在所有的通信線路上都有可能遭到窺視。

2）所謂網際網路，是由能連通到全世界的網絡組成的。無論世界哪個 角落的伺服器在和用戶端通信時，在此通信線路上的某些網絡裝置、光纜、計算機等都不可能是個人的私有物，是以不排除某個環節中會遭到惡意窺視行為。

3）即使已經過加密處理的通信，也會被窺視到通信内容，這點和未加密的通信是相同的。隻是說如果通信經過加密，就有可能讓人無法破解封包資訊的含義，但加密處理後的封包資訊本身還是會被看到的。

4）竊聽相同段上的通信并非難事。隻需要收集在網際網路上流動的資料包（幀）就行了。對于收集來的資料包的解析工作，可交給那些抓包（Packet Capture）或嗅探器（Sniffer）工具。

（3）加密處理防止被竊聽

• 通信的加密

1）HTTP協定中沒有加密機制，但可以通過和SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全層傳輸協定）的組合使用，加密HTTP的通信内容。

2）用SSL建立安全通信線路之後，就可以在這條線路上進行HTTP通信了。

3）與SSL組合使用HTTP被稱為HTTPS（Secure，超文本傳輸安全協定）或 HTTP over SSL。

• 内容的加密

1）由于HTTP協定中沒有加密機制，那麼就對HTTP協定傳輸的内容本身加密。即把HTTP封包裡所含的内容進行加密處理。

2）在這種情況下，用戶端需要對HTTP封包進行加密處理後再發送請求。

3）為了做到有效的内容加密，前提是要求用戶端和伺服器同時具備加密和解密機制。

4）由于該方式不同于SSL或TLS将整個通信線路加密處理，是以内容仍有被篡改的風險。

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

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

（1）任何人都可發起請求

1）在HTTP協定通信時，由于不存在确認通信方的處理步驟，任何人都可以發起請求。

2）伺服器隻要接收到請求，不管對方是誰都會傳回一個響應（但也僅限于發送端的 IP 位址和端口号沒有被 Web 伺服器設定限制通路的前提下）。

3）HTTP 協定的實作本身非常簡單，不論是誰發送過來的請求都會傳回響應，是以不确認通信方，會存在以下各種隐患。

無法确定請求發送至目标的 Web 伺服器是否是按真實意圖傳回響應的那台伺服器。有可能是已僞裝的 Web 伺服器。

無法确定響應傳回到的用戶端是否是按真實意圖接收響應的那個用戶端。有可能是已僞裝的用戶端。

無法确定正在通信的對方是否具備通路權限。因為某些Web 伺服器上儲存着重要的資訊，隻想發給特定使用者通信的權限。

無法判定請求是來自何方、出自誰手。

即使是無意義的請求也會照單全收。無法阻止海量請求下的 DoS 攻擊（Denial of Service，拒絕服務攻擊）。

（2）查明對手的證書

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

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

3）通過使用證書，以證明通信方就是意料中的伺服器。這對使用者個人來講，也減少了個人資訊洩露的危險性。

4）用戶端持有證書即可完成個人身份的确認，也可用于對Web 網站的認證環節。

• 無法證明封包完整性，可能已遭篡改

所謂完整性是指資訊的準确度。若無法證明其完整性，通常也就意味着無法判斷資訊是否準确。

• 接收到的内容可能有誤

1）由于 HTTP 協定無法證明通信的封包完整性，是以，在請求或響應送出之後直到對方接收之前的這段時間内，即使請求或響應的内容遭到篡改，也沒有辦法獲悉。換句話說，沒有任何辦法确認，發出的請求 / 響應和接收到的請求 / 響應是前後相同的。

• 如何防止篡改

1）雖然有使用 HTTP 協定确定封包完整性的方法，但事實上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校驗的方法，以及用來确認檔案的數字簽名方法。

2）提供檔案下載下傳服務的 Web 網站也會提供相應的以 PGP（Pretty Good Privacy，完美隐私）建立的數字簽名及 MD5 算法生成的散列值。

3）PGP 是用來證明建立檔案的數字簽名，MD5 是由單向函數生成的散列值。不論使用哪一種方法，都需要操縱用戶端的使用者本人親自檢查驗證下載下傳的檔案是否就是原來伺服器上的檔案。浏覽器無法自動幫使用者檢查。

4）可惜的是，用這些方法也依然無法百分百保證确認結果正确。因為 PGP 和 MD5 本身被改寫的話，使用者是沒有辦法意識到的。

5）為了有效防止這些弊端，有必要使用 HTTPS。SSL提供認證和加密處理及摘要功能。僅靠 HTTP 確定完整性是非常困難的，是以通過和其他協定組合使用來實作這個目标。

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

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

（1）使用HTTPS 通信時，不再用 http://，而是改用 https://。

（2）當浏覽器通路 HTTPS 通信有效的 Web 網站時，浏覽器的位址欄内會出現一個帶鎖的标記。對 HTTPS 的顯示方式會因浏覽器的不同而有所改變。

• HTTPS 是身披 SSL 外殼的 HTTP

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

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

（3）在采用 SSL後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。

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

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

（1）SSL采用一種叫做公開密鑰加密（Public-key cryptography）的加密處理方式。

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

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

• 共享密鑰加密的困境

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

2）以共享密鑰方式加密時必須将密鑰也發給對方。

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

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

2）公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰（private key），另一把叫做公開密鑰（public key）。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以随意釋出，任何人都可以獲得。

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

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

• HTTPS 采用混合加密機制

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

2）是以應充分利用兩者各自的優勢，将多種方法組合起來用于通信。在交換密鑰環節使用公開密鑰加密方式，之後的建立通信交換封包階段則使用共享密鑰加密方式。

四、證明公開密匙正确性的證書

（1）遺憾的是，公開密鑰加密方式還是存在一些問題的。那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。

比如，正準備和某台伺服器建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原本預想的那台伺服器發行的公開密鑰。或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了。

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

（3）數字證書認證機構處于用戶端與伺服器雙方都可信賴的第三方機構的立場上。

威瑞信（VeriSign）就是其中一家非常有名的數字證書認證機構

（4）數字證書認證機構的業務流程

1、首先，伺服器的營運人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份之後，會對已申請的公開密鑰做數字簽名，然後配置設定這個已簽名的公開密鑰，并将該公開密鑰放入公鑰證書後綁定在一起。

2、伺服器會将這份由數字證書認證機構頒發的公鑰證書發送給用戶端， 以進行公開密鑰加密方式通信。

3、公鑰證書也可叫做數字證書或直接稱為證書。

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

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

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

1）證書的一個作用是用來證明作為通信一方的伺服器是否規範，另外一個作用是可确認對方伺服器背後營運的企業是否真實存在。擁有該特性的證書就是 EV SSL證書（Extended Validation SSL Certificate）。

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

3）持有 EV SSL證書的 Web 網站的浏覽器位址欄處的背景色是綠色的，從視覺上就能一眼辨識出。而且在位址欄的左側顯示了 SSL證書中記錄的組織名稱以及頒發證書的認證機構的名稱。

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

• 用以确認用戶端的用戶端證書

1）HTTPS 中還可以使用用戶端證書。以用戶端證書進行用戶端認證，證明伺服器正在通信的對方始終是預料之内的用戶端，其作用跟伺服器證書如出一轍。

2）想獲驗證書時，使用者得自行安裝用戶端證書。但由于用戶端證書是要付費購買的，且每張證書對應到每位使用者也就意味着需支付和使用者數對等的費用。另外，要讓知識層次不同的使用者們自行安裝證書，這件事本身也充滿了各種挑戰。

3）現狀是，安全性極高的認證機構可頒發用戶端證書但僅用于特殊用途的業務。比如那些可支撐用戶端證書支出費用的業務。

例如，銀行的網上銀行就采用了用戶端證書。在登入網銀時不僅要求使用者确認輸入 ID 和密碼，還會要求使用者的用戶端證書，以

确認使用者是否從特定的終端通路網銀。

4）用戶端證書存在的另一個問題點是，用戶端證書畢竟隻能用來證明用戶端實際存在，而不能用來證明使用者本人的真實有效性。也就是說，隻要獲得了安裝有用戶端證書的計算機的使用權限，也就意味着同時擁有了用戶端證書的使用權限。

• 認證機構信譽第一

1）SSL機制中介入認證機構之是以可行，是因為建立在其信用絕對可靠這一大前提下的。

• 由自認證機構頒發的證書稱為自簽名證書

1）如果使用 OpenSSL這套開源程式，每個人都可以建構一套屬于自己的認證機構，進而自己給自己頒發伺服器證書。但該伺服器證書在網際網路上不可作為證書使用，似乎沒什麼幫助。

2）獨立建構的認證機構叫做自認證機構，由自認證機構頒發的“無用”證書也被戲稱為自簽名證書。

3）浏覽器通路該伺服器時，會顯示“無法确認連接配接安全性”或“該網站的安全證書存在問題”等警告消息。

4）由自認證機構頒發的伺服器證書之是以不起作用，是因為它無法消除僞裝的可能性。自認證機構能夠産生的作用頂多也就是自己對外宣稱“我是○○”的這種程度。即使采用自簽名證書，通過 SSL加密之後，可能偶爾還會看見通信處在安全狀态的提示，可那也是有問題的。因為 就算加密通信，也不能排除正在和已經過僞裝的假伺服器保持通信。

5）值得信賴的第三方機構介入認證，才能讓已植入在浏覽器内的認證機構頒布的公開密鑰發揮作用，并借此證明伺服器的真實性。

6）中級認證機構的證書可能會變成自認證證書 。

7）多數浏覽器内預先已植入備受信賴的認證機構的證書，但也有一小部分浏覽器會植入中級認證機構的證書。

8）對于中級認證機構頒發的伺服器證書，某些浏覽器會以正規的證書來對待，可有的浏覽器會當作自簽名證書。

五、HTTPS的安全通信機制

（1）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的通信。

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

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

（2）SSL 和 TLS

1）HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security）這兩個協定。

2）SSL技術最初是由浏覽器開發商網景通信公司率先倡導的，開發過 SSL3.0 之前的版本。目前主導權已轉移到 IETF（Internet

Engineering Task Force，Internet 工程任務組）的手中。

3）IETF 以 SSL3.0 為基準，後又制定了 TLS1.0、TLS1.1 和 TLS1.2。

4）TSL是以 SSL為原型開發的協定，有時會統一稱該協定為 SSL。目前主流的版本是 SSL3.0 和 TLS1.0。

（3）SSL 速度慢嗎

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

2）SSL的慢分兩種。一種是指通信慢。另一種是指由于大量消耗CPU 及記憶體等資源，導緻處理速度變慢。

3）和使用 HTTP 相比，網絡負載可能會變慢 2 到 100 倍。除去和TCP 連接配接、發送 HTTP 請求 • 響應以外，還必須進行 SSL通信，是以整體上處理通信量不可避免會增加。

4）另一點是 SSL必須進行加密處理。在伺服器和用戶端都需要進行加密和解密的運算處理。是以從結果上講，比起 HTTP 會更多地消耗伺服器和用戶端的硬體資源，導緻負載增強。

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

六、為什麼不一直使用HTTPS

（1）因為與純文字通信相比，加密通信會消耗更多的CPU 及記憶體資源。如果每次通信都加密，會消耗相當多的資源，平攤到一台計算機上時，能夠處理的請求數量必定也會随之減少。

（2）是以，如果是非敏感資訊則使用 HTTP 通信，隻有在包含個人資訊等敏感資料時，才利用 HTTPS 加密通信。

（3）在進行加密處理時，并非對所有内容都進行加密處理，而是僅在那些需要資訊隐藏時才會加密，以節約資源。

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

要進行 HTTPS 通信，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格可能會根據不同的認證機構略有不同。通常，一年的授權需要數萬日元（現在一萬日元大約折合 600人民币）。

那些購買證書并不合算的服務以及一些個人網站，可能隻會選擇采用 HTTP 的通信方式。