大家早上好，有段時間沒更新文章了。

其實疫情期間在家呆了一個多月的時間不能出門，時間倒是挺多的，我也利用這段時間寫了幾篇新文章。但由于新寫的這些文章大都是配合著新書中的內(nèi)容的，受疫情的影響我寫的新書遲遲不能出版，導致這些文章也無法發(fā)布，等得我好是焦急。希望疫情早日結(jié)束，大家都能快點恢復到正常的生活當中。

那么今天先發(fā)布一篇和Android無關的技術(shù)文章。

https這項技術(shù)現(xiàn)在已經(jīng)應用得非常廣泛了。隨著蘋果、Google等各大互聯(lián)網(wǎng)領頭企業(yè)紛紛在自己的操作系統(tǒng)、瀏覽器等主流產(chǎn)品中強制要求使用https，http的淘汰也正式進入了倒計時。

其實https對于客戶端開發(fā)人員來說并沒有什么需要特別注意的地方，因為代碼和寫http請求時并沒有什么兩樣。但也正是因為這個原因，導致許多客戶端開發(fā)人員對https并不了解，只知道它是安全的加密網(wǎng)絡傳輸，對其具體的工作原理卻一無所知。

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

我自己當初在學習https的時候查閱了很多網(wǎng)上的資料，但是絕大多數(shù)的文章寫得都不是那么易懂，讓不少人對https產(chǎn)生了一些畏懼。我認為要想理解https的工作原理，并不一定非得要知道它方方面面的細節(jié)（網(wǎng)上許多文章就是因為寫得太細，導致很難懂），其實只要掌握它的整體工作流程，以及搞清楚為什么它能夠保證網(wǎng)絡通信的安全就可以了。因此，今天我就給大家?guī)硪黄詈枚膆ttps講解。

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

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

而非對稱加密則要復雜一點，它將密鑰分成了兩種：公鑰和私鑰。公鑰通常存放在客戶端，私鑰通常存放在服務器。使用公鑰加密的數(shù)據(jù)只有用私鑰才能解密，反過來使用私鑰加密的數(shù)據(jù)也只有用公鑰才能解密。非對稱加密的優(yōu)點是安全性更高，因為客戶端發(fā)送給服務器的加密信息只有用服務器的私鑰才能解密，因此不用擔心被別人破解，但缺點是加解密的效率相比于對稱加密要差很多。非對稱加密的代表算法有：RSA、ElGamal等。

掌握了這兩個概念之后，我們就可以開始學習https了。這里先提前拋出一個問題，同時也是面試時可能經(jīng)常會問到的一個問題：https為了保證數(shù)據(jù)傳輸?shù)陌踩?，使用的是對稱加密還是非對稱加密呢？

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

首先我們來看一下，傳統(tǒng)的http方式在網(wǎng)絡傳輸時存在哪些問題。

由于我們在傳輸數(shù)據(jù)時信息都是明文的，因此很容易出現(xiàn)數(shù)據(jù)被監(jiān)聽和竊取的情況。示意圖如下：

另外，傳輸?shù)臄?shù)據(jù)還有可能被一些別有用心的人篡改，導致瀏覽器與網(wǎng)站收發(fā)的內(nèi)容不一致。示意圖如下：

也就是說，使用http傳輸數(shù)據(jù)至少存在著數(shù)據(jù)被監(jiān)聽以及數(shù)據(jù)被篡改這兩大風險，因此http是一種不安全的傳輸協(xié)議。

那么解決方案大家肯定都知道是使用https，但是我們先嘗試著自己思考一下該如何保證http傳輸?shù)陌踩?，進而也就能一步步地理解https的工作原理了。

既然數(shù)據(jù)以明文的形式在網(wǎng)絡上傳輸是不安全的，那么我們顯然要對數(shù)據(jù)進行加密才行。剛才提到了，加密方式主要有兩種，對稱加密和非對稱加密。對稱加密的優(yōu)點是加解密效率高，而我們在網(wǎng)絡上傳輸數(shù)據(jù)是非常講究效率的，因此這里很明顯應該使用對稱加密。示意圖如下：

可以看到，由于我們在網(wǎng)絡上傳輸?shù)臄?shù)據(jù)都是密文，所以不怕被監(jiān)聽者獲取到，因為他們無法得知原文是什么。而瀏覽器收到密文之后，只需要使用和網(wǎng)站相同的密鑰來對數(shù)據(jù)進行解密就可以了。

這種工作機制看上去好像確實保證了數(shù)據(jù)傳輸?shù)陌踩?，但是卻存在一個巨大的漏洞：瀏覽器和網(wǎng)站怎樣商定使用什么密鑰呢？

