http

http協議是將數據以明文的形式在網絡上傳輸。若是傳輸的數據中包含一些敏感信息比如銀行卡信息等可能會被有心人攻擊造成信息泄露或被篡改。

總結：http協議進行數據傳輸難以保證數據的隱私性以及數據完整性，為了保證數據的準確定引入了https這一協議。

https

簡單來說https就是安全版的http協議。

HTTPS協議也是一個應用層協議，是在http的基礎上使用TLS/SSL(套接字)進行加密，這樣通信就不容易受到攔截和攻擊。

TLS/SSL

• TLS：傳輸加密協議，規定了如何為網絡中的數據進行加密和解密。
• SSL：早期由網景公司設計的加密協議，后貢獻給IETF組織，并最終命名為TLS。
• tips：除了HTPPS外，TLS可以被用于任何基于TCP/IP協議的上層協議或應用程序，如SFTP協議、數據庫間通信加密…

常見的加密方式

常見的加密算法有對稱加密、非對稱加密、摘要算法

HTTP加密過程探究

[1] 只使用對稱加密

如上圖所示

• 客戶端發送請求：其中包含了客戶端所支持的TLS版本以及加密算法等信息；
• 服務端接收請求：從中選取最優的TLS版本以及加密算法 并將這些信息反饋給客戶端
• 客戶端接收響應：生成一段隨機字符串(這段隨機字符串被稱為預主密鑰)，通過服務端指定的加密函數和加密算法將這段隨機字符串生成一對密鑰(被稱為會話密鑰) 用于后續數據傳輸時的加密和解密；
• 客戶端發送請求：將預主密鑰發送給服務端并告知服務端生成密鑰的算法等信息
• 服務端接收請求： 接收信息后以同樣的方式生成會話密鑰
• 此時 客戶端和服務端 就可以 以會話密鑰加解密數據進行通信了

引入對稱加密之后即使數據被截獲, 由于黑客不知道密鑰是什么也就無法進行解密,獲取原始數據了。

問題

如何將預主密鑰傳遞給服務端成為最大的難題

若是預主密鑰以明文的方式傳輸，那么在傳輸過程中 黑客獲取到這個預主密鑰 他完全可以創建出與客戶端相同的會話密鑰，最終導致后面所有的傳輸數據都面臨著被破譯的風險。

解決

通過非對稱加密的方式 來傳輸預主密鑰 確保數據的安全性；

[2] 使用對稱加密+非對稱加密

非對稱加密包含兩個不同的密鑰文件 => 公鑰用于加密私鑰用于解密 公鑰對外公開任何人都可以隨意獲取私鑰則只有擁有者自己知道

與對稱加密不同的是 非對稱加密是不可逆

如上圖所示

• 客戶端發送請求：其中包含了客戶端所支持的TLS版本以及加密算法等信息；
• 服務端接收請求：從中選取最優的TLS版本以及加密算法 并將這些信息反饋給客戶端 除此之外還會將自己的公鑰發送給客戶端
• 客戶端接收響應：生成一段隨機字符串(這段隨機字符串被稱為預主密鑰)，通過服務端的公鑰將預主密鑰進行加密并傳遞給服務端；
• 客戶端發送請求：將預主密鑰發送給服務端并告知服務端生成密鑰的算法等信息
• 服務端接收請求： 接收信息后通過私鑰解密得到預主密鑰
• 客戶端和服務端：根據預主密鑰通過相同的算法計算得到會話密鑰
• 此時 客戶端和服務端 就可以 以會話密鑰加解密數據進行通信了

這樣即使黑客截取到數據也不知道密鑰的原始值是什么，就無法獲取后續傳遞的數據了。

問題

若是在最初建立連接的時候就被黑客監聽到 當服務端返回公鑰給客戶端的時候 黑客截取并模仿生成一個公鑰傳輸給客戶端，那么后面無論客戶端發送任何數據都不再安全了

如上圖

• 服務端發送公鑰給客戶端 但是中間被黑客攔截了，黑客模擬生成一個類似得公鑰并傳遞給客戶端
• 客戶端接收到之后認為此公鑰是客戶端的公鑰（實際是黑客傳遞的）=> 客戶端使用該公鑰加密預主密鑰傳輸給服務端(實際被黑克攔截 并將黑客生成的預主密鑰發送給服務端)
• 后續任何流程都是 客戶端與服務端中間加了一個流程與黑客進行數據傳輸了！

解決

