試用期沒過,因在公司上了 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 的優點:3d

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

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 不能相同,若是是同一個的話也剛好暴露了邏輯漏洞。

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

在這裏插入圖片描述

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

在這裏插入圖片描述

不過,我的認爲,咱也不必過分擔憂。通常公司也不會由於你上班偶爾摸個魚,逛逛淘寶、看看微博來找你麻煩的。畢竟不必這麼點芝麻事情來『大動干戈』。

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

相關文章
相關標籤/搜索