作者：Jaminzzhang

如何打造一個(gè)安全的App棕硫？這是每一個(gè)移動(dòng)開(kāi)發(fā)者必須面對(duì)的問(wèn)題。在移動(dòng)App開(kāi)發(fā)領(lǐng)域袒啼，開(kāi)發(fā)工程師對(duì)于安全方面的考慮普遍比較欠缺哈扮，而由于iOS平臺(tái)的封閉性，遭遇到的安全問(wèn)題相比于Android來(lái)說(shuō)要少得多蚓再，這就導(dǎo)致了許多iOS開(kāi)發(fā)人員對(duì)于安全性方面沒(méi)有太多的深入滑肉，但對(duì)于一個(gè)合格的軟件開(kāi)發(fā)者來(lái)說(shuō)，安全知識(shí)是必備知識(shí)之一摘仅。

對(duì)于未越獄的iOS設(shè)備來(lái)說(shuō)靶庙，由于強(qiáng)大的沙箱和授權(quán)機(jī)制，以及Apple自己掌控的App Store娃属， 基本上杜絕了惡意軟件的入侵六荒。但除系統(tǒng)安全之外，我們還是面臨很多的安全問(wèn)題：網(wǎng)絡(luò)安全膳犹、數(shù)據(jù)安全等恬吕，每一項(xiàng)涉及也非常廣，安全是非常大的課題须床，本人并非專業(yè)的安全專家铐料，只是從開(kāi)發(fā)者的角度，分析我們常遇到的各項(xiàng)安全問(wèn)題豺旬，并提出通常的解決方法钠惩，與各位交流。

每一個(gè)軟件工程師都有義務(wù)保護(hù)用戶數(shù)據(jù)的隱私和安全族阅。

首先是網(wǎng)絡(luò)安全篓跛，OSI模型各層都會(huì)面臨相應(yīng)的網(wǎng)絡(luò)安全問(wèn)題，涉及寬廣坦刀，而網(wǎng)絡(luò)安全也是安全領(lǐng)域發(fā)展最為繁榮的領(lǐng)域愧沟。本文我們只是從移動(dòng)應(yīng)用開(kāi)發(fā)角度蔬咬，以盡量簡(jiǎn)單的方式，講解HTTPS核心概念知識(shí)沐寺，以及在iOS平臺(tái)上的實(shí)現(xiàn)林艘。建議現(xiàn)在還在使用HTTP的應(yīng)用都升級(jí)到HTTPS。

引讀：互聯(lián)網(wǎng)全站HTTPS的時(shí)代已經(jīng)到來(lái)

1. HTTPS

其實(shí)HTTPS從最終的數(shù)據(jù)解析的角度混坞，與HTTP沒(méi)有任何的區(qū)別狐援，HTTPS就是將HTTP協(xié)議數(shù)據(jù)包放到SSL/TSL層加密后，在TCP/IP層組成IP數(shù)據(jù)報(bào)去傳輸究孕，以此保證傳輸數(shù)據(jù)的安全啥酱；而對(duì)于接收端，在SSL/TSL將接收的數(shù)據(jù)包解密之后厨诸，將數(shù)據(jù)傳給HTTP協(xié)議層镶殷，就是普通的HTTP數(shù)據(jù)。HTTP和SSL/TSL都處于OSI模型的應(yīng)用層泳猬。從HTTP切換到HTTPS是一個(gè)非常簡(jiǎn)單的過(guò)程批钠，在做具體的切換操作之前，我們需要了解幾個(gè)概念：

SSL/TSL

關(guān)于SSL/TSL得封，阮一峰的兩篇博客文章做了很好的介紹：

SSL/TLS協(xié)議運(yùn)行機(jī)制的概述

圖解SSL/TLS協(xié)議

簡(jiǎn)單的來(lái)說(shuō)埋心，SSL/TSL通過(guò)四次握手，主要交換三個(gè)信息：

