HTTPS 初步介紹

非對稱加密：

基於數學方法，生成乙個公鑰-金鑰對，來對資料做加密-解密，被公鑰加密的資料只能被私鑰解密，

同樣，被私鑰加密的資料也只能被公鑰解密。所以可以用別人公開的公鑰加密一段資訊然後傳送出去，

只有擁有對應金鑰的那個人才能解密。但是缺點是加密-解密的計算成本高，比較占用cpu資源

對稱加密：

和非對稱加密相比，只生成乙個金鑰，加密-解密都用這個金鑰，所以需要通訊雙方都擁有該金鑰才能正常加/解密，優點是計算成本低，加/解密速度比非對稱加密快很多

https：

http+ssl/tls，本質上就是將原本由http傳送的明文通訊內容，通過加密後傳送，從而保證通訊安全

ca：

全稱：certification authority ，證書頒發機構。是權威、可信的機構，可以視作是https可靠性的基石

* 客戶端先預置ca的公鑰(ca-pub.key)，一般會是各瀏覽器自帶，使用者不關心

* 伺服器生成公鑰(srv-pub.key)，並將公鑰和各種資訊(公司、位址、國家、郵箱等)傳送給ca做認證，ca認證通過之後會用ca自己的私鑰(ca-pri.key)加密這些資訊以及證書的hash值(hash-a)，生成完整證書，返回給伺服器，伺服器自行儲存。

* 客戶端向服務端發起連線請求(clienthello)，包含各種引數，這裡有乙個客戶端生成的隨機數，我們把它叫做r1，後面會用到

* 服務端返回響應(serverhello/certificate/serverkeyexchange/serverhellodone)，包含證書、服務端生成的隨機數r2、服務端選擇的加密演算法、加密通訊協議版本

* 客戶端拿到證書，用自身預置的ca公鑰(ca-pub.key)解開，得到對應的資訊，將解開後得到的伺服器資訊做hash後得到hash-b，然後與解開證書後得到的hash-a進行對比，對比一致後則確認該證書未經篡改，就從證書中取得伺服器的公鑰(srv-pub.key)，並記錄下服務端生成的隨機數r2、以及服務端所選擇的加密方式

* 客戶端產生第三個隨機數r3(預主密碼)，此時客戶端擁有了三個隨機數r1/r2/r3，然後通過商定的加密方法使用r1/r2/r3生成對稱金鑰，然後將r3以及將握手訊息hash後得到的hash值(verify_data1)通過服務端公鑰加密，加密後的內容傳送給服務端(clientkeyexchange/changecipherspec/clientfinished)

* 服務端使用自身的私鑰進行解密，得到預主密碼r3，此時，服務端也擁有了r1/r2/r3，以及和客戶端商定好的加密方法，於是使用商定好的加密方法和這三個隨機數，生成對稱金鑰

* 服務端將握手訊息做hash得到verify_data2，和客戶端發來的verify_data1做對比，如果一致，則認為握手過程沒有被篡改，然後通過生成的對稱金鑰加密verify_data2，返回給客戶端(serverfinished)

* 客戶端收到服務端返回的訊息，使用對稱金鑰解密後得到verify_data2並和自身計算出的verify_data1做對比，如果一致，則認為握手過程沒有被篡改，至此，金鑰交換成功

* 雙方使用對稱金鑰對通訊內容進行加密，開始通訊1、clienthello

客戶端發起請求到伺服器，其中包含了自身支援哪些加密方式和功能

其中包含：

1. version：客戶端支援的最佳協議版本 2. randon：隨機數，32位元組的資料，其中28位元組為隨機生成，剩餘4位元組包含額外資訊，受客戶端時鐘的影響；在握手時，客戶端和伺服器都會提供隨機數，可以防止重放攻擊，並確認初始資料交換的完整性 3. session id：首次會話時，該字段為空。這個字段表示會話的唯一標識，伺服器可以借助它從自己的快取中找到對應的會話狀態，可以用於恢復會話 4. cipher suites：密碼套件，這是由客戶端支援的所有密碼套件組成的列表，按照優先順序排列 5. compression：客戶端可以提供多個自身支援的壓縮方法，預設為null，代表沒有壓縮

6. extensions：擴充套件

2、serverhello

伺服器將自身選擇的連線引數回傳給客戶端，這個訊息的結構和1中類似，但每個欄位只包含乙個值；

伺服器無需支援客戶端支援的最佳版本，如果伺服器不支援客戶端相同的版本，可以提供某個其他版本以期待客戶端能接受

3、certificate

傳送伺服器的x509證書鏈，證書鏈指的是由根證書(也就是ca簽名後的那個證書)派生而成的一系列證書

4、serverkeyexchange

根據選擇的金鑰交換方式，伺服器傳送生成主金鑰的額外資訊

5、serverhellodone

伺服器通知自己完成了協商過程，在此之後，伺服器會等待客戶端傳送訊息

6、clientkeyexchange

客戶端傳送生成主金鑰所需的額外資訊

7、changecipherspec

已取得用以生成對稱金鑰的足夠資訊，已生成加密金鑰，並將切換到加密模式

8、finished

雙方計算傳送和收到的握手訊息的mac並傳送，這個訊息包含verify_data欄位，

它的值是握手過程中所有訊息的雜湊值，以驗證握手訊息沒有被第三方篡改

* 至此，對稱金鑰交換完畢，後續的應用資料傳輸都以此對稱金鑰加密後傳送。從而實現安全1、為什麼要用三個隨機數來生成對稱金鑰？

因為計算機所生成的隨機數其實是偽隨機數，通過統計學的方法是有規律可循的。

但是分別由服務端、客戶端生成共三個隨機數，其隨機性可以大大提高，基本可以視作是真隨機數。

2、為什麼finished訊息要帶有verify_data欄位？

主要是為了驗證整個握手過程沒有被第三方所篡改，確認client和server之間是否有攻擊者

3、為什麼不完全使用非對稱加密來做？

因為非對稱加密的cpu消耗很大，而對稱加密的消耗要小得多。並且通過非對稱加密交換的對稱金鑰並不是永久的，

當攻擊者暴力破解後，本次使用的對稱金鑰早就失效了，所以安全性是很有保障的。

https本質上就是通過使用非對稱加密方式交換對稱金鑰，從而實現安全性。

https的可靠性由ca作為基礎，客戶端和服務端之間通過對ca的信任從而建立信任關係，

但需要考慮的是ca可以不通過網域名稱所有者的同意而直接簽發某網域名稱的證書。所以為了解決這種情況，我們會使用「釘扎」的方式解決這個問題，下一次會詳細介紹

HTTPS 初步介紹

初步認識https與http

https協議介紹

HTTPS 簡單介紹

HTTPS 初步介紹

初步認識https與http

https協議介紹

HTTPS 簡單介紹

相關推薦