iOS中的HTTPS與AFNetworking

本節(jié)主要理解:
1.HTTP1.0和HTTP1.1和HTTP2.0的區(qū)別
2.HTTP請求報文頭內(nèi)容
3.https證書校驗原理
4.https的加密原理
5.AFNetworking的簡介
6.AFNetworking2.0與3.0與4.0的區(qū)別
7.中間人攻擊的原理孽尽,如何預(yù)防中間人攻擊藐鹤?

一.http與https的對比

什么是http?

超文本傳輸協(xié)議漏策,是一個基于請求與響應(yīng),無狀態(tài)的舀寓,應(yīng)用層的協(xié)議歧匈,潮嵫基于TCP/IP協(xié)議傳輸數(shù)據(jù)昼捍,互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個標準识虚。設(shè)計HTTP的初衷是為了提供一種發(fā)布和接收HTML頁面的方法。

什么是https?

《圖解HTTP》這本書中曾提過HTTPS是身披SSL外殼的HTTP妒茬。HTTPS是一種通過計算機網(wǎng)絡(luò)進行安全通信的傳輸協(xié)議担锤,經(jīng)由HTTP進行通信,利用SSL/TLS建立全信道乍钻,加密數(shù)據(jù)包肛循。HTTPS使用的主要目的是提供對網(wǎng)站服務(wù)器的身份認證,同時保護交換數(shù)據(jù)的隱私與完整性银择。

1 HTTP1.0和HTTP1.1的區(qū)別
1.1 長連接(Persistent Connection)---加快響應(yīng)速度
HTTP1.1支持長連接和請求的流水線處理多糠,在一個TCP連接上可以傳送多個HTTP請求和響應(yīng),減少了建立和關(guān)閉連接的消耗和延遲浩考,在HTTP1.1中默認開啟長連接keep-alive夹孔,一定程度上彌補了HTTP1.0每次請求都要創(chuàng)建連接的缺點。HTTP1.0需要使用keep-alive參數(shù)來告知服務(wù)器端要建立一個長連接析孽。

1.2 節(jié)約帶寬
HTTP1.0中存在一些浪費帶寬的現(xiàn)象搭伤,例如客戶端只是需要某個對象的一部分,而服務(wù)器卻將整個對象送過來了袜瞬,并且不支持斷點續(xù)傳功能怜俐。HTTP1.1支持只發(fā)送header信息(不帶任何body信息),如果服務(wù)器認為客戶端有權(quán)限請求服務(wù)器邓尤,則返回100拍鲤,客戶端接收到100才開始把請求body發(fā)送到服務(wù)器;如果返回401汞扎,客戶端就可以不用發(fā)送請求body了節(jié)約了帶寬季稳。

1.3 HOST域
在HTTP1.0中認為每臺服務(wù)器都綁定一個唯一的IP地址,因此澈魄,請求消息中的URL并沒有傳遞主機名(hostname)绞幌,HTTP1.0沒有host域。隨著虛擬主機技術(shù)的發(fā)展一忱,在一臺物理服務(wù)器上可以存在多個虛擬主機(Multi-homed Web Servers),并且它們共享一個IP地址谭确。HTTP1.1的請求消息和響應(yīng)消息都支持host域帘营,且請求消息中如果沒有host域會報告一個錯誤(400 Bad Request)。

1.4緩存處理
在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準逐哈,HTTP1.1則引入了更多的緩存控制策略例如Entity tag芬迄,If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

1.5錯誤通知的管理
在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼昂秃,如409(Conflict)表示請求的資源與資源的當前狀態(tài)發(fā)生沖突禀梳;410(Gone)表示服務(wù)器上的某個資源被永久性的刪除杜窄。