這絕對是一個計算機界的難題，瀏覽器和網(wǎng)站要使用相同的密鑰才能正常對數(shù)據(jù)進行加解密，但是如何讓這個密鑰只讓它們倆知曉，而不被任何監(jiān)聽者知曉呢？你會發(fā)現(xiàn)不管怎么商定，瀏覽器和網(wǎng)站的首次通信過程必定是明文的。這就意味著，按照上述的工作流程，我們始終無法創(chuàng)建一個安全的對稱加密密鑰。

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

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

可以看到，如果我們想要安全地創(chuàng)建一個對稱加密的密鑰，可以讓瀏覽器這邊來隨機生成，但是生成出來的密鑰不能直接在網(wǎng)絡上傳輸，而是要用網(wǎng)站提供的公鑰對其進行非對稱加密。由于公鑰加密后的數(shù)據(jù)只能使用私鑰來解密，因此這段數(shù)據(jù)在網(wǎng)絡上傳輸是絕對安全的。而網(wǎng)站在收到消息之后，只需要使用私鑰對其解密，就獲取到瀏覽器生成的密鑰了。

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

那么，上述的工作機制你認為已經(jīng)非常完善了嗎？其實并沒有，因為我們還是差了非常關鍵的一步，瀏覽器該怎樣才能獲取到網(wǎng)站的公鑰呢？雖然公鑰是屬于公開的數(shù)據(jù)，在網(wǎng)絡上傳輸不怕被別人監(jiān)聽，但是如果公鑰被別人篡改了怎么辦？示意圖如下：

也就是說，只要我們從網(wǎng)絡上去獲取任何網(wǎng)站的公鑰，就必然存在著公鑰被篡改的風險。而一旦你使用了假的公鑰來對數(shù)據(jù)進行加密，那么就可以被別人以假的私鑰進行解密，后果不堪設想。

方案設計到這里好像已經(jīng)進入了死胡同，因為無論如何我們都無法安全地獲取到一個網(wǎng)站的公鑰，而我們顯然也不可能將世界上所有網(wǎng)站的公鑰都預置在操作系統(tǒng)當中。

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

CA機構(gòu)專門用于給各個網(wǎng)站簽發(fā)數(shù)字證書，從而保證瀏覽器可以安全地獲得各個網(wǎng)站的公鑰。那么CA機構(gòu)是如何完成這個艱巨的任務的呢？下面開始一步步解析。

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

證書制作完成后，CA機構(gòu)會使用自己的私鑰對其加密，并將加密后的數(shù)據(jù)返回給我們，我們只需要將獲得的加密數(shù)據(jù)配置到網(wǎng)站服務器上即可。

然后，每當有瀏覽器請求我們的網(wǎng)站時，首先會將這段加密數(shù)據(jù)返回給瀏覽器，此時瀏覽器會用CA機構(gòu)的公鑰來對這段數(shù)據(jù)解密。

如果能解密成功，就可以得到CA機構(gòu)給我們網(wǎng)站頒發(fā)的證書了，其中當然也包括了我們網(wǎng)站的公鑰。你可以在瀏覽器的地址欄上，點擊網(wǎng)址左側(cè)的小鎖圖標來查看證書的詳細信息，如下圖所示。

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

而如果無法解密成功，則說明此段加密數(shù)據(jù)并不是由一個合法的CA機構(gòu)使用私鑰加密而來的，有可能是被篡改了，于是會在瀏覽器上顯示一個著名的異常界面，如下圖所示。

那么你可能會問了，有了CA機構(gòu)之后就真的安全了嗎？我們在瀏覽器端要使用CA機構(gòu)的公鑰來解密數(shù)據(jù)，那么又該如何安全地獲取到CA機構(gòu)的公鑰呢？

這個問題就很好解決了，因為世界上的網(wǎng)站是無限多的，而CA機構(gòu)總共就那么幾家。任何正版操作系統(tǒng)都會將所有主流CA機構(gòu)的公鑰內(nèi)置到操作系統(tǒng)當中，所以我們不用額外獲取，解密時只需遍歷系統(tǒng)中所有內(nèi)置的CA機構(gòu)的公鑰，只要有任何一個公鑰能夠正常解密出數(shù)據(jù)，就說明它是合法的。

Windows系統(tǒng)的內(nèi)置證書如下：

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

可以看到，由于攻擊者申請的證書也是由正規(guī)CA機構(gòu)制作的，因此這段加密數(shù)據(jù)當然可以成功被解密。

也正是因為這個原因，所有CA機構(gòu)在制作的證書時除了網(wǎng)站的公鑰外，還要包含許多其他數(shù)據(jù)，用來輔助進行校驗，比如說網(wǎng)站的域名就是其中一項重要的數(shù)據(jù)。

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

好了，方案設計到這里，其實我們的網(wǎng)絡傳輸就已經(jīng)做到足夠的安全了。當然，這其實也就是https的工作原理。

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

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

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

到此這篇關于最好懂的HTTPS講解的文章就介紹到這了,更多相關HTTPS講解內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論