- tcp三次握手創建鏈接
- 客戶端發送client-random+所支持的對稱和非對稱加密套件列表
- 服務端保存client-random,從中選擇一個加密套件,返回service-random和數字證書
- 客戶端收到service-random和數字證書,開始驗證數字證書的合法性以及服務器的合法性;保存公鑰,並生成pre-master隨機數用公鑰加密發送給服務器
- 服務器得到客戶端pre-master用私鑰解密;並用client-random,service-random和pre-master合成最終對稱加密的祕鑰master-secret
- 開始通訊
數字證書的驗證:git
- 客戶端用CA提供的HASH算法反算數字證書獲得信息摘要A
- 客戶端用CA的公鑰解密數字證書獲得信息摘要B
- 若是A/B一致則證書有效
注意:CA證書鏈會一直查找直根證書(操做系統內置)github
HTTP採用明文傳輸數據,在傳輸過程的每個環節都有可能被竊取或修改,這種攻擊方式叫 中間人攻擊
爲了解決該問題,在HTTP協議棧中引入 安全層(SSL/TLS)
對稱加密:加密、解密都使用相同的祕鑰。
加密流程以下:算法
- 瀏覽器發送它支持的加密套件(加密方法)列表和一個隨機數client-random
- 服務端會從加密套件列表中選擇一個加密套件,而後返回隨機數service-random
- 最好服務端和瀏覽器分別返回確認消息
存在問題:加密套件和隨機數都是用明文傳輸,很容易被劫持僞造祕鑰瀏覽器
非對稱加密:有A/B兩把祕鑰,數據要A加密要用B才能解密,反之B加密數據要用A祕鑰進行解密。
在HTTPS中經過明文傳輸的叫公鑰,服務器本身留下的不公開的叫私鑰。
加密流程以下:安全
- 瀏覽器將加密套件列表發送至服務器
- 而後服務器選加一個密套件,將公鑰經過明文發送給瀏覽器
- 雙方確認返回的消息
存在的問題:非對稱加密效率過低,沒法保證服務器發送給瀏覽器的數據安全(由於,公鑰容易得到,能夠經過公鑰解密服務器的數據,而後返回給客戶端)服務器
在傳輸過程經過對稱加密;可是獲取對稱加密的過程,非對稱加密實現。
加密流程以下:dom
- 瀏覽器向服務器發送對稱加密的套件列表、非對稱加密套件列表和隨機數client-random
- 服務保存隨機數client-random,選擇對稱加密和非對稱加密套件,而後生成隨機數service-random,並向瀏覽器發送選擇的加密套件、service-random、公鑰
- 瀏覽器保存公鑰、並生成隨機數pre-master,而後利用公鑰對pre-master加密,並向服務器發送加密後的數據
- 最好服務器用私鑰解密pre-master數據,並返回確認消息。
此時服務器、瀏覽器有了共同client-random、service-random、 pre-master,而後將這三組隨機數生成對稱祕鑰
注意:第三方劫持到pre-master也沒法解密,由於只有服務器纔有私鑰。tcp
經過對稱和非對稱混合加密方式,能夠完美實現數據的加密傳輸。
可是,沒法避免劫持DNS修改IP地址,而後經過僞造的IP創建中間站點竊取公鑰和私鑰。
因此服務器還要想瀏覽器證實「我就是我」。
經過權威機構頒發的證書(如:公安局派出所頒發身份證)
這個權威機構成爲CA(Certificate Authority),頒發的證書叫作數字證書(Digital Certificate)
對於瀏覽器來講,數字證書兩個做用:證實服務器的身份,攜帶服務器公鑰。
至此,請求流程改變以下:函數
- 服務器返回數字證書,公鑰包含在數字證書中
- 瀏覽器對了個證書驗證的過程,驗證證書以後,才繼續後續流程。
數字證書流程加密
- CA使用HASH函數計算提交明文的信息,並得出信息摘要
- CA使用它的私鑰對信息摘要進行加密(加密後的密文就是CA頒發的數字簽名)
分兩種:中間CA和根CA
根CA內嵌至操做系統,由WebTrust認證
中間CA一般辦理服務端的申請業務瀏覽器會沿着證書鏈一直查找至根證書是否在操做系統內,若是在就是合法,不然就是非法證書。