移動(dòng)端防止被抓包
最近在調(diào)試一個(gè)bug的時(shí)候沒有其它好的辦法了，用到了抓包這么個(gè)方式才發(fā)現(xiàn)問題，不過問題已經(jīng)解決了
不過在抓包的時(shí)候突然想到了，我擦，我用的https也可以被抓到包啊。所以又看了一下https的鏈接建立的流程（SSL/TLS原理詳解）和相關(guān)的中間人攻擊的流程，想了一下其中的原理。
首先介紹一下在https建立的過程中是如何被中間人抓到包的吧，前提是如果不熟悉https建立連接的過程，先看一下相關(guān)資料再接著看本文
1.客戶端首先要向遠(yuǎn)程的服務(wù)器發(fā)送建立連接的請(qǐng)求，并帶有自己的支持的加解密的方式級(jí)別，這個(gè)過程經(jīng)過了中間人的竊聽，中間人把消息修改后發(fā)給了真正的目的地——服務(wù)端
2.服務(wù)端收到了要建立https鏈接的請(qǐng)求后，會(huì)發(fā)送當(dāng)時(shí)從證書簽發(fā)機(jī)構(gòu)簽發(fā)的公鑰證書。這個(gè)過程中中間人又竊聽了，然后中間人替換上自己的證書后又轉(zhuǎn)發(fā)給了客戶端。
3.客戶端收到了中間人發(fā)過來的公鑰證書，驗(yàn)證證書的真?zhèn)?/span>，并產(chǎn)生隨機(jī)的對(duì)稱加密的密鑰，用中間人發(fā)的公鑰加密后發(fā)給了中間人。由于剛才客戶端收到的公鑰證書本身就是中間人產(chǎn)生的，所以中間人用相應(yīng)的私鑰就解開了，拿到了客戶端產(chǎn)生的那個(gè)隨機(jī)產(chǎn)生的對(duì)稱加密密鑰。中間人再用剛才服務(wù)端返回的公鑰證書加密這個(gè)客戶端產(chǎn)生的用來對(duì)稱加密的密鑰，發(fā)給服務(wù)端。
4.服務(wù)端收到了當(dāng)時(shí)用自己下發(fā)的公鑰的證書加密的對(duì)稱加密密鑰，用自己的私鑰解密，也得到了對(duì)稱加密的密鑰。
以后的通信都使用這個(gè)對(duì)稱加密的密鑰加密了。因?yàn)榭蛻舳?，中間人，服務(wù)端都有了這個(gè)對(duì)稱加密的密鑰，所以都可以用此解密通信的內(nèi)容。（上面的步驟是穿插了HTTPS建立握手過程和中間人的作用介紹的，屬于簡(jiǎn)潔介紹，明白原理就可以了）。
上面有幾個(gè)字“驗(yàn)證證書的真?zhèn)?/span>”標(biāo)為了紅色，其實(shí)一般來說這個(gè)過程應(yīng)該是安全的，因?yàn)橐话愕淖C書都是由操作系統(tǒng)來管理（Firefox自己管理）的，所以只要操作系統(tǒng)沒有證書鏈驗(yàn)證等方面的bug是沒有什么問題的，但是為了抓包其實(shí)我們是在操作系統(tǒng)中導(dǎo)入了中間人的CA，這樣中間人下發(fā)的公鑰證書就可以被認(rèn)為是合法的，可以通過驗(yàn)證的（中間人既承擔(dān)了辦法了證書，又承擔(dān)了驗(yàn)證證書，能不通過驗(yàn)證嘛）。
忘了說了，這個(gè)抓包是非常全面的，就是可以抓到你請(qǐng)求的參數(shù)，返回值都可以看的非常的清楚。
客戶端為了解決這個(gè)問題，最好的方式其實(shí)就是內(nèi)嵌證書，比對(duì)一下這個(gè)證書到底是不是自己真正的“服務(wù)端”發(fā)來的，而不是中間被替換了。下面就介紹一下解決的步驟吧：
1.問運(yùn)維要到接口站點(diǎn)的證書（即當(dāng)初證書機(jī)構(gòu)簽完的那個(gè)放到nginx里的公鑰證書），放到工程里面就可以，AF會(huì)自動(dòng)去查找
2.AFNetworking設(shè)置以下代碼
AFSecurityPolicy * policy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
網(wǎng)友評(píng)論
