確保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協議的請求和響應的內容,並進行解析。
加密處理防止被竊聽
目前大家正在研究的如何防止竊聽保護信息的幾種對策中,最爲普及的就是加密技術。而根據加密的對象歸納分爲了通信的加密和內容的加密。
通信的加密
一種方式就是將通信加密。HTTP協議中沒有加密機制,但是可以通過和SSL(Secure Socket Layer,安全套接層)或TLS(Transport Layer Security,安全傳輸層協議)組合使用,加密HTTP的通信內容。用SSL建立安全通信線路之後,就可以在這條線路上進行HTTP通信了。與SSL組合使用的HTTP被稱爲HTTPS(HTTP Secure ,超文本傳輸安全協議)
內容的加密
還有一種將參與通信的內容本身加密的方式。由於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 attrack ，MITM)。
如何防止篡改
雖然有使用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的顯示方式會因瀏覽器的不同而有所改變。
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是當今世界上應用最爲廣泛的網絡安全技術。
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的通信。
在以上流程中,應用層發送數據時會附加一種叫做MAC的報文摘要。MAC能夠查知報文是否遭到篡改,從而保護報文的完整性。
下面是對整個流程的圖解。圖中說明了從僅使服務器端的公開密鑰證書(服務器證書)建立HTTPS通信的整個過程。
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加速器的功效,已分擔負載。 
PS：爲什麼不一直使用HTTPS
既然HTTPS那麼安全可靠,那爲何所有的Web網站不一直使用HTTPS呢？其中一個原因是,因爲與純文本通信相比,加密通信會消耗更多的CPU及內存資源。如果每次通信都加密,會消耗相當多的資源,平攤到一臺計算機上時,能給處理的請求數量必定也會隨之減少。因此,如果是非敏感信息則使用HTTP通信,只有包含個人信息等敏感數據時,才利用HTTPS加密通信。特別是每當那些訪問量較多的Web網站進行加密處理時,他們所承受的負載不容小覷。在進行加密處理時,並非對所有內容都進行加密處理,而是僅在那些需要信息隱藏時纔會加密,以節約資源。