[[399399]]

圖片來自 Pexels

坦率地說，以前從來沒有分析過微信這類聊天軟件，大概率使用私有協議。

而私有協議在協議分析軟件上的呈現，一般都是 TCP 封裝一長串字節流，而這些字節流究竟是什么內容，協議軟件無法給出答案!

看看協議分析軟件能否看到微信網頁版、手機 APP 版及電腦版的聊天內容?

1、網頁版微信

①協議分析結果

不知道大家看到“美女好[玫瑰]”哇，這個就是協議分析軟件分析出來的聊天內容。

真實聊天內容：

一摸一樣!

②實驗結論

協議分析軟件可以將聊天內容解密出來!

③實驗分析

網頁版微信通常是使用瀏覽器來與微信服務器通信的，而瀏覽器多種多樣，有 Chrome、Firefox、IE 等等，要想與不同的廠商瀏覽器通信，必須使用標準協議，而標準協議在協議分析軟件上是可以解開的。

考慮到網頁版的微信，可能會使用 SSL/TLS 加密聊天內容，需要用 Fiddle 作為中間人，用 Fiddle 偽造的證書來欺騙瀏覽器，讓瀏覽器誤以為 Fiddle 就是微信服務器。

Fiddle 再與微信服務器建立 SSL/TLS 加密通道，傳輸聊天內容：

• 瀏覽器與 Fiddle 建立 SSL/TLS 加密通道。
• Fiddle 與微信服務器建立 SSL/TLS 加密通道。
• Fiddle 做為二傳手，將消息在兩條通道上進行傳遞，先解密，再加密。
• Fiddle 需要偽造微信服務器證書。
• 電腦需要安裝、信任 Fiddle 自簽名的根證書。

2、手機版微信

協議分析結果：

微信手機版沒有使用 TLS+HTTP=HTTPS 的加密傳輸方式，而是使用了 HTTP 的傳輸方式，如上圖所示。

每一個報文大概是這個樣子的：

除了 HTTP 報文頭(HTTP Header)是明文的，HTTP 報文體(HTTP Body)看起來是一堆雜亂無章的字節流。

沒有找到聊天的任何內容。最最滑稽的是，當發送聊天內容時，Fiddle 沒有任何反應!

意味著發送聊天內容的報文既不是 HTTP，也不是 HTTPS，那很可能是 TCP、或 UDP 協議原始(Raw)封裝。

為了確認到底是 TCP 還是 UDP 傳輸報文，特意去了微信研發公眾號去確認，得到的確認是采用 TCP 傳輸。

分為兩種連接方式：

• 長連接：TCP+私有協議+MMTLS+業務層
• 短連接：TCP+HTTP+MMTLS+業務層

官方的口徑是，短連接是為了兼容老版本的軟件，而長連接完全是私有實現，所以造成 Fiddle 沒有捕獲到，畢竟 Fiddle 只能捕獲到 HTTP 或 HTTPS，至于其它的協議壓根不在其感興趣范圍!

于是，使用 Wireshark 捕獲微信長連接的 TCP 報文，確實捕獲到了，再怎么私有實現，總不能長翅膀飛!

但是這些 TCP 報文沒有展示的意義，TCP 頭之后字段全是雜亂無章的，這些都在預料之中!

①MMTLS 是什么樣的存在?

MMTLS 是 TLS1.3 版本的改良版，或者說簡化版。在微信決定使用 MMTLS 之前，TLS1.3 版本長期逗留在草案狀態，沒有形成一個最終標準。

于是微信決定采用 TLS1.3 草案中的標準，大刀闊斧砍掉客戶端認證這個環節，只保留服務器認證。

手機微信 APP 里預置了微信服務器的兩件秘密武器：

• ECDSA 公鑰
• 靜態 ECDH 公鑰

②ECDSA 公鑰是干嘛的?

ECDSA 用于驗證服務器的真實身份，任何來自于服務器的 MMTLS 協商報文，只要使用 ECDSA 私鑰簽名的，ECDSA 公鑰都可以解密。

換句話說，如果簽名部分可以使用 ECDSA 公鑰解密，那就證明是真正微信服務器發送的!

在微信的私有實現里，不需要 CA，微信客戶端憑借預置的 ECDSA 公鑰完成服務器的認證!

③靜態 ECDH 公鑰又是干嘛的?

如果微信客戶端想最小延遲(0 RTT)發消息，可以直接生成自己的 ECDH 私鑰、公鑰、Nonce，再加上服務器預置的 Nonce。

