網絡安全與Https原理解析

http協議是如今網絡通訊中最經常使用的協議之一,可是因爲http協議自己並無考慮網絡安全方面的問題,所以不少基於http協議的應用都存在安全隱患。所以,咱們有必要了解這些安全問題及解決方法,以保證咱們的應用安全穩定的運行。本文簡單的介紹了網絡通訊中存在的常見問題和以及解決這些問題的一些技術,並簡介了https協議的工做原理。算法

http協議存在的安全問題

http協議自己是基於tcp/ip協議的,所以傳輸的數據極可能會在某個網絡節點被他人截獲,並且http自己並無考慮通訊時的一些安全問題,所以,在使用http協議進行通訊時會存在不少安全隱患,歸納的來講,這些安全問題能夠分爲如下幾種:瀏覽器

  • 信息保密性沒法獲得保障:在使用http協議進行通訊時,數據是以明文傳輸的,這也就意味着發送的信息若是中傳輸途中被他人截獲時,他人能夠直接讀取到信息中的內容。好比下圖中,客戶端向服務器發送密碼,中途被竊聽者截獲,竊聽者可直接讀取到密碼內容。

密碼被截獲.png

  • 沒法保證信息的完整性:當信息在傳輸過程當中被截獲時,別人能夠修改信息中的內容,咱們沒法肯定最終送達的信息和發送時是一致的。好比下圖,客戶端原本向服務器發送的內容是「今天是晴天」,結果中途被竊聽者篡改,到達服務器的內容變成"今天是陰天"

修改傳輸的內容.png

  • 沒法驗證信息發送者的身份:沒法肯定和咱們進行通訊的一方的真實身份,可能與咱們進行通訊的一方是黑客假裝的

通訊對象是假裝的.png

網絡安全中經常使用的技術

加密算法

爲了解決網絡通訊中的安全性問題,咱們通常會使用加密算法對傳輸的數據進行加密。加密算法通常分爲對稱加密和非對稱加密:安全

  • 對稱加密:使用單一的祕鑰進行加密,同一個祕鑰既能夠對信息進行加密,也能夠對信息進行解密,經常使用的對稱加密有如下幾種:
    • DES:使用56位祕鑰,速度較快
    • 3DES:3DES自己也是使用的DES算法進行加密,只不過3DES使用2或3條56位的密鑰對數據進行三次加密。過程以下:
    加密過程:key1加密->key2解密->key3加密 解密過程:key3解密->key2加密->key1解密
    • AES:是美國聯邦政府採用的一種區塊加密標準,用來替代原先的DES,使用12八、192或256位祕鑰進行加密,是如今最經常使用的對稱加密技術。

與非對稱加密相比,對稱加密最大的優勢是執行速度快,祕鑰便於管理,可是因爲對稱加密在加密和解密時使用的是同一個祕鑰,所以如何在互聯網上安全的分發祕鑰是非對稱加密最大的問題,雖然使用非對稱加密能夠對傳輸的內容進行加密,卻沒法保證祕鑰在傳輸途中不被截獲服務器

  • 非對稱加密:對數據進行加密和解密時所用的祕鑰是不一樣的,通訊的雙方各自持有本身的公鑰和私鑰,A向B發送數據,A使用B的公鑰進行加密,那麼B只能使用本身的私鑰才能進行解密,反之,若是B向A發送數據,那麼B須要用A的公鑰進行加密,A則須要用本身的私鑰進行解密。經常使用的非對稱加密算法有如下幾種:
    • RSA:RSA是如今使用最普遍的公鑰加密體制,一般使用512位以上的祕鑰,計算量龐大,難以被破解
    • ECC:橢圓曲線算法

