- 這個問題困擾了很久，最近看了資料，總結(jié)一番，總結(jié)不到位的地方還請指出
- http是明文傳輸而https加密傳輸（http的發(fā)展歷史及各版本的差異，報文頭這里就不介紹了，有興趣的同學(xué)自己查閱資料）這是它們最大的區(qū)別。那https是如何達(dá)到安全傳輸?shù)哪?，這個需要先了解下http與https的osi層次結(jié)構(gòu)(圖來源《圖解http》)
很明顯https 是在tcp與http之間添加了一層ssl（Secure Sockets Layer）層，俗稱安全套接層
- SSL釋義：請參看這里博文，有詳細(xì)講解：
http://www.itdecent.cn/p/6c981b44293d - 理解https的安全傳輸需要先了解兩種加密算法，因為在整個https通訊過程使用兩種加密算法，一種非對稱加密算法，另一種對稱加密算法
- 非對稱加密算法：這種加密或許理解起來比較困難，這種加密指的是可以生成一對密鑰 (k1, k2)。凡是 k1 加密的數(shù)據(jù)，k1 自身不能解密，而需要 k2 才能解密；凡是 k2 加密的數(shù)據(jù)，k2 不能解密，需要 k1 才能解密。這種算法事實上有很多，常用的是 RSA，其基于的數(shù)學(xué)原理是兩個大素數(shù)的乘積很容易算，而拿到這個乘積去算出是哪兩個素數(shù)相乘就很復(fù)雜了。好在以目前的技術(shù)，分解大數(shù)的素因數(shù)確實比較困難，尤其是當(dāng)這個大數(shù)足夠大的時候（通常使用2的10次方個二進(jìn)制位這么大），就算是超級計算機(jī)解密也需要非常長的時間
- 對稱加密算法簡單來說就是加密與解密使用的密鑰是一樣的。
有了這兩種算法做基礎(chǔ)之后對后面的內(nèi)容就好理解了。我們現(xiàn)在來一步一步揭開https的面紗。
先假設(shè)有兩臺計算機(jī)需要通信，它們的情況大致是這樣：
如果不進(jìn)行加密傳輸，裸傳就是http傳輸了，很容易被攔截。假設(shè)計算A與計算機(jī)B之間約定使用Key1=(20202020liuhulai)這個密鑰對報文內(nèi)容進(jìn)行加解密，即發(fā)送方使用key1對待發(fā)送的內(nèi)容進(jìn)行加密處理，接收方使用key1對接收過來的內(nèi)容進(jìn)行解密處理，看似已經(jīng)達(dá)到了安全傳輸?shù)男Ч绾伪ＷC計算機(jī)A安全的將key1發(fā)送給計算機(jī)B呢？如果這個階段被攔截了那么key1就被泄露了，別人就可以假冒發(fā)送方 計算機(jī)A 向接收方 計算機(jī)B 發(fā)送信息了，還是沒達(dá)到安全傳輸?shù)男Ч，F(xiàn)在問題是需要保證key1能夠安全在網(wǎng)絡(luò)上傳輸，很明顯不能再使用對稱加密來保護(hù)這個key1的安全傳輸了，聰明的人類于是引入了非對稱加密：
這種方法就是，讓客戶端和服務(wù)器都擁有兩把鑰匙，一把鑰匙是公開的(全世界知道都沒關(guān)系)，我們稱之為公鑰；另一把鑰匙則是保密的(只有自己本人才知道)，我們稱之為私鑰。并且用公鑰加密的數(shù)據(jù)，只有對應(yīng)的私鑰才能解密；用私鑰加密的數(shù)據(jù)，只有對應(yīng)的公鑰才能解密。
于是按照這種方法來保證key1在網(wǎng)絡(luò)上的安全傳輸，它的過程大致如下圖：
這種方式貌似已經(jīng)達(dá)到了，但是在第一步計算機(jī)B明文傳輸自己的公鑰時又存在泄露的風(fēng)險，被人攔截之后使用假冒的的公鑰假設(shè)為key2,發(fā)送給計算機(jī)A,接著計算機(jī)A收到這個報文之后，使用key2對 key1 再進(jìn)行加密傳輸，中間人攔截到這個報文之后使用自己的私鑰進(jìn)行解密得到key1，然后再偽造一個key1_1通過計算機(jī)B的公鑰發(fā)送給計算機(jī)B，于是計算A與計算機(jī)B整個通訊過程都暴露在中間人眼皮底下，無異于裸奔，這種現(xiàn)象就是中間人攻擊。
導(dǎo)致這個問題的根本原因是計算A無法知道這個公鑰是否來自計算機(jī)B。
科學(xué)是向前發(fā)展的，充滿智慧的人類總是能克服一個一個困難。因此，我們需要找到一種策略來證明這把公鑰就是服務(wù)器的，而不是別人冒充的。我們需要找到一個擁有公信力、大家都認(rèn)可的認(rèn)證中心(CA)。于是就誕生了數(shù)字證書。它的具體過程是這樣的：
計算機(jī)B在給計算機(jī)A傳輸公鑰的過程中，會把公鑰以及個人信息通過Hash算法生成信息摘要。如圖：
為了防止信息摘要也被人調(diào)換，計算機(jī)B還會用CA提供的私鑰對信息摘要進(jìn)行加密來形成數(shù)字簽名。如圖:
并且，最后還會把原來沒Hash算法之前的個人信息以及公鑰 和 數(shù)字簽名合并在一起，形成數(shù)字證書（回想下在使用https通信時是不是需要內(nèi)置一份證書文件）。當(dāng)計算機(jī)A拿到這份數(shù)字證書之后，就會用CA提供的公鑰來對數(shù)字證書里面的數(shù)字簽名進(jìn)行解密來得到信息摘要，然后對數(shù)字證書里服務(wù)器的公鑰以及個人信息進(jìn)行Hash得到另外一份信息摘要。最后把兩份信息摘要進(jìn)行對比，如果一樣，則證明這個人是服務(wù)器，否則就不是。
如圖：
下面是Charles 抓包原理的流程圖：
客戶端向服務(wù)器發(fā)起HTTPS請求
Charles攔截客戶端的請求，偽裝成客戶端向服務(wù)器進(jìn)行請求
服務(wù)器向“客戶端”（實際上是Charles）返回服務(wù)器的CA證書
Charles攔截服務(wù)器的響應(yīng)，獲取服務(wù)器證書公鑰，然后自己制作一張證書，將服務(wù)器證書替換后發(fā)送給客戶端。（這一步，Charles拿到了服務(wù)器證書的公鑰）
客戶端接收到“服務(wù)器”（實際上是Charles）的證書后，生成一個對稱密鑰，用Charles的公鑰加密，發(fā)送給“服務(wù)器”（Charles）
Charles攔截客戶端的響應(yīng)，用自己的私鑰解密對稱密鑰，然后用服務(wù)器證書公鑰加密，發(fā)送給服務(wù)器。（這一步，Charles拿到了對稱密鑰）
服務(wù)器用自己的私鑰解密對稱密鑰，向“客戶端”（Charles）發(fā)送響應(yīng)
Charles攔截服務(wù)器的響應(yīng)，替換成自己的證書后發(fā)送給客戶端
至此，連接建立，Charles拿到了 服務(wù)器證書的公鑰 和 客戶端與服務(wù)器協(xié)商的對稱密鑰，之后就可以解密或者修改加密的報文了。
HTTPS抓包的原理還是挺簡單的，簡單來說，就是Charles作為“中間人代理”，拿到了 服務(wù)器證書公鑰 和 HTTPS連接的對稱密鑰，前提是客戶端選擇信任并安裝Charles的CA證書，否則客戶端就會“報警”并中止連接。這樣看來，HTTPS還是很安全的。
原文鏈接：https://blog.csdn.net/zwjemperor/article/details/80719427
