搞懂HTTPS

總結下HTTPS相關知識點

HTTP協議

HTTP （HyperText Transfer Protocol，超文本傳輸協議） 是因特網上應用最爲普遍的一種網絡傳輸協議，全部的WWW文件都必須遵照這個標準。

• 缺點

HTTP協議是明文傳輸協議,通訊過程當中被中間人進行劫持、監聽、篡改,會形成我的隱私泄露等嚴重的安全問題

HTTPS

在傳輸層和應用層加了TSL/SSL

1. 如何加密？

• 對稱加密

Client -> Server 經過密鑰進行發送方加密、接收方解密

問題？如何安全傳輸密鑰，密鑰被中間人劫持，一切加密解密都是浪費時間

• 非對稱加密

也叫公開密鑰加密，有私鑰和公鑰

1. 如Client發送消息給Server，Client用Server的公鑰進行加密，server用本身的私鑰進行解密，反之亦然。
2. 一切看似很完美，但其實還有問題

中間人劫持

若是咱們使用非對稱加密傳輸數據，會有以下問題：

客戶端如何獲取服務器的公鑰?

1. 三次握手階段：Server發送本身的公鑰給Client，中間人H拿到Server的公鑰，而後發送本身的公鑰給client。
2. Client用H的公鑰進行加密，發給Server，中間人H劫持到消息，用本身的私鑰進行解密，而後用server的公鑰進行加密，發送給Server，Server用本身的私鑰進行解密，獲得消息。
3. Client、Server都以爲消息在正常傳輸，可是已經被中間人劫持了。

引入第三方CA (Certificate Authority證書頒發機構)

1. 數字證書出場，server主動去權威機構申請
2. Server把本身的公鑰、域名等信息發送給CA
3. CA拿到後用本身的私鑰進行加密
4. 權威本身用本身的私鑰進行加密了， 那應該如何解密？你發送給Client，中間人不是同樣能夠劫持嗎？。雞生蛋，蛋生雞的悖論了。
5. 答案是權威機構的公鑰不須要傳輸，由於權威機構會跟主流的瀏覽器或操做系統合做，將他們的公鑰內置到瀏覽器或操做系統環境中。
6. Client收到數字證書後，從數字證書中找到權威機構的信息，從本地找到權威機構的公鑰，就能正確解密Server的公鑰。

數字證書保證傳輸安全

若是不校驗，中間人也能夠向權威機構申請數字證書，而後劫持Server發送的證書，而後發送本身的數字證書給Client，Client接受到後，用本地的公鑰解密，拿到中間人的公鑰。

解決方案：簽名

1. 數字證書中包含了Server的公鑰，機構信息，還包括了證書內容的簽名、簽名計算方法、證書對應的域名

簽名 等於 Server的公鑰、其餘信息經過HASH函數計算獲得證書的數字摘要，權威機構的私鑰加密獲得數字簽名

2. Client使用公鑰解密，獲得服務器的公鑰、證書的數字簽名、簽名計算方法。從新計算簽名，對比簽名是否一致。判斷證書是否被中間人篡改。
3. 若是中間人拿到權威機構的公鑰，能解析證書內容並篡改，可是篡改後須要對證書進行加密。中間人沒有權威機構的私鑰進行加密，強行亂加密，Client就沒法用CA的本地公鑰進行解密。
4. 證書調包，中間人向權威機構申請一份證書，Server發送證書給Client，中間人直接替換成本身的證書，Client用本地權威機構的公鑰解密，對比證書籤名也沒問題。可是Client檢查證書中的域名和當前訪問的是否一致。不一致也會發出警告。

HTTPS通訊過程

1. Client發送Client Hello報文給Server開啓SSL通訊，報文中包含Random_1

2. 服務器支持SSL通訊的話，發送Server Hello報文迴應，報文中包含Random_2

3. 服務器以後發送Certificate報文，報文中包含數字證書

4. 服務器再發送Server Hello Done通知Client，最初的SSL握手階段協商部分結束

5. Client對數字證書校驗，正確後，解密獲得服務器的公鑰。經過RSA算法隨機生成Pre-Master Secret，而且用服務器的公鑰進行加密，包含在Client Key Exchange報文中，發送給Server

6. 客戶端繼續發送Change Cipher Spec報文，告知Server端，客戶端切換協商的加密套件，準備使用協商的加密套件加密數據並傳輸。

7. Client發送Finished報文，該報文包含了鏈接至今所有報文的總體校驗值（也就是hash值）

8. Server接收到Client的請求，用私鑰解密，把Pre-master secret取出來。Server發送一樣的Change Cipher Spec報文

9. Server一樣發送Finished報文，提供Client校驗

10. Server和Client的Finished報文交換完畢，SLL鏈接創建。開始通訊。

隨機數如何生成？

1. Client和Server都經過Random_1、andom_2、Pre-Master Secret三個隨機數，經過僞隨機函數PRF生成Master Secret。再根據master secret 推導出hash secret和sesson secret

此時用對稱加密算法進行通信，使用哪一個做爲共享密鑰呢？

1. 雙方使用對稱加密算法進行加密，用hash secret對HTTP報文作一次運算生成一個MAC，附在HTTP報文的後面，而後用session-secret加密全部數據（HTTP+MAC），而後發送。
2. 接收方則先用session-secret解密數據，而後獲得HTTP+MAC，再用相同的算法計算出本身的MAC，若是兩個MAC相等，證實數據沒有被篡改。

隨機數的做用

1. pre-master secret自己就是一個隨機數，再加上Hello和Server消息中的隨機，三個隨機數經過一個密鑰導出器最終導出一個對稱密鑰
2. 三個隨機數讓隨機數十分接近隨機。每次生成對稱密鑰也是爲了若是此次通訊被破解，不會致使之前的數據被破解。
3. 攔截人重複發送報文，擾亂正常通訊，Server接收到重複的隨機數，能夠中斷通訊。

參考文章

1. 解析HTTPS