因爲非對稱加密的公鑰是能夠公開的,解密時所需的私鑰無需再互聯網上分發,所以非對稱加密相對來講更加安全。且非對稱加密使用的祕鑰長度通常較長,破解難度相對較大,但也致使非對稱加密的執行速度較慢,不適合對大量數據進行加密。markdown

  • 數字信封技術:數字信封是綜合運用對稱加密和非對稱加密的一種技術,因爲對稱加密和非對稱加密各有優劣,所以數字信封技術使用對稱加密對傳輸的內容進行加密,並將對稱加密所用的祕鑰進行非對稱加密,這樣既保證了加密的效率,又保證了祕鑰的安全。

數字信封.png

信息摘要

雖然使用加密技術可以保證解惑者沒法直接讀取到截獲的內容,但卻沒法解決數據在傳輸過程當中被篡改的問題。若是數據在傳輸過程當中被黑客篡改,而後黑客也使用相關的加密技術對被篡改的數據進行加密,那麼最終接受者在獲取到數據時,依然沒法判斷拿取的數據是否已經遭到篡改。網絡

咱們一般使用信息摘要算法來解決數據的完整性問題。摘要算法採用單向Hash函數將需加密的明文"摘要"成一串固定位數的密文,當原文內容發生改變時,計算獲得的摘要信息也會變得不一樣。發送者同時將原文和原文的摘要發送給接受者,接受者接收到數據後,再用一樣的摘要算法對獲取的原文內容進行計算,而後用獲得的特徵信息和發送來的特徵信息進行比較,若是相同,說明數據沒有被篡改。 使用信息摘要驗證完整性.pngtcp

經常使用的信息摘要算法以下:函數

  • MD5:一種被普遍使用的密碼散列函數,能夠產生出一個128位的散列值
  • SHA-1:能夠生成一個被稱爲消息摘要的160位散列值,散列值一般的呈現形式爲40個十六進制數

數字簽名

雖然使用信息摘要能夠保證傳輸數據的完整性,可是若是發送的數據和信息摘要都被黑客截獲並修改,那麼最終接受者仍然沒法辯解獲取的數據是否和最初的發送者是否一致。爲了解決這個問題,就要使用數字簽名技術。網站

使用數字簽名技術能夠驗證數據發送方的身份,本質上也是使用的非對稱加密算法:A向B發送數據,A先使用本身的私鑰進行加密,獲得一串數字簽名,而後將本來的數據和數字簽名同時發送給B,B拿到發送來的數字簽名後,若是想要對數字簽名進行解密,就只能使用A的公鑰進行解密,若是解密成功,就說明獲得的數據確實是A發送的。加密

數字簽名一般和信息摘要技術配合使用,通常將計算出的信息摘要在進行數字簽名,這樣即便數據在發送途中被黑客截獲,因爲黑客沒法獲得本來發送者的私鑰,也就沒法對篡改後的數據進行簽名,這樣既保證了數據的完整性,也驗證了發送者的身份。

數字證書

使用加密算法、信息摘要和數字簽名技術以後,雖然數據的保密性、完整性以及同新方身份的驗證都有了必定的保障,可是假如與咱們進行通訊的一方自己就是他人假裝的,這樣前面使用的加密、信息摘要和數字簽名就都沒有意義了,爲了解決這個問題,就要用到數字證書技術。https之因此更加安全,很大程度上是由於https協議使用了數字證書技術。

簡單的來講,數字證書就如同咱們的身份證通常,當咱們同某我的進行交流的時候,如何肯定對方確實是咱們想要交流的那我的?只須要讓對方出示他的身份證便可。而身份證是由政府發放的,政府做爲權威機構保證身份證的正確性。所以,在數字證書技術中,也要有一個第三方來充當這個權威機構的角色,這個第三方即數字證書認證機構,簡稱CA。若是咱們想要在應用中使用https協議,那麼咱們首先須要向CA機構申請數字證書,申請流程以下:

  1. 向CA機構提交服務器端的公鑰、服務器的域名、公司的相關信息等數據
  2. CA機構對申請人的身份進行驗證經過以後會生成一個數字證書,證書中存放着服務器端的公鑰等信息,而後使用信息摘要算法生成這個證書的信息摘要,最後再使用CA機構的私鑰對信息摘要進行數字簽名。前面咱們說過,使用信息摘要配合數字簽名技術,能夠保證數據的完整性和驗證對方的身份。
  3. CA機構將最終生成的證書和數字簽名發放給申請人,申請人將證書等數據放在服務器端。

