讀《圖解HTTP》總結--第七章

標籤：https、ssl、tls

確保Web安全的HTTPS

    在HTTP協議中有可能存在資訊竊聽或者身份偽裝等問題。使用HTTPS通訊機制可以有效地防止這類問題。本篇著重介紹下HTTPS

7.1 HTTP的缺點

    到現在為止,我們已經瞭解到HTTP具有相當優秀和方便的一面,然而HTTP並非只有好的一面,事物皆具有兩面性,HTTP也具有不足之處。其主要的不足列舉如下:

• 通訊使用明文(不加密),內容可能會被竊聽;

• 不驗證通訊方的身份,因此有可能遭遇偽裝;

• 無法證明報文的完整性,所以有可能已遭篡改     

    這些問題不僅在HTTP上出現,其他未加密的協議中也會存在這類問題。除此之外,HTTP本身還有很多缺點。而且,還有像某些特定的Web伺服器和特定的Web瀏覽器在實際應用中存在的不足(也可以說成是脆弱性或安全性漏洞),另外,用Java和PHP等程式設計語言開發的Web應用也可能存在安全性漏洞。 

7.1.1 通訊使用明文可能會被竊聽

    由於HTTP本身不具備加密功能,所以也無法做到對通訊整體(使用HTTP協議通訊的請求和響應的內容)進行加密。即,HTTP報文使用明文(指未經過加密的報文)方式發送。

•   TCP/IP是可能被竊聽的網路

    如果要問為什麼通訊時不加密是一個缺點,這是因為,按TCP/IP協議簇的工作機制,通訊內容在所有的通訊線路上都有可能遭到窺視。即所謂互連網,是由能連通到全世界的網路組成的。無論世界上哪個角落的伺服器和用戶端通訊時,在此通訊線路上的某些網路裝置、光纜、電腦等都不可能是個人的私人物,所以不排除某個環節中會遭到惡意的窺視行為。

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

    竊聽相同段的通訊並非難事。只需要收集在互連網上流動的資料包(幀)就行了,對於收集來的資料包的解析工作,可交給那些抓包(Packet Capture)或嗅探器(Sniffer)工具。ps:廣泛使用的抓包工具Wireshark(http://www.wireshark.org/),可以擷取HTTP協議的請求和響應的內容,並進行解析。

•   加密處理防止被竊聽

    目前大家正在研究的如何防止竊聽保護資訊的幾種對策中,最為普及的就是加密技術。而根據加密的對象歸納分為了通訊的加密和內容的加密。

1. 1. 通訊的加密
      

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

650) this.width=650;" src="http://s1.51cto.com/wyfs02/M00/89/9A/wKiom1gYAPfSRfBSAABv6p2e86U200.png" title="07-01.png" alt="wKiom1gYAPfSRfBSAABv6p2e86U200.png" />

1. 內容的加密 

  還有一種將參與通訊的內容本身加密的方式。由於HTTP協議中沒有加密機制,那麼就對HTTP協議傳輸的內容本身加密。即把HTTP報文裡含有的內容進行加密處理。這種情況下用戶端需要對HTTP報文進行加密處理後在發送請求。當然,為了做到有效內容加密,前提是要求用戶端和伺服器同事具備加密和解密機制。主要應用在Web服務中。有一點需要引起注意,由於該方式不同於SSL或TLS將整個通訊線路加密處理,所以內容仍有被篡改的風險。 

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

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

• 任何人都可發起請求

    在HTTP協議通訊時,由於不存在確認通訊方的處理步驟,任何人都可以發起請求。另外,伺服器只要在接收到請求,不管對方是否是誰都會返回一個響應(但也僅限於發送端ip地址和連接埠號碼沒有被Web伺服器設定限制訪問的前提下)。HTTP協議的實現本身非常簡單,不論誰發送過來的請求都會返迴響應,因此不確認通訊方會存在以下各種隱患。

