圖解HTTP-HTTPS筆記

一、HTTP的缺點

HTTP主要有這些不足:算法

  • 通訊使用明文(不加密),內容可能被竊聽
  • 不驗證通訊方的身份,所以有可能遭遇假裝
  • 沒法證實報文的完整性,因此有可能已遭篡改

二、HTTPS

爲了統一解決上述問題,在HTTP上再加入加密處理和認證等機制,成爲HTTPS(HTTP Secure)數組

HTTPS並不是是應用層的一種新協議。只是HTTP通訊接口部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)協議代替。一般HTTP直接和TCP通訊,當使用SSL時,則變成先和SSL通訊,再由SSL與TCP通訊。安全

採用SSL後,HTTP就擁有了加密、證書和完整性保護這些功能服務器

SSL是獨立於HTTP的協議,不光是HTTP協議,其餘運行在應用層的SMTP和Telnet等協議都可配合SSL協議使用。能夠說SSL是當今世界上應用最普遍的網絡安全技術網絡

三、加密方式

1.共享密鑰加密(Commom key crypto system),也叫作對稱密鑰加密併發

加密和解密同用一個密鑰。在加密後密鑰也會發送給對方,在通訊過程當中若是被監聽那麼密鑰就會落入攻擊者手中從而對信息解密性能

2.公開密鑰加密(Public-key-cryptography),也叫作非對稱密鑰加密加密

使用一對非對稱的密鑰,私有祕鑰和公有密鑰。私有密鑰不能讓其餘任何人知道,而公有密鑰則能夠隨意發佈。發送密文的一方使用對方的公開密鑰進行加密處理,對方收到被加密的信息後,再使用本身的私有祕鑰進行解密。利用這種方式,不須要發送私有祕鑰,從而使信息安全接口

對稱加密並不安全,而非對稱加密雖然說安全度數高,但對CPU資源的消耗大,效率低,進而影響性能。HTTPS所採用的加密方式是結合二者的混合加密機制:在交換密鑰環節使用非對稱加密方式,在創建通訊交換報文階段使用對稱加密方式網絡安全

使用對稱加密生成的key對傳輸數據加密,而後使用非對稱加密的公鑰對key加密

  • 獲取到非對稱加密的公鑰A
  • 使用對稱加密的密鑰B對數據加密
  • 使用公鑰A對密鑰B進行加密得密鑰C
  • 將密鑰B加密後的數據和密鑰C通訊

四、證書

遺憾的是,公開密鑰加密方式仍是存在一些問題:沒法證實公開密鑰自己就是貨真價實的公開密鑰。好比,正準備和某臺服務器創建公開密鑰加密方式下的通訊,如何證實收到的公開密鑰就是本來預想的那臺服務器發行的公開密鑰,或許在公開密鑰傳輸過程當中,真正的公開密鑰已經被攻擊者替換掉了

爲了解決上述問題,可使用由數組證書認證機構和其相關機關頒發的公開密鑰證書

數字證書認證機構處於客戶端與服務器雙方均可信賴的第三方機構的立場上

服務器會將由數字證書認證機構頒發的公鑰證書(數字證書)發送給客戶端,以進行公開密鑰加密方式通訊。接到證書的客戶端可以使用數字證書認證機構的公開密鑰,對那張證書上的數字簽名進行驗證,一旦驗證經過,客戶端即可明確兩件事:認證服務器的公開密鑰是真實有效的數字證書認證機構、服務器的公開密鑰是可信賴的

五、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報文

2019.7.11更新 通俗來理解:

  1. 首先,客戶端訪問服務器。客戶端會生成一個隨機數A,把隨機數A、支持的SSL版本號以及加密算法等信息發送至服務器
  2. 服務器接收到信息後,確認一下雙方的加密算法。而後服務端也生成一個隨機數B,並將隨機數B和CA證書發送給客戶端
  3. 客戶端獲得CA證書後,會去校驗該CA證書的有效性。校驗經過後,客戶端生成一個隨機數C,而後用證書中的公鑰加密隨機數C 併發送給服務端
  4. 服務端B獲得加密後的隨機數C,而後利用私鑰進行解密,獲得真正的隨機數C
  5. 客戶端和服務端都有隨機數A、隨機數B、隨機數C,而後雙方利用這三個隨機數生成一個對話密鑰。以後傳輸內容就是利用對話密鑰來進行加解密了(利用了對稱加密,通常用的都是 AES 算法)
  6. 客戶端通知服務端,指明後面的通信用對話密鑰來完成,同時通知服務器客戶端的握手過程結束
  7. 服務端通知客戶端,指明後面的通信用對話密鑰來完成,同時通知客戶端服務器的握手過程結束
  8. SSL的握手部分結束,SSL安全通道的數據通信開始.客戶端和服務器開始使用相同的對話密鑰進行數據通信

六、HTTPS不足

HTTPS也存在一些問題,如當使用SSL時,它處理速度會變慢 和使用HTTP相比,網絡負載可能會變慢2到100倍,除去和TCP鏈接、發送HTTP請求以外,還必須進行SSL通訊,所以總體上處理通訊量不可避免地增長。因爲SSL需加密傳輸,會更多地消耗資源

相關文章
相關標籤/搜索