蘋果在2017年的開發(fā)者大會(huì)中已經(jīng)明確說(shuō)到AppStore的所有APP都必須啟用ATS安全功能，啟用ATS以后，明文HTTP資源加載將被屏蔽，APP需要通過(guò)HTTPS連接網(wǎng)絡(luò)服務(wù)。

為何要使用HTTPS呢?

1.無(wú)法證明報(bào)文的完整性，所以有可能已遭篡改--可能會(huì)被劫持插入廣告

2.通信使用明文，敏感信息被截取(銀行卡、各種密碼、手機(jī)號(hào)等)

3.不驗(yàn)證通信方的身份，因此可能遭遇跟偽裝的服務(wù)器通信

注釋：因?yàn)镠TTP通過(guò)明文傳輸，沒有經(jīng)過(guò)任何安全處理，且很容易受到中間人的攻擊，比如：通過(guò)重定向把客戶端的請(qǐng)你求轉(zhuǎn)到一個(gè)另外的服務(wù)器；查看客戶端的敏感信息；或者偷偷修改客戶端的請(qǐng)求/相應(yīng)數(shù)據(jù)包。所以才迫切的想要引人HTTPS。

為何使用HTTPS以后能夠保證傳輸安全呢？

HTTPS被稱為Hyperttext Transfer Protocol Secure(安全的超文本傳輸協(xié)議)或者說(shuō)HTTP over Secure Socket Layer(安全套接字層HTTP協(xié)議)，實(shí)際上HTTPS協(xié)議是在HTTP協(xié)議的基礎(chǔ)上添加了SSL(Secure Socket Layer)/TLS(Transport Layer Security)加密協(xié)議

握手流程如下：

1.客戶端-->服務(wù)器 發(fā)起請(qǐng)求

客戶端發(fā)起請(qǐng)求到服務(wù)器。主要參數(shù)是支持的協(xié)議版本，加密方法以及一個(gè)隨機(jī)數(shù)n1;

2.服務(wù)器-->客戶端 發(fā)送證書，客戶端驗(yàn)證證書

服務(wù)器收到請(qǐng)求并確認(rèn)加密方法，然后返回公鑰，以及一個(gè)由服務(wù)器生成的隨機(jī)數(shù)n2;在這個(gè)階段iOS中的CA認(rèn)證的認(rèn)證的證書會(huì)自動(dòng)驗(yàn)證，而私有的證書則需要手動(dòng)驗(yàn)證放行，否則拒絕鏈接；

3.客戶端-->服務(wù)器? 發(fā)送消息

客戶端驗(yàn)證證書成功后會(huì)生成第三個(gè)隨機(jī)數(shù)n3，并用第2步服務(wù)器返回的證書對(duì)該隨機(jī)數(shù)加密，并發(fā)送給服務(wù)器，同時(shí)也會(huì)發(fā)送一些其他信息，比如：編碼信息和客戶端握手結(jié)束的通知。

4.服務(wù)器-->客戶端 發(fā)送信息

服務(wù)器用私鑰解密后，得到客戶端傳來(lái)的第三個(gè)隨機(jī)數(shù)n3,兩端使用這三個(gè)隨機(jī)數(shù)n1、n2、n3來(lái)生成Session Key。服務(wù)器想客戶端發(fā)送編碼信息和服務(wù)器握手結(jié)束通知。

5.完整性驗(yàn)證

完整性驗(yàn)證以后，后面的信息傳輸就靠這個(gè)Session key進(jìn)行對(duì)稱加密了。

SSL在握手的過(guò)程中主要交換了以下三個(gè)信息：

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

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

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

中間人攻擊

中間人攻擊是通過(guò)與客戶端、服務(wù)器分別建立連接，來(lái)獲得了明文的信息攻擊方式。在這個(gè)過(guò)程中，客戶端與服務(wù)器的通信被第三方解密、查看、修改。

為什么有些APP即便使用了HTTPS，還是會(huì)被中間人攻擊呢？

基本都是因?yàn)闆]做客戶端驗(yàn)證，特別是在使用未經(jīng)CA認(rèn)證的證書時(shí)，更容易中招。關(guān)于黑客是如何在協(xié)議握手初期劫持服務(wù)，從而實(shí)現(xiàn)中間人攻擊，可以做如下推演:

1.黑客劫持到服務(wù)器公鑰，并冒充客戶端與服務(wù)器連接；

2.黑客自己生成公鑰，冒充服務(wù)器公鑰返回給真正的客戶端；

如果客戶端未做驗(yàn)證的話，就不會(huì)發(fā)現(xiàn)證書被替換，于是客戶端會(huì)用黑客的公鑰發(fā)送數(shù)據(jù)，黑客劫持?jǐn)?shù)據(jù)后，用自己的私鑰解密，查看。

由此可見，需要做好客戶端驗(yàn)證。比如吧證書打包進(jìn)APP，然后與服務(wù)器返回的證書對(duì)比驗(yàn)證，驗(yàn)證成功以后才允許連接。當(dāng)然是用這種方式會(huì)導(dǎo)致一些問題，比如：當(dāng)證書過(guò)期時(shí)APP連不上服務(wù)器，這時(shí)需要我們將新證書提前打包進(jìn)APP，或者通過(guò)Socket通道從服務(wù)器傳送證書進(jìn)APP中，來(lái)實(shí)現(xiàn)無(wú)縫對(duì)接。