【刷題】麪筋-網絡-HTTPS抓包原理與charles抓包步驟

時間 2020-06-08

標籤刷題麪筋網絡 https 抓包原理 charles 步驟欄目系統網絡简体版

原文原文鏈接

http爲何不安全？

http協議屬於明文傳輸協議，交互過程以及數據傳輸都沒有進行加密，通訊雙方也沒有進行任何認證，通訊過程很是容易遭遇劫持、監聽、篡改，嚴重狀況下，會形成惡意的流量劫持等問題，甚至形成我的隱私泄露（好比銀行卡卡號和密碼泄露）等嚴重的安全問題。html
能夠把http通訊比喻成寄送信件同樣，A給B寄信，信件在寄送過程當中，會通過不少的郵遞員之手，他們能夠拆開信讀取裏面的內容（由於http是明文傳輸的）。A的信件裏面的任何內容（包括各種帳號和密碼）都會被輕易竊取。除此以外，郵遞員們還能夠僞造或者修改信件的內容，致使B接收到的信件內容是假的。git
好比常見的，在http通訊過程當中，「中間人」將廣告連接嵌入到服務器發給用戶的http報文裏，致使用戶界面出現不少不良連接；或者是修改用戶的請求頭URL，致使用戶的請求被劫持到另一個網站，用戶的請求永遠到不了真正的服務器。這些都會致使用戶得不到正確的服務，甚至是損失慘重。算法

https如何保證安全？

引入對稱加密和非對稱加密
- 要解決http帶來的問題，就要引入加密以及身份驗證機制。瀏覽器
- 若是Server（之後簡稱服務器）給Client（之後簡稱客戶端）的消息是密文的，只有服務器和客戶端才能讀懂，就能夠保證數據的保密性。同時，在交換數據以前，驗證一下對方的合法身份，就能夠保證通訊雙方的安全。那麼，問題來了，服務器把數據加密後，客戶端如何讀懂這些數據呢？這時服務器必需要把加密的密鑰（對稱密鑰，後面會詳細說明）告訴客戶端，客戶端才能利用對稱密鑰解開密文的內容。可是，服務器若是將這個對稱密鑰以明文的方式給客戶端，仍是會被中間人截獲，中間人也會知道對稱密鑰，依然沒法保證通訊的保密性。可是，若是服務器以密文的方式將對稱密鑰發給客戶端，客戶端又如何解開這個密文，獲得其中的對稱密鑰呢？緩存
- 說到這裏，你們是否是有點兒糊塗了？一下子密鑰，一下子對稱密鑰，都有點兒被搞暈的節奏。在這裏，提早給你們普及一下，這裏的密鑰，指的是非對稱加解密的密鑰，是用於TLS握手階段的；對稱密鑰，指的是對稱加解密的密鑰，是用於後續傳輸數據加解密的。下面將詳細說明。安全
- 這時，咱們引入了非對稱加解密的概念。在非對稱加解密算法裏，公鑰加密的數據，有且只有惟一的私鑰纔可以解密，因此服務器只要把公鑰發給客戶端，客戶端就能夠用這個公鑰來加密進行數據傳輸的對稱密鑰。客戶端利用公鑰將對稱密鑰發給服務器時，即便中間人截取了信息，也沒法解密，由於私鑰只部署在服務器，其餘任何人都沒有私鑰，所以，只有服務器纔可以解密。服務器拿到客戶端的信息並用私鑰解密以後，就能夠拿到加解密數據用的對稱密鑰，經過這個對稱密鑰來進行後續通訊的數據加解密。除此以外，非對稱加密能夠很好的管理對稱密鑰，保證每次數據加密的對稱密鑰都是不相同的，這樣子的話，即便客戶端病毒拉取到通訊緩存信息，也沒法竊取正常通訊內容。服務器
小結：
- 服務器把公鑰發給客戶端
- 客戶端用這個公鑰來加密進行數據傳輸的對稱密鑰。
  - 客戶端利用公鑰將對稱密鑰發給服務器時，即便中間人截取了信息，也沒法解密，由於私鑰只部署在服務器，其餘任何人都沒有私鑰，所以，只有服務器纔可以解密。