1. 1. 無法確定請求發送至目標的Web伺服器是否是按真實意圖返迴響應的那台伺服器。有可能是已偽裝的Web伺服器。

   2. 無法確定響應返回道德用戶端是否是按真實意圖接收響應的那個用戶端。有可能是已偽裝的用戶端。

   3. 無法確定正在通訊的對方是否具備存取權限。因為某些Web伺服器上儲存著重要的資訊,只發送給特定使用者通訊的許可權。

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

   5. 即使是無意義的請求也會照單全收。無法阻止海量請求下的DoS攻擊。(Denial of Service)

• 查明對手的認證

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

    通過使用認證,以證明通訊方就是意料中的伺服器。這對使用者個人來講,也減少了個人資訊泄露的危險性。另外,用戶端持有認證即可完成個人身份的確認,也用於對Web網站的認證環節。

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

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

• 接收到的內容可能有誤

    由於HTTP協議無法證明通訊的報文完整性,因此,在請求或響應送出之後直到對方接收之前的這段時間內,即使請求或響應的內容遭到篡改,也沒有辦法獲悉。換而言之,沒有任何辦法確認,發出的請求/響應和接收到的請求/響應是前後相同的。比如,從某個Web網站上下載內容,是無法確定用戶端下載的檔案和伺服器上存放的檔案是否前後一致的。檔案內容在傳輸途中可能已經被篡改為其他內容。即使內容真的已經改變,作為接收方的用戶端也是察覺不到的。像這樣,請求或響應在傳輸途中,遭攻擊者攔截並篡改內容的攻擊稱為中間人攻擊(Man-in-the-Middle attrack ，MITM)。

650) this.width=650;" src="http://s2.51cto.com/wyfs02/M01/89/98/wKioL1gYAlOyA0pPAAA5ZQp-W9g143.png" title="07-02.png" alt="wKioL1gYAlOyA0pPAAA5ZQp-W9g143.png" />

• 如何防止篡改

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

    為了有效防止這些弊端,有必要使用HTTPS。SSL提供認證和加密處理及摘要功能。僅靠HTTP確保完整性是非常困難的,因此通過和其他協議組合來實現這個目標。

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的顯示方式會因瀏覽器的不同而有所改變。

650) this.width=650;" src="http://s2.51cto.com/wyfs02/M02/89/99/wKioL1gYCbvD-GrwAABK2SzvkB8928.png" title="07-03.png" alt="wKioL1gYCbvD-GrwAABK2SzvkB8928.png" />

7.2.2 HTTPS是身披SSL外殼的HTTP

    HTTPS並非是應用程式層的一種新協議。只是HTTP通訊介面部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)協議代替而已。通常HTTP直接和TCP通訊,當使用SSL時,則演變成和SSL通訊,再由SSL和TCP通訊了。簡言之,所謂的HTTPS,其實就是身披SSL協議這層外殼的HTTP。

    採用SSL後,HTTP就擁有了HTTPS的加密、認證和完整性保護這些功能。SSL是獨立於HTTP的協議,所以不光是HTTP協議,其他運行在應用程式層的SMTP和Telnet等協議均可配合SSL協議使用。可以說SSL是當今世界上應用最為廣泛的網路安全技術。

