Http存在的問題
??上過網(wǎng)的朋友都知道，網(wǎng)絡(luò)是非常不安全的。尤其是公共場所很多免費的wifi，或許只是攻擊者的一個誘餌。還有大家平時喜歡用的萬能鑰匙，等等。那我們平時上網(wǎng)可能會存在哪些風險呢？
??1. 泄密，個人隱私、賬戶密碼等信息可能會被盜取。
??2. 篡改，收到的數(shù)據(jù)可能被第三方修改過，或被植入廣告等。
??3. 假冒，訪問的站點非目標服務(wù)器站點。如域名欺騙、域名劫持、釣魚網(wǎng)站等。

可能住你隔壁穿人字拖、說話都略顯羞澀的小王，一到夜深人靜的時候就開始偷窺你的一舉一動！陪你一起看91某社區(qū)的電影還好，萬一竊取了各購物網(wǎng)站或其他站點的登錄信息就……是不是想想有些害怕呢！

為什么別人能獲取你上網(wǎng)的數(shù)據(jù)呢？有過一定網(wǎng)絡(luò)基礎(chǔ)的朋友多少都對TCP/IP有些了解，對各種握手揮手早已背得滾瓜爛俗，對http協(xié)議也早了然于心。http是應用層的協(xié)議，位于TCP/IP參考模型的最上層。用戶數(shù)據(jù)經(jīng)過應用層、傳輸層、網(wǎng)絡(luò)層、鏈路層的層層封裝后經(jīng)過物理層發(fā)送到目標機器。在這幾層中，數(shù)據(jù)都沒有經(jīng)過加密處理，所以一旦別人獲取到你的數(shù)據(jù)包，就能輕易的獲取到數(shù)據(jù)的信息。

為了保護數(shù)據(jù)隱私，讓數(shù)據(jù)不再“裸奔”。對需要傳輸?shù)臄?shù)據(jù)進行加密處理就很有必要了。目前而言，加密算法可以分兩大類，一類是對稱加密算法，還有一類是非對稱加密算法。

對稱加密
??對稱加密算法的加密和解密都是用同一個密鑰。在一定條件下，對稱加密可以解決數(shù)據(jù)傳輸安全性的問題。比如我在登錄某個網(wǎng)站的時候，需要填寫賬戶名和密碼進行登錄，客戶端把登錄的表單信息進行對稱加密后再傳輸，這時候就算小王截獲數(shù)據(jù)包，他也無法獲取數(shù)據(jù)的內(nèi)容，因為數(shù)據(jù)已經(jīng)被加密了。但是服務(wù)器收到數(shù)據(jù)后也是一臉懵逼，你發(fā)來的加密的數(shù)據(jù)包服務(wù)器也不知道解密的密鑰！

??那是不是客戶端與服務(wù)端在通信之前應該先協(xié)商密鑰呢？客戶端可以通知服務(wù)器需要開啟數(shù)據(jù)傳輸了，然后服務(wù)器告訴客戶端，咱們以后用xxxx這個密鑰進行加密解密吧！

??這樣內(nèi)容是可以加密傳輸了，但是上圖中第一步協(xié)商密鑰的過程又同樣存在安全的問題！萬一小王截獲了協(xié)商密鑰的數(shù)據(jù)，那后續(xù)加密傳輸?shù)臄?shù)據(jù)對小王來說無異于未加密！所以，對稱加密存在密鑰協(xié)商的問題！

非對稱加密
??基于對稱加密存在的問題，又有了非對稱加密。非對稱加密算法需要一組密鑰對，分別是公鑰和私鑰，這兩個密鑰是成對出現(xiàn)的。公鑰加密的內(nèi)容需要用私鑰解密，私鑰加密的內(nèi)容需要用公鑰解密！私鑰由服務(wù)器自己保存，公鑰發(fā)送給客戶端?？蛻舳四玫焦€后就可以對請求進行加密后發(fā)送給服務(wù)端了，這時候就算被小王截獲，小王沒有私鑰也無法解密發(fā)送的內(nèi)容，這樣確保了客戶端發(fā)送到服務(wù)端數(shù)據(jù)的“安全”！但是由于公鑰也需要通過網(wǎng)絡(luò)發(fā)送給客戶端，同樣能被小王截獲，這樣服務(wù)器私鑰加密后的內(nèi)容依然可以被小王截獲并解密，并且非對稱加密的效率很低。