當客戶端使用https與服務器端進行通訊時,客戶端會先下載服務器端部署的數字證書,而後使用CA機構的公鑰(CA機構的公鑰一般會預先內置在瀏覽器或操做系統中)對證書的數字簽名進行解密,獲得數字證書的信息摘要。若是對數字簽名解密成功,則說明客戶端拿到的數字證書確實是CA機構下發給服務端的證書,這樣就能判斷出對方確實是咱們想要通訊的對象。而後客戶端會使用一樣的信息摘要算法計算數字證書的信息摘要,並將計算出的信息摘要同對數字簽名解密獲得的摘要進行對比,若是相同,說明該證書沒有遭到篡改,保證了獲取到的服務器端公鑰是完整的。 數字證書技術.png

自簽名證書

除了向CA機構申請證書意外,咱們其實也能夠本身來生成數字證書,經常使用的如使用openSSL來生成證書,可是使用自簽名證書時不安全的,由於沒有了可信賴的CA機構的擔保,客戶端即便可以拿到自簽名證書,也沒法證實這個證書確實是真正的服務器發送的證書,極可能在網絡傳輸過程當中這個證書已經被掉包了。

若是網站的服務端使用的時自簽名證書,當咱們瀏覽網站時,瀏覽器會提示訪問的網站不安全,一般會讓用戶自行選擇是否繼續訪問。

自簽名證書一般只在程序開發調試階段使用,不建議在生產環境中使用。

HTTPS

https協議並不是一種新的協議,而是在http協議的基礎上加入了SSL、TSL等協議,使得網絡通訊變得更加安全。

https協議通訊流程

https的通訊流程能夠歸納爲如下幾步: https協議通訊流程.png

  1. 客戶端向服務器發送ClientHello報文以開始SSL通訊,該報文中包含了客戶端所用的SSL的版本及加密組件列表

  2. 服務器端向客戶端發送Server Hello報文,該報文中一樣包含了服務器端的SSL版本及加密組件列表

  3. 服務器端發送Certificate報文,該報文中包含了服務器端的數字證書,客戶端收到數字證書後會驗證該證書的真實性

  4. 服務器發送Server Hello Done報文,最初的SSL握手結束

  5. 客戶端發送Client Key Exchange報文,該報文中包含了客戶端生成的一種被稱爲Pre-master secret的隨機密碼串,用於在以後的http通訊中進行對稱加密。而且該報文已經使用第三部中獲取的服務器端公鑰進行加密,防止了對稱加密祕鑰被獲取。

  6. 客戶端發送Change Cipher Spec報文,告知服務端以後的通訊會使用第5步中的Pre-master secret密碼進行加密

  7. 客戶端發送Finish報文。

  8. 服務端一樣發送Change Clipher Spec報文

  9. 服務端一樣發送Finish報文

  10. 客戶端和服務器端都發送了Finish報文以後,SSL鏈接便創建完成了。以後客戶端發送普通的http請求,請求的內容會用以前的Pre-master secret進行對稱加密

  11. 服務器響應客戶端的http請求,並返回http響應,一樣會使用Pre-master secret進行對稱加密。

  12. 客戶端斷開鏈接,關閉TCP通訊

https的優缺點:

很明顯,https最大的優勢就是安全,保證了數據的保密性、完整性,驗證了通訊方的身份。可是,因爲https加入了SSL等協議,增長了握手次數,使得網絡通訊變得更加複雜,相比http,網絡負載可能會變慢2-100倍,並且因爲在通訊中加入了大量的加密解密過程,增長了cpu的負擔,加劇了服務器的壓力。所以,是否使用https協議,須要根據實際使用場景和業務需求,進行綜合的評判。

參考資料:《圖解HTTP》 上野宣 著

相關文章
相關標籤/搜索