iOS - HTTPS接口加密和身份認證

為什么要使用HTTPS代替HTTP

HTTPS和HTTP的區別

https協議需要到CA申請證書，一般免費證書很少，需要交費。
http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的SSL加密傳輸協議。
http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

 

HTTP為什么不安全

http協議沒有任何的加密以及身份驗證的機制，非常容易遭遇竊聽、劫持、篡改，因此會造成個人隱私泄露，惡意的流量劫持等嚴重的安全問題。

就像寄信一樣，我給你寄信，中間可能會經過很多的郵遞員，他們可以拆開信讀取里面的內容，因為是明文的。如果你的信里涉及到了你們銀行賬號等敏感信息，可能就會被竊取。除此之外，郵遞員們還可以給你偽造信的內容，導致你遭到欺騙。

 

HTTPS如何保證安全

HTTPS是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。它是一個URI scheme（抽象標識符體系），句法類同http:體系。用於安全的HTTP數據傳輸。https:URL表明它使用了HTTPS，但HTTPS存在不同於HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，現在它被廣泛用於萬維網上安全敏感的通訊，例如交易支付方面。

 

HTTPS的加密原理

首先先介紹一些加密過程中用到的原理：

對稱加密

對稱加密是指加密和解密使用相同密鑰的加密算法。它要求發送方和接收方在安全通信之前，商定一個密鑰。對稱算法的安全性依賴於密鑰，泄漏密鑰就意味着任何人都可以對他們發送或接收的消息解密，所以密鑰的保密性對通信至關重要。

對稱加密算法的優、缺點：

優點：算法公開、計算量小、加密速度快、加密效率高。

缺點：

交易雙方都使用同樣鑰匙，安全性得不到保證；
每對用戶每次使用對稱加密算法時，都需要使用其他人不知道的惟一鑰匙，這會使得發收信雙方所擁有的鑰匙數量呈幾何級數增長，密鑰管理成為用戶的負擔。
能提供機密性，但是不能提供驗證和不可否認性。

 

非對稱加密算法

這種加密或許理解起來比較困難，這種加密指的是可以生成公鑰和私鑰。凡是公鑰加密的數據，公鑰自身不能解密，而需要私鑰才能解密；凡是私鑰加密的數據，私鑰不能解密，需要公鑰才能解密。這種算法事實上有很多，常用的是RSA，其基於的數學原理是兩個大素數的乘積很容易算，而拿到這個乘積去算出是哪兩個素數相乘就很復雜了，具體原理有興趣可以自行研究。

非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點：

CPU計算資源消耗非常大。一次完全TLS握手，密鑰交換時的非對稱解密計算量占整個握手過程的90%以上。而對稱加密的計算量只相當於非對稱加密的0.1%，如果應用層數據也使用非對稱加解密，性能開銷太大，無法承受。
非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是2048位，意味着待加密內容不能超過256個字節。

 

所以公鑰加密目前只能用來作密鑰交換或者內容簽名，不適合用來做應用層傳輸內容的加解密。

身份認證（CA數字證書）

https協議中身份認證的部分是由數字證書來完成的，證書由公鑰、證書主體、數字簽名等內容組成，在客戶端發起SSL請求后，服務端會將數字證書發給客戶端，客戶端會對證書進行驗證，並獲取用於秘鑰交換的非對稱密鑰。

數字證書有兩個作用：

身份授權。確保瀏覽器訪問的網站是經過CA驗證的可信任的網站。
分發公鑰。每個數字證書都包含了注冊者生成的公鑰。在SSL握手時會通過certificate消息傳輸給客戶端。

 

申請一個受信任的數字證書通常有如下流程：

終端實體（可以是一個終端硬件或者網站）生成公私鑰和證書請求。
RA（證書注冊及審核機構）檢查實體的合法性。如果個人或者小網站，這一步不是必須的。
CA（證書簽發機構）簽發證書，發送給申請者。
證書更新到repository（負責數字證書及CRL內容存儲和分發），終端后續從repository更新證書，查詢證書狀態等。

 

數字證書驗證：

申請者拿到CA的證書並部署在網站服務器端，那瀏覽器發起握手接收到證書后，如何確認這個證書就是CA簽發的呢？怎樣避免第三方偽造這個證書？答案就是數字簽名（digital signature）。數字簽名是證書的防偽標簽，目前使用最廣泛的SHA-RSA（SHA用於哈希算法，RSA用於非對稱加密算法）數字簽名的制作和驗證過程如下：

數字簽名的簽發。首先是使用哈希函數對待簽名內容進行安全哈希，生成消息摘要，然后使用CA自己的私鑰對消息摘要進行加密。
數字簽名的校驗。使用CA的公鑰解密簽名，然后使用相同的簽名函數對待簽名證書內容進行簽名並和服務端數字簽名里的簽名內容進行比較，如果相同就認為校驗成功。

 

 

需要注意的是：

1. 數字簽名簽發和校驗使用的密鑰對是CA自己的公私密鑰，跟證書申請者提交的公鑰沒有關系。
2. 數字簽名的簽發過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。
3. 現在大的CA都會有證書鏈，證書鏈的好處一是安全，保持根CA的私鑰離線使用。第二個好處是方便部署和撤銷，即如果證書出現問題，只需要撤銷相應級別的證書，根證書依然安全。
4. 根CA證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的制作和驗證。而證書鏈上的證書簽名都是使用上一級證書的密鑰對完成簽名和驗證的。
5. 怎樣獲取根CA和多級CA的密鑰對？它們是否可信？當然可信，因為這些廠商跟瀏覽器和操作系統都有合作，它們的公鑰都默認裝到了瀏覽器或者操作系統環境里。

