移動安全-iOS（三）

DreamCultivator發表於2019-03-13
iOS

網路通訊

我們知道無線傳輸的資料能被第三方輕易截獲（如使用抓包工具Charles），如果未使用加密措施，可能直接暴露使用者的各種關鍵資料，例如使用者名稱，密碼等。加入了SSL（Secure Socket Layer）子層實現的HTTPS協議可確保資料在網路上加密傳輸，即使傳輸的資料被截獲，也無法解密和還原。

http不使用SSL/TLS的HTTP通訊，就是不加密的通訊。所有資訊明文傳播，帶來了三大風險。

  • 1 竊聽風險（eavesdropping）：第三方可以獲知通訊內容。
  • 2 篡改風險（tampering）：第三方可以修改通訊內容。
  • 3 冒充風險（pretending）：第三方可以冒充他人身份參與通訊。

SSL/TLS協議是為了解決這三大風險而設計的，希望達到：

  • 所有資訊都是加密傳播，第三方無法竊聽。
  • 具有校驗機制，一旦被篡改，通訊雙方會立刻發現。
  • 配備身份證書，防止身份被冒充。

網際網路是開放環境，通訊雙方都是未知身份，這為協議的設計帶來了很大的難度。而且，協議還必須能夠經受所有匪夷所思的攻擊，這使得SSL/TLS協議變得異常複雜。

基本的執行過程

SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向伺服器端索要公鑰，然後用公鑰加密資訊，伺服器收到密文後，用自己的私鑰解密。關於公鑰加密法

但是，這裡有兩個問題。

（1）如何保證公鑰不被篡改？

解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。

（2）公鑰加密計算量太大，如何減少耗用的時間？

解決方法：每一次對話（session），客戶端和伺服器端都生成一個"對話金鑰"（session key），用它來加密資訊。由於"對話金鑰"是對稱加密，所以運算速度非常快，而伺服器公鑰只用於加密"對話金鑰"本身，這樣就減少了加密運算的消耗時間。

因此，SSL/TLS協議的基本過程是這樣的：

  • 客戶端向伺服器端索要並驗證公鑰。
  • 雙方協商生成"對話金鑰"。
  • 雙方採用"對話金鑰"進行加密通訊。

上面過程的前兩步，又稱為"握手階段"（handshake）。

四、握手階段的詳細過程

移動安全-iOS（三）

"握手階段"涉及四次通訊，我們一個個來看。需要注意的是，"握手階段"的所有通訊都是明文的。

客戶端發出請求（ClientHello）

01 首先，客戶端（通常是瀏覽器）先向伺服器發出加密通訊的請求，這被叫做ClientHello請求。 在這一步，客戶端主要向伺服器提供以下資訊

  • 支援的協議版本，比如TLS 1.0版。
  • 一個客戶端生成的隨機數，稍後用於生成"對話金鑰"。
  • 支援的加密方法，比如RSA公鑰加密。
  • 支援的壓縮方法。

這裡需要注意的是，客戶端傳送的資訊之中不包括伺服器的域名。也就是說，理論上伺服器只能包含一個網站，否則會分不清應該向客戶端提供哪一個網站的數字證書。這就是為什麼通常一臺伺服器只能有一張數字證書的原因。

** 伺服器迴應（SeverHello）**

02 :伺服器收到客戶端請求後，向客戶端發出迴應，這叫做SeverHello。伺服器的迴應包含以下內容。

  • 確認使用的加密通訊協議版本，比如TLS 1.0版本。如果瀏覽器與伺服器支援的版本不一致，伺服器關閉加密通訊。
  • 一個伺服器生成的隨機數，稍後用於生成"對話金鑰"。
  • （3） 確認使用的加密方法，比如RSA公鑰加密。
  • 伺服器證書。

除了上面這些資訊，如果伺服器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。比如，金融機構往往只允許認證客戶連入自己的網路，就會向正式客戶提供USB金鑰，裡面就包含了一張客戶端證書。

03客戶端迴應

客戶端收到伺服器迴應以後，首先驗證伺服器證書。如果證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通訊。 如果證書沒有問題，客戶端就會從證書中取出伺服器的公鑰。然後，向伺服器傳送下面三項資訊。

  • 一個隨機數。該隨機數用伺服器公鑰加密，防止被竊聽。
  • 編碼改變通知，表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。
  • 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面傳送的所有內容的hash值，用來供伺服器校驗。

上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它以後，客戶端和伺服器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話金鑰"。 至於為什麼一定要用三個隨機數，來生成"會話金鑰"，dog250解釋得很好：

"不管是客戶端還是伺服器，都需要隨機數，這樣生成的金鑰才不會每次都一樣。由於SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的金鑰的隨機性。
對於RSA金鑰交換演算法來說，pre-master-key本身就是一個隨機數，再加上hello訊息中的隨機，三個隨機數通過一個金鑰匯出器最終匯出一個對稱金鑰。
pre master的存在在於SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret作為金鑰就不合適了，因此必須引入新的隨機因素，那麼客戶端和伺服器加上pre master secret三個隨機數一同生成的金鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"
複製程式碼

此外，如果前一步，伺服器要求客戶端證書，客戶端會在這一步傳送證書及相關資訊。