2 HTTP1.1和HTTP2.0的區(qū)別
2.1 多路復(fù)用---加快響應(yīng)速度
HTTP2.0使用了多路復(fù)用的技術(shù),做到同一個連接并發(fā)處理多個請求算途,而且并發(fā)請求的數(shù)量比HTTP1.1大了好幾個數(shù)量級塞耕。HTTP1.1也可以多建立幾個TCP連接,來支持處理更多并發(fā)的請求嘴瓤,但是創(chuàng)建TCP連接本身也是有開銷的扫外。

2.2 頭部數(shù)據(jù)壓縮---節(jié)省帶寬
在HTTP1.1中,HTTP請求和響應(yīng)都是由狀態(tài)行廓脆、請求/響應(yīng)頭部筛谚、消息主體三部分組成。一般而言停忿,消息主體都會經(jīng)過gzip壓縮驾讲,或者本身傳輸?shù)木褪菈嚎s過后的二進制文件,但狀態(tài)行和頭部卻沒有經(jīng)過任何壓縮席赂,直接以純文本傳輸吮铭。隨著Web功能越來越復(fù)雜,每個頁面產(chǎn)生的請求數(shù)也越來越多氧枣,導(dǎo)致消耗在頭部的流量越來越多沐兵,尤其是每次都要傳輸UserAgent、Cookie這類不會頻繁變動的內(nèi)容便监,完全是一種浪費扎谎。
HTTP1.1不支持header數(shù)據(jù)的壓縮,HTTP2.0使用HPACK算法對header的數(shù)據(jù)進行壓縮烧董,這樣數(shù)據(jù)體積小了毁靶,在網(wǎng)絡(luò)上傳輸就會更快。

2.3 服務(wù)器推送
服務(wù)端推送是一種在客戶端請求之前發(fā)送數(shù)據(jù)的機制逊移。網(wǎng)頁使用了許多資源:HTML预吆、樣式表、腳本胳泉、圖片等等拐叉。在HTTP1.1中這些資源每一個都必須明確地請求。這是一個很慢的過程扇商。瀏覽器從獲取HTML開始凤瘦,然后在它解析和評估頁面的時候,增量地獲取更多的資源案铺。因為服務(wù)器必須等待瀏覽器做每一個請求蔬芥,網(wǎng)絡(luò)經(jīng)常是空閑的和未充分使用的。
為了改善延遲,HTTP2.0引入了server push笔诵,它允許服務(wù)端推送資源給瀏覽器返吻,在瀏覽器明確地請求之前,免得客戶端再次創(chuàng)建連接發(fā)送請求到服務(wù)器端獲取乎婿。這樣客戶端可以直接從本地加載這些資源测僵,不用再通過網(wǎng)絡(luò)。

2.HTTP請求報文頭內(nèi)容
常見的HTTP請求報文頭屬性
Accept
請求報文可通過一個“Accept”報文頭屬性告訴服務(wù)端 客戶端接受什么類型的響應(yīng)次酌。

Accept:text/plain

Cookie
如上報文頭相當于告訴服務(wù)端恨课,俺客戶端能夠接受的響應(yīng)類型僅為純文本數(shù)據(jù)啊,你丫別發(fā)其它什么圖片啊岳服,視頻啊過來剂公,那樣我會歇菜的~~~:

客戶端的Cookie就是通過這個報文頭屬性傳給服務(wù)端的哦!如下所示:
Cookie: $Version=1; Skin=new jsessionid=5F4771183629C9834F8382E23BE13C4C

服務(wù)端是怎么知道客戶端的多個請求是隸屬于一個Session呢吊宋?注意到后臺的那個jsessionid=5F4771183629C9834F8382E23BE13C4C木有纲辽?原來就是通過HTTP請求報文頭的Cookie屬性的jsessionid的值關(guān)聯(lián)起來的!(當然也可以通過重寫URL的方式將會話ID附帶在每個URL的后面哦)璃搜。

Referer
表示這個請求是從哪個URL過來的拖吼,假如你通過google搜索出一個商家的廣告頁面,你對這個廣告頁面感興趣这吻,鼠標一點發(fā)送一個請求報文到商家的網(wǎng)站吊档,這個請求報文的Referer報文頭屬性值就是http://www.google.com

