我們用https的目的是什麼？
為了 a端與b端互發的訊息 就算被攔截獲取到也是加密了無法檢視的，通用的加密/解密過程如下：
以上的過程分析如下：
1 a端傳入加密串"xx"進a端的加密方法中，加密處理後假設生成了「fwe^%^&y*h^」。
2 然後a端將「fwe^%^&y*h^」傳送到b端。
3 b端接收到「
fwe^%^&y*h^」後，用其b端上的解密方法進行解密獲得"xx"，根據"xx"查到了對應的字串"yy",然後用自己的對應的加密方法將"yy"加密成」**&6jnj^^&「。
4 b端將」**&6jnj^^&「傳送給a端，然後a端同樣用其解密方法進行解密拿到返回結果"yy"。
注：以上是一般加密演算法的通用過程，常用的加密演算法型別一般有對稱加密和非對稱加密。但是！！需要確保雙方都清楚對方的加密演算法，才能正確加解密。
如何確保雙方都清楚對方的加密演算法？
具體的方案是：假設a端是伺服器，b端是客戶端，c端是客戶端，則可以b、c端請求a端，然後a端返回對應的加密演算法如下：
通過上面的過程b、c。。。等的客戶端就能拿到a端提供的加密演算法。
確保清楚加密演算法會有什麼安全隱患？
但是！！上一步是客戶端生成一些加密申請資訊然後像服務端請求，這樣客戶端向服務端請求的過程中，加密申請資訊就可能會被攔截並篡改掉然後發給a端，其可能的篡改過程如下：
以下舉乙個例子作為解析：這裡通過客戶端向服務端傳送加密方式，然後服務端用客戶端提供的加密方式對帶公鑰的資料穿進行加密，最後將當前資料串發給客戶端，客戶端用它最早提供的加密引數進行解密，然後拿到了服務端提供的公鑰pub_key，然後服務端和客戶都安各自儲存當前pub_key用非堆成加密確保資料傳輸安全。
1 假設客戶端向服務端傳送了如下資料，當前資料用data表示(即b端發下面的資料給a端)：
----
----
2 這時，中間人竊取到了上面"1"中的資料data，然後將其篡改為如下(此次篡改後的資料表記為data1)：
----
----
3 中間人將"2"中篡改過的data1發給a端。
4 這是a端接收到的資料是篡改後的，所以是不對的，
服務端即a端就會根據篡改後的請求資料去找到自己的加密演算法，也有可能根據其他引數返回不同的資料
，然後假設服務端使用客戶端提供的加密引數進行加密，返回的資料如下(此次返回的資料標記為data2)：
----
" //其餘的擴充套件引數
}--加密後的資料串(這個返回的資料標記為data3) 假設為：
u2fsdgvkx1+ysgbsyezmq0fl4/v/vg9gb+b9w
----
5 這時，中間人竊取到了"4"中的data2(即由服務端發過來的)，然後中間人獲取到加密串data3之後用在"2"中篡過改的data1的加密引數進行解密，拿到了服務端的返回資料data2，然後修改data2為如下資料(標記為data4)：
----
" //其餘的擴充套件引數
！！！這裡將a、b值都篡改了
}--然後用在"1"步中拿到的原真實加密資料data對上面的data4加密(標記為data5)：a9wlh549w3ziqz/pbqj05ggfu=
----
6 中間人將data5 發給客戶端，客戶端即b端接收到了data5後，使用data的加密引數對data5解密，解密後得到中間人篡改後的data4資料。
注：中間人在服務端返回給客戶端的過程中，用了篡改的加密引數對服務端的資料進行解密，然後用客戶端原來發給他的加密引數進行加密，這是為了讓客戶端那邊能夠正常解密。
如何為客戶端/服務端確認加密演算法這個過程加上乙個保障?
上一步我們通過客戶端-服務端的互動確認的加密演算法，但是因為都是明文的，所以造成傳輸的過程中被中間人竊取、偽造、冒充。這樣導致服務端和客戶端都被中間人欺騙了，均接收到了假資料。
上面可知加密的過程是通過客戶端服務端先確認了乙個公有的加密演算法然後服務端加密出乙個公鑰返回給客戶端，客戶端和服務端就能同時持有這個公鑰，然後使用非對稱加密來傳輸資料。這裡的關鍵點是客戶端與服務端先用大家的知道的進行加密，然後最後在服務端決定出了乙個公鑰，然後使用大家都知道的對這個公鑰進行加密，因為這個公鑰是隨機的，這樣就確保加密的演算法是隨機的。然而客戶端發給服務端確認大家都知道加密演算法時會被中間人竊取，這個就是我們需要優化的點，優化了之後才能確保加密的公鑰不被其他人所知。
但是！！怎麼保障了？可通過https的ssl/tls協議保證安全如下：
1 。為什麼要用ssl/tls？
從上面分析得到當前確保權的方法最終是拿到加密的公鑰來進行資料傳輸的加密，然後服務端用對應的私鑰解密，比如上面舉的例子就是用另乙個加密演算法對這個生成的公鑰進行加密然後返回，但是又涉及到了這個"另乙個加密演算法"的安全問題。但是如何確保傳輸的過程中加密公鑰不被竊取，這時候
https就採用了ssl/tls協議中的數字證書來替代這個簡單的"另乙個加密演算法"，確保身份驗證的安全，避免資料被竊取
。2。數字證書的作用？
數字證書能確保"另乙個加密演算法"的公鑰安全可信。即會將"另乙個加密演算法"的公鑰放在數字證書裡面，只要數字證書是可信的，那麼這個公鑰就可信。
3。公鑰是安全了，但是如何又確保數字證書安全？
因為數字證書不是乙個人私有的(數字證書給多家公司提供)，所以單純使用數字證書的話。如果數字證書裡面的公鑰被調包了，我們就無法分辨是否正確。這時候需要身份驗證即
"數字簽名"
。可通過數字簽名來確保身份的安全，什麼是數字簽名？
伺服器通過第三方機構提供的私鑰採用非對稱加密演算法對證書編號進行加密，然後在返回數字證書給客戶端。
客戶端通過第三方機構的公鑰對其數字簽名(證書編號)進行解密，然後使用證書上的其他引數對這些引數進行加密等到客戶端生成的證書編號。最後比較兩個是否相等，如果相等就身份驗證通過。
本圖參考自：
但是！客戶端是怎麼辨別數字證書是真的？
瀏覽器維護了所有合法機構的證書，可以直接在瀏覽器找到(當然瀏覽器被黑了話那也沒辦法了)。
說完上面的，說說ssl/tls的請求響應過程？
ssl/tls分為三步如下：
（1） 客戶端向伺服器端索要並驗證公鑰。
（2） 雙方協商生成"對話金鑰"。
-------------------------------------------
（3） 雙方採用"對話金鑰"進行加密通訊。
其中前兩步屬於握手階段，其握手階段如下：
其中上圖是使用數字證書包含會話金鑰即資訊互發的公鑰安全，會話金鑰是上圖隨機數a+b+c組成的，這樣可確保當前偽隨機數的隨機性更大。
更多待續。。。。。。。。。。。。。。
參考文件：
HTTPS原理解析
開門見山地說，眾所周知，https http ssl tls，使用非對稱加密演算法 對稱加密演算法的混合加密演算法。最近在面試過程中被問到幾次這個問題，看過幾篇部落格，說的都不是很清楚，理解也有偏差，毫無意外的面試都掛了，今天看到了阮一峰老師的部落格 ssl tls 協議，終於有一種醍醐灌頂的感覺。...
HTTPS原理解析
https的驗證流程 延伸的問題 如果中間人自己向權威機構申請乙個證書，並且把服務端發來的證書進行偷換成自己的證書，該如何？並不能造成危害，因為證書的簽名是由服務端 等資訊生成的，並且經過機構私鑰加密，中間人無法篡改。所以，發個服務端的證書是無法通過驗證的。https的缺點 https和http的區...
https原理解析
最近公司分享會講了這塊的內容，於是就學習了一下。在客戶端和伺服器中作怪的中間人無非做三件事 竊聽 假冒 篡改 https的出現就是為了防止中間人作怪的。這裡要引入兩個概念 想想，兩方通訊若是直接明文傳輸，相當於打 中開著揚聲器，巴拉巴拉，周圍的人都能聽到，有危險的機率不言而喻。所以我們就要加密，用什...