其實上述問題的本質就是客戶端無法確定收到的含有公鑰的數據報文就是?標服務器發送過來的。

為了解決這一問題 引入了證書這一概念 。

客戶端獲取的不再是公鑰而是證書 => 證書是由證書頒發機構(CA)簽發的，用于唯一標識一個站點的身份信息。

[3] 將公鑰存放在證書中

證書定義

簡單來說 證書就像網站的身份證和護照用于幫助我們鑒別一個網站的真偽。

證書是用于鑒別網站的真實性和有效性，所有人都可以查看網站的證書。

查看證書

證書信息

證書的指紋用于唯一標識一個證書=>確保證書的完整性！

申請證書

證書是由CA機構辦法的，CA機構分布在全球各處

申請證書：

• 向某個心儀的機構提交證書申請

• 申請成功后將其部署到web服務中即可

CA組織機構做了什么呢？

• CA組織在為申請者申請證書時 會對證書的內容和公鑰分別進行hash計算并將得到的值作為證書指紋附加到證書中，同時說明使用的hash算法 => 內容 + 公鑰 + 由內容和公鑰生成的hash值(證書指紋) + hash算法說明(一般使用hash256)

  客戶端得到證書之后 使用相同的算法對 內容和公鑰進行hash計算 得到的結果與證書指紋進行比對 若是完全一致則表明證書沒有被截獲/篡改從而確保了證書的完整性。

• CA組織生成好證書后，會使用CA的私鑰進行加密并將加密結果附加到證書

  客戶端在獲取到網站證書后還需要驗證證書的真實性 表明該證書確實是由該證書上描述的CA機構所頒發的！

  通過數字簽名對證書進行加密和解密來驗證真偽的 => 使用私鑰進行加密 使用公鑰進行解密

  客戶端在獲取到網站證書后會使用CA對應的公鑰進行解密 => 解密成功則表示客戶端使用的公鑰與CA加密時使用的私鑰是一對密鑰從而確保該證書確實是由該CA證書所簽發的

問題

現在好像又循環到最初的問題了 => 如何安全的獲取CA的公鑰呢?

答案就是預安裝

其實CA機構在對證書進行簽名的時候 使用的是私鑰+根證書

根證書最主要的作用之一就是對其他證書進行簽名，CA的公鑰也被附加在CA的根證書中

每個操作系統都會維護一個根證書庫并默認安裝好了受信任的全國各地的CA根證書。

當需要認證證書簽名時直接從系統中找到對應的CA根證書即可。=> 避免網絡傳輸 不會被竊聽/碉堡

總結流程

如上圖所示： 先通過TCP三次握手建立連接

• 客戶端發送請求：其中包含了客戶端所支持的TLS版本以及加密算法等信息；

• 服務端接收請求：從中選取最優的TLS版本以及加密算法 并將這些信息反饋給客戶端 除此之外還會將自己的證書發送給客戶端

• 客戶端接收響應：獲取證書 => 驗證證書的真實性與完整性，沒有問題在證書中拿到服務器的公鑰

  生成一段隨機字符串(這段隨機字符串被稱為預主密鑰)，將預主密鑰使用服務器的公鑰進行加密

• 客戶端發送請求：將預主密鑰發送給服務端并告知服務端生成密鑰的算法等信息

• 服務端接收請求： 接收信息后通過私鑰解密得到預主密鑰

• 客戶端和服務端：根據預主密鑰通過相同的算法計算得到會話密鑰

• 此時 客戶端和服務端 就可以 以會話密鑰加解密數據進行通信了

tips: 這一過程也被稱為TLS握手。

http與https的區別

http是基于TCP協議以明文方式進行傳遞數據的協議；

不同點	http	https
核心本質	信息以明文進行傳輸，沒有任何加密	通過http+TLS套接字進行加密數據傳輸
安全性	不安全 => 容易被竊聽、篡改或冒充	安全 => 提供身份認證，確保連接到的是正確的網站，在信息傳輸過程中數據經過加密、具有校驗機制
協議與端口號	基于 TCP，使用端口 80	在 HTTP 基礎上加入了 SSL/TLS 加密層，使用端口 443
數字證書	不需要	由受信任的證書頒發機構 (CA) 頒發的 SSL/TLS 證書=> 存在一定開銷。
工作方式	直接與 TCP 通信	先與 SSL/TLS 通信，再由 SSL/TLS 和 TCP 通信。相當于在 HTTP 和 TCP 之間加了一個“安全層”。