https祕鑰互動

想想還是算了發表於2018-10-17

https和http的區別

  • http是超文字傳輸協議,資訊是明文傳輸,https則是具有安全性的SSL加密傳輸協議
  • http和https使用的是完全不同的連線方式,用的埠也不一樣,前者是80,後者是443
  • http的連線很簡單,是無狀態的;HTTPS協議是由SSL(現在是TLS)+HTTP協議構建的可進行加密傳輸、身份認證的網路協議,比http協議安全。

進行TLS握手前的TCP 三次握手必不可少,這裡描述的場景假設已經完成了 TCP 三次握手:
1.“往”、由客戶端在一個型別為 Client Hello 的 TLS 握手包中攜帶客戶端執行的TLS 協議版本,支援的金鑰交換演算法集合(加密套件列表)傳送至伺服器端
2.“返”、伺服器在一個型別 Server Hello 的 TLS 握手包中攜帶選取的特定金鑰交換演算法,在型別為 Certificate 的 TLS 握手包中攜帶自己的數字證書公鑰(或層級信任關係的證書鏈),以及一個型別為 Server Hello Done 的 TLS 握手包傳送給客戶端,客戶端遍歷本地檔案系統中的所有已匯入的 CA(證書頒發機構)證書,嘗試驗證伺服器的證書確實由其聲稱的那個 CA 機構所簽發,如果驗證失敗,則提示使用者該伺服器證書不可信,並詢問是否“手動”設定信任關係,或者拒絕,如果驗證成功,不向使用者顯示任何資訊。
3.“往”、客戶端用先前與伺服器協商的金鑰交換演算法(通常為對稱加密演算法,如果為 RSA 則為非對稱加密演算法)生成一個隨機金鑰,它將用於兩者會話的“鑰匙”,然後客戶端再用伺服器的證書公鑰來加密這個會話鑰匙,並通過 Change Cipher Spec Protocol(變更密碼通知協議),在一個型別為 Client Key Exchange 的 TLS 握手包中攜帶,傳送至伺服器端。
4.“返”、伺服器收到後,用自己的證書私鑰,解開這個會話鑰匙(公鑰加密私鑰解密),如果解密失敗,說明客戶端的身份不可信(可能是一箇中間人截獲與原來的客戶端通訊後,偽造的,但是由於該中間人無法偽造最先兩者使用的協商協議,因此伺服器端也就不能用私鑰解開偽造的會話金鑰) 如果伺服器端解密成功,則說明客戶端是合法的,伺服器在型別為 Change Cipher Spec Protocol 的 TLS 記錄層中包含 Finished 握手包,返回給客戶端,表明客戶端的身份通過驗證;

客戶端收到通知後(解密 Finished 握手包後),開始用協商好的會話鑰匙(客戶端在第二次“往”中傳送的隨機金鑰,此刻不需要再用伺服器公鑰加密,前面加密的目的在於驗證客戶端的身份)來加密併傳送 HTTP 請求;伺服器用相同的會話鑰匙解密並讀取 HTTP 請求,加密並返回 HTTP 響應,瀏覽器用會話鑰匙解密並讀取 HTTP 響應。。。如此反覆,構成完整的 HTTPS 通訊流量。

身份認證(CA數字證書)

證書由公鑰、證書主體、數字簽名等內容組成,在客戶端發起SSL請求後,服務端會將數字證書發給客戶端,客戶端會對證書進行驗證,並獲取用於祕鑰交換的非對稱金鑰。
數字證書驗證:
申請者拿到CA的證書並部署在網站伺服器端,那瀏覽器發起握手接收到證書後,如何確認這個證書就是CA簽發的呢?怎樣避免第三方偽造這個證書?答案就是數字簽名(digital signature)。數字簽名是證書的防偽標籤,目前使用最廣泛的SHA-RSA(SHA用於雜湊演算法,RSA用於非對稱加密演算法)數字簽名的製作和驗證過程如下:

數字簽名的簽發。首先是使用雜湊函式對待簽名內容進行安全雜湊,生成訊息摘要,然後使用CA自己的私鑰對訊息摘要進行加密。
數字簽名的校驗。使用CA的公鑰解密簽名,然後使用相同的簽名函式對待簽名證書內容進行簽名並和服務端數字簽名裡的簽名內容進行比較,如果相同就認為校驗成功。
複製程式碼

https協議就是http+ssl協議,如下圖所示為其連線過程:

https祕鑰互動

中間人劫持攻擊

https祕鑰互動

預防中間人攻擊:
這種攻擊,我們可以加上身份認證:這個時候就要引入CA證書。數字證書中包括的主要內容有:證書擁有者的個人資訊、證書擁有者的公鑰、公鑰的有效期、頒發數字證書的CA、CA的數字簽名等。所以網上雙方經過相互驗證數字證書後,不用再擔心對方身份的真偽,可以放心地與對方進行交流或授予相應的資源訪問許可權。
伺服器端把公鑰交個CA證書,CA證書再包裝一層。然後再發給客戶端,這個包裝一層的意思是:保證這個證書是我(伺服器)給你(客戶端的),其他人拿到了也沒有用

最後,你可能會想既然非對稱加密可以那麼安全,為什麼我們不直接用它來加密資訊,而是用來加密對稱加密的金鑰呢?

這是因為非對稱加密的密碼對生成和加密的消耗時間比較長,為了節省雙方的計算時間,通常只用它來交換金鑰,而非直接用來傳輸資料(具體的可看上文非對稱加密的缺點)。

AFNetworking證書驗證:

相關文章