加密的詳細過程

首先服務器端用非對稱加密（RSA）產生公鑰和私鑰。然后把公鑰發給客 戶端，路徑或許有人會截取，但是沒有用，因為用公鑰加密的文件只有私鑰可以解密，而私鑰永遠都不會離開服務器的。當公鑰到達客戶端之后，客戶端會用對稱加密產生一個秘鑰並且用公鑰來加密發送給服務器端，這個秘鑰就是以后用來通信的鑰匙。這樣服務器端收到公鑰加密的秘鑰時就可以用私鑰來解公鑰從而獲得秘鑰。這樣的話客戶端和服務器端都獲得了秘鑰，信息交流相對是安全的。流程圖如下：

聽起來確實是挺安全的，但實際上，還有一種更惡劣的攻擊是這種方法無 法防范的，這就是傳說中的“中間人攻擊”。在身份認證的過程中，出現了一個“中間人”攔截我們的信息，他有意想要知道你們的消息。我們將這個中間人稱為M。當服務器第一次給客戶端發送公鑰的時候，途徑M。M知道你要進行密鑰交換了，它把公鑰扣了下來，假裝自己是客戶端，偽造了一個偽秘鑰（對稱加密產生的），然后用服務器發來的公鑰加密了偽秘鑰發還給服務器，這樣服務器以為和客戶端完成了密鑰交換，實際上服務器是和M完成了密鑰交換（獲得了偽秘鑰）。同時M假扮成服務器自行用非對稱加密產生偽公鑰和偽私鑰，與客戶端進行秘鑰交換，拿到客戶端發送過來的秘鑰。現在客戶端拿着秘鑰，M拿着秘鑰和為偽秘鑰，服務器拿着偽秘鑰，整個交流的過程就是：

簡單點說就是：

1. 客戶端用秘鑰加密信息發送給M；
2. M收到后用秘鑰解密拿到信息，然后用偽秘鑰加密信息發送給服務器；
3. 服務器收到后用偽秘鑰解密拿到信息。

這樣中間人M就拿到了客戶端和服務器所有的交流信息。

對於這種攻擊，我們可以加上身份認證：這個時候就要引入CA證書，CA證書的原理可回到2.1.3。數字證書中包括的主要內容有：證書擁有者的個人信息、證書擁有者的公鑰、公鑰的有效期、頒發數字證書的CA、CA的數字簽名等。所以網上雙方經過相互驗證數字證書后，不用再擔心對方身份的真偽，可以放心地與對方進行交流或授予相應的資源訪問權限。

通俗一點理解就是，服務器端把公鑰交個CA證書，CA證書再包裝一層。（具體原理請回看2.3）然后再發給客戶端，這個包裝一層的意思是：保證這個證書是我（服務器）給你（客戶端的），其他人拿到了也沒有用。

最后，你可能會想既然非對稱加密可以那么安全，為什么我們不直接用它來加密信息，而是用來加密對稱加密的密鑰呢？

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

使用AFNetworking進行雙向認證

客戶端認證服務器端證書

如上圖所示客戶端想要認證服務器，首先需要和服務端的數字證書匹配（server.cer），具體方法如下。

1. 在項目中導入證書sever.cer和AFNetworking框架：
2. 然后到AFSecurityPolicy.m中重寫
3. 重寫

 

 

1 2 3

+ (instancetype)policyWithPinningMode:(AFSSLPinningMode)pinningMode

方法：

AFNetworking2是允許內嵌證書的，通過內嵌證書，AFNetworking2通過比對服務器端證書、內嵌的證書、站點域名是否一致來驗證連接的服務器是否正確。在完成以上兩條的情況下，會自動掃描bundle中.cer的文件，並引入，這樣就可以通過自簽證書來驗證服務器唯一性了。

服務器端認證客戶端

1. 服務端驗證客戶端證書，首先把服務端的證書client.p12導入到服務端的密鑰庫里，同時導入工程；
2. 在AFURLConnectionOperation.m中加入以下方法：

1. 重寫AFURLConnectionOperation.m中的- (void)connection:(NSURLConnection*)connection

如果是需要認證的時候不會先調用didReceiveResponse，而是先調用3）和2）的函數，NSURLAuthenticationChallenge是一個認證挑戰類，也就是要求客戶端進行挑戰，要接收挑戰也就是客戶端提供挑戰的憑證(用戶和密碼，或者客戶端證書，或者信任服務器證書，或者代理)，IOS提供了一個NSURLCredential的類來表示挑戰憑證。可以通過如下函數來建立挑戰憑證。所以訪問https的時候服務器認證客戶端就調用這個方法。

這兩段代碼是通過p12文件來驗證服務器的，需要自己修改的地方只有一個，那就是2）中的CFStringRefpassword =CFSTR("123456");這是p12證書的密碼，用自己的p12證書密碼替換"123456"。

控制器里如何請求

通過4.1和4.2我們的客戶端和服務器雙向認證已經設置好了，在控制器里只需要需要調用

 

1 2 3

manager.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModePublicKey];

的方法來進行雙向認證：

然后就可以訪問HTTPS的服務器了。