https時代來了，你卻還一無所知？

本文做者：茄果，專一前端開發領域，更多文章請關注知乎專欄《前端小事》

如今打開各大知名網站，你有沒有發現地址欄都已經加了個綠色的小鎖？

是的，這就是https，這就是https的時代。

然而，你瞭解https嗎？

簡單來講，https就是套在SSL/TLS內的http，也就是安全的http。何爲安全？一個安全的網絡通訊環境要解決3個問題：

1. 通訊內容的保密
2. 通訊雙方身份的真實
3. 通訊內容的完整

而https就是爲了解決這3大問題而誕生的（準確來講應該是ssl），下面分別看看這3個問題的解決方案。

通訊內容的保密

通訊內容的保密須要經過加密來實現。咱們的互聯網環境是很是透明的，通訊須要通過不少中轉才能到接收方手中。這個情形有點像你上課的時候給第一排的小紅遞紙條同樣，紙條上你確定不會直接寫今夜三更操場見，而是機靈地寫了老地方見。這個老地方只有你和小紅知道，這樣就算小明小李看到了紙條，他們也不知道老地方是圖書館仍是英語角，這就是加密，而老地方就是所謂的密鑰。

固然，這個例子並非很準確。簡單來講，加解密就是一個函數，而密鑰則是這個函數的參數。好比咱們定義一個簡單的加密函數，f(x)=x+b，x就是輸入的明文，而b是密鑰；解密函數就是加密函數的反函數，也就是g(x)=x-b。當不知道b的時候，你就算看到了密文也猜不出真實內容，這樣就實現了加密。這種加解密都用同一個密鑰，叫對稱加密。

但這裏有個問題，這裏的參數b是怎麼協商出來的？

你和小紅能夠花前月下約好b值，可是在真實網絡環境中你和小紅根本沒有直接溝通的可能，全部溝通都要靠小明小李去傳紙條的話，怎麼作才能躲過他們呢？這裏就須要用到非對稱加密算法了，這種算法有公鑰和私鑰一對鑰匙，公鑰是全部人都能獲取到的鑰匙，私鑰則是服務器私自保存的鑰匙。非對稱加密算法中公鑰加密的內容只能用私鑰解密，私鑰加密的內容則只有公鑰才能解密。因此當你使用小紅的公鑰加密你的紙條以後，幫你傳遞紙條小明小李等人看到紙條也沒法讀取內容了，只有擁有私鑰的小紅才能讀出你的信息。

對稱加密算法在加密和解密時使用的是同一個祕鑰；而非對稱加密算法須要兩個密鑰來進行加密和解密，這兩個祕鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰（private key，簡稱私鑰）。你可能比較好奇非對稱加密算法的原理，可是我這裏不展開講算法，有興趣的同窗能夠自行搜索。

那麼問題來了，小紅給你的迴應也想加密怎麼辦？

若是小紅用她的私鑰加密的話，班上全部人都知道公鑰，而公鑰能夠解私鑰的加密，也意味着全部人都能解密小紅的迴應消息。聰明的你必定想到了解決方案：利用非對稱加密算法加密出一個對稱密鑰給小紅，小紅用她的私鑰讀取對稱密鑰，而後大家就用這個對稱密鑰來作對稱加密，而後就能夠愉快地約約約了。

固然，https也是這麼幹的。

通訊雙方身份的真實

加密以後貌似通訊過程就完美了？且慢，小紅的公鑰是怎麼公告天下的呢？

要知道在網絡環境中全部信息交互都是經過傳紙條的方式來進行的，小紅的公鑰也不例外，萬一在通過小明手裏的時候被掉包了怎麼辦？怎麼保證你手上的小紅公鑰是就是真正的小紅公鑰呢？看到班上的癡男怨女的紙條被各類掉包，文娛委員鳳姐決定自告奮勇。鳳姐想出了一個辦法，全部加密通訊都要帶上一本證，用來證實本身的身份。這本證是鳳姐特地爲班上全部單身狗作的，公鑰就放在證書裏面返回給紙條的發送者，證書裏面除了公鑰還有學號、人名、甚至星座身高三圍等各類信息。證書上蓋了一個大大的鑑定章，這是鳳姐獨有的章，表示證上的信息真實性由鳳姐保證，看到這個章就能夠認爲對方是個真·單身狗。

經過這些信息你就能夠知道對方是小紅仍是如花了，這就是證書機制。

顯然你會懷疑證書上鳳姐的公章是有可能被僞造的，懷疑有理！因此證書上的公章也是非對稱加密過的，加密方式跟上面提到的恰好相反：用鳳姐的私鑰加密，用鳳姐公鑰就能夠解密，這樣就能夠鑑定證書的真僞。這個公章就是證書的數字簽名，具體來講就是先將證書用哈希算法提取摘要，而後對摘要進行加密的過程。另外你也能夠直接拿着證書去找鳳姐，鳳姐就會幫你驗證證書的有效性。（證書是有期限的，因此即便是真證書也會可能過時，須要注意）

這個機制看起來至關完善，可是咱們要以懷疑一切的態度去作安全機制，鳳姐保證的東西是可信任的了。

可是，鳳姐真的是鳳姐嗎？？？

