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

本文首發自【程序猿石頭】微信公衆號:可怕,原來 HTTPS 也沒用 其餘相同內容均爲未受權轉載抄襲。html

用 HTTPS 摸魚,你覺得就安全了?

工做時間上網摸魚,你覺得公司就不知道了?git

背景

最近發生了幾個事情,想必你已經看到過了:github

  • 網傳 某PDD員工在某匿名社區發佈同事被擡上救護車的照片被抓出來並辭退?web

  • 某運營同窗在試用期期間由於在工做期間上了某 1024 網站,致使試用期不過。(剛好今天瀏覽到一個知乎問題)算法

試用期不過因在公司瀏覽 1024 網站試用期不過因在公司瀏覽 1024 網站windows

  • 前兩天還看到很多公衆號推文,大意是:看小電影前必定要注意網址是否是 HTTPS 的,由於 HTTPS 是加密的,別人就不知道了。

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

  • 經過瀏覽器訪問 HTTPS 站點,其餘人知道嗎?
  • 經過 App 訪問匿名論壇(HTTPS),公司知道麼?(他是否是接入了公司 WiFi?)

總之就是,上班時間上網摸魚嗎?哪怕用 HTTPS 問,若是公司知道,是經過什麼手段?安全

本文談談個人見解,主要分爲如下幾個方面:服務器

  • HTTPS 爲何安全。
  • HTTPS 真的安全嗎?
  • App 如何保證信息安全,不被爬走?
  • 公司可能的監控手段有哪些?咱們應該怎麼作?

HTTPS 爲何安全

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

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

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

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

上面內容參考了HTTPS工做原理[1]。(石頭在N 久前用印象筆記收藏的,如今好多原文訪問不了了)

HTTPS 原理HTTPS 原理

上圖就是大體介紹了 HTTPS 的握手流程,感興趣的同窗能夠用 WireShark 抓包詳細看看其中的每個步驟,有助於理解 HTTPS 的完整流程。這裏,我就不詳述了,能夠參考下小林的這篇圖解 HTTPS,很詳細;石頭在 14 年也寫過一篇抓包分析的文章。 Mac/Windows Wireshark/tcpdump抓包TCP 3次握手,4次揮手實例[2]

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

這對密鑰很牛皮,好比要加密傳輸消息『tangleithu』,客戶端經過公鑰加密獲得的密文『xyyaabbccdd』進行傳輸,服務端用本身的私鑰對密文解密,剛好能獲得『tangleithu』。中間錯一位都不行,這樣就保證了數據完整和隱私性。

這個過程比較複雜,本文不詳述,相似的原理可參考石頭多年前寫的這篇文章 —— RSA算法

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

例如,以下圖所示,當我訪問某個網站,此時經過 wireshark 抓包獲得的信息,能得到僅僅是一些通訊的IP地址而已。

HTTPS加密傳輸HTTPS加密傳輸

這下放心了嗎?

摸魚的過程當中,就算訪問的 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 SNIHTTPS SNI

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

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

中間人攻擊

前面也提到 HTTPS 中的關鍵其實在於這個證書。從名字能夠看出來,中間人攻擊就是在客戶端、服務器之間多了個『中介』,『中介』在客戶端、服務器雙方中假裝對方,以下圖所示,這個『MitmProxy』充當了中間人,互相欺騙:

中間人攻擊,來源 evil0x中間人攻擊,來源 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 不能相同,若是是同一個的話也剛好暴露了邏輯漏洞。

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

耗子尾汁耗子尾汁

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

圖源知乎圖源知乎

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

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

石頭才疏學淺,文章不免有所疏漏,若有相應問題,還望你們指教。最後,祝你們一生都不要由於這種事情掉坑裏。

後記

本文重點強調了 HTTPS 的知識點(中間人攻擊、SNI等),其實早在域名解析階段就已經暴露了。

對域名發起請求前,要知道域名的IP地址,就要訪問DNS服務器,公司只需網絡中指定DNS服務器,截獲不加密的 DNS 報文分分鐘就瞭解「摸魚」的狀況。

DNSDNS

這裏引用下公衆號文章發出後,某個讀者的評論,以爲有收穫,特此補充以下:

想要「偷偷」的摸魚不被監控,除了上文中提到的 HTTPS,不要忘了安全的DNS,DoH(DNS over HTTPs, DoH)或DoT(DNS over TLS, DoT)。

目前比較好的方式仍是,本身搭建DoH的DNS server,連上網絡後設置DNS服務器爲你的server IP,原生Android甚至在設置裏提供了「私人DNS」選項。

固然若是還能跑一個代理服務,前面提到的SNI泄露訪問域名的問題也一塊兒解決了。抓包只能發現你一直在訪問你本身的server。爲了再真一點,甚至能夠在你的server上再搭一個web server,放上一些內容,這樣就算有人追蹤到這個IP,打開看也是一個正常的站點。

參考資料:

  • HTTPS工做原理: https://cattail.me/tech/2015/11/30/how-https-works.html
  • 如何評價互聯網公司監控員工平常上網的行爲?: https://www.zhihu.com/question/46818840/answer/103329958
  • 網傳拼多多員工因在網上發佈同事被擡上救護車的照片,被管理層逼迫主動辭職、趕出公司?事件真實性如何?: https://www.zhihu.com/question/438581129/answer/1670519587
  • HTTPS工做原理: https://cattail.me/tech/2015/11/30/how-https-works.html
  • 淺析HTTPS中間人攻擊與證書校驗: http://www.evil0x.com/posts/26569.html
  • Mac/Windows Wireshark/tcpdump抓包TCP3次握手,4次揮手實例: https://www.tanglei.name/blog/example-show-3-times-handshaking-of-tcp-in-mac-or-windows.html
相關文章
相關標籤/搜索