HTTPS原理

1、原理

1. 數據傳輸過程

瀏覽器訪問一個HTTPS URL的數據傳輸的過程：

1. 瀏覽器發送支持的加密方式給服務器
2. 服務器選取一種加密方式，返回服務器的證書給瀏覽器，證書包含：網站域名，非對稱加密的公鑰，證書的頒發機構等
3. 客戶端驗證證書是否合法。
4. 若是證書合法或者用戶贊成使用不合法的證書，客戶端隨機生成一個隨機密碼TOKEN。
5. 使用服務器返回的公鑰加密隨機密碼，獲得加密後的字符串TOKEN_EN
6. 使用TOKEN（對稱加密方法）加密一段握手信息（MSG），獲得EN_MSG。
7. 對MSG進行hash加密，獲得HASH_MSG
8. 把TOKEN_EN，HASH_MSG,EN_MSG一塊兒發回給服務端
9. 服務端使用密鑰解密TOKEN_EN，獲得TOKEN
10. 服務端使用TOKEN解密EN_MSG，獲得握手信息MSG，對MSG進行hash加密，獲得HASH_MSG_，並驗證是否與客戶端發來的HASH_MSG同樣。
11. 服務端生成一段握手信息MSG1，使用TOKEN進行加密，獲得EN_MSG1。使用hash加密，獲得HASH_MSG1，把EN_MSG1和HASH_MSG1發送給客戶端。
12. 服務端使用TOKEN解密EN_MSG1，獲得握手信息MSG1，對MSG進行hash加密，獲得HASH_MSG1_，並驗證是否與服務端發來的HASH_MSG1同樣。
13. 這樣，握手階段就結束了，握手階段的做用：1. 驗證服務端的證書 2. 客戶端和服務端約定一個對稱加密的祕鑰，也就是TOKEN
14. 後面全部的數據傳輸，都是發送方使用對稱加密後，發送給接收方，接收方再進行解密，這樣就能夠保證，傳輸的過程當中，1. 明文不會泄漏，2. 明文不會被篡改。這樣就能夠保證傳輸的安全性

最後的對MSG和MSG1的加密和解密，主要是用於測試的，也就是測試服務端和客戶端的TOKEN，加密方式是否是都是一致的，這樣能夠保證後面的數據傳輸不會出錯。

經常使用的加密方式：
非對稱加密算法：RSA，DSA/DSS
對稱加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256

非對稱加密用於客戶端和服務端協商TOKEN，這樣能夠作到只有服務端和客戶端知道TOKEN的明文，使用密文來傳輸，防止被別人看到TOKEN
對稱加密用於對HTTP傳輸的數據進行加密，發送方使用對稱加密進行加密獲得密文，傳輸密文給接收方，接收方解密後獲得明文，這樣傳輸的過程當中，其餘人看不到明文
HASH加密用於協商TOKEN後，客戶端和服務端的傳輸測試，主要做用是判斷加密前的數據和加密後再被解密獲得的數據，是否同樣。也就是驗證測試是否經過。其實也能夠不用hash加密，測試的時候直接發送明文，可是相對來講，安全性會差一點。

2、變化

1. 相對HTTP，能解決的問題

1. 網絡中間人。也就是有人破解了你的路由器，就能夠看到你全部的請求。使用HTTPS後，全部通過路由器的數據都是通過加密的數據，因此別人看不到真實的數據。
2. 運營商HTTP劫持。運營商會在返回的HTML文件裏面加上本身的推廣DOM，可是因爲瀏覽器會對返回數據進行解密，這樣會致使解密失敗，可能會顯示亂碼。
3. 運營商DNS劫持。DNS劫持的話，運營商會把域名解析爲他們本身的IP，這樣，返回的證書多是假的，這樣瀏覽器可以辨別，若是是真的，可是瀏覽器檢查證書會發現DNS解析的IP和證書的IP不同，也會報錯，告訴用戶。

2. 仍是不能解決的問題

1. 釣魚網站。用戶一開始就訪問了錯誤的域名，因此HTTPS也不能解決，釣魚網站也多是HTTPS，可是如今相對較少。
2. 篡改跳轉連接。不少時候，並非全部頁面都是https的，有時候是從一個http頁面跳轉到https頁面，這樣網絡中間人就能夠修改http頁面裏的跳轉地址，改成非https的，這樣用戶通常不會察覺。這樣就能夠實現中間人和服務器創建https連接，瀏覽器和中間人創建http連接，這樣用戶的全部輸入，例如密碼，中間人均可以看到。即便JS中對密碼進行md5加密也沒有用，由於中間人也能夠修改JS代碼。因此最好的方法是輸入密碼前，看看瀏覽器的地址是否是https的。

3、證書驗證原理

上面的數據傳輸過程當中，有一個步是：客戶端驗證證書是否合法
那客戶端是怎麼驗證收到的證書是合法的仍是不合法的呢？

假若有證書機構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. 證書是否吊銷

吊銷是指在有效期過時前，證書被吊銷了。
這樣的話，客戶端怎麼發現證書是否被吊銷呢？

1. 客戶端會按期從信任的服務器下載已吊銷的證書的MD5。
2. 客戶端收到服務端的證書後，能夠訪問信任的網站，查驗證書是否有效。

其餘：
訪問一個https的網站，網站的旁邊會有個信任的標誌，裏面能夠看到證書的詳細信息。
Internet選項-內容-證書 能夠看到瀏覽器信任的證書和根證書

未經許可，請不要轉載。

運營商