1. 數(shù)字證書(shū)：該證書(shū)包含了公鑰等信息忙上，一般是由服務(wù)器發(fā)給客戶端拷呆，接收方通過(guò)驗(yàn)證這個(gè)證書(shū)是不是由信賴的CA簽發(fā)，或者與本地的證書(shū)相對(duì)比疫粥，來(lái)判斷證書(shū)是否可信茬斧；假如需要雙向驗(yàn)證，則服務(wù)器和客戶端都需要發(fā)送數(shù)字證書(shū)給對(duì)方驗(yàn)證梗逮；

2. 三個(gè)隨機(jī)數(shù)：這三個(gè)隨機(jī)數(shù)構(gòu)成了后續(xù)通信過(guò)程中用來(lái)對(duì)數(shù)據(jù)進(jìn)行對(duì)稱加密解密的“對(duì)話密鑰”项秉。

首先客戶端先發(fā)第一個(gè)隨機(jī)數(shù)N1，然后服務(wù)器回了第二個(gè)隨機(jī)數(shù)N2（這個(gè)過(guò)程同時(shí)把之前提到的證書(shū)發(fā)給客戶端）慷彤，這兩個(gè)隨機(jī)數(shù)都是明文的娄蔼；而第三個(gè)隨機(jī)數(shù)N3（這個(gè)隨機(jī)數(shù)被稱為Premaster secret），客戶端用數(shù)字證書(shū)的公鑰進(jìn)行非對(duì)稱加密底哗，發(fā)給服務(wù)器岁诉；而服務(wù)器用只有自己知道的私鑰來(lái)解密，獲取第三個(gè)隨機(jī)數(shù)跋选。只有涕癣，服務(wù)端和客戶端都有了三個(gè)隨機(jī)數(shù)N1+N2+N3，然后兩端就使用這三個(gè)隨機(jī)數(shù)來(lái)生成“對(duì)話密鑰”前标，在此之后的通信都是使用這個(gè)“對(duì)話密鑰”來(lái)進(jìn)行對(duì)稱加密解密坠韩。因?yàn)檫@個(gè)過(guò)程中距潘，服務(wù)端的私鑰只用來(lái)解密第三個(gè)隨機(jī)數(shù)，從來(lái)沒(méi)有在網(wǎng)絡(luò)中傳輸過(guò)同眯，這樣的話绽昼，只要私鑰沒(méi)有被泄露，那么數(shù)據(jù)就是安全的须蜗。

3. 加密通信協(xié)議：就是雙方商量使用哪一種加密方式，假如兩者支持的加密方式不匹配目溉，則無(wú)法進(jìn)行通信明肮；

有個(gè)常見(jiàn)的問(wèn)題，關(guān)于隨機(jī)數(shù)為什么要三個(gè)缭付？只最后一個(gè)隨機(jī)數(shù)N3不可以么柿估？

這是由于SSL/TLS設(shè)計(jì)，就假設(shè)服務(wù)器不相信所有的客戶端都能夠提供完全隨機(jī)數(shù)陷猫，假如某個(gè)客戶端提供的隨機(jī)數(shù)不隨機(jī)的話秫舌，就大大增加了“對(duì)話密鑰”被破解的風(fēng)險(xiǎn)，所以由三組隨機(jī)數(shù)組成最后的隨機(jī)數(shù)绣檬，保證了隨機(jī)數(shù)的隨機(jī)性足陨，以此來(lái)保證每次生成的“對(duì)話密鑰”安全性。

數(shù)字證書(shū)

數(shù)字證書(shū)是一個(gè)電子文檔娇未，其中包含了持有者的信息墨缘、公鑰以及證明該證書(shū)有效的數(shù)字簽名。而數(shù)字證書(shū)以及相關(guān)的公鑰管理和驗(yàn)證等技術(shù)組成了PKI（公鑰基礎(chǔ)設(shè)施）規(guī)范體系零抬。一般來(lái)說(shuō)镊讼，數(shù)字證書(shū)是由數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)(Certificate authority，即CA)來(lái)負(fù)責(zé)簽發(fā)和管理平夜，并承擔(dān)PKI體系中公鑰合法性的檢驗(yàn)責(zé)任蝶棋；數(shù)字證書(shū)的類型有很多，而HTTPS使用的是SSL證書(shū)忽妒。

