1. 程式人生 > >【讀書筆記】HTTPS與HTTP

【讀書筆記】HTTPS與HTTP

文章:非對稱加密與HTTPS

總結:

當你訪問一個純HTTP的網站(以及與這個網站有任何網路互動)時,你發出去一個請求。在這個請求到達網站伺服器的路途上,不管是你家的路由器、你樓層的路由器、你小區的路由器、你當地電信的機房裡,再一直到那個網站的伺服器機房之間的所有網路裝置上,都有你請求的資料通過。只要中間有任何一個裝置想要把資料記錄下來,它可以沒有任何阻力的做到,因為這些資料是完全可見、沒有經過任何混淆和加密的。

如果你發出的是一個註冊請求,那這條鏈路上的每個網路裝置都能看見你輸入的賬號密碼;如果你發出的是一個轉賬請求,每個裝置都能看見轉賬金額和目標。

那是不是隻要大家都不在HTTP協議的網站上輸入敏感資訊,網路就變得安全了呢?

不是。除了你的請求,還有網站的響應資料也完整地走了一遍這條鏈路,只是方向相反而已。

HTTPS則完全避免了以上的問題。

HTTPS相比HTTP,在請求前多了一個「握手」的環節。在握手時,你和你想訪問的網站會交換一個金鑰;握手完成後,你的請求先用金鑰加密才會發出去,網站伺服器的響應會先用金鑰加密再傳給你。由於整條鏈路上的節點拿到的資料都是加密過的,所以他們即無法分析出源資料的內容,也無法篡改這個加密過的資料(如果一個節點篡改了加密後的資料,你和伺服器都沒辦法用金鑰解密出來,會認為資料是無效的)

握手環節交換的金鑰難道不會被鏈路上的節點知道嗎?金鑰採用非對稱加密!

非對稱加密思想描繪了這樣的美好場景:你的手上有兩個金鑰(一對金鑰),它們有一定的關聯,但沒有辦法通過其中一個算出另外一個。你把一個金鑰緊緊地攥在手裡,永遠不向別人公佈(私鑰);把另外一個傳送給我,當然,傳送給我的途中,所有的裝置都知道了這個金鑰(公鑰)。之後我用公鑰加密了資料,併發送給你,你卻可以奇蹟般地用私鑰解密它。更神奇的是,中間所有的裝置,居然都不能用公鑰解開它!

假如伺服器要傳輸給我們的是一整張網頁。使用非對稱加密的方法加密時,這個包含數百k的資料被轉換成一個巨大的整數,再對它做e次方的操作,這將是非常耗時的,所以HTTPS選擇了握手時交換金鑰的方案。

總的來說,握手過程中,伺服器會發出一張證書(帶著公鑰),客戶端用公鑰加密了一段較短的資料S,並返回給伺服器。伺服器用私鑰解開,拿到S。此時,握手步驟完成,S成為了一個被安全傳輸到對方手中的對稱加密金鑰。此後,伺服器與我的請求響應,只需要用S作為金鑰進行一次對稱的加密就好。

上面的方案已經很完美了,但是有這麼一種攻擊方案可以輕鬆的突破這一套體系——中間人劫持

 

目前我們解決問題的思路,卻是放在了公鑰發放

上,暫時繞開了這個問題。這就是證書體系(也是為什麼你要去找證書籤發機構花錢購買證書的原因)。

 

簡單來說,一個HTTPS網站響應給我們的並不是一個公鑰,而是證書。證書上包含了公鑰,還包含了域名、簽發機構、有效期、簽名等等。

最後無奈地說,在破解了這麼多數學上的難題後,HTTPS的安全性仍然保證在『證書籤發機構一定都是很有良心的』這種脆弱的基礎上。