這篇原理講的蠻好的https原理通俗理解
還有迪哥的這篇 簡單粗暴系列之HTTPS
https就是http over ssl 。大致原理如下。（還缺了一個自己畫的圖，以后補上）
1： 客戶端-》 服務器 信息傳輸不安全，需要加密
2：使用對稱加密方式A： 產生如下情況
客戶端A--- 對稱加密方式A -----服務器
客戶端B---- 對稱加密方式A ----- 服務器
所有的客戶端和服務器的鏈接都用同一種方式加密，無異于沒加密。
- 所以，解決方案是：
客戶端A--- 對稱加密方式A -----服務器
客戶端B---- 對稱加密方式B----- 服務器
客戶端和服務器之間使用不同的對稱加密方式。如何讓客戶端和服務器知道使用了什么那種對稱加密方式呢。
- 解決方案是：
客戶端A -------我要用加密算法A---> 服務端
客戶端A <---------我知道了--------- 服務端
客戶端B-------我要用加密算法B---> 服務端
客戶端B <------- 我知道了--------- 服務端
客戶端和服務器有一個協商的過程，協商使用那種加密方式和什么秘鑰。 產生的問題是協商的部分沒有加密。可以被中間人攔截。
- 解決的方案：
使用非對稱加密方式，對協商的部分加密。
客戶端（公鑰）------協商內容（對稱加密方式和秘鑰）-----> 服務端（私鑰）
這樣有有一個問題 ，客服端必須有這個公鑰，但是客戶端如何保證該公鑰的確是服務器給的公鑰，如下，客戶端獲取的公鑰可能被篡改
客戶端<---- 假公鑰<-----中間劫持（假公鑰，假私鑰）<----真公鑰---服務器
中間劫持獲取服務端真公鑰,然后下發假公鑰，服務端使用假公鑰加密，中間劫持使用假私鑰解密，然后將信息篡改，使用真公鑰加密后給服務端。
- 解決方案
如果一直加密下去也不是辦法。 這時候需要一個第三方機構來處理。
客戶端 (本地存儲有第三方機構的公鑰)<-- 使用第三方機構的私鑰加密后的(我們的公鑰)---服務端
服務端發送給我們的 使用第三方機構的私鑰加密后的 （我們協商要用的公鑰等信息）的東西稱為 證書。
這樣我們對 客戶端和服務器之間協商要用的自己的公鑰也進行了加密，使用的是第三方機構的私鑰。 而第三方機構的公鑰存在我們本地不用傳輸，保證了不會被劫持和替換 。
如果服務器給我們的證書，我們用本地的第三方公鑰解密不了，說明證書有問題。
現在遇到一個問題，如果同一個第三方機構用同一個私鑰加密了我們要用的公鑰M，給了證書1， 也加密了中間劫持人的公約N，給了證書2.
這時，中間劫持人可以解密我們的證書1， 然后給我們一個偽造或者
篡改后的證書2，此時是同一個私鑰加密獲取的證書，客戶端還是可以解密證書2。
- 解決方案是：使用數字簽名來防止證書有問題
證書在發送到客戶端后，客戶端解密后， 對證書的 內容進行 一個簽名算法（md5等） 然后與證書自帶的 結果進行比對，可以保證證書沒有內容沒有別篡改。
證書內容 ---簽名算法MD5等--> 證書編號結果1 ==？ 證書自帶編號結果2
8.關于第三方機構
到這里： 證書就是TTTPS中的數字證書
證書編號就是數字簽名
第三方機構就是數字證書頒發機構CA
CA的公鑰是如何存在客戶端的呢？
其實呢，現實中，瀏覽器和操作系統都會維護一個權威的第三方機構列表（包括它們的公鑰）
CA如何將證書給我們的服務端的？
簽合同-》付款-》 申請-》頒發。
- HTTP的簡單實現流程（其實和上邊的原理一樣）
1、客戶端首先會將自己支持的加密算法，打個包告訴服務器端。
2、服務器端從客戶端發來的加密算法中，選出一組加密算法和HASH算法（注，HASH也屬于加密），并將自己的身份信息以證書的形式發回給客戶端。而證書中包含了網站的地址，加密用的公鑰，以及證書的頒發機構等；
3、客戶端收到了服務器發來的數據包后，會做這么幾件事情：
?1）驗證一下證書是否合法。一般來說，證書是用來標示一個站點是否合法的標志。如果說該證書由權威的第三方頒發和簽名的，則說明證書合法。
?2）如果證書合法，或者客戶端接受和信任了不合法的證書，則客戶端就會隨機產生一串序列號，使用服務器發來的公鑰進行加密。這時候，一條返回的消息就基本就緒。
?3）最后使用服務器挑選的HASH算法，將剛才的消息使用剛才的隨機數進行加密，生成相應的消息校驗值，與剛才的消息一同發還給服務器。4、服務器接受到客戶端發來的消息后，會做這么幾件事情：
?1）使用私鑰解密上面第2）中公鑰加密的消息，得到客戶端產生的隨機序列號。
?2）使用該隨機序列號，對該消息進行加密，驗證的到的校驗值是否與客戶端發來的一致。如果一致則說明消息未被篡改，可以信任。
?3）最后，使用該隨機序列號，加上之前第2步中選擇的加密算法，加密一段握手消息，發還給客戶端。同時HASH值也帶上。5、客戶端收到服務器端的消息后，接著做這么幾件事情：
?1）計算HASH值是否與發回的消息一致
?2）檢查消息是否為握手消息
握手結束后，客戶端和服務器端使用握手階段產生的隨機數以及挑選出來的算法進行對稱加解密的傳輸。
??為什么不直接全程使用非對稱加密算法進行數據傳輸？這個問題的答案是因為非對稱算法的效率對比起對稱算法來說，要低得多得多；因此往往只用在HTTPS的握手階段。
以下是我們一些經常使用的加密算法
???非對稱加密算法：RSA, DSA/DSS
???對稱加密算法： AES, 3DES
???HASH算法：MD5, SHA1, SHA256
這就是HTTPS的基本原理。
