這一次，完全理解 https 原理

個人github/blog，若star，無比感謝

建議電腦觀看，圖有點擠，手機屏幕過小可能看不清楚。

放輕鬆

做爲一個前端er，你總會在學習或工做中，聽到這樣的聲音：什麼是https？你對https理解多少？說一說https吧？等此類問題，這也是在前端面試中比較容易被問到的問題，目的在於考究被面試者的知識廣度，我相信你也不想在被問到的時候是如下表情：

此篇文章旨在幫助對於 https徹底沒有了解的小小前端er創建起一個宏觀的理解，此處的「宏觀」並不是草草了事，而是涉及到一些加密算法不予解析以及技術細節不予解讀，總之這篇文章不須要多少的思考與理解能力，只須要認真地閱讀，我相信你必定會理解 https原理的，請 放輕鬆。好了，讓咱們先來進入如下一個場景。

Michael和琪兒長期合做的夥伴關係，他們之間常常有密切的交易聯繫，常常會涉及一些金額的絕密信息須要經過互聯網發送至對方，然而擁有技術的黑客Jack早已凱覦已久，總想着盜取點什麼信息。

一天，Michael和琪兒仍然按着原來的方式來進行通訊，所謂原來的方式，就是不對想要發送的信息作任何處理，直接在網絡上傳輸：

這下，黑客Jack可樂壞了，他截獲了Michael的消息，並把其中的卡號改爲了本身的，給琪兒發了過去：

此時琪兒並不知道Michael發過來的信息以及被篡改過了，因而將資金打入了黑客本身的銀行帳號(上圖中的8888)，而且出於禮貌給了一個簡單的回覆，這條回覆事實上也能被黑客Jack截獲，可是他並不在乎了，收到錢後的他揚長而去，直到Michael再次發消息給琪兒催款的時候，琪兒才知道本身被黑客攻擊了。

咱們將以上的各類關係與咱們與服務端獲取發送消息的關係對應一下：

Michael	琪兒	黑客Jack	原來的方式
客服端	服務端	中間人	http

解決辦法之一：對稱加密

這下壞了，Michael和琪兒已經不敢在如此的進行信息交換了，否則鬼知道還要送多少錢給黑客Jack，可是生意仍然要作啊，交易也不能中止，Michael不可能爲了叫琪兒打個錢還得特地坐飛機去找琪兒，並當面告訴他卡號吧？（在此請不要問爲何不打電話，問就是爲了場景須要，沒有電話😊）

聰明的Michael想了一下子說：「不如你設定一個規則，我給你發消息的時候，我用這個規則去對數據進行變換，讓它不會被直接認出來咱們說了什麼，而後你收到以後你再用這個規則將變換後的信息轉變回真正的信息。 你如今先給我講一下這個規則吧」，琪兒說：「那咱們將每一箇中文字的拼音中的每一個字母用1-26的數字代替，每一個英語字母.....balablabala」( 此處即是一個加密及解密的「算法」，也就是一個key，具體的算法有不少，不展開)，Michael聽聞後說：「這個規則(加密算法)很是nice，就這樣作吧」。

以上演示的就是對稱加密算法，加密和解密用的都是同一個key，且雙方都互有。

不久後，琪兒發現這個方式有嚴重的漏洞：

• 個人客戶遍及全球，若是某黑客(好比Jack)冒充個人客戶，得到了個人key，也就是個人加密算法，那他豈不是又能夠像以前同樣截獲解密其餘客戶發給個人消息啦？
• 就算我對每個客戶生成一個不一樣的key，且不說個人記憶存儲成本有多高，那黑客要是在我發送key給客戶的時候就截獲了這個key，那他又能夠肆無忌憚地解密了。

這該死的黑客把Michael和琪兒搞的很頭大，不過Michael恰好認識一個搞密碼學的朋友，一次閒聊中Michael從他那裏得知了一種加密算法，稱爲非對稱加密算法(RSA)，這下Michael可樂壞了，立馬告訴了琪兒。

解決辦法之二：非對稱加密

所謂非對稱加密，其實原理很簡單，以前琪兒只有一個公共的key，全部客戶(其中也能夠有黑客)均可以獲取到，或者截獲到，從而能解密其餘人的消息。可是如今不同了，琪兒有兩個key，一個公鑰(public key)，全部人均可以獲取獲得；另外一個是私鑰(private key)，只有琪兒一我的知道。

如今Michael發正式消息以前，先問琪兒索要公鑰：

獲得公鑰以後，使用公鑰去對要發送的正式消息進行加密，琪兒接收到以後，再用本身的私鑰去解密（私鑰只有琪兒有，只有她才能解開這個公鑰加密的內容）

如今就算黑客Jack從中間截獲了Michael的消息，因爲他沒有琪兒的私鑰，他看到的也是一陣亂七八糟的字符，根本無從解密，黑客Jack存在感降低了許多。