Cache-Control

對緩存進行控制唾糯,如一個請求希望響應(yīng)返回的內(nèi)容在客戶端要被緩存一年怠硼,或不希望被緩存就可以通過這個報文頭達到目的。

如以下設(shè)置移怯,相當于讓服務(wù)端將對應(yīng)請求返回的響應(yīng)內(nèi)容不要在客戶端緩存:
Cache-Control: no-cache

3.HTTP特點:
1.無狀態(tài):協(xié)議對客戶端沒有狀態(tài)存儲香璃,對事物處理沒有“記憶”能力,比如訪問一個網(wǎng)站需 要反復(fù)進行登錄操作
2.無連接:HTTP/1.1之前舟误,由于無狀態(tài)特點葡秒,每次請求需要通過TCP三次握手四次揮手,和服務(wù)器重新建立連接嵌溢。比如某個客戶機在短時間多次請求同一個資源眯牧,服務(wù)器并不能區(qū)別是否已經(jīng)響應(yīng)過用戶的請求,所以每次需要重新響應(yīng)請求赖草,需要耗費不必要的時間和流量炸站。
3.基于請求和響應(yīng):基本的特性,由客戶端發(fā)起請求疚顷,服務(wù)端響應(yīng)
4 簡單快速、靈活
5.通信使用明文、請求和響應(yīng)不會對通信方進行確認腿堤、無法保護數(shù)據(jù)的完整性
PS:TLS是傳輸層加密協(xié)議阀坏,前身是SSL協(xié)議,由網(wǎng)景公司1995年發(fā)布笆檀,有時候兩者不區(qū)分

HTTPS特點:
內(nèi)容加密:采用混合加密技術(shù)忌堂,中間者無法直接查看明文內(nèi)容
驗證身份:通過證書認證客戶端訪問的是自己的服務(wù)器
保護數(shù)據(jù)完整性:防止傳輸?shù)膬?nèi)容被中間人冒充或者篡改

二.HTTPS的數(shù)據(jù)傳輸

HTTPS采用的是非對稱加密+對稱加密結(jié)合的方式保證數(shù)據(jù)加密的

圖片.png

中文版??????


圖片.png

大概過程
https證書校驗原理(簡介版)
1.客戶端向服務(wù)端發(fā)其請求,服務(wù)端發(fā)送證書酗洒。
2.客戶端本地有內(nèi)置的證書簽發(fā)機構(gòu)對應(yīng)的公鑰士修,客戶端使用公鑰解密簽名,然后自己計算hash看是否一致樱衷。

如果不一致棋嘲,客戶端會進行信任鏈的驗證操作。

重點>毓稹沸移!

1)服務(wù)器用RSA生成公鑰和私鑰
2)客戶端發(fā)起https請求,連接到服務(wù)端的443端口
3)服務(wù)端將公鑰放在證書中傳給客戶端侄榴,私鑰自己保存
4)客戶端驗證證書合法性雹锣,驗證成功的話,生成一串隨機數(shù)作為數(shù)據(jù)傳輸對稱加密的密鑰癞蚕,我們稱之為對稱密鑰
5)然后客戶端用公鑰對密鑰進行加密, 再發(fā)給服務(wù)器
6)服務(wù)端收到客戶端發(fā)出的數(shù)據(jù)蕊爵,使用私鑰解密,獲取到隨機數(shù)密鑰桦山。即可進行數(shù)據(jù)傳輸

三.AFNetworking與HTTPS

1.AFNetworking簡介
框架結(jié)構(gòu)

這里分析4.0版本的結(jié)構(gòu)攒射。主要分為五個部分:

1、NSURLSession:網(wǎng)絡(luò)通信模塊度苔,兩個文件AFURLSessionManager匆篓,AFHTTPSessionManager。AFHTTPSessionManager繼承與AFURLSessionManager

