HTTPS(超文本傳輸安全協議),並非是應用層的一種新協議,只是HTTP通信接口部分用SSL和TLS協議代替而已。通常,HTTP直接和TCP通信。而當使用SSL時,則演變成先和SSL通信,再由SSL和TCP通信了。簡言之,所謂HTTPS,其實就是身披SSL協議這層外殼的HTTP。
在採用SSL後,HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。
對稱加密算法的加密和解密都是同一個**。
客戶端發送**至服務器,服務器接受該**,之後所有的數據傳輸都採用該**進行加密和解密。
該方法雖然可以解決明文傳輸的問題,卻存在安全隱患。在**協商階段,客戶端需要發送**給服務器,此時如果攻擊者監測到該**,就可以使用該**來解密之後所有的數據,那麼本次經對稱加密後的數據傳輸也就變爲明文傳輸。
因此,如何確保對稱加密方式中**的安全是此方式中最爲核心的問題。
非對稱加密算法需要一組**對,分別是公鑰和私鑰,這兩個**是成對出現的。公鑰加密的內容需要對應的私鑰解密,私鑰加密的內容需要對應的公鑰解密。
私鑰由服務器自己保存,公鑰發送給客戶端。客戶端拿到公鑰後可以對請求進行加密後發送給服務端,這時候就算中間被截獲,沒有私鑰也無法解密發送的內容,這樣確保了客戶端發送到服務端數據的安全。
但是,採用非對稱加密的方式只能保證客戶端到服務器的數據是安全的,並不能保證服務器到客戶端也是安全的,因此只是一種單向安全的加密方式。
混合加密算法採用非對稱加密+對稱加密結合的方式,即通信雙方所有的數據傳輸採用對稱加密,**傳輸採用非對稱加密。
服務器生成公鑰和私鑰,並將公鑰發給客戶端;客戶端生成對稱加密的**,用公鑰對該**進行加密,併發給服務器,之後所有的數據傳輸都使用該**進行加密;服務器收到該客戶端發過來的經公鑰加密的數據,使用私鑰對其解密,從而得到客戶端的**,之後所有來自該客戶端的數據,都使用該**解密。
混合加密的方式在一定程度上確實能提高數據傳輸的安全性,但是存在中間人攻擊。
因此,對於混合加密方式核心的問題在於確認公鑰是否來源於貨真價實的服務器
爲了解決上述問題,可以使用由CA機構(Certificate Authority,數字證書認證機構)和其相關機關頒發的數字證書。
數字證書包含明文和數字簽名兩部分
明文包括
數字簽名的製作過程
CA擁有非對稱加密的私鑰和公鑰
CA對證書內容進行hash得到信息摘要,即hash值。
製作數字簽名時爲什麼需要hash一次?
最顯然的是性能問題,非對稱加密效率較差,證書信息一般較長,比較耗時。而hash後得到的是固定長度的信息,這樣加密解密就會快很多。
對hash後的值用私鑰加密,得到數字簽名
瀏覽器的驗證過程
建立SSL連接
客戶端通過發送Client Hello
報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件列表(所使用的加密算法及**長度等)
服務器可進行SSL通信時,會以Server Hello
報文作爲應答。和客戶端一樣,在報文中包含SSL版本和加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的
之後服務器發送Certificate
報文,報文中包含公開**證書,即數字證書
最後服務器發送Server Hello Done
報文通知客戶端,最初階段的SSL握手協商部分結束
客戶端的TLS解析數字證書,確認證書的有效性,如果發現異常,則會彈出一個警告框,提示證書存在問題。如果證書沒有問題,就生成一個被稱爲Pre-master secret的隨機密碼串(**)
SSL第一次握手結束後,客戶端以Client Key Exchange
報文作爲響應。報文中包含通信加密中使用的隨機密碼串(**)。該報文已用步驟3的公鑰加密
接着客戶端繼續發送 Change Cigher Spec
報文。該報文會提示服務器,在此報文之後的通信會採用Pre-master secret**加密
客戶端發送Finished
報文。該報文包含連接至今全部報文的整體校驗值。這次握手是否能夠成功,要以服務器是否能夠正確揭祕該報文作爲判定標準
服務器同樣發送Finished
報文
服務器和客戶端的Finished
報文交換完畢之後,SSL連接就算建立完成。當然,通信會受到SSL的保護。從此開始進行應用層協議,即發送HTTP請求
傳輸數據
11. 應用層協議通信,即發送HTTP響應