1.對稱加密

其變成複雜的加密密文傳送出去。收信方收到密文後，若想解讀原文，則需要使用加密用過的金鑰及相同演算法的逆演算法對密文進行解密，才能使其恢復成可讀明文。在對稱加密演算法中，使用的金鑰只有一個，發收信雙方都使用這個金鑰對資料進行加密和解密，這就要求解密方事先必須知道加密金鑰。
對稱加密演算法的特點是演算法公開、計算量小、加密速度快、加密效率高。
不足之處是，交易雙方都使用同樣鑰匙，安全性得不到保證。此外，每對使用者每次使用對稱加密演算法時，都需要使用其他人不知道的惟一鑰匙，這會使得發收信雙方所擁有的鑰匙數量呈幾何級數增長，金鑰管理成為使用者的負擔。對稱加密演算法在分散式網路系統上使用較為困難，主要是因為金鑰管理困難，使用成本較高。而與公開金鑰加密演算法比起來，對稱加密演算法能夠提供加密和認證卻缺乏了簽名功能，使得使用範圍有所縮小。在計算機專網系統中廣泛使用的對稱加密演算法有DES和IDEA等。美國國家標準局倡導的AES即將作為新標準取代DES。

2.非對稱加密

對稱加密演算法在加密和解密時使用的是同一個祕鑰；而非對稱加密演算法需要兩個金鑰來進行加密和解密，這兩個祕鑰是公開金鑰（public key，簡稱公鑰）和私有金鑰（private key，簡稱私鑰）。

1、乙方生成一對金鑰（公鑰和私鑰）並將公鑰向其它方公開。
2、得到該公鑰的甲方使用該金鑰對機密資訊進行加密後再發送給乙方。
3、乙方再用自己儲存的另一把專用金鑰（私鑰）對加密後的資訊進行解密。乙方只能用其專用金鑰（私鑰）解密由對應的公鑰加密後的資訊。
在傳輸過程中，即使攻擊者截獲了傳輸的密文，並得到了乙的公鑰，也無法破解密文，因為只有乙的私鑰才能解密密文。
同樣，如果乙要回復加密資訊給甲，那麼需要甲先公佈甲的公鑰給乙用於加密，甲自己儲存甲的私鑰用於解密。

3.https如何使用對稱加密和非對稱加密

HTTPS的解決方案是這樣的：用非對稱演算法隨機加密出一個對稱金鑰，然後雙方用對稱金鑰進行通訊。具體來說，就是客戶端生成一個隨機金鑰，用伺服器的公鑰對這個金鑰進行非對稱加密，伺服器用私鑰進行解密，然後雙方就用這個對稱金鑰來進行資料加密了。

4. 信任主機

採用https的伺服器必須從CA （Certificate Authority）申請一個用於證明伺服器用途型別的證書。該證書只有用於對應的伺服器的時候，客戶端才信任此主機。所以所有的銀行系統網站，關鍵部分應用都是https 的。客戶通過信任該證書，從而信任了該主機。其實這樣做效率很低，但是銀行更側重安全。這一點對區域網對內提供服務處的伺服器沒有任何意義。區域網中的伺服器，採用的證書不管是自己釋出的還是從公眾的地方釋出的，其客戶端都是自己人，所以該區域網中的客戶端也就肯定信任該伺服器。

5. https 通訊流程

①客戶端的瀏覽器向伺服器傳送客戶端SSL 協議的版本號，加密演算法的種類，產生的隨機數，以及其他伺服器和客戶端之間通訊所需要的各種資訊。
②伺服器向客戶端傳送SSL 協議的版本號，加密演算法的種類，隨機數以及其他相關資訊，同時伺服器還將向客戶端傳送自己的證書。
③客戶利用伺服器傳過來的資訊驗證伺服器的合法性，伺服器的合法性包括：證書是否過期，發行伺服器證書的CA 是否可靠，發行者證書的公鑰能否正確解開伺服器證書的“發行者的數字簽名”，伺服器證書上的域名是否和伺服器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續進行第四步。
④使用者端隨機產生一個用於後面通訊的“對稱密碼”，然後用伺服器的公鑰（伺服器的公鑰從步驟②中的伺服器的證書中獲得）對其加密，然後將加密後的“預主密碼”傳給伺服器。
4.1如果伺服器要求客戶的身份認證（在握手過程中為可選），使用者可以建立一個隨機數然後對其進行資料簽名，將這個含有簽名的隨機數和客戶自己的證書以及加密過的“預主密碼”一起傳給伺服器。

4.2 如果伺服器要求客戶的身份認證，伺服器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，為客戶提供證書的CA 是否可靠，發行CA 的公鑰能否正確解開客戶證書的發行CA 的數字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗如果沒有通過，通訊立刻中斷；如果驗證通過，伺服器將用自己的私鑰解開加密的“預主密碼”，然後執行一系列步驟來產生主通訊密碼（客戶端也將通過同樣的方法產生相同的主通訊密碼）。
5伺服器和客戶端用相同的主密碼即“通話密碼”，一個對稱金鑰用於SSL 協議的安全資料通訊的加解密通訊。同時在SSL 通訊過程中還要完成資料通訊的完整性，防止資料通訊中的任何變化。
客戶端向伺服器端發出資訊，指明後面的資料通訊將使用的步驟5中的主密碼為對稱金鑰，同時通知伺服器客戶端的握手過程結束。
6伺服器向客戶端發出資訊，指明後面的資料通訊將使用的步驟5中的主密碼為對稱金鑰，同時通知客戶端伺服器端的握手過程結束。
7SSL 的握手部分結束，SSL 安全通道的資料通訊開始，客戶和伺服器開始使用相同的對稱金鑰進行資料通訊，同時進行通訊完整性的檢驗。

6. Charles 抓包原理

客戶端向伺服器發起HTTPS請求

Charles攔截客戶端的請求，偽裝成客戶端向伺服器進行請求

伺服器向“客戶端”（實際上是Charles）返回伺服器的CA證書

Charles攔截伺服器的響應，獲取伺服器證書公鑰，然後自己製作一張證書，將伺服器證書替換後傳送給客戶端。（這一步，Charles拿到了伺服器證書的公鑰）

客戶端接收到“伺服器”（實際上是Charles）的證書後，生成一個對稱金鑰，用Charles的公鑰加密，傳送給“伺服器”（Charles）

Charles攔截客戶端的響應，用自己的私鑰解密對稱金鑰，然後用伺服器證書公鑰加密，傳送給伺服器。（這一步，Charles拿到了對稱金鑰）

伺服器用自己的私鑰解密對稱金鑰，向“客戶端”（Charles）傳送響應

Charles攔截伺服器的響應，替換成自己的證書後傳送給客戶端

至此，連線建立，Charles拿到了 伺服器證書的公鑰 和 客戶端與伺服器協商的對稱金鑰，之後就可以解密或者修改加密的報文了。

HTTPS抓包的原理還是挺簡單的，簡單來說，就是Charles作為“中間人代理”，拿到了 伺服器證書公鑰 和 HTTPS連線的對稱金鑰，前提是客戶端選擇信任並安裝Charles的CA證書，否則客戶端就會“報警”並中止連線。這樣看來，HTTPS還是很安全的。