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的證書，從而形成一個信任環。

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

以上是https時代，你還對他一無所知嗎？的詳細內容。更多資訊請關注PHP中文網其他相關文章！