一、原理
1. 資料傳輸過程
瀏覽器訪問一個HTTPS URL的資料傳輸的過程：
- 瀏覽器傳送支援的加密方式給伺服器
- 伺服器選取一種加密方式，返回伺服器的證書給瀏覽器，證書包含：網站域名，非對稱加密的公鑰，證書的頒發機構等
- 客戶端驗證證書是否合法。
- 如果證書合法或者使用者同意使用不合法的證書，客戶端隨機生成一個隨機密碼TOKEN。
- 使用伺服器返回的公鑰加密隨機密碼，得到加密後的字串TOKEN_EN
- 使用TOKEN（對稱加密方法）加密一段握手資訊（MSG），得到EN_MSG。
- 對MSG進行hash加密，得到HASH_MSG
- 把TOKEN_EN，HASH_MSG,EN_MSG一起發回給服務端
- 服務端使用金鑰解密TOKEN_EN，得到TOKEN
- 服務端使用TOKEN解密EN_MSG，得到握手資訊MSG，對MSG進行hash加密，得到HASH_MSG_，並驗證是否與客戶端發來的HASH_MSG一樣。
- 服務端生成一段握手資訊MSG1，使用TOKEN進行加密，得到EN_MSG1。使用hash加密，得到HASH_MSG1，把EN_MSG1和HASH_MSG1傳送給客戶端。
- 服務端使用TOKEN解密EN_MSG1，得到握手資訊MSG1，對MSG進行hash加密，得到HASH_MSG1_，並驗證是否與服務端發來的HASH_MSG1一樣。
- 這樣，握手階段就結束了，握手階段的作用：1. 驗證服務端的證書 2. 客戶端和服務端約定一個對稱加密的祕鑰，也就是TOKEN
- 後面所有的資料傳輸，都是傳送方使用對稱加密後，傳送給接收方，接收方再進行解密，這樣就可以保證，傳輸的過程中，1. 明文不會洩漏，2. 明文不會被篡改。這樣就可以保證傳輸的安全性
最後的對MSG和MSG1的加密和解密，主要是用於測試的，也就是測試服務端和客戶端的TOKEN，加密方式是不是都是一致的，這樣可以保證後面的資料傳輸不會出錯。
常用的加密方式：
非對稱加密演算法：RSA，DSA/DSS
對稱加密演算法：AES，RC4，3DES
HASH演算法：MD5，SHA1，SHA256
非對稱加密用於客戶端和服務端協商TOKEN，這樣可以做到只有服務端和客戶端知道TOKEN的明文，使用密文來傳輸，防止被別人看到TOKEN
對稱加密用於對HTTP傳輸的資料進行加密，傳送方使用對稱加密進行加密得到密文，傳輸密文給接收方，接收方解密後得到明文，這樣傳輸的過程中，其他人看不到明文
HASH加密用於協商TOKEN後，客戶端和服務端的傳輸測試，主要作用是判斷加密前的資料和加密後再被解密得到的資料，是否一樣。也就是驗證測試是否通過。其實也可以不用hash加密，測試的時候直接傳送明文，但是相對來說，安全性會差一點。
二、變化
1. 相對HTTP，能解決的問題
- 網路中間人。也就是有人破解了你的路由器，就可以看到你所有的請求。使用HTTPS後，所有經過路由器的資料都是經過加密的資料，所以別人看不到真實的資料。
- 運營商HTTP劫持。運營商會在返回的HTML檔案裡面加上自己的推廣DOM，但是由於瀏覽器會對返回資料進行解密，這樣會導致解密失敗，可能會顯示亂碼。
- 運營商DNS劫持。DNS劫持的話，運營商會把域名解析為他們自己的IP，這樣，返回的證書可能是假的，這樣瀏覽器能夠辨別，如果是真的，但是瀏覽器檢查證書會發現DNS解析的IP和證書的IP不一樣，也會報錯，告訴使用者。
2. 還是不能解決的問題
- 釣魚網站。使用者一開始就訪問了錯誤的域名，所以HTTPS也不能解決，釣魚網站也可能是HTTPS，但是現在相對較少。
- 篡改跳轉連結。很多時候，並不是所有頁面都是https的，有時候是從一個http頁面跳轉到https頁面，這樣網路中間人就可以修改http頁面裡的跳轉地址，改為非https的，這樣使用者一般不會察覺。這樣就可以實現中間人和伺服器建立https連結，瀏覽器和中間人建立http連結，這樣使用者的所有輸入，例如密碼，中間人都可以看到。即使JS中對密碼進行md5加密也沒有用，因為中間人也可以修改JS程式碼。所以最好的方法是輸入密碼前，看看瀏覽器的地址是不是https的。
三、證書驗證原理
上面的資料傳輸過程中，有一個步是：客戶端驗證證書是否合法
那客戶端是怎麼驗證收到的證書是合法的還是不合法的呢？
假如有證書機構A，伺服器B，客戶端C
有資料
- A的公鑰A_PUB和私鑰A_PRI
- B的公鑰B_PUB和私鑰B_PRI
正式驗證流程：
- 客戶端會有一個信任的根證書庫。儲存的是證書機構的公鑰，當然會有很多個證書機構。這個證書庫，可能是系統級別的（例如window），也有可能是瀏覽器級別的。
- 伺服器B，生成公鑰和私鑰後，需要證書機構的簽發。證書機構會對伺服器B進行詳細的驗證，然後會為B生成一張證書，證書的內容有：有效期，對應的網站，B的公鑰，證書頒發機構的名字，B對證書的數字簽名，A對證書的數字簽名。
- 當C訪問B的時候，B會把證書傳送給C
- C會根據證書頒發機構的名字，從自己的根證書庫裡面找出A的公鑰A_PUB。如果找不到，會提示使用者，證書不可靠。
- 證書中會有B_PUB，這樣通過B_PUB，A_PUB就可以驗證A和B的數字簽名是否正確。如果正確，就可以確定證書沒有被篡改，而且是A頒發的。否則提示證書不可靠。
- C再驗證其他內容，例如有效期，是否吊銷（下面會說是否吊銷的驗證方法）等。
- 如果都通過，就可以認定，證書沒有被修改，而且是屬於B的證書。
數字簽名的原理就是：證書機構，對證書的內容（數字簽名外的其他內容，例如網站，有效期等）計算HASH值，然後使用A的私鑰或者B的私鑰進行加密。具體可以看RSA數字簽名方法。
1.Fiddler抓包HTTPS的原理
Fiddler抓包的時候，Fiddler是充當中間人的角色的，上面說了，HTTPS可以解決中間人問題，所以按理Fiddler是不能抓HTTPS的包的。
但是我們知道使用Fiddler，可以實現對HTTPS的抓包的，那Fiddler是怎麼實現的呢？
步驟是：
- Fiddler會自己生成一個模擬證書機構MA的公鑰和私鑰，還有一個模擬伺服器MB的公鑰和私鑰
- 然後需要我們把模擬證書機構的公鑰新增到客戶端的信任的根證書庫裡面。
- 當服務端B下發證書CA給Fiddler時，Fiddler會通過MA和MB的公鑰和私鑰，生成另一張正式MCA給客戶端。
- 由於客戶端信任了MA的公鑰，所以客戶端不會發現MCA有異常。
其實這就說明Fiddler可以實現中間人的攻擊。而可以實現攻擊的根本原因是客戶端信任了MA的公鑰。
所以平時我們不要輕易相信未知的證書。
2. 證書是否吊銷
吊銷是指在有效期過期前，證書被吊銷了。
這樣的話，客戶端怎麼發現證書是否被吊銷呢？
- 客戶端會定期從信任的伺服器下載已吊銷的證書的MD5。
- 客戶端收到服務端的證書後，可以訪問信任的網站，查驗證書是否有效。
其他：
訪問一個https的網站，網站的旁邊會有個信任的標誌，裡面可以看到證書的詳細資訊。
Internet選項-內容-證書 可以看到瀏覽器信任的證書和根證書
未經許可，請不要轉載。