http協議是如今網絡通訊中最經常使用的協議之一,可是因爲http協議自己並無考慮網絡安全方面的問題,所以不少基於http協議的應用都存在安全隱患。所以,咱們有必要了解這些安全問題及解決方法,以保證咱們的應用安全穩定的運行。本文簡單的介紹了網絡通訊中存在的常見問題和以及解決這些問題的一些技術,並簡介了https協議的工做原理。算法
http協議自己是基於tcp/ip協議的,所以傳輸的數據極可能會在某個網絡節點被他人截獲,並且http自己並無考慮通訊時的一些安全問題,所以,在使用http協議進行通訊時會存在不少安全隱患,歸納的來講,這些安全問題能夠分爲如下幾種:瀏覽器
爲了解決網絡通訊中的安全性問題,咱們通常會使用加密算法對傳輸的數據進行加密。加密算法通常分爲對稱加密和非對稱加密:安全
與非對稱加密相比,對稱加密最大的優勢是執行速度快,祕鑰便於管理,可是因爲對稱加密在加密和解密時使用的是同一個祕鑰,所以如何在互聯網上安全的分發祕鑰是非對稱加密最大的問題,雖然使用非對稱加密能夠對傳輸的內容進行加密,卻沒法保證祕鑰在傳輸途中不被截獲。服務器
因爲非對稱加密的公鑰是能夠公開的,解密時所需的私鑰無需再互聯網上分發,所以非對稱加密相對來講更加安全。且非對稱加密使用的祕鑰長度通常較長,破解難度相對較大,但也致使非對稱加密的執行速度較慢,不適合對大量數據進行加密。markdown
雖然使用加密技術可以保證解惑者沒法直接讀取到截獲的內容,但卻沒法解決數據在傳輸過程當中被篡改的問題。若是數據在傳輸過程當中被黑客篡改,而後黑客也使用相關的加密技術對被篡改的數據進行加密,那麼最終接受者在獲取到數據時,依然沒法判斷拿取的數據是否已經遭到篡改。網絡
咱們一般使用信息摘要算法來解決數據的完整性問題。摘要算法採用單向Hash函數將需加密的明文"摘要"成一串固定位數的密文,當原文內容發生改變時,計算獲得的摘要信息也會變得不一樣。發送者同時將原文和原文的摘要發送給接受者,接受者接收到數據後,再用一樣的摘要算法對獲取的原文內容進行計算,而後用獲得的特徵信息和發送來的特徵信息進行比較,若是相同,說明數據沒有被篡改。 tcp
經常使用的信息摘要算法以下:函數
雖然使用信息摘要能夠保證傳輸數據的完整性,可是若是發送的數據和信息摘要都被黑客截獲並修改,那麼最終接受者仍然沒法辯解獲取的數據是否和最初的發送者是否一致。爲了解決這個問題,就要使用數字簽名技術。網站
使用數字簽名技術能夠驗證數據發送方的身份,本質上也是使用的非對稱加密算法:A向B發送數據,A先使用本身的私鑰進行加密,獲得一串數字簽名,而後將本來的數據和數字簽名同時發送給B,B拿到發送來的數字簽名後,若是想要對數字簽名進行解密,就只能使用A的公鑰進行解密,若是解密成功,就說明獲得的數據確實是A發送的。加密
數字簽名一般和信息摘要技術配合使用,通常將計算出的信息摘要在進行數字簽名,這樣即便數據在發送途中被黑客截獲,因爲黑客沒法獲得本來發送者的私鑰,也就沒法對篡改後的數據進行簽名,這樣既保證了數據的完整性,也驗證了發送者的身份。
使用加密算法、信息摘要和數字簽名技術以後,雖然數據的保密性、完整性以及同新方身份的驗證都有了必定的保障,可是假如與咱們進行通訊的一方自己就是他人假裝的,這樣前面使用的加密、信息摘要和數字簽名就都沒有意義了,爲了解決這個問題,就要用到數字證書技術。https之因此更加安全,很大程度上是由於https協議使用了數字證書技術。
簡單的來講,數字證書就如同咱們的身份證通常,當咱們同某我的進行交流的時候,如何肯定對方確實是咱們想要交流的那我的?只須要讓對方出示他的身份證便可。而身份證是由政府發放的,政府做爲權威機構保證身份證的正確性。所以,在數字證書技術中,也要有一個第三方來充當這個權威機構的角色,這個第三方即數字證書認證機構,簡稱CA。若是咱們想要在應用中使用https協議,那麼咱們首先須要向CA機構申請數字證書,申請流程以下:
當客戶端使用https與服務器端進行通訊時,客戶端會先下載服務器端部署的數字證書,而後使用CA機構的公鑰(CA機構的公鑰一般會預先內置在瀏覽器或操做系統中)對證書的數字簽名進行解密,獲得數字證書的信息摘要。若是對數字簽名解密成功,則說明客戶端拿到的數字證書確實是CA機構下發給服務端的證書,這樣就能判斷出對方確實是咱們想要通訊的對象。而後客戶端會使用一樣的信息摘要算法計算數字證書的信息摘要,並將計算出的信息摘要同對數字簽名解密獲得的摘要進行對比,若是相同,說明該證書沒有遭到篡改,保證了獲取到的服務器端公鑰是完整的。
除了向CA機構申請證書意外,咱們其實也能夠本身來生成數字證書,經常使用的如使用openSSL來生成證書,可是使用自簽名證書時不安全的,由於沒有了可信賴的CA機構的擔保,客戶端即便可以拿到自簽名證書,也沒法證實這個證書確實是真正的服務器發送的證書,極可能在網絡傳輸過程當中這個證書已經被掉包了。
若是網站的服務端使用的時自簽名證書,當咱們瀏覽網站時,瀏覽器會提示訪問的網站不安全,一般會讓用戶自行選擇是否繼續訪問。
自簽名證書一般只在程序開發調試階段使用,不建議在生產環境中使用。
https協議並不是一種新的協議,而是在http協議的基礎上加入了SSL、TSL等協議,使得網絡通訊變得更加安全。
https的通訊流程能夠歸納爲如下幾步:
客戶端向服務器發送ClientHello報文以開始SSL通訊,該報文中包含了客戶端所用的SSL的版本及加密組件列表
服務器端向客戶端發送Server Hello報文,該報文中一樣包含了服務器端的SSL版本及加密組件列表
服務器端發送Certificate報文,該報文中包含了服務器端的數字證書,客戶端收到數字證書後會驗證該證書的真實性
服務器發送Server Hello Done報文,最初的SSL握手結束
客戶端發送Client Key Exchange報文,該報文中包含了客戶端生成的一種被稱爲Pre-master secret的隨機密碼串,用於在以後的http通訊中進行對稱加密。而且該報文已經使用第三部中獲取的服務器端公鑰進行加密,防止了對稱加密祕鑰被獲取。
客戶端發送Change Cipher Spec報文,告知服務端以後的通訊會使用第5步中的Pre-master secret密碼進行加密
客戶端發送Finish報文。
服務端一樣發送Change Clipher Spec報文
服務端一樣發送Finish報文
客戶端和服務器端都發送了Finish報文以後,SSL鏈接便創建完成了。以後客戶端發送普通的http請求,請求的內容會用以前的Pre-master secret進行對稱加密
服務器響應客戶端的http請求,並返回http響應,一樣會使用Pre-master secret進行對稱加密。
客戶端斷開鏈接,關閉TCP通訊
很明顯,https最大的優勢就是安全,保證了數據的保密性、完整性,驗證了通訊方的身份。可是,因爲https加入了SSL等協議,增長了握手次數,使得網絡通訊變得更加複雜,相比http,網絡負載可能會變慢2-100倍,並且因爲在通訊中加入了大量的加密解密過程,增長了cpu的負擔,加劇了服務器的壓力。所以,是否使用https協議,須要根據實際使用場景和業務需求,進行綜合的評判。
參考資料:《圖解HTTP》 上野宣 著