客戶端通信如何加密並且防抓包？

12-29

https還是可以在安裝了證書之後抓包看到的，有一種方式是綁定服務端證書，但是存在證書過期、更換等問題，更新比較麻煩。不知道支付寶、微信這些是怎麼做的，可否有大神解答一下？

為了讓更多對安全感興趣的讀者，有一點背景知識，先科普一點安全的知識。

當我們訪問知乎網站時，輸入https://zhihu.com，需要域名解析，一般有兩種結果：

1）假的IP

2）真的IP

無論是真假IP，都需要瀏覽器認證對方是"http://zhihu.com"（Distinguished Name ）的正主，需要在TLS（Transport Layer Securiy)握手階段，伺服器出示自己對"http://zhihu.com"的證書，通常由一個CA簽名（CA私鑰加密的消息摘要），由於瀏覽器已經預先安裝該CA的證書，該證書有CA的明文公鑰，用CA公鑰可以解密伺服器出示證書的簽名，一旦可以成功解密，即認為伺服器出示的證書可信任，然後檢查證書的有效期是有效的，並且沒有出現在證書撤銷列表CRL，那麼認證通過。

然後瀏覽器從伺服器的數字證書，獲得伺服器的明文公鑰，並用該公鑰加密一個Master Key傳輸給伺服器，伺服器使用自己的私鑰解密，獲得Master Key，至此，雙方擁有一個共同的秘密「Master Key」，雙方運行相同的偽隨機函數（PRF，比如SHA256），輸入量有 Master Key + Client Nonce (客戶端鹽，隨機碼）+ Server Nonce (伺服器端鹽），生成 Encryption Key(加密，防偷窺）、Integrity Key （HMAC，防篡改），使用對稱加密演算法AES-CBC，Hash演算法 SHA2，完成數據加密/解密，鑒權/認證的工作。

一切看起來都是那麼完美無邪…

但，如果客戶端安裝了一個Root CA，相當於信任該CA簽發的任何證書，而該CA如果不負責任亂簽證書，比如簽一個證書「http://zhihu.com"給第三方，那麼第三方就可以使用該證書來欺騙客戶端，客戶端自然就相信對方，並與此建立安全加密TLS連接，中間人可以看到客戶端的所有明文數據。

為了杜絕證書欺騙，客戶端通常使用一個或幾個最值得信賴的CA簽發的證書，其它的CA一律無效。

由於CA證書有一個自然壽命，APP客戶端可以通過軟體版本升級的辦法來更新客戶端的數字證書的版本。

我說說App協議加密的故事吧，本文會粗略提到傳說中的刷單、群發、批量註冊、直播人氣、刷榜、引流等軟體的製作工藝。。。。許多dalao靠這些灰產技術月入百萬。

App協議加密不是為了防止被中間人攻擊，而是防止協議被模擬。群發軟體啊，刷單軟體啊，刷榜軟體啊都是這樣做出來的，所以防止協議被模擬，廠商想出來了很多花樣。

最早的方法是在url或者tcp包中加一個sign簽名欄位，該欄位的計算方法只有廠商知道，計算方法會實現在App中。最早也是最簡單的方法是直接對url裡面各個欄位排序後md5，再複雜一點就加一段salt。

這種方法很容易解決哇，hook一下MessageDigest類，列印出md5內容即可，然後該寫登陸就寫登陸，該寫批量註冊寫批量註冊。

後來啊，聰明的開發者，發現native庫好像不容易被逆向，比用Java寫安全一點，就紛紛把演算法改寫到SO裡面，然而事實是這樣的。。。

SO拖入IDA中，清一色openssl調用，下兩個斷點即可看參數。

再後來啊，不用md5了，開始玩混搭，怎麼混搭？md5 aes des rsa 亂搭，然並卵，對於逆向工作者來說，還原只是時間問題，更何況清一色的openssl，頂多就多幾分鐘的工作量。

再後來啊，開始玩so里調java，沒意思。

再後來啊，開始玩dex分包，動態載入。

這裡就不得不提一下小米商城了，有部分演算法它是插件形式存放的，默認情況下是加密的。

通過一些技術手段導出了它的原始dex文件，就能很容易的找到小米通用的http某參數演算法。

小米商城呢，以前用過滑塊驗證碼，它以為用個protobuf + base64 就能起點作用，然而並沒什麼用。

小米商城呢，還用過推送驗證碼，推送伺服器是tcp的，某dalao用了一周時間逆向，最後還是實現了，重要的是驗證碼是提送過來的，這倒好，給壞人省下一筆打碼費用。

小米盒子裡面的演算法呢，就更容易啦，好像是個HMAC，後來有人寫成搶單軟體，也賺了不少錢。

至於58同城嘛，信息多，很多做爬蟲的公司喜歡，裡面的手機號好像是aes + 變異base64 處理過。

Vivo商城也很火啊，裡面有遊戲卷，vivo的http包關鍵是一個int值，其演算法在so中，極其複雜，聰明的人用了特殊手段將其還原，還原後還是對演算法原理不知qwq。

最近嘛，狼人殺。狼人殺有點厲害啊，為什麼厲害？他用了同盾。同盾的那幾個演算法能賣好幾w呢，反正我沒逆出來。

現在好多APP都加殼了，脫殼現在有專業人士，秒脫。

所以嘛，流水線了。

發現活動線報 - 》找人脫殼-》找人分析協議-》找人逆向演算法-》找人寫軟體-》找人合伙人運營-》分錢

這TM都成流水線了，有關部門都不重視一下！

綁定服務端也可以看到流量啊，我hook掉openssl庫行不行？你的app在別人手機裡面，手機在別人手裡，流量一定能被研究者看到。再nb的技術也只能提高看流量的成本，哪怕你是usb key.

但是換個角度，app和雲端通信的流量被人看到了怕什麼？你應該像加密演算法一樣，不怕被公開，要做的是保證代碼裡面的安全，即使看到了協議交互過程依舊無能為力。

你可以做混淆，代碼和通訊協議都做混淆，提高反向的難度。

曾經在某乙方公司工作過一段時間，工作內容是甲方提供 APP ，我們破解某個加密流量，比如登錄的流量。按我的理解除了使用非對稱加密演算法（RSA 等）之外，使用對稱的加密演算法（AES 等）加密的流量都存在被破解的風險，實際上只要知道加密演算法和密鑰就可以了。然而對稱加密演算法的加解密的密鑰是一樣的，那麼客戶端要加密就一定存有密鑰，所以難度就在於怎麼找到這個密鑰了。最蠢的做法就是把密鑰硬編碼在 APP 里，別人只要一逆向就拿到了。我見過的最麻煩的是寫在 so 里，然後對這個 so 各種加殼混淆花指令，分析起來就很麻煩了。但無論怎麼樣，對稱加密都存在被破解的風險，只是門檻高不高的問題。個人建議敏感信息一律走非對稱加密，稍微不那麼重要的信息可以走對稱加密提高效率，當然也不要蠢到把密鑰直接硬編在 APP 里。

最後，一定要記得校驗服務端證書。

你說，「https可以在安裝證書後抓包看到」

首先，https(SSL)是不能通過抓包看到的。要看到裡面的內容，你需要進行中間人攻擊。也就是你自己偽裝成伺服器接受客戶端的連接，然後你再與真正的伺服器建立連接，轉發客戶端與伺服器之間的通信流量。

https客戶端與伺服器建立連接的時候，會檢驗伺服器的身份。伺服器必須有可信證書的私鑰才能通過檢驗。如果你能得到這個私鑰，就可以完美的偽裝成伺服器。但私鑰保存在伺服器上，你只有取得伺服器的控制權才能得到它。如果你都取得伺服器的控制權了，那直接在上面動手腳截獲明文數據就行了，不需要進行中間人攻擊來竊聽。

你也可以自己生成一個私鑰，用這個私鑰簽發一個證書來進行中間人攻擊。但該證書不在客戶端的信任鏈裡面，身份校驗會失敗，用戶的瀏覽器就會顯示警告說該連接不安全。為了預防社工，現在瀏覽器遇到這種情況都會阻止訪問，強行訪問需要進行非常複雜的操作，一般用戶很難做到。

有些企業防火牆為了審核流量，也會劫持SSL連接，當然瀏覽器也會提示連接不安全。

你說，「有一種方式是綁定服務端證書，但是存在證書過期、更換等問題，更新比較麻煩」

「綁定服務端證書」，應該就是指伺服器用了你自己發行的證書。由於該證書不是公開的簽名機構發行，所以要手動將其導入客戶端的信任鏈。

既然證書是你自己簽發的，那你生成的時候過期時間設久一點唄，25年夠用了吧。我的路由器、NAS管理頁面就是這樣做的。將路由器、NAS的證書導入為Windows可信證書，就可以通過瀏覽器安全的訪問，防止中間人攻擊。

如果你是APP開發者，要用SSL實現安全通信，那就更簡單了。創建SSL連接的時候就可以選擇證書信任鏈，選你發行的證書就可以了。證書過期前，你可以通過安全的連接傳一個新的證書給客戶端。所以支付寶、微信，這些APP當然也是用的SSL。

（誤）數據都放本地，不跟伺服器通訊。

把公鑰隨客戶端程序一起分發，私鑰放在伺服器，通信時客戶端首先生成一個隨機的密鑰：Key（對稱加密演算法的密鑰，如AES-256），再通過公鑰加密後把key傳給伺服器，伺服器通過私鑰解密後得到Key，至此以後雙方的流量均通過key加密並用HMAC做消息認證，整個過程可以有效杜絕中間人攻擊。

加密與防抓包是基本不可能的，微信也有itchat這類的模擬庫。

應該多驗證客戶端發送的信息是否合法，做到防篡改、防重放等即可。

題主說的大概不是防止中間人攻擊，而是防止協議破解。理論上來講，不可能，只是破解成本多少而已。

一般做法是客戶端加密，用native加密，自己搞一套複雜的加密演算法（組合），，，等等都可以提高破解的成本，不過最終都是可以破解的。

可以換個思路，在服務端做限制，不過可能會導致正常用戶體驗下降。

你說的「綁定服務端證書」就是 SSL Pinning，只 Pin 證書里的公鑰不要 Pin 整個證書，且更新證書時不要修改公鑰（使用原來的 CSR），就不會有更新證書的問題。回到原來的問題，客戶端加密方案都只能增加破解成本，無法防止破解，被破解只是時間問題

https證書雙向強校驗，校驗客戶端和服務端。

通訊數據加密。然後用https傳遞密鑰，加密演算法隱藏在so裡面並使用so加固提高逆向成本。

防重放，每次請求中含有一個時間戳，基於時間戳和請求參數和密鑰生成sha256值。

服務端每次通訊前校驗客戶端證書，校驗後傳遞密鑰，收到請求檢查時間戳和sha256值。

我想回答這個問題，但是居然要我驗證手機號，那我只好匿名了。但是居然還是不能回答。那我只好隨便找個號了。

樓上各位注意讀題，客戶端通信如何加密並且防止被抓包。客戶端和誰通信？想必是伺服器？

我只想回答後面一個問題。基本上抓包是一定能夠抓到的。只是這個問題要轉換為如何防止別人重放你的包和如何防止別人解密你的包。

關於這個可以看看什麼叫PKI 模型，了解其原理。為了抓包安卓我曾經深入研究過什麼是PKI，CA，如何認證通信保證安全。之後我又好害怕去看了看SSL中間人劫持。

最後建議你讀兩個論文可能比你來這裡問問題要好很多。至少你可以迅速了解你想要了解的東西，即便只是個大概，你也可以有個方向了，不是嗎?

其實我只是來裝逼的。不是來回答問題的。。樓上的難道不是這樣嗎？

簡單說下我們的做法。以下實現難度由易到難：

1、所有數據走二進位協議，例如pb等。

2、數據加密解密邏輯放在so中，避免反編譯，密鑰也可以放，嫌3麻煩的話。

3、含過期時間的動態密鑰，並且每個用戶都不相同，我們稱為安全通道。發所有請求前先請求密鑰。

不專門搞破解加密，所以不是很懂。但是看到很多人說HTTPS可以被抓包破解，還是比較疑惑的，畢竟HTTPS流程的設計，是可以避免被抓包破解的。

任何加密安全方案都是有適用範圍的，即使你的手機和電腦是絕對不會被破解的，那麼你輸入密碼的時候，旁邊站個人記下來，那仍然會泄漏啊。

但是，我們從實際應用場景來看，到底有哪些情況可能被盜取數據，還是有一定意義的。

首先，如果你的操作系統不安全，比如留了後門（比如某雲操作系統，國產操作系說真的，不能讓人放心底層是否就被監控了？），或者某個加密演算法（某安加密演算法），加密晶元（某安全手機）留了後門，這個時候就別談什麼安全了，道理不用講。
中了木馬病毒，或者底層加密庫被替換為帶後門的版本，此時也無從談安全了。
就是現在主流的非對稱加密傳輸方案，比如HTTPS。看了幾個破解HTTPS的方案，實際上都是中間人攻擊，也就是攻擊者偽裝成伺服器，你把信息發送到了一個假的伺服器，假伺服器再重新封包，發到真的伺服器，整個中間都被破解了，自然安全無從談起。

解決方法，那麼除了保證操作系統沒有後門，系統不中木馬病毒，突然想到，如果某數字殺毒軟體自帶後門，那也真是無解了，總覺得他們幹得出這種事。真正討論通信安全，就是公鑰寫死在APP中，時不時的更新版本的時候更新一下。網站證書的方案屬於大眾方案，其實不用我們怎麼操心，安全也好不安全也好，你能解決，大家早解決了。自己的伺服器，自己的APP，自己搞個根證書，只信任自己這套驗證，中間人基本無法攻擊了。

端對端加密啊

只校驗服務端證書的public key，不管證書是否過期是否就可以了？

題主您說的通信安全，HTTPS完全沒有問題的。

您說的「https還是可以在安裝了證書之後抓包看到的」，這句話是什麼意思？

你的伺服器端證書哪那麼容易被別人安裝，你不保管好你的家門鑰匙，那不就是敞開大門嗎，話說你究竟是在意通信安全還是不在意呢？

非對稱加密，一樣的信息每次加密都是不一樣的，找不到私鑰誰都破解不了