試用期沒過,因在公司上了 1024 網站...

最近瀏覽到一個知乎問題:某運營同學在試用期期間因爲在工作期間上了某 1024 網站,導致試用期不過。

在這裏插入圖片描述

前兩天還看到不少推文,大意是:看小電影前一定要注意網址是不是 HTTPS 的,因爲 HTTPS 是加密的,別人就不知道了。

看到上面幾個問題,我不禁想問(這腦回路也是……):

  • 通過瀏覽器訪問 HTTPS 站點,其他人真的沒法知道嗎?

  • 通過 App 訪問匿名論壇(HTTPS),公司怎麼知道的?(他是不是接入了公司 WiFi?)

總之就是,上班時間上網摸魚嗎?哪怕用 HTTPS 訪問,如果公司知道,是通過什麼手段?

在這裏插入圖片描述

本文談談我的看法,主要分爲以下幾個方面:

  • HTTPS 爲什麼安全?
  • HTTPS 真的安全嗎?
  • App 如何保證信息安全,不被爬走?
  • 公司可能的監控手段有哪些?我們如何做才能確保自己的隱私泄露?

HTTPS 爲什麼安全

HTTPS,也稱作 HTTP over TLS,TLS 前身是 SSL,會有各個版本。

TLS 協議在 TCP/IP 協議棧中的關係

上圖描述了在 TCP/IP 協議棧中 TLS(各子協議)和 HTTP 的關係,HTTP+TLS 也就是 HTTPS。

和 HTTP 相比,HTTPS 的優勢:

  • 數據完整性:內容傳輸經過完整性校驗。
  • 數據隱私性:內容經過對稱加密,每個連接生成一個唯一的加密密鑰。
  • 身份認證:第三方無法僞造服務端(客戶端)身份。

HTTPS 原理

上圖就是大致介紹了 HTTPS 的握手流程,感興趣的同學可以用 WireShark 抓包詳細看看其中的每一個步驟,有助於理解 HTTPS 的完整流程。這裏,我就不詳述了。

大致就是客戶端和服務端通過“握手會談”商量出一個雙方支持的加密算法和相應隨機參數,得到一對密鑰,後續的傳輸的內容都通過這對密鑰進行加解密。

這對密鑰很牛皮,比如要加密傳輸消息『tangleithu』,客戶端通過公鑰加密得到的密文『xyyaabbccdd』進行傳輸,服務端用自己的私鑰對密文解密,恰好能得到『tangleithu』。

中間錯一位都不行,這樣就保證了數據完整和隱私性。這個過程比較複雜,本文不詳述。

因此,你在通過 HTTPS 訪問網站的時候,就算流量被截取監聽,獲取到的信息也是加密的,啥實質性的內容也看不到。

例如,如下圖所示,當我訪問某個網站,此時通過 wireshark 抓包得到的信息,能獲得僅僅是一些通信的 IP 地址而已。 在這裏插入圖片描述

這下放心了嗎?摸魚的過程中,就算訪問的 IP 地址被知道了,好像也無關緊要?其實,有了 IP 地址也能獲取不少信息了。

在這裏插入圖片描述

還好這個 IP 搜出來是 Github,而不是……

在這裏插入圖片描述

你或許會高興,連個網站域名都看不到,可以放心摸魚了。不過,這是真的嗎? 在這裏插入圖片描述

HTTPS 真的安全嗎?

HTTPS 真的完全安全嗎?連訪問的域名都獲取不到?答案是否定的。上述 HTTPS 在握手階段有一個很重要的東西:證書。

SNI:域名裸奔

當訪問 HTTPS 站點時,會首先與服務器建立 SSL 連接,第一步就是請求服務器的證書。

當一個 Server IP 只對應一個域名(站點)時,很方便,任意客戶端請求過來,無腦返回該域名(服務)對應的證書即可。

但 IP 地址(IPv4)是有限的呀,多個域名複用同一個 IP 地址的時候怎麼辦?

服務器在發送證書時,不知道瀏覽器訪問的是哪個域名,所以不能根據不同域名發送不同的證書。

因此 TLS 協議升級了,多了 SNI 這個東西,SNI 即 Server Name Indication,是爲了解決一個服務器使用多個域名和證書的 SSL/TLS 擴展。

現在主流客戶端都支持這個協議的。別問我怎麼知道這個點的,之前工作上因爲這個事情還費了老大勁兒……

它的原理是:在與服務器建立 SSL 連接之前,先發送要訪問站點的域名(Hostname),這樣服務器會根據這個域名返回一個合適的證書。此時還沒有辦法進行加解密,因此至少這個域名是裸奔的。

如下圖所示,上面的截圖其實是訪問我的個人博客(www.tanglei.name)的抓包情況,客戶端發送握手請求時,很自覺帶上了自己的域名。

在這裏插入圖片描述

因此,即便是 HTTPS,訪問的域名信息也是裸奔狀態。你上班期間訪問小電影網站,都留下了痕跡,若接入了公司網絡,就自然而然被抓個正着。