怎么來(lái)驗(yàn)證數(shù)字證書(shū)是由CA簽發(fā)的玩裙，而不是第三方偽造的呢？ 在回答這個(gè)問(wèn)題前锰扶，我們需要先了解CA的組織結(jié)構(gòu)献酗。首先，CA組織結(jié)構(gòu)中坷牛，最頂層的就是根CA罕偎，根CA下可以授權(quán)給多個(gè)二級(jí)CA，而二級(jí)CA又可以授權(quán)多個(gè)三級(jí)CA京闰，所以CA的組織結(jié)構(gòu)是一個(gè)樹(shù)結(jié)構(gòu)颜及。對(duì)于SSL證書(shū)市場(chǎng)來(lái)說(shuō)甩苛，主要被Symantec(旗下有VeriSign和GeoTrust)、Comodo SSL俏站、Go Daddy 和 GlobalSign 瓜分讯蒲。 了解了CA的組織結(jié)構(gòu)后，來(lái)看看數(shù)字證書(shū)的簽發(fā)流程：

數(shù)字證書(shū)的簽發(fā)機(jī)構(gòu)CA肄扎，在接收到申請(qǐng)者的資料后進(jìn)行核對(duì)并確定信息的真實(shí)有效墨林，然后就會(huì)制作一份符合X.509標(biāo)準(zhǔn)的文件。證書(shū)中的證書(shū)內(nèi)容包括了持有者信息和公鑰等都是由申請(qǐng)者提供的犯祠，而數(shù)字簽名則是CA機(jī)構(gòu)對(duì)證書(shū)內(nèi)容進(jìn)行hash加密后等到的旭等，而這個(gè)數(shù)字簽名就是我們驗(yàn)證證書(shū)是否是有可信CA簽發(fā)的數(shù)據(jù)。

接收端接到一份數(shù)字證書(shū)Cer1后衡载，對(duì)證書(shū)的內(nèi)容做Hash等到H1搔耕；然后在簽發(fā)該證書(shū)的機(jī)構(gòu)CA1的數(shù)字證書(shū)中找到公鑰，對(duì)證書(shū)上數(shù)字簽名進(jìn)行解密痰娱，得到證書(shū)Cer1簽名的Hash摘要H2弃榨；對(duì)比H1和H2，假如相等梨睁，則表示證書(shū)沒(méi)有被篡改鲸睛。但這個(gè)時(shí)候還是不知道CA是否是合法的，我們看到上圖中有CA機(jī)構(gòu)的數(shù)字證書(shū)而姐，這個(gè)證書(shū)是公開(kāi)的腊凶，所有人都可以獲取到。而這個(gè)證書(shū)中的數(shù)字簽名是上一級(jí)生成的拴念，所以可以這樣一直遞歸驗(yàn)證下去钧萍，直到根CA。根CA是自驗(yàn)證的政鼠，即他的數(shù)字簽名是由自己的私鑰來(lái)生成的风瘦。合法的根CA會(huì)被瀏覽器和操作系統(tǒng)加入到權(quán)威信任CA列表中，這樣就完成了最終的驗(yàn)證公般。所以万搔，一定要保護(hù)好自己環(huán)境（瀏覽器/操作系統(tǒng)）中根CA信任列表，信任了根CA就表示信任所有根CA下所有子級(jí)CA所簽發(fā)的證書(shū)官帘，不要隨便添加根CA證書(shū)瞬雹。

了解了上面兩個(gè)概念之后，對(duì)HTTPS就有了個(gè)初步的了解刽虹，下面我們看如何在iOS上實(shí)現(xiàn)對(duì)HTTPS的支持酗捌。

2. 實(shí)現(xiàn)支持HTTPS