2寇窑、Reachability 網(wǎng)絡(luò)狀態(tài)監(jiān)聽鸦概,AFNetworkReachabilityManager

3、Security 網(wǎng)絡(luò)通訊安全策略模塊甩骏,AFSecurityPolicy

4窗市、Serialization 序列化,AFURLResponseSerialization饮笛,AFURLRequestSerialization

5咨察、UIKit 對于UIKit的擴展庫

AFNetworking的請求AFHTTPSessionManager 有一個專門的屬性來處理加密策略,AFSecurityPolicy
1.創(chuàng)建一個AFSecurityPolicy

AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];

傳入?yún)?shù)表示https驗證模式福青,一共三種選項

typedef NS_ENUM(NSUInteger, AFSSLPinningMode) {
    //不驗證
    AFSSLPinningModeNone,
    //只驗證公鑰
    AFSSLPinningModePublicKey,
    //驗證證書
    AFSSLPinningModeCertificate,
};

此外AFSecurityPolicy還有三個重要屬性

//可以去匹配服務(wù)端證書驗證的證書
@property (nonatomic, strong, nullable) NSSet <NSData *> *pinnedCertificates;
//是否支持非法的證書(例如自簽名證書)
@property (nonatomic, assign) BOOL allowInvalidCertificates;
//是否去驗證證書域名是否匹配
@property (nonatomic, assign) BOOL validatesDomainName;

我們項目使用的是機構(gòu)頒發(fā)的證書所以配置比較簡單

- (AFSecurityPolicy *)customSecurityPolicy {
    NSData *data = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"server" ofType:@"p12"]];
    AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
    securityPolicy.allowInvalidCertificates = NO;
    securityPolicy.validatesDomainName = NO;
    securityPolicy.pinnedCertificates = [NSSet.alloc initWithObjects:data, nil];
    return securityPolicy;
}

2.AFNetworking3.0與2.0的區(qū)別

最大區(qū)別: AFNetworking2.0使用的NSURLConnection,3.0使用的是NSURLSession

1)NSURLConnection下載文件時摄狱,先是將整個文件下載到內(nèi)存脓诡,然后再寫入到沙盒,如果文件比較大媒役,就會出現(xiàn)內(nèi)存暴漲的情況祝谚。而使用NSURLSessionUploadTask下載文件,會默認下載到沙盒中的tem文件中酣衷,不會出現(xiàn)內(nèi)存暴漲的情況交惯。

2)NSURLConnection停止請求的發(fā)送,停止后不能繼續(xù)訪問穿仪,需要創(chuàng)建新的請求席爽。NSURLSession有三個控制方法,取消(cancel)啊片、暫停(suspend)只锻、繼續(xù)(resume),暫停以后可以通過繼續(xù)恢復(fù)當前的請求任務(wù)钠龙。

3)AFN3.0 NSURLSession 不需要2.0NSURLConnection 的常駐線程炬藤。
2.0需要常駐線程是因為請求回調(diào)依賴當前線程,而AFN3.0 NSURLSession的請求回調(diào)不需要依賴當前線程碴里,可以指定回調(diào)的delegateQueue沈矿,這樣也就不需要再對線程進行保活咬腋。

7.中間人攻擊的原理羹膳,如何預(yù)防中間人攻擊?
SSL劫持攻擊

SSL劫持攻擊即SSL證書欺騙攻擊根竿,攻擊者為了獲得HTTPS傳輸?shù)拿魑臄?shù)據(jù)陵像,需要先將自己接入到客戶端和目標網(wǎng)站之間;在傳輸過程中偽造服務(wù)器的證書寇壳,將服務(wù)器的公鑰替換成自己的公鑰醒颖,這樣,中間人就可以得到明文傳輸帶Key1壳炎、Key2和Pre-Master-Key泞歉,從而竊取客戶端和服務(wù)端的通信數(shù)據(jù);