對稱加密和非對稱加密都存在密鑰傳輸?shù)膯栴}，但是至少非對稱加密可以保證客戶端傳輸給服務(wù)端的內(nèi)容無法被“破解”，而對稱加密算法性能又比較好，那我們是不是可以這樣子呢。第一次通信的時候服務(wù)端發(fā)送公鑰給客戶端，由客戶端產(chǎn)生一個對稱密鑰，通過服務(wù)端的公鑰加密后發(fā)送給服務(wù)端，后續(xù)的交互中都通過對稱密鑰進行加密傳輸。也就是說先通過非對稱密鑰加密對稱密鑰，通過對稱密鑰加密實際請求的內(nèi)容。

上面的方案看起來天衣無縫，小王拿到數(shù)據(jù)后貌似就無償下手了，但是真的就天意無縫了嗎？我們看看下圖

也就是說小王可以偽裝成服務(wù)器，與客戶端進行通信。類似于你與服務(wù)端之間多了一個中間商！也就是說協(xié)商密鑰的過程依然存在漏洞！

有點腦闊疼！還能不能讓我安全的上網(wǎng)了！就沒有更安全的機制了么？ 在協(xié)商密鑰的過程中，客戶端怎么能確定對方是真正的目標服務(wù)器呢？怎么證明服務(wù)器的身份呢？我們先了解一下數(shù)字證書！

數(shù)字證書
??我們生活中有各種證，有能證明自己是個有身份的人的身份證，有能證明自己讀了幾年書的畢業(yè)證。這些證都是由某些權(quán)威機關(guān)認證、無法偽造的，能證明自己身份的憑據(jù)。那服務(wù)器是不是也能有個類似身份證的東西，在與服務(wù)器進行通信的時候證明自己確實是目標服務(wù)器而不是小王偽造的呢？在生活中這些證件都是事實在在能看得見摸得著的，而計算機中的證書是虛擬的，看得見但是摸不著，是數(shù)據(jù)形式記錄的，所以叫數(shù)字證書！

客戶端第一次與服務(wù)器進行通信的時候，服務(wù)器需要出示自己的數(shù)字證書，證明自己的身份以及自己的公鑰，類似如下（實際上就是一堆數(shù)據(jù)，這里為了直觀）

那這個數(shù)字證書怎么產(chǎn)生的呢？總不能是服務(wù)器自己造一個吧？上面說到了我們生活中的證書是由權(quán)威機構(gòu)頒發(fā)的、無法偽造的，比如身份證就是由派出所發(fā)證、畢業(yè)證由教育部發(fā)證，如果需要驗證真假，只需要上相關(guān)的系統(tǒng)輸入編號查詢就能查到了！那我們數(shù)字證書也應該有這兩個特性-權(quán)威機構(gòu)頒發(fā)、防偽！

CA機構(gòu)
??CA機構(gòu)就是數(shù)字證書頒發(fā)的權(quán)威機構(gòu)，負責頒發(fā)證書以及驗證證書的合法性。如果服務(wù)器需要做個有身份的服務(wù)器，就需要向CA機構(gòu)提交申請，當然有錢才好辦事，交錢才能給你辦證……

服務(wù)器向CA機構(gòu)提交申請，需要提交站點的信息如域名、公司名稱、公鑰等等，CA審批無誤之后就可以給服務(wù)器頒發(fā)證書了！

客戶端在拿到服務(wù)器的證書后，就需要驗證證書編號是否能在對應的CA機構(gòu)查到，并且核對證書的基本信息如證書上的域名是否與當前訪問的域名一致等等，還可以拿到證書中服務(wù)器的公鑰信息用于協(xié)商對稱密鑰！

證書頒發(fā)了，可是又怎么防止偽造，怎么保證在傳輸過程中不被篡改呢？萬一小王截獲到數(shù)字證書，把公鑰改成自己的那不是依然無法保證安全了么？這就需要數(shù)字簽名了！

