帶你通俗理解https

前言

我的緣由最近要離開杭州了，接下來也不知道去哪，其實挺想去深圳發展，可是不知道行情怎麼樣，有沒有深圳的老哥們，介紹一波，哈哈~

好了，廢話很少說，本文主要嘗試着用簡單的語言來解析下HTTPS的原理，或者說HTTPS的實現思想，但並不保證真正的實現過程，老哥們能夠自行參考

從一個例子提及

背景

假如你穿越回高中，你和你女友在教室遙遠的對角落，只能經過傳紙條來進行交流（不能直接說話，否則會被抓到早戀，hh），可是又不想紙條的內容內中間傳遞人給看到，那怎麼樣才能達到這樣的效果呢？

STEP ONE

這裏咱們假設男女對象是A和B，中間傳遞紙條的人爲C

這個時候第一想法就是，使用對稱加密的方式，A使用祕鑰對消息進行對稱加密，而後B也經過同一份祕鑰進行解密，這樣就算C看到消息，也是密文，可是有個問題 ，以前也說了A和B是不能直接說話的，那麼這個祕鑰A怎麼告訴B呢，有人說再加密。。那就回到了雞生蛋蛋孵雞的問題了

STEP TWO

爲了解決上面的問題，咱們引出了非對稱加密的概念，特色是私鑰加密後的密文，只要是公鑰，均可以解密，可是公鑰加密後的密文，只有私鑰能夠解密。私鑰只有一我的有，而公鑰能夠發給全部的人

那假如B持有公鑰，自身生成STEP1中約定加密的私鑰（通常使用隨機數），而後用公鑰將此私鑰進行加密，而後A使用非對稱加密的私鑰進行解密拿到B生成的私鑰，而後再用STEP1中的方法進行加解密消息。這樣就是C攔截到消息，因爲只有A有非對稱加密的私鑰，也沒法解密出協商的私鑰

有朋友可能就有疑問了，既然非對稱加密能夠達到這樣的效果，爲啥還要用非對稱加密來協商出一個私鑰，再用對稱加密進行消息加密交互，直接用非對稱加密加密消息不就好了，這裏就涉及到了一個速度以及消耗性能的問題，對稱加密會比非對稱加密的速度更快，計算量小等優勢，詳細的老哥們能夠深刻了解下

STEP THREE

因此如今問題又來了，這個B的非對稱加密公鑰怎麼獲得呢？首先第一想到的方案由A給B發送過去，那麼不由就會有疑問，若是C拿到了這個公鑰，會不會產生問題呢，不仔細思考的可能以爲沒啥問題，畢竟私鑰只有一份在A那裏，只要B是使用公鑰進行加密了，只有A才能解密，C也沒啥辦法。

可是會出現一個問題，這裏假設A那邊的公私鑰稱爲X/Y，A將公鑰X發送給B，C攔截到消息，但C本身也有一套公私鑰，這裏稱爲J/K，C拿到公鑰X後，把本身的公鑰J發送給了B，這個時候B是不知情的，將數據用C給的公鑰J加密後返回，這個時候C又能夠經過私鑰K進行解密，獲得了B的數據，假設C將數據修改後，再經過以前的X公鑰進行加密，而後再傳遞給A，A也能夠經過Y進行解密

引用一張圖方便幫助你們理解下

STEP FOUR

公鑰被掉包的問題，其實也就是身份驗證的問題，B沒法驗證這個公鑰究竟是A給的仍是C掉包以後給的。

因此怎麼解決這個問題，再進行加密解密，感受又要進入到雞生蛋蛋孵雞的問題了，因此，A不可以直接將公鑰傳遞給B，經過一個信任的第三方（假如兄弟閨蜜啥的，hh）用私鑰將公鑰進行加密後，再傳遞給B，B經過公鑰解密出最終A要傳遞的公鑰，若是最終可以解密出來，說明這個公鑰是沒有通過C給掉包的，假如STEP 3的狀況，C使用本身的私鑰加密後，B是沒法使用第三方的公鑰解密的。

那麼如今問題也就回到一點，B是怎麼得到到第三者的公鑰的呢，其實答案是B本身內置了這些第三者的公鑰的，能夠理解爲B是信任這些第三方的，內部會維護一個信任的第三方公鑰列表，只要是經過這些信任列表中的加密以後的東西，B是能夠經過公鑰解密出來的

這裏的第三方映射到https的話，也就是CA機構了，客戶端（瀏覽器）的"證書管理器"，有"受信任的根證書頒發機構"列表。客戶端會根據這張列表，查看解開數字證書的公鑰是否在列表以內

總結

這裏再將上面的例子替換成https，總結下大概流程

• 服務端先持有非對稱加密的公私鑰，將公鑰發送給第三方CA機構，CA機構經過自身私鑰加密公鑰，返回數字證書，服務端將數字證書發送給客戶端
• 客戶端經過數字證書，經過信任證書列表拿到改機構的公鑰進行解密，拿到非對稱加密的公鑰
• 客戶端自身經過隨機數算法等等生成對稱加密算法私鑰，經過第二步拿到的公鑰將此私鑰進行加密
• 服務端經過自己的私鑰進行解密，拿到客戶端生成的私鑰
• 服務端、客戶端經過此私鑰，使用對稱加密算法進行交互，保證數據安全

總結來講Https是經過對稱加密算法+非對稱加密算法+第三方CA機構實現的，使用CA結構拿到正確的非對稱加密的公鑰，使用公鑰加密對稱加密算法的私鑰，最終使用對稱加密算法進行消息加解密.

水平有限，如有錯誤，請及時指出，謝謝

參考資料

https實現原理