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的服務器了。