數(shù)字簽名
??與公司簽過勞動合同的朋友應該都知道，在合同信息的填寫中，是不能有涂改的，否則需要重新填寫！并且在最后需要甲方和乙方簽名并且蓋章。一旦簽名蓋章后的合同就具有了法律的效力，合同就不能再修改。簽名和蓋章操作就是防止合同偽造，規(guī)定不能修改就防止了合同被篡改！

在實際生活中簽名、蓋章操作是實實在在的動作，作用在具體某個物體上的！但是我們的數(shù)字證書本身就是虛擬的，怎么去給一個虛擬的證書簽名蓋章呢？數(shù)字簽名又是什么機制呢？

我們在做權(quán)限系統(tǒng)的時候，存儲用戶密碼的時候都會經(jīng)過MD5計算摘要后存儲，在登錄的時候計算用戶填寫的密碼的MD5摘要與數(shù)據(jù)庫存儲的摘要進行對比，如果一致則密碼正確，否則登錄失??！MD5是不可逆的，且不同的數(shù)據(jù)計算出來的摘要是不一樣的（當然也有極小的概率會hash碰撞），基于這個特性，就有了數(shù)字簽名的思路。

服務(wù)器提交自己的基本信息想CA機構(gòu)提出申請，CA機構(gòu)在給服務(wù)器頒發(fā)證書的時候，會連同數(shù)字證書以及根據(jù)證書計算的摘要一同發(fā)送給服務(wù)器，且這個摘要是需要經(jīng)過CA機構(gòu)自己的私鑰進行加密的。申請流程如下：

啥？不夠直觀？那我們再來個直觀點的！通過下圖我們能看到，CA給服務(wù)器頒發(fā)的證書是有自己專屬的“公章”的。

哪些CA機構(gòu)對于客戶端來說是權(quán)威或者說是認可的呢？我們打開IE瀏覽器能看到客戶端內(nèi)置的CA機構(gòu)的信息，包含了CA的公鑰、簽名算法、有效期等等…

服務(wù)器在與客戶端通信的時候，就會將數(shù)字證書和數(shù)字簽名出示給客戶端了?？蛻舳四玫綌?shù)字證書和數(shù)字簽名后，先通過操作系統(tǒng)或者瀏覽器內(nèi)置信任的CA機構(gòu)找到對應CA機構(gòu)的公鑰對數(shù)字簽名進行解密，然后采用同樣的摘要算法計算數(shù)字證書的摘要，如果自己計算的摘要與服務(wù)器發(fā)來的摘要一致，則證書是沒有被篡改過的！這樣就防止了篡改！第三方拿不到CA機構(gòu)的私鑰，也就無法對摘要進行加密，如果是第三方偽造的簽名自然也在客戶端也就無法解密，這就防止了偽造！所以數(shù)字簽名就是通過這種機制來保證數(shù)字證書被篡改和被偽造。具體流程如下：

??啥？又不夠直觀？那我們繼續(xù)…

這里需要注意一點，一個是CA機構(gòu)的公鑰，內(nèi)置在客戶端，用來解密數(shù)字簽名！另一個是目標服務(wù)器的公鑰，在數(shù)字證書內(nèi)容里，用來協(xié)商對稱密鑰！

HTTPS
??本文的標題是HTTPS，但是到目前為止HTTPS只字未提！其實HTTPS=HTTP SSL，在HTTP層和TCP之間加了一個SSL/TLS層，如下圖：

??SSL（Secure Sockets Layer）中文叫“安全套接層”，后來由于廣泛應用，SSL標準化之后就改名為TLS（Transport Layer Security）了,其實HTTPS就是通過上面說到的那些手段來解決網(wǎng)絡(luò)上可能存在的數(shù)據(jù)泄密、篡改、假冒的這些問題，保證網(wǎng)絡(luò)傳輸?shù)陌踩睦玻?/p>

看到這里的你，對HTTPS的原理是否懂了呢，反正我奶奶看完已經(jīng)懂了！手動狗頭(*￣︶￣)
??歡迎朋友們加入我的前端學習交流群：562862926群內(nèi)提供免費的前端學習資料（2019最新整理，各種開發(fā)工具）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！