首先，需要明確你使用HTTP/HTTPS的用途，因?yàn)镺SX和iOS平臺(tái)提供了多種API胖缤，來(lái)支持不同的用途尚镰，官方文檔《Making HTTP and HTTPS Requests》有詳細(xì)的說(shuō)明，而文檔《HTTPS Server Trust Evaluation》則詳細(xì)講解了HTTPS驗(yàn)證相關(guān)知識(shí)哪廓，這里就不多說(shuō)了狗唉。本文主要講解我們最常用的NSURLConnection支持HTTPS的實(shí)現(xiàn)（NSURLSession的實(shí)現(xiàn)方法類似，只是要求授權(quán)證明的回調(diào)不一樣而已）涡真，以及怎么樣使用AFNetworking這個(gè)非常流行的第三方庫(kù)來(lái)支持HTTPS分俯。本文假設(shè)你對(duì)HTTP以及NSURLConnection的接口有了足夠的了解。

驗(yàn)證證書(shū)的API

相關(guān)的Api在Security Framework中哆料，驗(yàn)證流程如下：

1). 第一步澳迫，先獲取需要驗(yàn)證的信任對(duì)象(Trust Object)。這個(gè)Trust Object在不同的應(yīng)用場(chǎng)景下獲取的方式都不一樣剧劝，對(duì)于NSURLConnection來(lái)說(shuō)，是從delegate方法-connection:willSendRequestForAuthenticationChallenge:回調(diào)回來(lái)的參數(shù)challenge中獲取([challenge.protectionSpace serverTrust])抓歼。

2). 使用系統(tǒng)默認(rèn)驗(yàn)證方式驗(yàn)證Trust Object讥此。SecTrustEvaluate會(huì)根據(jù)Trust Object的驗(yàn)證策略，一級(jí)一級(jí)往上谣妻，驗(yàn)證證書(shū)鏈上每一級(jí)數(shù)字簽名的有效性（上一部分有講解）萄喳，從而評(píng)估證書(shū)的有效性。

3). 如第二步驗(yàn)證通過(guò)了蹋半，一般的安全要求下他巨，就可以直接驗(yàn)證通過(guò)，進(jìn)入到下一步：使用Trust Object生成一份憑證([NSURLCredential credentialForTrust:serverTrust])减江，傳入challenge的sender中([challenge.sender useCredential:cred forAuthenticationChallenge:challenge])處理染突，建立連接。

4). 假如有更強(qiáng)的安全要求辈灼，可以繼續(xù)對(duì)Trust Object進(jìn)行更嚴(yán)格的驗(yàn)證份企。常用的方式是在本地導(dǎo)入證書(shū)，驗(yàn)證Trust Object與導(dǎo)入的證書(shū)是否匹配巡莹。更多的方法可以查看Enforcing Stricter Server Trust Evaluation司志，這一部分在講解AFNetworking源碼中會(huì)講解到。

5). 假如驗(yàn)證失敗降宅，取消此次Challenge-Response Authentication驗(yàn)證流程骂远，拒絕連接請(qǐng)求。

ps: 假如是自建證書(shū)的腰根，則會(huì)跳過(guò)第二步激才，使用第三部進(jìn)行驗(yàn)證，因?yàn)樽越ㄗC書(shū)的根CA的數(shù)字簽名未在操作系統(tǒng)的信任列表中。

iOS授權(quán)驗(yàn)證的API和流程大概了解了贸营，下面吨述，我們看看在NSURLConnection中的代碼實(shí)現(xiàn)：

使用NSURLConnection支持HTTPS的實(shí)現(xiàn)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27//?Now?start?the?connection

NSURL?*?httpsURL?=?[NSURL?URLWithString:@"https://www.google.com"];

self.connection?=?[NSURLConnection?connectionWithRequest:[NSURLRequest?requestWithURL:httpsURL]?delegate:self];

//回調(diào)