但是對于客戶端來說匿辩,如果中間人偽造了證書腰耙,在校驗證書過程中會提示證書錯誤,由用戶選擇繼續(xù)操作還是返回铲球,由于大多數(shù)用戶的安全意識不強挺庞,會選擇繼續(xù)操作,此時稼病,中間人就可以獲取瀏覽器和服務(wù)器之間的通信數(shù)據(jù)

圖片.png

如何預(yù)防中間人攻擊选侨?
因為在握手階段服務(wù)端的證書必須返回給客戶端掖鱼,如果客戶端在打包的時候,就把服務(wù)端證書放到本地侵俗,在握手校驗證書的環(huán)節(jié)進行比較锨用,服務(wù)端返回的證書和本地內(nèi)置的證書一模一樣,才發(fā)起網(wǎng)絡(luò)請求隘谣。否則,直接斷開連接啄巧,不可用寻歧。

參考文章
AFNetworking之于https認證
HTTP和HTTPS協(xié)議,看一篇就夠了
https原理

over !!

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末秩仆,一起剝皮案震驚了整個濱河市码泛,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌澄耍,老刑警劉巖噪珊,帶你破解...
    沈念sama閱讀 222,681評論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異齐莲,居然都是意外死亡痢站,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,205評論 3 399
  • 文/潘曉璐 我一進店門选酗,熙熙樓的掌柜王于貴愁眉苦臉地迎上來阵难,“玉大人,你說我怎么就攤上這事芒填∥亟校” “怎么了?”我有些...
    開封第一講書人閱讀 169,421評論 0 362
  • 文/不壞的土叔 我叫張陵殿衰,是天一觀的道長朱庆。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么袖扛? 我笑而不...
    開封第一講書人閱讀 60,114評論 1 300
  • 正文 為了忘掉前任伴逸,我火速辦了婚禮,結(jié)果婚禮上维蒙,老公的妹妹穿的比我還像新娘。我一直安慰自己果覆,他們只是感情好颅痊,可當我...
    茶點故事閱讀 69,116評論 6 398
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著局待,像睡著了一般斑响。 火紅的嫁衣襯著肌膚如雪菱属。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,713評論 1 312
  • 那天舰罚,我揣著相機與錄音纽门,去河邊找鬼。 笑死营罢,一個胖子當著我的面吹牛赏陵,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播饲漾,決...
    沈念sama閱讀 41,170評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼蝙搔,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了考传?” 一聲冷哼從身側(cè)響起吃型,我...
    開封第一講書人閱讀 40,116評論 0 277
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎僚楞,沒想到半個月后勤晚,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 46,651評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡泉褐,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,714評論 3 342
  • 正文 我和宋清朗相戀三年赐写,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片兴枯。...
    茶點故事閱讀 40,865評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡血淌,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出财剖,到底是詐尸還是另有隱情悠夯,我是刑警寧澤,帶...
    沈念sama閱讀 36,527評論 5 351
  • 正文 年R本政府宣布躺坟,位于F島的核電站沦补,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏咪橙。R本人自食惡果不足惜夕膀,卻給世界環(huán)境...
    茶點故事閱讀 42,211評論 3 336
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望美侦。 院中可真熱鬧产舞,春花似錦、人聲如沸菠剩。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,699評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽具壮。三九已至准颓,卻和暖如春哈蝇,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背攘已。 一陣腳步聲響...
    開封第一講書人閱讀 33,814評論 1 274
  • 我被黑心中介騙來泰國打工炮赦, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人样勃。 一個月前我還...
    沈念sama閱讀 49,299評論 3 379
  • 正文 我出身青樓吠勘,卻偏偏與公主長得像,于是被迫代替她去往敵國和親峡眶。 傳聞我的和親對象是個殘疾皇子看幼,可洞房花燭夜當晚...
    茶點故事閱讀 45,870評論 2 361

推薦閱讀更多精彩內(nèi)容