HTTP基礎知識(七)

 
7、確保Web安全的HTTPS
 
一、HTTP的缺點
  (1)通訊使用明文(不加密),內容可能會被竊聽
由於按TCP/IP協議族的工做機制,通訊內容在全部的通訊線路上都有可能遭受到窺視。即便已通過加密處理的通訊,也會被窺視到通訊內容,這點和未加密的通訊時相同的。(使用抓包工具就能夠獲取HTTP協議的請求和響應的內容,並對其進行解析)
加密的方式:
1)通訊的加密
HTTP協議可經過和SSL(Secure Socket Layer,安全套接層)或TLS(Transport Layer Security,安全層傳輸協議)的組合使用,加密HTTP的通訊內容。
與SSL組合使用的HTTP被稱爲HTTPS(HTTP Secure,超文本傳輸安全協議)或HTTP over SSL
2)內容的加密
即把HTTP報文裏所含的內容盡心加密處理。爲了作到有效的內容加密,並且要求客戶端和服務器同時具有加密和解密機制。
 
  (2)不驗證通訊方的身份,所以有可能遭遇假裝
在HTTP協議通訊時,因爲不存在確認通訊方的處理步驟,任何人均可以發起請求。
隱患:
1)沒法肯定請求發送至目標的Web服務器是否按真實意圖返回的那臺服務器。有多是已假裝的Web服務器。
2)沒法肯定響應返回到的客戶端是不是按真實意圖接收響應的那個客戶端。有多是已假裝的客戶端。
3)沒法肯定正在通訊的對方是否具有訪問權限。由於某些服務器上班保存着重要的信息,只想發給特定用戶通訊的權限。
4)沒法斷定請求是來自何方、出自誰手
5)即便是無心義的請求也會照單全收。沒法阻止海量請求下的DOS攻擊(Denial of Service,拒絕服務攻擊)
措施:
查明對方的證書
使用SSL能夠肯定通訊方,不只提供加密處理,並且還使用了一種被稱爲證書的手段,可用於肯定方。
證書由值得信任的第三方機構頒發,用以證實服務器和客戶端是實際存在的。
客戶端持有證書便可完成我的身份的確認,也可用於對Web網站的認證環節。
 
  (3)沒法證實報文的完整性,因此有可能已遭篡改
因爲HTTP協議沒法證實通訊的報文完整性,所以,在請求或響應送出以後直到對方接收以前的這段時間內,即便請求或響應的內容遭到篡改,也沒有辦法獲悉。(沒有辦法確認發出的請求/響應和接收到的請求/響應是先後相同的。)
請求或響應在傳輸途中,遭攻擊者攔截並篡改內容的攻擊成爲中間人攻擊(Man-in-the-Middle attack,MITM)
措施:
經常使用的是MD5和SHA-1等散列值校驗的方法,以及用來確認文件的數字簽名方法。
提供文件下載服務的Web網站也會提供響應的PGP(Pretty Good Privacy,完美隱私)建立的數字簽名及MD5算法生成的散列值。
可是PGP和MD5自己唄改寫的話,用戶是沒有辦法意識到的。
 
二、HTTP+加密+認證+完整性保護=HTTPS
使用HTTPS通訊時,改用https://,是身披SSL外殼的HTTP。使用SSL時,HTTP先和SSL通訊,再由SSL和TCP通訊。
SSL是獨立於HTTP的協議,許多運行在應用層的協議都可配合SSL協議使用,SSL是當今世界上應用最爲普遍的網絡安全技術。
  (1)相互交換密鑰的公開密鑰加密技術
SSL採用一種叫公開密鑰加密(Public-key crytography)的加密處理方式。即加密和解密都會用到密鑰,沒有密鑰就沒法對密碼解密。
加密和解密同用一個密鑰的方式稱爲共享密鑰,也叫對稱密鑰加密。可是這種共享密鑰的方式必須將密鑰發給對方,若是通訊被監聽就可能會落入攻擊者之手,失去了加密的意義。
公開密鑰方式很好地解決了共享密鑰加密的困難。它使用一對非對稱的密鑰,一把是私有密鑰,另外一把是公開密鑰。公開密鑰加密,私有密鑰解密,過程當中無需發送私有密鑰,不會被盜走。
HTTPS採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。
 
  (2)證實公開密鑰正確性的證書
公開密鑰加密方式沒法證實自己是貨真價實的公開密鑰。未解決此問題,可用由數字證書認證機構(CA,Certificate Authority)和其相關機關頒發的公開密鑰證書。
數字證書認證機構的業務流程:
1)服務器運營人員向機構提出公開密鑰的申請;
2)機構判明提出申請者的身份;
3)機構對申請的公開密鑰作數字簽名,將該公開密鑰放入公鑰證書後綁定在一塊兒
證書的一個做用是用來證實做爲通訊一方的服務器是否規範,另一個做用是可確認對方服務器背後運營 的企業是否真實存在。擁有該特性的證書就是EV SSL證書
 
  (3)HTTPS的安全通訊機制
HTTPS的通訊步驟:
1)客戶端經過發送Client Hello報文開始SSL通訊。報文中包含客戶端支持的SSL的指定版本、加密組件列表(所使用的加密算法及密鑰長度等)
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的通訊。
 
  應用層發送數據時附加一種叫作MAC(Message Authentication Code)的報文摘要。可以差值報文是否遭到篡改,從而保護報文的完整性。
  可是當使用SSL時,處理速度會變慢。一是通訊慢,一是因爲大量消耗CPU及內存等資源致使處理速度變慢。因此並非全部的Web網站不一直使用HTTPS,訪問量大的網站在進行加密處理時會承擔大量的負載。並且HTTPS所使用的證書必須向認證機構購買,這也是網站須要考慮到的因素。
 
 
這裏蒐集了一些大神的貼子:

HTTPS 爲何更安全,先了解一下密碼學的這些原理

相關文章
相關標籤/搜索