650) this.width=650;" src="http://s2.51cto.com/wyfs02/M02/89/9B/wKiom1gYGZzRDVolAAAdArJ9FnQ817.png" title="07-04.png" alt="wKiom1gYGZzRDVolAAAdArJ9FnQ817.png" />

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

    在對SSL進行講解之前,先介紹下加密方法。SSL採用一種叫做公開秘鑰加密(Public-key-Crytography)的加密處理方式。近代的加密方法中密碼編譯演算法是公開的，而秘鑰確是保密的。通過這種方式得以保持加密方法的安全性。加密和解密都會用到秘鑰。沒有秘鑰就無法對密碼解密,反過來說,任何人只要持有秘鑰就能解密。如果秘鑰被攻擊者獲得,那加密也就失去意義。

    ·共用秘鑰加密的困境

     加密和解密同用一個秘鑰的方式稱為共用秘鑰加密(Common keycrypto system),也被叫做對稱秘鑰加密。以共用秘鑰的方式加密時必須將秘鑰也發送對方。可究竟怎樣才能安全地轉交?在互連網上轉寄秘鑰時,如果通訊被監聽那麼秘鑰就會可落入攻擊者之手,同時也就失去了加密的意義。另外還得設法安全地保管就收到的秘鑰。

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

    公開祕密金鑰加密方式很好地解決了共用秘鑰加密的困難，公開秘鑰加密使用一對非對稱的秘鑰。一把叫做私人秘鑰(Private Key),另一把叫做公有秘鑰(Public Key )。顧名思義,私人秘鑰不能讓其他任何人知道,而公有秘鑰則可以隨意發布,任何人都可以獲得。

    使用公開秘鑰加密方式,發送密文的一方使用對方的公開秘鑰進行加密處理,對方接收到被加密的資訊後,再使用自己的私人秘鑰進行解密。利用這種方式,不需要發送解密的私人秘鑰,也就不必擔心秘鑰被攻擊者竊聽而盜走。另外想要根據密文和公開密鑰,恢複到資訊原文是異常困難的,因為解密過程就是在對離散對數進行求值,這並非輕而易舉就能辦到的,退一步講,如果對一個非常大的整數做到快速的因式分解,那麼密碼破解還是存在希望的。但就目前的技術來看是不太現實。

    ·HTTPS採用混合加密的機制

    HTTPS採用共用秘鑰加密和公開秘鑰加密兩者並用的混合加密機制。若秘鑰能夠實現安全交換,那麼有可能會考慮僅使用公開秘鑰 加密來通訊。但是公開秘鑰加密與共用秘鑰加密相比,其處理速度要慢。所以應充分利用兩者各自的優勢,將多種方法組合起來用於通訊。在交換秘鑰環節使用公開祕密金鑰加密方式,之後的建立通訊交換報文則使用共用秘鑰加密方式。

7.2.4   證明公開秘鑰正確性的認證

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

    為瞭解決上述問題,可以使用由數位憑證認證機構(CA,Certificate Authority)和其相關機關頒發的公開秘鑰認證。數位憑證認證機構處理用戶端與伺服器雙方都可信賴的第三方機構的立場上。威瑞信(VeriSign)就是其中一家非常有名的數位憑證認證機構。數位憑證認證機構的商務程序。首先伺服器的運營人員向數位憑證認證機構提出公開秘鑰的申請。數位憑證認證機構在判明提出申請者的身份後,會對已申請的公開秘鑰做數位簽章,然後分配這個已簽名的公開密鑰,並將該公開秘鑰放入密鑰憑證後綁定在一起。伺服器會將這份由數位憑證認證機構頒發的密鑰憑證發送給用戶端,以進行公開秘鑰加密通訊方式通訊。密鑰憑證也可叫做數位憑證或直接稱之為認證。    

    接到認證的用戶端可使用數位憑證認證機構的公開秘鑰,對那張認證上的數位簽章進行驗證,一旦驗證通過,用戶端便可明確兩件事,一、證明伺服器的公開秘鑰是真實有效數位憑證認證機構。二、伺服器的公開秘鑰是指的信賴的。此處認證機關的公開秘鑰必須安全地轉交給用戶端。使用通訊方式時,如何安全轉交是一件困難的事,因此,多數瀏覽器開發商發布版本時,會事先在內部植入常用的認證機關的公開秘鑰。