因此，鳳姐自己也要由證書來保證，鳳姐的證書由班主任頒發，而班主任的證書由校長頒發……這個鏈一直到最權威的幾個機構，這些機構在https體系中就是所謂的根CA。根是不可懷疑的權威，他們爲本身帶鹽，本身證實本身是本身。在https證書體系裏面，根證書是操做系統/瀏覽器自帶的，咱們能夠相信被這些機構認證的證書的，從而一層一層推導到鳳姐這個級別。

另外，因爲證書其實很容易作，地鐵口10塊一本，不管哈佛仍是斯坦福，通通10塊！因此有些公司會本身作證書，根本不去找根CA機構，好比著名的12306。你也能夠本身作證書放到網上讓用戶下載導入瀏覽器，但由於你沒有鳳姐的影響力，因此沒人會相信你，固然也有人連鳳姐都不相信……

通訊內容的完整

密也加了，鳳姐的公章也蓋了，是否是這套機制就perfect了呢？

NoNoNo，想一下暗戀着你的小明看到你給小紅傳紙條，內心確定不爽，雖然看不懂可是仍是能夠改密文呀。原本你是要約小紅半夜三更操場見，結果小明刪掉了前半部分的密文，解密後剛好變成了「操場見」，而後小紅下課立刻往操場跑，而你卻跑回宿舍好好洗了個澡。。。而後，而後小紅就跟小明跑了~~

這種篡改通訊內容的場景相信你們都深有體會，咱們訪問一些站點的時候平白無故就出現了運營商的廣告，這都是運營商給加的！！因此內容的完整性也須要保證，這比較簡單：先用哈希算法提取內容摘要，而後對摘要進行加密生成數字簽名，驗證數字簽名就能夠判斷出通訊內容的完整性了。

以上就是https用到技術的簡化版，一個http通訊流程以下：

大致步驟：

1. 客戶端發送Client Hello報文開始SSL通訊，報文中包含SSL版本、可用算法列表、密鑰長度等。
2. 服務器支持SSL通訊時，會以Server Hello報文做爲應答，報文中一樣包括SSL版本以及加密算法配置，也就是協商加解密算法。
3. 而後服務器會發送Certificate報文，也就是將證書發送給客戶端。
4. 客戶端發送Client Key Exchange報文，使用3中的證書公鑰加密Pre-master secret隨機密碼串，後續就以這個密碼來作對稱加密進行通訊。
5. 服務器使用私鑰解密成功後返回一個響應提示SSL通訊環境已經搭建好了。
6. 而後就是常規的http c/s通訊。

根據前文所述，在步驟3和步驟6都會使用摘要和簽名算法來保證傳遞的證書和通訊內容不被篡改。經過這個流程能夠看出，https的核心在於加密，尤爲是非對稱加密算法被屢次使用來傳送關鍵信息。

理解了加密，認識到網絡的透明性，抱着懷疑一切的態度，理解https這套體系就變得簡單了。

結語

最近在系統地重溫http相關的東西，這一篇先介紹了https的基本原理，才疏學淺，文中有不當之處，還望斧正！後續會介紹實際應用、靜態服務器的配置等~

附錄

https如何避免中間人劫持？

若是有人劫持了你的dns服務器，將wwe.icbc.com解析到他的非法網站，或者代理服務器將你導向他的非法網站去，這都是中間人攻擊。若是沒有https，那麼攻擊就這樣發生了。那https怎麼避免這類攻擊？

答案是經過證書鑑別。

1. 在申請證書的時候CA會對所要申請的域名進行控制權認證，因此你是不可能用隔壁老王的網站來申請證書的。就算你黑了他的站點，只要老王去申請證書就能發現了。

2. 若是僞造一個證書，這個證不是權威CA簽發的，那麼瀏覽器檢查的時候會報警提示用戶證書非法。固然用戶仍然能夠繼續操做，好比搶火車票什麼的。。

3. 若是你把真正站點的證書搞下來，證書上的域名不變，只是將公鑰替換掉，那麼瀏覽器比對證書數字簽名的時候就能發現對不上了，二話不說，報警。

4. 若是中間人直接用www.icbc.com的真實證書，那麼他雖然能收到客戶端的消息，可是沒法解密，因此也沒法響應客戶端的請求，攻擊無效！

證書的數字簽名

以前對哈希算法和數字簽名瞭解很少，瞭解以後發現其實原理仍是挺簡單的。哈希算法能夠將大量的數據轉換成定長的摘要，並且摘要是與輸入對應的，輸入變化後摘要也會發生變化。因此對數據應用哈希算法求出摘要，比對摘要就能夠判斷數據是否被篡改過了。證書使用了私鑰加密摘要，而後客戶端就能夠用公鑰解密獲得摘要，對比哈希算法算出來的摘要就能夠判斷證書是否被篡改過。另外一方面，由於公私鑰是成對的，篡改後的證書雖然能求出摘要，可是沒法加密出簽名，因此摘要和加密組合使用就能夠保證證書的真實性了。這裏的私鑰是證書的發證機構的私鑰，也就是CA鏈上CA加密用戶服務器證書，上級CA加密下級CA的證書，從而造成一個信任環。

本文做者：茄果，專一前端開發領域，更多文章請關注知乎專欄《前端小事》

原創文章，轉載請註明出處！本文連接：http://www.cnblogs.com/qieguo/p/6280292.html