反過來也是一樣地，若是琪兒想要給Michael發消息，也得先索要Michael的公鑰，琪兒獲得後用其加密發送，Michael再用本身的私鑰解密。爲了便於理解，咱們如今只討論單向通訊，默認雙方都完成了一樣創建通訊的動做。

在雙方用非對稱加密通訊了一段時間後，他們又發現了這個方式通訊效率特別低(這是非對稱加密算法的問題，不作深究)，比以前的對稱加密慢了100多倍，實在讓人難以忍受，因而聰明的Michael將對稱加密和非對稱加密結合在一塊兒，分兩步走：「(1)琪兒先生成一個臨時的對稱加密的算法，也就是一個臨時key，而後將該key以非對稱加密(RSA)的方式發給Michael;(2)Michael安全拿到對稱加密算法key以後，以後他們的通訊就以對稱加密方式進行」。

如今看起來解決了安全地傳遞對稱密鑰的問題，又解決了速度問題，簡直妙！

在Michael爲本身的聰明沾沾自喜時，黑客Jack表示這就是雕蟲小計，Jack發起了惡名昭彰的中間人攻擊

中間人攻擊

根據以上的對稱 + 非對稱加密算法可知，Michael須要一開始問琪兒拿到公鑰，由於黑客Jack也有本身事先設好的公鑰和私鑰，當他截獲了Michael問琪兒索取公鑰的消息，Jack就把本身的公鑰發給了Michael，並假惺惺地把這條消息經過本身繼續傳給琪兒。

琪兒收到索取公鑰的請求，將公鑰發送回並附帶了一條信息，黑客Jack截獲了這個公鑰以後，只將信息發給Michael，琪兒的公鑰本身保留。

以後Michael就用Jack的公鑰去加密本身想要發送給琪兒的數據信息，並被黑客Jack截獲，Jack再用本身的私鑰去解密，便能獲取Michael的信息，並且能夠隨意篡改消息內容，用以前保留的琪兒的公鑰去加密發送給琪兒，這一切能夠用如下一張圖解釋：

是的，Michael和琪兒再一次被噁心到了，可是問題仍是得解決啊，日子還得過，生意還得作啊。

解決辦法之三：第三方公證機構涉入

上面的核心問題是Michael沒法確保本身拿到的公鑰是琪兒的公鑰，那可不能夠創建一個公證處(CA)，只要琪兒拿着本身的公鑰去公證處開個證實，把一些琪兒的我的信息、開具的證實和琪兒的公鑰包裝成一個證書，凡是收到這個證書的客戶，就能確認這是琪兒的公鑰，從而再進行安全地傳輸。這就好像一我的去jc局開身份證同樣，去開一個能證實本身身份的東西。

公證處(CA)有本身的私鑰和公鑰

但是一個無解的問題又冒出來了，Michael又怎麼知道這個證書在傳輸過程當中沒有被黑客篡改呢？？不用擔憂，數字簽名幫助咱們～

數字簽名

琪兒如今準備去公證處(CA)開具證實，可是會出現上面咱們想到的無解的問題，因而琪兒先把本身的公鑰和我的信息以及一些其餘必要的信息用一個 hash算法 生成一個 數字摘要 ，這個 hash算法 有很好的特性，只要信息內容有一點的更改，從新使用該算法生成的 數字摘要 內容將會產生鉅變。

以後，公證處(CA)使用本身的私鑰對該 數字摘要 進行加密，生成一個叫作 數字簽名 的東東。

數字證書

再以後，把琪兒的原始信息和 數字簽名 合併，造成一個全新的東西，叫作 數字證書

這時候，Michael問琪兒索要公鑰的時候，琪兒就把該頒發的證書發送給Michael

Michael收到該證書後，先用從證書內拿到的 hash算法 對琪兒的原始信息生成新的 數字摘要 ，再用公證處(CA)的公鑰對 數字簽名 進行解密，也生成一個 數字摘要 ，還記得咱們說過的該hash算法的特性馬？只要有一點內容變更，摘要就會產生巨大變更，因此若是琪兒的一些信息被篡改了，hash生成的摘要將會與CA公鑰解密獲得的摘要有巨大的不一樣，由此可斷定傳過來的公鑰等其餘信息是否被中途篡改過。

(我知道你想問CA的公鑰是如何獲取的，你們先暫時理解爲存在了你的操做系統裏，或者自定義添加的)

若是如今Michael終於確認了是琪兒的公鑰後，他就能夠高枕無憂的使用非對稱加密算法先獲取琪兒臨時生成的對稱加密算法key，進行安全通訊了。

結語

很是感謝你們的認真閱讀，文中大量圖片都是本人爲了幫助你們理解繪製，但願你們經過本篇文章的閱讀，真的理解了https的原理，這也是我寫此文的目的，若文筆有所不適之處，請儘量見諒。另外，本文參考了許多文章，奈何寫該篇文章的時候已經不記得參考過的文章了，也沒有去從新找過，故沒有放出參考文章，至此抱歉。