iOS 基于AFNetworking下自簽名證書配置的方法
自從https推出以后,客戶端對(duì)網(wǎng)絡(luò)安全的要求程度也越來越高。甚至在iOS9之后,蘋果強(qiáng)制要求必須支持https請(qǐng)求。
https是什么呢?它又是如何保證數(shù)據(jù)安全的呢?
簡(jiǎn)單來說,https就是http+TLS/SSL。就是在http上又加了一層處理加密信息的模塊。服務(wù)端和客戶端的信息傳輸都會(huì)通過TLS進(jìn)行加密,也就說傳輸中的數(shù)據(jù)都是加密的,如果不知道私鑰,是無法真正知道傳輸內(nèi)容的真正意思的。
整個(gè)https單向驗(yàn)證流程簡(jiǎn)單總結(jié)如下:
- 就是用戶發(fā)起請(qǐng)求,服務(wù)器響應(yīng)后返回一個(gè)證書,證書中包含一些基本信息和公鑰。
- 用戶拿到證書后,去驗(yàn)證這個(gè)證書是否合法,不合法,則請(qǐng)求終止。
- 合法則生成一個(gè)隨機(jī)數(shù),作為對(duì)稱加密的密鑰,用服務(wù)器返回的公鑰對(duì)這個(gè)隨機(jī)數(shù)加密。然后返回給服務(wù)器。
- 服務(wù)器拿到加密后的隨機(jī)數(shù),利用私鑰解密,然后再用解密后的隨機(jī)數(shù)(對(duì)稱密鑰),把需要返回的數(shù)據(jù)加密,加密完成后數(shù)據(jù)傳輸給用戶。
- 最后用戶拿到加密的數(shù)據(jù),用一開始的那個(gè)隨機(jī)數(shù)(對(duì)稱密鑰),進(jìn)行數(shù)據(jù)解密。整個(gè)過程完成。
當(dāng)然這僅僅是一個(gè)單向認(rèn)證,https還會(huì)有雙向認(rèn)證,相對(duì)于單向認(rèn)證也很簡(jiǎn)單。僅僅多了服務(wù)端驗(yàn)證客戶端這一步。
那么在AFNetworking中,我們要完成自簽名證書配置:
// 自簽名證書在路徑 NSString *certFilePath = [[NSBundle mainBundle] pathForResource:@"service" ofType:@"cer"]; // 自簽名證書轉(zhuǎn)換成二進(jìn)制數(shù)據(jù) NSData *certData = [NSData dataWithContentsOfFile:certFilePath]; // 將二進(jìn)制數(shù)據(jù)放到NSSet中 NSSet *certSet = [NSSet setWithObject:certData]; /* AFNetworking中的AFSecurityPolicy實(shí)例化方法 第一個(gè)參數(shù): AFSSLPinningModeNone, //不驗(yàn)證 AFSSLPinningModePublicKey, //只驗(yàn)證公鑰 AFSSLPinningModeCertificate, //驗(yàn)證證書 第二個(gè)參數(shù):存放二進(jìn)制證書數(shù)據(jù)的NSSet */ AFSecurityPolicy *policy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate withPinnedCertificates:certSet]; // shareManager 是繼承自AFHTTPSessionManager的一個(gè)類的實(shí)例對(duì)象 sharedManager.securityPolicy = policy;
這樣在請(qǐng)求時(shí),如果服務(wù)器要校驗(yàn)自簽名證書就會(huì)調(diào)用AFSecurityPolicy類中以下方法
- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust
forDomain:(NSString *)domain
AFNetworking就是在這個(gè)方法中進(jìn)行的單向驗(yàn)證。如果有需要雙向驗(yàn)證的也需要重寫這個(gè)方法,以實(shí)現(xiàn)雙向驗(yàn)證。(雙向驗(yàn)證在銀行類等app中使用的較多)
在該方法中使用自簽名證書可能會(huì)出現(xiàn)的一個(gè)問題就是
[pinnedCertificates addObject:(__bridge_transfer id)SecCertificateCreateWithData(NULL, (__bridge CFDataRef)certificateData)];
這行代碼有可能數(shù)組中添加了nil,即自簽名證書沒有獲取到。
解決方法:
- 將后端發(fā)過來的.crt證書,修改后綴.cer,導(dǎo)入鑰匙串。
- 再?gòu)蔫€匙串導(dǎo)出該證書,拉到項(xiàng)目里直接使用
其本質(zhì)原因是后端的自簽名證書需要進(jìn)行base64反編碼才能使用。
總結(jié)語(yǔ):
通過對(duì)自簽名證書這塊的研究,對(duì)https有了更加深入、更深刻的認(rèn)識(shí),同時(shí)對(duì)AFNetworking中AFSecurityPolicy的源碼進(jìn)行了閱讀和理解。
以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
- iOS實(shí)現(xiàn)電子簽名
- iOS mobileconfig配置文件進(jìn)行簽名的配置方法
- iOS 超級(jí)簽名之描述文件的實(shí)現(xiàn)過程
- iOS應(yīng)用腳本重簽名的實(shí)現(xiàn)方法
- iOS APP簽名機(jī)制原理詳解
- 詳解IOS微信上Vue單頁(yè)面應(yīng)用JSSDK簽名失敗解決方案
- Android和iOS包批量重簽名
- iOS安全防護(hù)系列之重簽名防護(hù)與sysctl反調(diào)試詳解
- iOS中的ipa重簽名(逆向必備)
- iOS之Https自簽名證書認(rèn)證及數(shù)據(jù)請(qǐng)求的封裝原理
- IOS 簽名錯(cuò)誤codesign failed with exit code 1解決方法
- ios的簽名機(jī)制詳解
相關(guān)文章
iOS表視圖之下拉刷新控件功能的實(shí)現(xiàn)方法
下拉刷新是重新刷新表視圖或列表,以便重新加載數(shù)據(jù),這種模式廣泛用于移動(dòng)平臺(tái),相信大家對(duì)于此也是非常熟悉的,那么iOS是如何做到的下拉刷新呢?下面小編給大家分享iOS表視圖之下拉刷新控件的實(shí)現(xiàn)方法,一起看看吧2017-01-01
iOS10語(yǔ)音識(shí)別框架SpeechFramework應(yīng)用詳解
在iOS10系統(tǒng)了,apple開放了與語(yǔ)音識(shí)別相關(guān)的接口,開發(fā)者可以將其應(yīng)用到自己的App中,實(shí)現(xiàn)用戶通過語(yǔ)音進(jìn)行功能操作。 這篇文章主要介紹了iOS10語(yǔ)音識(shí)別框架SpeechFramework應(yīng)用,需要的朋友可以參考下2016-09-09
IOS應(yīng)用內(nèi)支付返回新舊Receipt適配的方法
本篇文章主要介紹了IOS應(yīng)用內(nèi)支付返回新舊Receipt適配的方法,小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2017-12-12
iOS應(yīng)用中發(fā)送HTTP的get請(qǐng)求以及HTTP異步請(qǐng)求的方法
這篇文章主要介紹了iOS應(yīng)用中發(fā)送HTTP的get請(qǐng)求以及HTTP異步請(qǐng)求的方法,代碼為傳統(tǒng)的Objective-C語(yǔ)言,說明都簡(jiǎn)單地融入于注釋之中,需要的朋友可以參考下2016-02-02
實(shí)例解析設(shè)計(jì)模式中的外觀模式在iOS App開發(fā)中的運(yùn)用
這篇文章主要介紹了設(shè)計(jì)模式中的外觀模式在iOS App開發(fā)中的運(yùn)用,實(shí)例代碼為傳統(tǒng)的Objective-C,需要的朋友可以參考下2016-03-03

