HTTPS協議（全稱是HTTP over SSL，即在HTTP傳輸上增加了SSL協議的加密能力）
1.對稱加密： 如DES演算法，即一個主站與用戶之間可以使用相同的密鑰對傳輸內容進行加密，
2.非對稱加密： 如RSA加密演算法，把密碼革命性的分成公鑰和私鑰，由于兩個密鑰并不相同，所以稱為非對稱加密，私鑰是用來對公鑰加密的資訊進行解密的，是需要嚴格保密的，公鑰是對資訊進行加密，任何人都可以知道，包括黑客，
非對稱加密的原理： 非對稱加密的安全性是基于大質數分解的困難性，在非對稱的加密中公鑰和私鑰是一對大質數函式，計算兩個大質數的乘積是簡單的，但是這個程序的逆運算（即將這個乘積分解為兩個大質數）是非常困難的，在RSA演算法中，從一個公鑰和密文中解密出明文的難度等同于分解兩個大質數乘積的難度，因此實際傳輸中，可以把公鑰發給對方，一方發送資訊時，另一方的公鑰進行加密生成密文，收到密文的一方在用私鑰進行解密，這樣一來，傳輸相對安全了，
非對稱加密的缺點： 加密和解密耗時長，只適合對少量資料進行處理，
HTTPS使用的就是非對稱加密的方式來建立安全的SSL連接的，
用戶甲與用戶已進行非對稱加密傳輸的程序：
- 甲告訴乙，使用RSA演算法進行加密，乙說好的，
- 甲和乙分別根據RSA生成一對密鑰，互相發送公鑰，
- 甲使用乙的公鑰給已加密報文資訊，
- 乙收到資訊，并用自己的私鑰進行解密，
- 乙使用同樣的方式給甲發送資訊，甲使用相同方式進行解密，
這個程序，看起來似乎無懈可擊，但是在TCP/IP里，端到端的通信，路途遙遠，夜長夢多，在（2）中，如果甲的送信使者中途被攔截，強盜知道使者送的是公鑰，雖然沒辦法破解甲的加密資訊，但是可以把這個使者關起來，自己生成一對密鑰，然后冒充甲的使者到乙家，把自己的公鑰給乙，乙信了，把銀行卡密碼、存款金額統統告訴了中間的強盜，所以，在解決了加密危機之后又產生了新的危機，如何解決信任問題呢？如果有一個具有公信力的組織來證明身份，這個問題就得到了解決，CA（Certificate Authority）就是頒發HTTPS證書的組織，HTTPS是當前網站的主流文本傳輸協議，在基于HTTPS進行連接時，就需要數字證書，
訪問一個HTTPS的網站的大致流程：
- 瀏覽器向服務器發送請求，請求中包含了瀏覽器支持的協議，并攜帶一個亂數，
- 服務器收到請求后，選擇某種非對稱加密演算法，把數字證書簽名公鑰、身份資訊發送給瀏覽器，同時也附帶一個亂數，
- 瀏覽器收到后，驗證證書的真實性，用服務器的公鑰發送握手資訊給服務器，
- 服務器解密后，使用之前的亂數計算出一個對稱加密的密鑰，以此作為加密資訊并發送，
- 后續所有的資訊發送都是以對稱加密方式進行的，
證書的資訊中出現了傳輸層安全協議（TLS）的概念，這里先解釋TLS和SSL的區別，
- TLS可以理解成SSL協議3.0版本的升級，所以TLS的1.0版本也被標示為SSL3.1版本，但對于大的協議堆疊而言，SSL和TLS并沒有太大的區別，因此在Wireshark里，分層依然用的是安全套接字層（SSL）標識，
-在HTTPS的傳輸程序中，主要分為兩部分：首先是HTTPS的握手，然后是資料的傳輸，前者是建立一個HTTPS的通道，并確定連接使用的加密套件以及資料傳輸使用的密鑰，而后者主要使用密鑰對資料加密的傳輸，
首先來看HTTPS是如何進行握手的，
第一，客戶發送了一個Client Hello協議請求：在Client Hello中最重要的資訊是Cipher Suites欄位，這里客戶端會告訴服務端自己支持哪些加密的套件，
第二，服務端收到客戶端發來的Client Hello的請求后，會回傳一系列的協議資料，并以一個沒有資料的內容的Server Hello Done作為結束，這些協議資料有的是單獨發送，有的則是合并發送，這里分別解釋下幾個重要的協議， - Server Hello協議，主要告知客戶端后續協議中要是用的TLS協議版本，這個版本主要和客戶端與服務端支持的最高版本有關，
- Certificate協議，主要傳輸服務端的證書內容，
- Server Key Exchange，如果在Certificate協議中未給出客戶端足夠的資訊，則會在Server Key Exchange進行補充，
- Certificate Request，這個協議是一個可選項，當服務端需要對客戶端進行證書驗證的時候，才會向客戶端發送一個證書請求，
- Server Hello Done作為結束資訊，告知客戶端整個Server Hello程序結束，
第三，客戶端在收到服務端的握手資訊后，根據服務端的請求，也會發送一系列的協議，
- Certificate，它是可選項，因為上文中服務端發送了Certificate Request需要對客戶端進行證書驗證，所以客戶端要發送自己的證書資訊，
- Client Key Exchange，它在上文中Server Key Exchange類似，是對客戶端Certificate資訊的補充，在本次請求中同樣是補充了客戶端證書的公鑰資訊，
- Certification Verify，對服務端發送的證書資訊進行確認，
- Change Cipher Spec，該協議不同于其他握手協議而是作為一個獨立協議告知服務端，客戶端已經接收之前服務端確認的加密套件，并會在后續通信中使用該加密套件進行加密，
- Encrypted Handshake Message，用于客戶端給服務端加密套件加密一段Finish的資料，用以驗證這條建立起來的加密通道的正確性，
第四，服務端在接收客戶端的確認資訊以及驗證資訊后，會對客戶端發送的資料進行確認，這里也分為幾個協議進行回復， - Change Cipher Spec，通過使用私鑰對客戶端發送的資料進行解密，并告知后續使用協商好的加密套件進行加密傳輸資料，
- Encrypted Handshake Message，與客戶端的操作相同，發送一段Finish的加密資料驗證加密通道的正確性，
最后，如果客戶端和服務端都確認加密無誤后，各自按照之前約定的Session Secret對Application Data進行加密傳輸，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/254806.html
標籤：區塊鏈
下一篇：通過vuecli創建vue