A :可證明組織真實性的EV SSL認證

  認證的一個作用是用來證明作為通訊方的伺服器是否規範,另外一個作用就是可以確定對方伺服器背後運營的企業是否真實存在。擁有該特徵的認證就是EV SSL認證(Extended Validation SSL Certificate).EV SSL認證是基於國際標準認證指導方針頒發的認證。其嚴格規定了對運營組織是否真實的確認方針,因此,通過認證的Web網站能夠獲得更高的認可度。持有EV SSL認證的Web網站的瀏覽器地址欄處背景色是綠色的,從視覺上就能一眼辨別出。，而且在地址欄的左側顯示了SSL認證中記錄的組織名稱以及頒發認證的認證機構的名稱。

B  :用以確認用戶端的用戶端認證

  HTTPS中還可以使用用戶端認證,以用戶端認證進行用戶端認證,證明伺服器正在通訊的對方始終是預料之內的用戶端,其作用跟伺服器憑證如出一轍。但是用戶端認證仍存在幾處問題,其中一個問題就是認證的擷取和發布。想要擷取認證時,使用者得自行安裝用戶端認證。但由於用戶端認證是付費購買的,且每張認證對應到美味使用者也就意味著需要支付 和使用者數對等的費用。另外,要讓層次不同的使用者們安裝認證,這件事本身也充滿各種挑戰,現狀是安全性極高的認證機構可頒發用戶端認證但僅用於特殊用途的業務,比如那些可支撐用戶端認證支出費用的業務。

   用戶端認證存在的另一個問題就是用戶端認證畢竟只能用來證明用戶端實際存在,而不能用來證明使用者本人的真實有效性。也就是說只要獲得了安裝有用戶端認證的電腦的使用權,也就意味著同時擁有了用戶端認證的使用許可權。

C  :認證機構信譽第一

   SSL機制中介入認證機構之所以可行,是因為建立再起信用絕對可靠這一大前提下的。ps：2011年7月荷蘭的一家名叫DigiNotar的認證機構曾遭駭客不法入侵,頒布了google.com和twitter.com等網站的偽造認證事件。這一事件從根本上撼動了SSL的可信度。因為偽造認證上有正規認證機構的數位簽章,所以瀏覽器會判定該認證是正當的。當偽造認證被用作伺服器偽裝時,使用者根本無法察覺到。雖然存在可將認證無效化的憑證撤銷清單(Certificate Revocation List，CRL)機制,以及從用戶端刪除根授權(Root Certificate Authority  ,RCA )的對策。但是距離生效還需要一段時間,而這段時間內也會有許多使用者蒙受損失時就不得而知了。

    

D  :自由認證機構頒發的認證稱為自我簽署憑證

   如果使用OpenSSL這套開來源程式,每個人都可以構建一套屬於自己的認證機構,從而給自己頒發伺服器憑證。但該伺服器憑證在互連網上不可作為認證使用,似乎沒什麼協助。獨立構建的認證機構叫做自認證機構,由自認證機構頒發的"無用"認證也被戲稱為自我簽署憑證。瀏覽器訪問該伺服器時,會顯示"無法確認串連安全性"或"該網站的安全性憑證存在問題"等警告資訊。自由認證機構頒發的伺服器憑證之所以不起作用,是因為它無法消除偽裝的可能性。自認證機構能產生的作用頂多也就是自己對外宣稱這種程度,採用自我簽署憑證,通過SSL加密之後可能偶爾還會看見通訊處於在安全狀態的提示,可那也是有問題的。因為就算是加密通訊,也不能排除正在和已經偽裝的假伺服器保持通訊。值得信賴的第三方機構介入認證時,才能讓已植入在瀏覽器內的認證機構頒發的公開秘鑰發揮作用,並藉此證明伺服器的真實性。

E  :中級認證機構的認證可能會變成自認證認證

   多數瀏覽器內預先已植入備受信賴的認證機構的認證,但也有一小部分瀏覽器會植入中級認證機構的認證。對於中級認證機構頒發的伺服器憑證,某些瀏覽器會以正規的認證來對待,可有的瀏覽器會當做自我簽署憑證。

