【轉】公司能不能監控到大家的微信聊天內容?

轉自:https://mp.weixin.qq.com/s/PMVBdyC8qZ3Q0NidmK1Dyg

最近有朋友私信問我一個問題,在公司用微信聊天,用公司網絡,公司能看到聊天內容嗎?

坦率地說,以前從來沒有分析過微信這類聊天軟件,大概率使用私有協議。而私有協議在協議分析軟件上的呈現,一般都是TCP封裝一長串字節流,而這些字節流究竟是什么內容,協議軟件無法給出答案!看看協議分析軟件能否看到微信網頁版、手機APP版的聊天內容?

網頁版微信

協議分析結果

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

圖片

真實聊天內容

圖片

一摸一樣!

實驗結論

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

實驗分析

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

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

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

手機版微信

協議分析結果

圖片

微信手機版沒有使用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只能捕獲到HTTPHTTPS,至于其它的協議壓根不在其感興趣范圍!

于是,使用Wireshark捕獲微信長連接的TCP報文,確實捕獲到了,再怎么私有實現,總不能長翅膀飛!但是這些TCP報文沒有展示的意義,TCP頭之后字段全是雜亂無章的,這些都在預料之中!

MMTLS****是什么樣的存在?

MMTLSTLS1.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之所以可以實現私有協議,是因為服務器、客戶端都是微信的代碼,再怎么私有,理解起來也沒有任何障礙!

最終結論

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

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

  • 微信手機版,使用私有協議通信,手機APP嵌入了服務器的公鑰,APP只認與這個公鑰一一對應的私鑰簽名。使用其它私鑰簽名的一概不認,所以無法欺騙微信APP。使用微信手機版聊天是安全的,無論是使用公司網絡還是4G網絡,公司都無法看到聊天內容。

?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,488評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,034評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,327評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,554評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,337評論 6 404
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,883評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,975評論 3 439
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,114評論 0 286
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,625評論 1 332
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,555評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,737評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,244評論 5 355
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 43,973評論 3 345
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,362評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,615評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,343評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,699評論 2 370

推薦閱讀更多精彩內容