寫一篇通俗易懂的HTTPS講解

今天先發布一篇和Android無關的技術文章。


https這項技術現在已經應用得非常廣泛了。隨著蘋果、Google等各大網際網路領頭企業紛紛在自己的作業系統、瀏覽器等主流產品中強制要求使用https，http的淘汰也正式進入了倒數計時。


其實https對於客戶端開發人員來說並沒有什麼需要特別注意的地方，因為程式碼和寫http請求時並沒有什麼兩樣。但也正是因為這個原因，導致許多客戶端開發人員對https並不瞭解，只知道它是安全的加密網路傳輸，對其具體的工作原理卻一無所知。


那麼客戶端開發人員到底需不需要了解https呢？我認為還是有一定必要的，掌握了https的工作原理可以幫助你更加有效地理解並解決一些工作當中遇到的問題。另外，有很多公司也喜歡在面試的時候問一些https相關的問題，如果你完全不瞭解的話，在這裡就很容易會被刷掉。


我自己當初在學習https的時候查閱了很多網上的資料，但是絕大多數的文章寫得都不是那麼易懂，讓不少人對https產生了一些畏懼。我認為要想理解https的工作原理，並不一定非得要知道它方方面面的細節（網上許多文章就是因為寫得太細，導致很難懂），其實只要掌握它的整體工作流程，以及搞清楚為什麼它能夠保證網路通訊的安全就可以了。因此，今天我就給大家帶來一篇最好懂的https講解。


在正式開始講解https之前我們還得先搞清楚兩個概念：什麼是對稱加密，以及什麼是非對稱加密？這兩個概念都是屬於加密學中的基礎知識，其實非常好懂。


對稱加密比較簡單，就是客戶端和伺服器共用同一個金鑰，該金鑰可以用於加密一段內容，同時也可以用於解密這段內容。對稱加密的優點是加解密效率高，但是在安全性方面可能存在一些問題，因為金鑰存放在客戶端有被竊取的風險。對稱加密的代表演算法有：AES、DES等。


而非對稱加密則要複雜一點，它將金鑰分成了兩種：公鑰和私鑰。公鑰通常存放在客戶端，私鑰通常存放在伺服器。使用公鑰加密的資料只有用私鑰才能解密，反過來使用私鑰加密的資料也只有用公鑰才能解密。非對稱加密的優點是安全性更高，因為客戶端傳送給伺服器的加密資訊只有用伺服器的私鑰才能解密，因此不用擔心被別人破解，但缺點是加解密的效率相比於對稱加密要差很多。非對稱加密的代表演算法有：RSA、ElGamal等。


掌握了這兩個概念之後，我們就可以開始學習https了。這裡先提前丟擲一個問題，同時也是面試時可能經常會問到的一個問題：https為了保證資料傳輸的安全，使用的是對稱加密還是非對稱加密呢？


學完本篇文章之後你就能知道答案了。


首先我們來看一下，傳統的http方式在網路傳輸時存在哪些問題。


由於我們在傳輸資料時資訊都是明文的，因此很容易出現資料被監聽和竊取的情況。示意圖如下：




另外，傳輸的資料還有可能被一些別有用心的人篡改，導致瀏覽器與網站收發的內容不一致。示意圖如下：




也就是說，使用http傳輸資料至少存在著資料被監聽以及資料被篡改這兩大風險，因此http是一種不安全的傳輸協議。


那麼解決方案大家肯定都知道是使用https，但是我們先嚐試著自己思考一下該如何保證http傳輸的安全性，進而也就能一步步地理解https的工作原理了。


既然資料以明文的形式在網路上傳輸是不安全的，那麼我們顯然要對資料進行加密才行。剛才提到了，加密方式主要有兩種，對稱加密和非對稱加密。對稱加密的優點是加解密效率高，而我們在網路上傳輸資料是非常講究效率的，因此這裡很明顯應該使用對稱加密。示意圖如下：




可以看到，由於我們在網路上傳輸的資料都是密文，所以不怕被監聽者獲取到，因為他們無法得知原文是什麼。而瀏覽器收到密文之後，只需要使用和網站相同的金鑰來對資料進行解密就可以了。


這種工作機制看上去好像確實保證了資料傳輸的安全性，但是卻存在一個巨大的漏洞：瀏覽器和網站怎樣商定使用什麼金鑰呢？


這絕對是一個計算機界的難題，瀏覽器和網站要使用相同的金鑰才能正常對資料進行加解密，但是如何讓這個金鑰只讓它們倆知曉，而不被任何監聽者知曉呢？你會發現不管怎麼商定，瀏覽器和網站的首次通訊過程必定是明文的。這就意味著，按照上述的工作流程，我們始終無法建立一個安全的對稱加密金鑰。


所以，只使用對稱加密看來是永遠無法解決這個問題了，這個時候我們需要將非對稱加密引入進來，協助解決無法安全建立對稱加密金鑰的問題。


那麼為什麼非對稱加密就可以解決這個問題呢？我們還是透過示意圖的方式來理解一下：