除了域名是裸奔外,其實還有更嚴重的風險,那就是中間人攻擊。

中間人攻擊

前面也提到 HTTPS 中的關鍵其實在於這個證書。

從名字可以看出來,中間人攻擊就是在客戶端、服務器之間多了個『中介』,『中介』在客戶端、服務器雙方中僞裝對方。

如下圖所示,這個『MitmProxy』充當了中間人,互相欺騙:

在這裏插入圖片描述

中間人攻擊,來源 evil0x

可以安裝 MitmProxy 或者 Fiddler 之類的抓包軟件嘗試一把,然後開啓代理。

此時用手機訪問百度,得到的信息如下: 在這裏插入圖片描述

證書信任前

提示,連接不是私密連接,其實就是瀏覽器識別了證書不太對勁,沒有信任。而如果此時手機安裝了 Fiddler 的證書,就會正常訪問。 在這裏插入圖片描述

證書信任後可正常訪問

因此,當你信任證書後,在中間人面前,又是一覽無餘了。

而如果你用了公司電腦,估計你有相應的操作讓信任證書吧,或者手機上是否有安裝類似的客戶端軟件吧?

抓緊時間看看手機的證書安裝明細(比如我手機上的):

在這裏插入圖片描述

我前任公司在信息安全這塊做得就非常謹慎,手機會有工作手機,未授權的任何 App 都不能安裝,誰知道 App 會悄悄幹些什麼事情呢。(最新熱點,QQ 掃描瀏覽器歷史記錄,你可知道)

當然各種 App 肯定也不是喫素的,不會讓『中間人攻擊』這麼容易就得逞的,咱們接着看。

如何防止信息安全,反爬

前面提到,要實施中間人攻擊,關鍵在於證書是否得到信任。瀏覽器的行爲是證書可以讓用戶授權是否信任,而 APP 就可以開發者自己控制。

比如我嘗試通過類似的方式對某匿名社區進行抓包解密 HTTPS,但最終失敗了,爲什麼呢?

在這裏插入圖片描述

這就要談到『SSL Pinning』技術。App 可以自己檢驗 SSL 握手時服務端返回的證書是否合法,“SSL pinning” 技術說的就是在 App 中只信任固定的證書或者公鑰。

因爲在握手階段服務端的證書必須返回給客戶端,如果客戶端在打包的時候,就把服務端證書放到本地,在握手校驗證書的環節進行比較,服務端返回的證書和本地內置的證書一模一樣,才發起網絡請求。

否則,直接斷開連接,不可用。當然,一般情況下,用這種技術也就能防止 HTTPS 信息被解密了。

不過,也還有其他的技術能夠破解這種方法,比如 Android 下的一些 Hook 技術,具體而言就是繞過本地證書強校驗的邏輯。

感興趣的同學可以抱着學習目的研究一下。不過據說這種方式需要對系統進行 Root、越獄等,需要一些更高權限的設置。

因此,也告誡我們,一定不要亂安裝一些軟件,稍不注意可能就中招,讓自己在互聯網上進行裸奔。

一方面個人隱私信息等泄露,另外一個方面可能一些非常重要的如賬戶密碼等也可能被竊取。

可能的監控手段有哪些?

辦公電腦當然要接入公司網絡,通過上面介紹的內容,你也應該知道,你在什麼時候瀏覽了哪些網站,公司其實都是一清二楚的。

若自己的手機如果接入了公司網絡也是一模一樣(連 Agent 軟件都不需要裝)。這就提醒我們,私人上網儘量用自己的移動網絡呀。

瀏覽記錄,來源知乎

上面提到,如一些涉及隱私的敏感信息,如一些 PC 軟件、手機 App 自己內部加密傳輸的話,內容加密(包括但不限於 HTTPS)不被破解也問題不大。

不過,這當然依賴這些軟件設計者的水平了。比如同一個匿名用戶對外展示的 ID 不能相同,如果是同一個的話也恰好暴露了邏輯漏洞。

當然,我們還是不要抱有僥倖心理,在監管的要求下,如果確實有一些違法等不恰當的言論等,始終還是有門路找到你的。

在這裏插入圖片描述

更何況,一般辦公電腦都會預安裝一些公司安全軟件,至於這些軟件究竟都幹了些什麼,有沒有進行傳說中悄悄截圖什麼的,這就因人(公司)而異了。(不討論類似行爲是否涉及到侵犯了員工隱私等問題)

在這裏插入圖片描述

不過,個人認爲,咱也沒必要過度擔心。一般公司也不會因爲你上班偶爾摸個魚,逛逛淘寶、看看微博來找你麻煩的。畢竟沒必要這麼點芝麻事情來『大動干戈』。

但最好是不是對照員工手冊來看看,是否有明令禁止的行爲?自己的行爲是不是太過了,免得被抓住把柄,正所謂『常在河邊走哪有不溼鞋』,『欲加之罪、何患無辭』。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章