前言
個人原因最近要離開杭州了，接下來也不知道去哪，其實挺想去深圳發展，但是不知道行情怎麼樣，有沒有深圳的老哥們，介紹一波，哈哈~
好了，廢話不多說，本文主要嘗試著用簡單的語言來解析下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結構拿到正確的非對稱加密的公鑰，使用公鑰加密對稱加密演算法的私鑰，最終使用對稱加密演算法進行訊息加解密.