-?(void)connection:(NSURLConnection?*)connection?willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge?*)challenge?{

//1)獲取trust?object

SecTrustRef?trust?=?challenge.protectionSpace.serverTrust;

SecTrustResultType?result;

//2)SecTrustEvaluate對(duì)trust進(jìn)行驗(yàn)證

OSStatus?status?=?SecTrustEvaluate(trust,?&result);

if(status?==?errSecSuccess?&&

(result?==?kSecTrustResultProceed?||

result?==?kSecTrustResultUnspecified))?{

//3)驗(yàn)證成功，生成NSURLCredential憑證cred钞脂，告知challenge的sender使用這個(gè)憑證來(lái)繼續(xù)連接

NSURLCredential?*cred?=?[NSURLCredential?credentialForTrust:trust];

[challenge.sender?useCredential:cred?forAuthenticationChallenge:challenge];

}else{

//5)驗(yàn)證失敗揣云，取消這次驗(yàn)證流程

[challenge.sender?cancelAuthenticationChallenge:challenge];

}

}

上面是代碼是通過(guò)系統(tǒng)默認(rèn)驗(yàn)證流程來(lái)驗(yàn)證證書(shū)的。假如我們是自建證書(shū)的呢冰啃？這樣Trust Object里面服務(wù)器的證書(shū)因?yàn)椴皇强尚湃蔚腃A簽發(fā)的邓夕，所以直接使用SecTrustEvaluate進(jìn)行驗(yàn)證是不會(huì)成功。又或者阎毅，即使服務(wù)器返回的證書(shū)是信任CA簽發(fā)的焚刚，又如何確定這證書(shū)就是我們想要的特定證書(shū)？這就需要先在本地導(dǎo)入證書(shū)扇调，設(shè)置成需要驗(yàn)證的Anchor Certificate(就是根證書(shū))矿咕，再調(diào)用SecTrustEvaluate來(lái)驗(yàn)證。代碼如下

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29//先導(dǎo)入證書(shū)

NSString?*?cerPath?=?...;//證書(shū)的路徑

NSData?*?cerData?=?[NSData?dataWithContentsOfFile:cerPath];

SecCertificateRef?certificate?=?SecCertificateCreateWithData(NULL,?(__bridge?CFDataRef)(cerData));

self.trustedCertificates?=?@[CFBridgingRelease(certificate)];

//回調(diào)

-?(void)connection:(NSURLConnection?*)connection?willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge?*)challenge?{

//1)獲取trust?object

SecTrustRef?trust?=?challenge.protectionSpace.serverTrust;

SecTrustResultType?result;

//注意：這里將之前導(dǎo)入的證書(shū)設(shè)置成下面驗(yàn)證的Trust?Object的anchor?certificate

SecTrustSetAnchorCertificates(trust,?(__bridge?CFArrayRef)self.trustedCertificates);

//2)SecTrustEvaluate會(huì)查找前面SecTrustSetAnchorCertificates設(shè)置的證書(shū)或者系統(tǒng)默認(rèn)提供的證書(shū)狼钮，對(duì)trust進(jìn)行驗(yàn)證

OSStatus?status?=?SecTrustEvaluate(trust,?&result);

if(status?==?errSecSuccess?&&

(result?==?kSecTrustResultProceed?||

result?==?kSecTrustResultUnspecified))?{

//3)驗(yàn)證成功碳柱，生成NSURLCredential憑證cred，告知challenge的sender使用這個(gè)憑證來(lái)繼續(xù)連接

NSURLCredential?*cred?=?[NSURLCredential?credentialForTrust:trust];

[challenge.sender?useCredential:cred?forAuthenticationChallenge:challenge];

}else{

//5)驗(yàn)證失敗熬芜，取消這次驗(yàn)證流程

[challenge.sender?cancelAuthenticationChallenge:challenge];

}

}

建議采用本地導(dǎo)入證書(shū)的方式驗(yàn)證證書(shū)莲镣，來(lái)保證足夠的安全性。更多的驗(yàn)證方法涎拉，請(qǐng)查看官方文檔《HTTPS Server Trust Evaluation》

使用AFNetworking來(lái)支持HTTPS

AFNetworking是iOS/OSX開(kāi)發(fā)最流行的第三方開(kāi)源庫(kù)之一瑞侮，其作者是非常著名的iOS/OSX開(kāi)發(fā)者Mattt Thompson，其博客NSHipster也是iOS/OSX開(kāi)發(fā)者學(xué)習(xí)和開(kāi)闊技術(shù)視野的好地方鼓拧。AFNetworking已經(jīng)將上面的邏輯代碼封裝好半火，甚至更完善，在AFSecurityPolicy文件中毁枯，有興趣可以閱讀這個(gè)模塊的代碼慈缔；

