為了一個?HTTPS，瀏覽器操碎了心···
[導讀]我是一個瀏覽器，每到夜深人靜的時候，主人就打開我開始學習。為了不讓別人看到瀏覽記錄，主人選擇了“無痕模式”。但網(wǎng)絡中總是有很多壞人，他們通過抓包截獲我和服務器的通信，主人干了什么，請求了什么數(shù)據(jù)全被他們知道了！光竊聽也就罷了，他們還經常篡改內容，在網(wǎng)頁里面插入誘人的小廣告，真是太壞了！為了保護主人的隱私還他一個干凈的上網(wǎng)環(huán)境，我決定對通信加密！第一版：直接簡單加密加密嘛，很簡單，把原來要發(fā)送的數(shù)據(jù)加密處理后再發(fā)給服務器就行了。為了安全，密鑰當然不能固定，每一次通信都要隨機生成。不過接下來我犯難了，我該怎么把這個秘鑰告訴服務器呢，服務器沒有秘鑰就解不了密，也就不知道我在請求什么資源了。也不能直接...
我是一個瀏覽器，每到夜深人靜的時候，主人就打開我開始學習。為了不讓別人看到瀏覽記錄，主人選擇了“無痕模式”。但網(wǎng)絡中總是有很多壞人，他們通過抓包截獲我和服務器的通信，主人干了什么，請求了什么數(shù)據(jù)全被他們知道了！證書的簽發(fā) 證書的驗證
第一版：直接簡單加密
加密嘛，很簡單，把原來要發(fā)送的數(shù)據(jù)加密處理后再發(fā)給服務器就行了。第二版：非對稱加密
服務器告訴我，我們之前用的那種加密算法叫對稱加密算法，也就是加密和解密使用的同一個秘鑰。還有一種叫非對稱加密算法，這種算法有兩個秘鑰，一個公開的叫公鑰，一個私藏的叫私鑰。第三版：非對稱與對稱加密結合
但我忍了沒幾天就忍不住了。這個非對稱加密算法好是好，就是加解密太費時間了，導致我渲染一個網(wǎng)頁要花很久時間，卡的不行。我打算去跟服務器商量一下辦法，沒想到服務器比我更頭疼，他要服務很多瀏覽器，每一個都這么加解密，把他累的夠嗆。于是我們決定，還是用原來的對稱加密算法，這樣快得多。但是一開始的時候可以用非對稱加密算法來傳輸后面要用的秘鑰，把兩種算法的優(yōu)勢結合起來。第四版：秘鑰計算
有一天，服務器告訴我，我們現(xiàn)在的秘鑰就是一個隨機數(shù)，而隨機數(shù)并不是真正隨機的，可能被預測出來，所以我們得提升這個秘鑰的安全性。一個隨機數(shù)不夠，那就多弄幾個！一端容易被猜出來，那就兩端一起生成！我們決定各自生成一個隨機數(shù)發(fā)給對方，我再額外加密傳輸一個隨機數(shù)給服務器，這一來，咱們雙方都有3個隨機數(shù)了，然后雙方都用這三個隨機數(shù)計算出真正的秘鑰，這可比一個單純的隨機數(shù)要安全得多了。第五版：數(shù)字證書
原以為這個方案已經萬無一失了，沒想到我和服務器的通信還是泄露了···原來有個家伙冒充服務器跟我通信，然后又冒充我跟服務器通信，把我的請求進行了轉發(fā)，我們倆都被蒙在鼓里，這就是中間人攻擊。第六版：信任鏈
我們這加密方案一傳十，十傳百，很快就傳遍了整個互聯(lián)網(wǎng)，想要使用這套方案的服務器越來越多，畢竟，誰都不希望自己的網(wǎng)站被人插入小廣告。可原來的那個公證人有些忙不過來了，于是，大家開始推選更多的公證人，公證人開始多了起來，不僅多了起來，而且還形成了產業(yè)鏈。原來的公證人變成了一代目，一代目可以給新的公證人簽發(fā)證書，新的公證人就變成了二代目，還有三代目，搞得跟傳銷似的。原來只有一個公證人的時候，大家直接保存他的公鑰就行了。現(xiàn)在公證人越來越多，我們沒辦法保存所有的公證人的公鑰了，就算能保存得下，但有新的公證人出現(xiàn)的時候我們也做不到實時更新。PS：本文用故事形式講述了HTTPS是如何工作的，只是起一個引領入門的作用，略去了很多細節(jié)，實際情況遠比這復雜，比如對稱加密秘鑰的計算方式、秘鑰的交換算法（RSA、DH、ECDH還有區(qū)別），雙方測試秘鑰正確性的方式都沒有體現(xiàn)出來，有機會再寫一篇正經的技術文來詳細抓包剖析HTTPS詳細流程。希望本文對大家理解HTTPS機制有一些幫助，再看其他專業(yè)介紹時不再吃力。- EOF -
下載文檔