- 服務器拿到客戶端的信息並用私鑰解密以後，就能夠拿到加解密數據用的對稱密鑰，經過這個對稱密鑰來進行後續通訊的數據加解密。
- 後續傳輸數據時可用前幾步的對稱密鑰來進行加解密。
引入數字證書
- 可是這樣彷佛還不夠，若是通訊過程當中，在三次握手或者客戶端發起HTTP請求過程當中，客戶端的請求被中間人劫持，那麼中間人就能夠假裝成「假冒客戶端」和服務器通訊；中間人又能夠假裝成「假冒服務器」和客戶端通訊。接下來，咱們詳細闡述中間人獲取對稱密鑰的過程：網絡
- 中間人在收到服務器發送給客戶端的公鑰（這裏是「正確的公鑰」）後，並無發給客戶端，而是中間人將本身的公鑰（這裏中間人也會有一對公鑰和私鑰，這裏稱呼爲「僞造公鑰」）發給客戶端。以後，客戶端把對稱密鑰用這個「僞造公鑰」加密後，發送過程當中通過了中間人，中間人就能夠用本身的私鑰解密數據並拿到對稱密鑰，此時中間人再把對稱密鑰用「正確的公鑰」加密發回給服務器。此時，客戶端、中間人、服務器都擁有了同樣的對稱密鑰，後續客戶端和服務器的全部加密數據，中間人均可以經過對稱密鑰解密出來。併發
- 爲了解決此問題，咱們引入了數字證書的概念。服務器首先生成公私鑰，將公鑰提供給相關機構（CA），CA將公鑰放入數字證書並將數字證書頒佈給服務器，此時服務器就不是簡單的把公鑰給客戶端，而是給客戶端一個數字證書，數字證書中加入了一些數字簽名的機制，保證了數字證書必定是服務器給客戶端的。中間人發送的僞造證書，不可以得到CA的認證，此時，客戶端和服務器就知道通訊被劫持了。函數
小結：
- 非對稱加密算法（公鑰和私鑰）交換對稱密鑰+數字證書驗證身份（驗證公鑰是不是僞造的）+利用對稱密鑰加解密後續傳輸的數據=安全

對稱加密算法

概述
- 對稱加密是指：加密和解密使用相同密鑰的算法。
- 它要求發送方和接收方在安全通訊以前，商定一個對稱密鑰。
- 對稱算法的安全性徹底依賴於密鑰，密鑰泄漏就意味着任何人均可以對他們發送或接收的消息解密，因此密鑰的保密性對通訊相當重要。
對稱加密又分爲兩種模式：流加密和分組加密
- 流加密是將消息做爲字節流對待，而且使用數學函數分別做用在每個字節位上。使用流加密時，每加密一次，相同的明文位會轉換成不一樣的密文位。流加密使用了密鑰流生成器，它生成的字節流與明文字節流進行異或，從而生成密文。
- 分組加密是將消息劃分爲若干個分組，這些分組隨後會經過數學函數進行處理，每次一個分組。假設使用64位的分組密碼，此時若是消息長度爲640位，就會被劃分紅10個64位的分組（若是最後一個分組長度不到64，則用0補齊以後加到64位），每一個分組都用一系列數學公式進行處理，最後獲得10個加密文本分組。而後，將這條密文消息發送給對端。對端必須擁有相同的分組密碼，以相反的順序對10個密文分組使用前面的算法解密，最終獲得明文消息。比較經常使用的分組加密算法有DES、3DES、AES。其中DES是比較老的加密算法，如今已經被證實不安全。而3DES是一個過渡的加密算法，至關於在DES基礎上進行三重運算來提升安全性，但其本質上仍是和DES算法一致。而AES是DES算法的替代算法，是如今最安全的對稱加密算法之一。
對稱加密算法的優缺點：
- 優勢：計算量小、加密速度快、加密效率高。
- 缺點：
  - （1）交易雙方都使用一樣密鑰，安全性得不到保證；
  - （2）每次使用對稱加密算法時，都須要使用其餘人不知道的唯一密鑰，這會使得發收信息雙方所擁有的鑰匙數量呈幾何級數增加，密鑰管理成爲負擔。

非對稱加密算法那

非對稱加密算法
- 在非對稱密鑰交換算法出現之前，對稱加密的最主要缺陷就是不知道如何在通訊雙方之間傳輸對稱密鑰，而又不讓中間人竊取。非對稱密鑰交換算法誕生以後，專門針對對稱密鑰傳輸作加解密，使得對稱密鑰的交互傳輸變得很是安全了。
- 非對稱密鑰交換算法自己很是複雜，密鑰交換過程涉及到隨機數生成，模指數運算，空白補齊，加密，簽名等等一系列極其複雜的過程，。常見的密鑰交換算法有RSA，ECDHE，DH，DHE等算法。涉及到比較複雜的數學問題。其中，最經典也是最經常使用的是RSA算法。
- RSA：誕生於1977年，通過了長時間的破解測試，算法安全性很高，最重要的是，算法實現很是簡單。缺點就是須要比較大的質數（目前經常使用的是2048位）來保證安全強度，極其消耗CPU運算資源。RSA是目前惟一一個既能用於密鑰交換又能用於證書籤名的算法，RSA 是最經典，同時也是最經常使用的是非對稱加解密算法。
非對稱加密相比對稱加密更加安全，但也存在兩個致命的缺點：
- （1）CPU計算資源消耗很是大。一次徹底TLS握手，密鑰交換時的非對稱解密計算量佔整個握手過程的90%以上。而對稱加密的計算量只至關於非對稱加密的0.1%。若是後續的應用層數據傳輸過程也使用非對稱加解密，那麼CPU性能開銷太龐大，服務器是根本沒法承受的。賽門特克給出的實驗數據顯示，加解密同等數量的文件，非對稱算法消耗的CPU資源是對稱算法的1000倍以上。
- （2）非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。好比如今經常使用的公鑰長度是2048位，意味着待加密內容不能超過256個字節。
- 因此非對稱加解密（極端消耗CPU資源）目前只能用來做對稱密鑰交換或者CA簽名，不適合用來作應用層內容傳輸的加解密。