AFNetworking上配置對(duì)HTTPS的支持非常簡(jiǎn)單：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21NSURL?*?url?=?[NSURL?URLWithString:@"https://www.google.com"];

AFHTTPRequestOperationManager?*?requestOperationManager?=?[[AFHTTPRequestOperationManager?alloc]?initWithBaseURL:url];

dispatch_queue_t?requestQueue?=?dispatch_create_serial_queue_for_name("kRequestCompletionQueue");

requestOperationManager.completionQueue?=?requestQueue;

AFSecurityPolicy?*?securityPolicy?=?[AFSecurityPolicy?policyWithPinningMode:AFSSLPinningModeCertificate];

//allowInvalidCertificates?是否允許無(wú)效證書(shū)（也就是自建的證書(shū)），默認(rèn)為NO

//如果是需要驗(yàn)證自建證書(shū)种玛，需要設(shè)置為YES

securityPolicy.allowInvalidCertificates?=?YES;

//validatesDomainName?是否需要驗(yàn)證域名藐鹤，默認(rèn)為YES；

//假如證書(shū)的域名與你請(qǐng)求的域名不一致赂韵，需把該項(xiàng)設(shè)置為NO

//主要用于這種情況：客戶端請(qǐng)求的是子域名娱节，而證書(shū)上的是另外一個(gè)域名。因?yàn)镾SL證書(shū)上的域名是獨(dú)立的祭示，假如證書(shū)上注冊(cè)的域名是www.google.com肄满，那么mail.google.com是無(wú)法驗(yàn)證通過(guò)的；當(dāng)然，有錢可以注冊(cè)通配符的域名*.google.com稠歉，但這個(gè)還是比較貴的掰担。

securityPolicy.validatesDomainName?=?NO;

//validatesCertificateChain?是否驗(yàn)證整個(gè)證書(shū)鏈，默認(rèn)為YES

//設(shè)置為YES怒炸，會(huì)將服務(wù)器返回的Trust?Object上的證書(shū)鏈與本地導(dǎo)入的證書(shū)進(jìn)行對(duì)比带饱，這就意味著，假如你的證書(shū)鏈?zhǔn)沁@樣的：

//GeoTrust?Global?CA

//????Google?Internet?Authority?G2

//????????*.google.com

//那么阅羹，除了導(dǎo)入*.google.com之外勺疼，還需要導(dǎo)入證書(shū)鏈上所有的CA證書(shū)（GeoTrust?Global?CA,?Google?Internet?Authority?G2）；

//如是自建證書(shū)的時(shí)候捏鱼，可以設(shè)置為YES执庐，增強(qiáng)安全性；假如是信任的CA所簽發(fā)的證書(shū)导梆，則建議關(guān)閉該驗(yàn)證轨淌；

securityPolicy.validatesCertificateChain?=?NO;

requestOperationManager.securityPolicy?=?securityPolicy;

這就是AFNetworking的支持HTTPS的主要配置說(shuō)明，AFHTTPSessionManager與之基本一致看尼，就不重復(fù)了猿诸。

3. 總結(jié)

雖然HTTPS相比于HTTP來(lái)說(shuō)，會(huì)有一定的性能上的劣勢(shì)狡忙，但對(duì)于網(wǎng)絡(luò)飛速發(fā)展，移動(dòng)設(shè)備的性能成倍增長(zhǎng)的今天址芯，安全才是我們更應(yīng)該去考慮的灾茁。全網(wǎng)HTTPS并不是那么遙遠(yuǎn)。

下一篇準(zhǔn)備講內(nèi)存數(shù)據(jù)安全和持久化數(shù)據(jù)的安全谷炸，敬請(qǐng)期待北专。

版權(quán)所有，轉(zhuǎn)載請(qǐng)保留Jaminzzhang署名