可以看到，如果我們想要安全地建立一個對稱加密的金鑰，可以讓瀏覽器這邊來隨機生成，但是生成出來的金鑰不能直接在網路上傳輸，而是要用網站提供的公鑰對其進行非對稱加密。由於公鑰加密後的資料只能使用私鑰來解密，因此這段資料在網路上傳輸是絕對安全的。而網站在收到訊息之後，只需要使用私鑰對其解密，就獲取到瀏覽器生成的金鑰了。


另外，使用這種方式，只有在瀏覽器和網站首次商定金鑰的時候需要使用非對稱加密，一旦網站收到了瀏覽器隨機生成的金鑰之後，雙方就可以都使用對稱加密來進行通訊了，因此工作效率是非常高的。


那麼，上述的工作機制你認為已經非常完善了嗎？其實並沒有，因為我們還是差了非常關鍵的一步，瀏覽器該怎樣才能獲取到網站的公鑰呢？雖然公鑰是屬於公開的資料，在網路上傳輸不怕被別人監聽，但是如果公鑰被別人篡改了怎麼辦？示意圖如下：




也就是說，只要我們從網路上去獲取任何網站的公鑰，就必然存在著公鑰被篡改的風險。而一旦你使用了假的公鑰來對資料進行加密，那麼就可以被別人以假的私鑰進行解密，後果不堪設想。


方案設計到這裡好像已經進入了死衚衕，因為無論如何我們都無法安全地獲取到一個網站的公鑰，而我們顯然也不可能將世界上所有網站的公鑰都預置在作業系統當中。


這個時候，就必須引入一個新的概念來打破僵局了：CA機構。


CA機構專門用於給各個網站簽發數字證書，從而保證瀏覽器可以安全地獲得各個網站的公鑰。那麼CA機構是如何完成這個艱鉅的任務的呢？下面開始一步步解析。


首先，我們作為一個網站的管理員需要向CA機構進行申請，將自己的公鑰提交給CA機構。CA機構則會使用我們提交的公鑰，再加上一系列其他的資訊，如網站域名、有效時長等，來製作證書。


證書製作完成後，CA機構會使用自己的私鑰對其加密，並將加密後的資料返回給我們，我們只需要將獲得的加密資料配置到網站伺服器上即可。


然後，每當有瀏覽器請求我們的網站時外匯技術面 首先會將這段加密資料返回給瀏覽器，此時瀏覽器會用CA機構的公鑰來對這段資料解密。

如果能解密成功，就可以得到CA機構給我們網站頒發的證書了，其中當然也包括了我們網站的公鑰。你可以在瀏覽器的位址列上，點選網址左側的小鎖圖示來檢視證書的詳細資訊，如下圖所示。




得到了公鑰之後，接下來的流程就和剛才示意圖中所描述的一樣了。


而如果無法解密成功，則說明此段加密資料並不是由一個合法的CA機構使用私鑰加密而來的，有可能是被篡改了，於是會在瀏覽器上顯示一個著名的異常介面，如下圖所示。




那麼你可能會問了，有了CA機構之後就真的安全了嗎？我們在瀏覽器端要使用CA機構的公鑰來解密資料，那麼又該如何安全地獲取到CA機構的公鑰呢？


這個問題就很好解決了，因為世界上的網站是無限多的，而CA機構總共就那麼幾家。任何正版作業系統都會將所有主流CA機構的公鑰內建到作業系統當中，所以我們不用額外獲取，解密時只需遍歷系統中所有內建的CA機構的公鑰，只要有任何一個公鑰能夠正常解密出資料，就說明它是合法的。


Windows系統的內建證書如下：




但是即使使用CA機構的公鑰能夠正常解密出資料，目前的流程也還是存在問題的。因為每一家CA機構都會給成千上萬的網站製作證書，假如攻擊者知道abc.com使用的是某家CA機構的證書，那麼他也可以同樣去這家CA機構申請一個合法的證書，然後在瀏覽器請求abc.com時對返回的加密證書資料進行替換。示意圖如下：




可以看到，由於攻擊者申請的證書也是由正規CA機構製作的，因此這段加密資料當然可以成功被解密。


也正是因為這個原因，所有CA機構在製作的證書時除了網站的公鑰外，還要包含許多其他資料，用來輔助進行校驗，比如說網站的域名就是其中一項重要的資料。


同樣是剛才的例子，如果證書中加入了網站的域名，那麼攻擊者就只能無功而返了。因此，即使加密資料可以被成功解密，但是最終解密出來的證書中包含的域名和瀏覽器正在請求的域名對不上，那麼此時瀏覽器仍然會顯示異常介面。示意圖如下：




好了，方案設計到這裡，其實我們的網路傳輸就已經做到足夠的安全了。當然，這其實也就是https的工作原理。


那麼回到一開始的問題：https使用的是對稱加密還是非對稱加密呢？答案也很明顯了，https使用的是對稱加密與非對稱加密相結合的方式。


當然，如果你想繼續深入研究，https中還有許許多多的細節值得去挖掘。但是繼續寫下去的話，這篇文章可能就不再是最好懂的https講解了，所以我覺得寫到這裡剛剛好。


假如你和我一樣，主要從事的是客戶端方向的開發，那麼瞭解這麼多https的知識已經足夠應對常見的面試以及工作中遇到的問題了。