身份認證

概述
- https協議中身份認證的部分是由CA數字證書完成的，證書由公鑰、證書主體、數字簽名等內容組成。在客戶端發起SSL請求後，服務端會將數字證書發給客戶端，客戶端會對證書進行驗證（驗證這張證書是不是僞造的？也就是公鑰是不是僞造的），若是證書不是僞造的，客戶端就獲取用於對稱密鑰交換的非對稱密鑰（獲取公鑰）。
數字證書有三個做用：
- 一、身份受權。確保瀏覽器訪問的網站是通過CA驗證的可信任的網站。
- 二、分發公鑰。每一個數字證書都包含了註冊者生成的公鑰（驗證確保是合法的，非僞造的公鑰）。在SSL握手時會經過certificate消息傳輸給客戶端。
- 三、驗證證書合法性。客戶端接收到數字證書後，會對證書合法性進行驗證。只有驗證經過後的證書，纔可以進行後續通訊過程。
申請一個受信任的CA數字證書一般有以下流程：
- （1）公司（實體）的服務器生成公鑰和私鑰，以及CA數字證書請求。
- （2）RA（證書註冊及審覈機構）檢查實體的合法性（在註冊系統裏面是否註冊過的正規公司）。
- （3）CA（證書籤發機構）簽發證書，發送給申請者實體。
- （4）證書更新到repository（負責數字證書及CRL內容存儲和分發），實體終端後續從repository更新證書，查詢證書狀態等。
數字證書驗證
- 申請者拿到CA的證書並部署在網站服務器端，那瀏覽器發起握手並接收到證書後，如何確認這個證書就是CA簽發的呢？怎樣避免第三方僞造這個證書？答案就是數字簽名（digital signature）。數字簽名是證書的防僞標籤，目前使用最普遍的SHA-RSA（SHA用於哈希算法，RSA用於非對稱加密算法）。數字簽名的製做和驗證過程以下：
- 一、數字簽名的簽發。首先是使用哈希函數對待簽名內容進行安全哈希，生成消息摘要，而後使用CA本身的私鑰對消息摘要進行加密。
- 二、數字簽名的校驗。使用CA的公鑰解密簽名，而後使用相同的簽名函數對簽名證書內容進行簽名，並和服務端數字簽名裏的簽名內容進行比較，若是相同就認爲校驗成功。
- 須要注意的是：
  - （1）數字簽名簽發和校驗使用的非對稱密鑰是CA本身的公鑰和私鑰，跟證書申請者（提交證書申請的公司實體）提交的公鑰沒有任何關係。
  - （2）數字簽名的簽發過程跟公鑰加密的過程恰好相反，便是用私鑰加密，公鑰解密。（一對公鑰和私鑰，公鑰加密的內容只有私鑰可以解密；反過來，私鑰加密的內容，也就有公鑰纔可以解密）
  - （3）如今大的CA都會有證書鏈，證書鏈的好處：首先是安全，保持CA的私鑰離線使用。第二個好處是方便部署和撤銷。這裏爲啥要撤銷呢？由於，若是CA數字證書出現問題（被篡改或者污染），只須要撤銷相應級別的證書，根證書依然是安全的。
  - （4）根CA證書都是自簽名，即用本身的公鑰和私鑰完成了簽名的製做和驗證。而證書鏈上的證書籤名都是使用上一級證書的非對稱密鑰進行簽名和驗證的。
  - （5）怎樣獲取根CA和多級CA的密鑰對？還有，既然是自簽名和自認證，那麼它們是否安全可信？這裏的答案是：固然可信，由於這些廠商跟瀏覽器和操做系統都有合做，它們的根公鑰都默認裝到了瀏覽器或者操做系統環境裏。

數據完整性驗證