7.2.5   HTTPS的安全通訊機制

    HTTPS的通訊步驟如下：

    步驟一：用戶端通過發送Client Hello報文開始SSL通訊。報文中包含用戶端支援的SSL的指定版本、加密組件(CipherSuite)列表(所使用的密碼編譯演算法及密鑰長度等)。

    步驟二：伺服器可進行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的通訊。

650) this.width=650;" src="http://s5.51cto.com/wyfs02/M01/89/9F/wKiom1gYXt6hjMR7AACEbQuOisA363.png-wh_500x0-wm_3-wmp_4-s_3721529606.png" title="08-03.png" alt="wKiom1gYXt6hjMR7AACEbQuOisA363.png-wh_50" />

    在以上流程中,應用程式層發送資料時會附加一種叫做MAC的報文摘要。MAC能夠查知報文是否遭到篡改,從而保護報文的完整性。 

    下面是對整個流程的圖解。圖中說明了從僅使伺服器端的公開密鑰認證(伺服器憑證)建立HTTPS通訊的整個過程。                                              

650) this.width=650;" src="http://s1.51cto.com/wyfs02/M00/89/9E/wKiom1gYUJSiSRTYAAH1p-t7OYw864.jpg-wh_500x0-wm_3-wmp_4-s_2100645252.jpg" title="08-01.jpg" alt="wKiom1gYUJSiSRTYAAH1p-t7OYw864.jpg-wh_50" />

• 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。TLS是以SSL為原型開發的協議。有時會統一稱該協議為SSL。當前主流的版本是SSL3.0和TLS1.0。由於SSL1.0協議在設計之初被發現出了問題,就沒有實際投入使用。SSL2.0也被發現存在問題,所以很多瀏覽器直接廢除了該協議版本。

• SSL速度慢嗎
  

     HTTPS也存在一些問題,那就是使用SSL時,它的處理速度會變慢。SSL的慢分兩種。一種是指通訊慢;另一種是指由於大量消耗CPU及記憶體等資源,導致處理速度變慢。和使用HTTP相比,網路負載可能會變慢2-100倍。除去和TCP串連、發送HTTP請求&響應以外,還必須進行SSL通訊。因此整體上處理通訊量不可避免會增加。另一點是SSL必須進行加密處理。在伺服器和用戶端都需要進行加密和解密的運算處理。因此從結果上來講,比起HTTP會更多地消耗伺服器和用戶端的硬體資源,導致敷在增加。

    針對速度變慢這一問題,並沒有根本性的解決方案,我們會使用SSL加速器這種(專用伺服器)硬體來改善該問題。該硬體為SSL通訊專用硬體,相對軟體來講,能夠提高數倍SSL的計算速度。僅在SSL處理時發揮SSL加速器的功效,已分擔負載。                                                650) this.width=650;" src="http://s1.51cto.com/wyfs02/M00/89/9F/wKiom1gYVyyDIV8MAAMGKKpIm1s138.png" title="08-02.png" alt="wKiom1gYVyyDIV8MAAMGKKpIm1s138.png" />              

    PS：為什麼不一直使用HTTPS

    既然HTTPS那麼安全可靠,那為何所有的Web網站不一直使用HTTPS呢？其中一個原因是,因為與純文字通訊相比,加密通訊會消耗更多的CPU及記憶體資源。如果每次通訊都加密,會消耗相當多的資源,平攤到一台電腦上時,能給處理的請求數量必定也會隨之減少。因此,如果是非敏感資訊則使用HTTP通訊,只有包含個人資訊等敏感性資料時,才利用HTTPS加密通訊。特別是每當那些訪問量較多的Web網站進行加密處理時,他們所承受的負載不容小覷。在進行加密處理時,並非對所有內容都進行加密處理,而是僅在那些需要資訊隱藏時才會加密,以節約資源。

                                                                                                                                                                                                                                                                                                                                  

讀《圖解HTTP》總結--第七章