就可以單方面計算出 Pre-Master Key，Master Key，Session Key，進而將消息加密發出。

微信服務器收到消息的同時，一同收到的還有客戶端的 ECDH 公鑰、客戶端Nonce，服務器用自己的 ECDH 私鑰、預留在客戶端的 Nonce，這四個參數，計算出可以解密消息的 Key，并將消息解密出。

MMTLS 沒有給消息增加額外的延遲，稱這種通信為 0 RTT 通信。

由于微信客戶端，強制使用服務器的 ECDSA 公鑰來認證服務器的身份，所以 Fiddle 壓根沒法欺騙微信 APP。

如果 Fiddle 強制替換，微信客戶端會放棄連接服務器，造成的后果就是微信永遠登錄不了服務器!

微信 APP 之所以可以實現私有協議，是因為服務器、客戶端都是微信的代碼，再怎么私有，理解起來也沒有任何障礙!

3、電腦版微信

前面只提到了網頁版微信、手機 APP 微信，但是唯獨沒有提到電腦版微信，究竟老板能否監控到員工使用電腦版微信聊天內容?

揭曉答案：不能，各位放心大膽使用!

大家那點小心思早就被微信之父“張小龍”看穿了，為了最大限度保護各位的隱私，只要是從騰訊官方下載的電腦版微信、手機 APP，都是安全的、可靠的。

我帶著這個疑問又做了一次實驗。值得慶幸的是，第三方監控軟件無法解密微信聊天，實驗過程與實驗圖片略。

這個結論可能依然無法打消部分讀者的疑慮，為何微信網頁版可以監控，而其他的兩種微信卻無法監控?

①網頁版微信

客戶端是形形色色的瀏覽器，有 Chrome、Firefox、IE 等等，這些瀏覽器之所以可以與微信服務器通信并下載聊天內容，是因為客戶端、服務器端使用業界標準的 TLS 協議通信。

在此通信場景下，騰訊能夠完全控制的代碼是服務器端，而客戶端的代碼則鞭長莫及、無法控制。為了使通信成為可能，服務器必須嚴格遵守 TLS 協議標準。

監控軟件一方面欺騙客戶端，自己就是微信服務器;另一方面欺騙服務器，自己就是微信客戶端。

這樣一來，監控軟件一方面可以解密客戶端的消息，又可以解密服務器的消息。

②電腦版/手機 APP 微信

客戶端的代碼，完全是微信的代碼;服務器的代碼更不用說了，依然也是微信的代碼。

既然雙方的代碼都由微信完全控制，他們想使用什么私有加密協議來保護通信安全，那都是他們內部的私事，任何第三方幾乎無法破解。

其實微信并沒有使用什么私有協議，依然使用 TLS 協議來加密數據。同學們可能會更迷惑了，既然使用標準的 TLS 協議通信，為何第三方卻無法監控呢?

客戶端預先嵌入(硬編碼)了微信服務器的公鑰，客戶端抱著“一顆紅心，兩種準備”。

如果服務器出示的公鑰，與客戶端預先嵌入的公鑰完全相同(暗號比對成功)，客戶端立馬曉得，這是來自于微信官方的大佬，接頭成功，繼續通信。

如果對方出示的公鑰，與客戶端預先嵌入的公鑰不同。客戶端立馬意識到，遇到騙子了，“打死俺也不說” !對待騙子不理不睬，忽視他。。。

當然微信這種加密傳輸，只是為了防止在傳輸過程中泄密。毫無疑問，微信服務器還是可以看到各位聊天的明文數據。

所以，最好不要在微信里明文傳輸非常非常隱私的數據，如果一定要傳，可以先將數據加密之后再傳，接收方解密數據之后，就可以得到明文的數據了。

4、最終結論

微信網頁版，使用公司網絡，公司可以看到聊天內容，無論使用的是公司電腦還是個人電腦。

微信網頁版，使用 4G 網絡，流量沒走公司，公司自然也無法看到聊天內容。

微信手機版，使用私有協議通信，手機 APP 嵌入了服務器的公鑰，APP 只認與這個公鑰一一對應的私鑰簽名。

使用其他私鑰簽名的一概不認，所以無法欺騙微信 APP。使用微信手機版聊天是安全的，無論是使用公司網絡還是 4G 網絡，公司都無法看到聊天內容。

電腦版微信：公司依然無法監控到聊天內容。

作者：車小胖談網絡

編輯：陶家龍

出處：轉載自公眾號車小胖談網絡(ID：chexiaopangnetwork)