數據傳輸過程當中的完整性使用MAC算法來保證。爲了不網絡中傳輸的數據被非法篡改，或者數據比特被污染，SSL利用基於MD5或SHA的MAC算法來保證消息的完整性（因爲MD5在實際應用中存在衝突的可能性比較大，因此儘可能別採用MD5來驗證內容一致性）。 MAC算法是在密鑰參與下的數據摘要算法，能將密鑰和任意長度的數據轉換爲固定長度的數據。發送者在密鑰的做用下，利用MAC算法計算出消息的MAC值，並將其添加在須要發送的消息以後，併發送給接收者。接收者利用一樣的密鑰和MAC算法計算出消息的MAC值，並與接收到的MAC值比較。若是兩者相同，則報文沒有改變；不然，報文在傳輸過程當中被修改或者污染，接收者將丟棄該報文。 SHA也不能使用SHA0和SHA1，山東大學的王小云教授（很牛的一個女教授，你們有興趣能夠上網搜索一下她的事蹟）在2005年就宣佈破解了 SHA-1完整版算法，並得到了業內專家的承認。微軟和google都已經宣佈16年及17年以後再也不支持sha1簽名證書。

https 通訊流程

一、客戶端的瀏覽器向服務器傳送客戶端SSL 協議的版本號，加密算法的種類，產生的隨機數，以及其餘服務器和客戶端之間通信所須要的各類信息。
二、服務器向客戶端傳送SSL 協議的版本號，加密算法的種類，隨機數以及其餘相關信息，同時服務器還將向客戶端傳送本身的證書。
三、客戶利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過時，發行服務器證書的CA 是否可靠，發行者證書的公鑰可否正確解開服務器證書的「發行者的數字簽名」，服務器證書上的域名是否和服務器的實際域名相匹配。若是合法性驗證沒有經過，通信將斷開；若是合法性驗證經過，將繼續進行第四步。
四、用戶端隨機產生一個用於後面通信的「對稱密碼」，而後用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中得到）對其加密，而後將加密後的「預主密碼」傳給服務器。
- 4.一、若是服務器要求客戶的身份認證（在握手過程當中爲可選），用戶能夠創建一個隨機數而後對其進行數據簽名，將這個含有簽名的隨機數和客戶本身的證書以及加密過的「預主密碼」一塊兒傳給服務器。
- 4.二、若是服務器要求客戶的身份認證，服務器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，爲客戶提供證書的CA 是否可靠，發行CA 的公鑰可否正確解開客戶證書的發行CA 的數字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗若是沒有經過，通信馬上中斷；若是驗證經過，服務器將用本身的私鑰解開加密的「預主密碼」，而後執行一系列步驟來產生主通信密碼（客戶端也將經過一樣的方法產生相同的主通信密碼）。
五、服務器和客戶端用相同的主密碼即「通話密碼」，一個對稱密鑰用於SSL 協議的安全數據通信的加解密通信。同時在SSL 通信過程當中還要完成數據通信的完整性，防止數據通信中的任何變化。
六、服務器向客戶端發出信息，指明後面的數據通信將使用的步驟5中的主密碼爲對稱密鑰，同時通知客戶端服務器端的握手過程結束。
七、SSL 的握手部分結束，SSL 安全通道的數據通信開始，客戶和服務器開始使用相同的對稱密鑰進行數據通信，同時進行通信完整性的檢驗。

charles抓包原理

客戶端向服務器發起HTTPS請求
Charles攔截客戶端的請求，假裝成客戶端向服務器進行請求
服務器向「客戶端」（其實是Charles）返回服務器的CA證書
Charles攔截服務器的響應，獲取服務器證書公鑰，而後本身製做一張證書，將服務器證書替換後發送給客戶端。（這一步，Charles拿到了服務器證書的公鑰）
客戶端接收到「服務器」（其實是Charles）的證書後，生成一個對稱密鑰，用Charles的公鑰加密，發送給「服務器」（Charles）
Charles攔截客戶端的響應，用本身的私鑰解密對稱密鑰，而後用服務器證書公鑰加密，發送給服務器。（這一步，Charles拿到了對稱密鑰）
服務器用本身的私鑰解密對稱密鑰，向「客戶端」（Charles）發送響應
Charles攔截服務器的響應，替換成本身的證書後發送給客戶端
至此，鏈接創建，Charles拿到了服務器證書的公鑰和客戶端與服務器協商的對稱密鑰，以後就能夠解密或者修改加密的報文了。
HTTPS抓包的原理仍是挺簡單的，簡單來講，就是Charles做爲「中間人代理」，拿到了服務器證書公鑰和 HTTPS鏈接的對稱密鑰，前提是客戶端選擇信任並安裝Charles的CA證書，不然客戶端就會「報警」並停止鏈接。這樣看來，HTTPS仍是很安全的。