04 伺服器的最後迴應

伺服器收到客戶端的第三個隨機數pre-master key之後，計算生成本次會話所用的"會話金鑰"。然後，向客戶端最後傳送下面資訊。

  • 編碼改變通知，表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。
  • 伺服器握手結束通知，表示伺服器的握手階段已經結束。這一項同時也是前面傳送的所有內容的hash值，用來供客戶端校驗。

關於數字證書

該證書包含了公鑰等資訊，一般是由伺服器發給客戶端，接收方通過驗證這個證書是不是由信賴的CA簽發，或者與本地的證書相對比，來判斷證書是否可信；假如需要雙向驗證，則伺服器和客戶端都需要傳送數字證書給對方驗證；

數字證書是一個電子文件，其中包含了持有者的資訊、公鑰以及證明該證書有效的數字簽名。而數字證書以及相關的公鑰管理和驗證等技術組成了PKI（公鑰基礎設施）規範體系。一般來說，數字證書是由數字證書認證機構(Certificate authority，即CA)來負責簽發和管理，並承擔PKI體系中公鑰合法性的檢驗責任；數字證書的型別有很多，而HTTPS使用的是SSL證書。 怎麼來驗證數字證書是由CA簽發的，而不是第三方偽造的呢？ 在回答這個問題前，我們需要先了解CA的組織結構。首先，CA組織結構中，最頂層的就是根CA，根CA下可以授權給多個二級CA，而二級CA又可以授權多個三級CA，所以CA的組織結構是一個樹結構。對於SSL證書市場來說，主要被Symantec(旗下有VeriSign和GeoTrust)、Comodo SSL、Go Daddy 和 GlobalSign 瓜分。 瞭解了CA的組織結構後，來看看數字證書的簽發流程：

移動安全-iOS（三）

數字證書的簽發機構CA，在接收到申請者的資料後進行核對並確定資訊的真實有效，然後就會製作一份符合X.509標準的檔案。證書中的證書內容包含的持有者資訊和公鑰等都是由申請者提供的，而數字簽名則是CA機構對證書內容進行hash加密後得到的，而這個數字簽名就是我們驗證證書是否是有可信CA簽發的資料。

移動安全-iOS（三）

假設上圖證書是由證書籤發機構CA1簽發的。

  • 接收端接到一份數字證書Cer1後，對證書的內容做Hash得到H1；
  • 從簽發該證書的機構CA1的數字證書中找到公鑰，對證書上數字簽名進行解密，得到證書Cer1簽名的Hash摘要H2；
  • 對比H1和H2，如相等，則表示證書沒有被篡改。
  • 但這個時候還是不知道CA是否是合法的，我們看到上圖中有CA機構的數字證書，這個證書是公開的，所有人都可以獲取到。而這個證書中的數字簽名是上一級生成的，所以可以這樣一直遞迴驗證下去，直到根CA。根CA是自驗證的，即他的數字簽名是由自己的私鑰來生成的。合法的根CA會被瀏覽器和作業系統加入到權威信任CA列表中，這樣就完成了最終的驗證。所以，一定要保護好自己環境（瀏覽器/作業系統）中根CA信任列表，信任了根CA就表示信任所有根CA下所有子級CA所簽發的證書，不要隨便新增根CA證書。

一般作業系統和瀏覽器只包含根CA機構的證書，而在配置Web伺服器的HTTPS時，也會將配置整個證書鏈，所以整個校驗流程是從最後的葉子節點證書開始，用父節點校驗子節點，一層層校驗整個證書鏈的可信性。

Basic Constraint校驗漏洞 那是否不管多少層都可以這樣一直信任下去呢？理論上是可行的，但會遇到一個問題。假設我從可信CA機構購買了一張證書，使用這張證書籤發的證書是否也會被作業系統和瀏覽器信任呢？明顯是不應該相信的，因為我並不是CA機構，假如我簽發的證書也被信任的話，那我完全可以自己簽發任何域名的證書來進行偽造攻擊。這就是著名的Basic Constraint校驗漏洞，X.509證書中的Basic Constraint包含了這是不是一個CA機構，以及有效證書路徑的最大深度（即，這個CA還能否繼續簽發CA機構證書及其簽發子CA證書的路徑深度）。但在幾年前，包括微軟和Apple都爆出了沒有正確校驗這些資訊的漏洞。

Basic Constraint資訊請看下圖：

移動安全-iOS（三）
上圖是Google Internet Authority G2的證書，該證書是個CA機構證書；路徑深度為0，表示該證書無法再簽發CA證書，只能簽發客戶證書(client certificate)。
移動安全-iOS（三）
上圖是google.com的證書，這是個客戶證書(client certificate)，不可再簽發子證書，所以由該證書籤發的子證書是不會被信任的。

以上是我對TLS的學習， 主要參考文章

阮一峰：SSL/TLS協議執行機制的概述

MicroSoft TechNet： MicroSoft TechNet,

The First Few Milliseconds of an HTTPS Connection :The First Few Milliseconds of an HTTPS Connection

Transport Layer Security: en.wikipedia.org/wiki/Transp…

stackChange :How does SSL/TLS work?

Jaminzzhang :iOS安全系列之一：HTTPS

相關文章