t Transfer Protocol Secure)，是一種基於SSL/TLS的HTTP，所有的HTTP數據都是在SSL/TLS協議封裝之上進行傳輸的。HTTPS協議是在HTTP協議的基礎上，添加了SSL/TLS握手以及數據加密傳輸，也屬於應用層協議。所以，研究HTTPS協議原理，最終就是研究SSL/TLS協議。
運行過程
我們都知道HTTPS在保證數據安全傳輸上使用了加密算法，但是具體是如何加密的，或許許多人和我一樣也是雲裏霧裏。
實際上SSL/TLS協議的基本思路是非對稱加密和對稱加密結合來傳輸數據，一言以弊之，HTTPS是通過一次非對稱加密算法（如RSA算法）進行了協商密鑰的生成與交換，然後在後續通信過程中就使用協商密鑰進行對稱加密通信，之所以要使用這兩種加密方式的原因在於非對稱加密計算量較大，如果一直使用非對稱加密來傳輸數據的話，會影響效率。
1. HTTPS請求
這個步驟是整個通信過程中的第一步，首先，客戶端（通常是瀏覽器）先向服務器發出加密通信的請求，在這一步中，客戶端主要向服務器提供以下信息：
- 支持的協議版本，比如TLS 1.0版
- 一個客戶端生成的隨機數RandomC，稍後用於生成**“協商密鑰”**。
- 支持的加密方法，比如RSA公鑰加密。
- 支持的壓縮方法。
2. 服務器響應
服務器收到客戶端請求後，向客戶端發出迴應，服務器的迴應一般包含以下內容：
- 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
- 一個服務器生成的隨機數RandomS，稍後用於生成*“協商密鑰”**。
- 從客戶端支持的加密方法中選擇一個作爲確認要使用的加密方法，比如RSA公鑰加密。
- 服務器證書。
這個服務器證書就是表明服務器身份的東西，其中也包含了非對稱加密中需要使用的公鑰。
3. 證書校驗、生成密碼、公鑰加密
客戶端收到服務器迴應以後，首先驗證服務器返回的證書。如果證書不是可信機構頒發，或者證書中的域名與實際域名不一致，或者證書已經過期，以瀏覽器爲例客戶端會向網頁訪問者顯示一個警告，由其選擇是否還要繼續通信。 如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰。然後生成密碼、公鑰加密。
生成密碼的過程會先產生一個隨機數Pre-master key，該隨機數是整個握手階段出現的第三個隨機數，稍後會經過公鑰加密發送到服務端，有了它以後，客戶端和服務器就同時有了三個隨機數——RandomC，RandomS，Pre-master key，接着雙方就用事先商定的加密方法，各自生成本次會話所用的同一把“協商密鑰”。
4. 加密信息C-S
加密信息是指上面一步生成的內容，主要包括
- 一個隨機數Pre-master key。用於給服務端生成“協商密鑰”。
- 編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
- 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項通常也是前面發送的所有內容的hash值，用來供服務器校驗。
5. 私鑰解密、解密握手消息、驗證Hash
服務器收到客戶端公鑰加密的第三個隨機數Pre-master key之後，通過自身私鑰解密該數值並由之前的RandomC和RandomS計算生成本次會話所用的“會話密鑰”。然後，通過約定的Hash算法驗證客戶端發送的數據完整性。
6. 加密信息S-C
主要是指
- 編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
- 服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發生的所有內容的hash值，用來供客戶端校驗。
7. 解密握手消息、驗證Hash
客戶端解密並計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束。
8. 正常加密通信
握手成功之後，所有的通信數據將由之前協商密鑰及約定好的算法進行加密解密。
Charles抓HTTPS包原理
Charles本身是一個協議代理工具，如果只是普通的HTTP請求，因爲數據本身沒經過再次加密，因此作爲代理可以知道所有客戶端發送到服務端的請求內容以及服務端返回給客戶端的數據內容，這也就是抓包工具能夠將數據傳輸內容直接展現出來的原因。對於HTTPS請求，4，6，8步驟的數據都已經經過了加密，代理如果什麼都不做的話是無法獲取到其中的內容的。爲了實現這個過程的數據獲取，Charles需要做的事情是對客戶端僞裝服務端，對服務端僞裝客戶端，具體
- 截獲真實客戶端的HTTPS請求，僞裝客戶端向真實服務端發送HTTPS請求
- 接受真實服務器響應，用Charles自己的證書僞裝服務端向真實客戶端發送數據內容