HTTPS

所有的HTTP請求和響應資料都需要加密。 一個傳輸級的安全密碼層：SSL
後繼者：TLS。 我們不嚴格的用SSL表示SSL和TLS
HTTPS是位於安全層之上的HTTP，這個安全層位於TCP之上。

為什麼用HTTPS (必要性)
伺服器認證 ：客戶端知道它是在與真正的而不是偽造的伺服器通話
客戶端認證：伺服器知道他們是在與真正的而不是偽造的客戶端通話
完整性： 客戶端和伺服器的資料不會被修改
加密：對話是私密的，不怕被竊聽
效率： 一個執行足夠快速的演算法
普遍性：所有的客戶和伺服器都支援這些協議
管理的可擴充套件性：任何地方的任何人都可以立即進行安全通訊

加密原理

對稱加密技術

編碼的時候使用的金鑰值 和 解碼的一樣
e=d . 對稱金鑰加密中傳送端和接收端共享相同的金鑰才能通訊！
舉例
一個客戶端傳送資訊給另一個節點，它用自己的一個金鑰加密這個資訊，然後傳送給另一個節點客戶端，另一個節點也要使用這個對應的金鑰來解密這個資訊。 如果一個通訊鏈路上有N個節點，那麼其中一個節點和其他N-1個節點進行通訊的話就需要N^2個金鑰。這對於管理來說非常困難。

非對稱加密技術

一把公鑰發給多個客戶端，它們可以用這個公鑰加密自己的資訊然後傳送給服務端，如果要對內容解密的話就必須用服務端的私鑰才能解密。

對於一個通訊鏈路中的一個節點來說，就是，任何想要傳送報文給節點X的人它的金鑰是公開的，你使用它提供的金鑰加密即可。 X接收到資訊後，使用它自己的私鑰才能解密。 別人就算獲取了它的報文，也無法破解。

RSA

RSA是一種用在公開金鑰非對稱加密系統的演算法。
公開金鑰（公有的）
一小片攔截下來的密文（可通過網路獲取）
一條報文及與之相關的密文（對任意一段文字執行加密器就可以得到）

破解它的難度就是對一個極大的數進行質因子分解的難度

數字簽名

將報文按雙方約定的HASH演算法計算得到一個固定位數的報文摘要。
在數學上保證：只要改動報文中任何一位，重新計算出來的報文摘要值就會與原先的值不相符。這就保證了報文的不可更改性。

關鍵: Hash生成摘要然後再用私鑰加密

HASH –> 摘要
私鑰加密—> 簽名

簽名是加了密的“校驗和”

• 簽名可以證明是作者編寫了這條報文。
• 簽名防止被篡改。惡意攻擊者報文傳輸過程修改，校驗和不再匹配了。 校驗和只有作者保密的私有金鑰才能產生，所以攻擊者無法為報文偽造出正確的校驗碼。

流程

傳送者
節點A 將報文 HASH ,然後生成一個摘要。
然後一個摘要應用一個簽名函式以及私鑰加密，生成簽名

接收者
接收者需要使用公鑰解密數字簽名，然後將得到報文的摘要。 證明這個報文確實是節點A傳送的。
然後再對接收到的報文使用Hash函式，得到摘要，與剛才的摘要比較，兩者一致則證明沒有被修改過。

附加

校驗和：是傳輸位數的累加，當傳輸完成，接收者可以根據這個數值判斷是否接到了所有資料。 如果數值匹配，那麼說明傳送已經完成。
以每16位為單位進行反碼求和，如果最高位進位，就與最後一位求和。 將結果取反。

數字證書

數字證書一般是CA機構頒發的。
原因：
無法確定公鑰是否權威。 如果A的公鑰被惡意的B用自己的公鑰替換了，那麼本來要傳送報文給A的客戶端都會擁有了B的公鑰，然後用B的公鑰加密傳送給B，無法區分兩個公鑰。
我們用證書，給公鑰附加很多的資訊！！！
CA證書中心會對公鑰和一些相關資訊一起加密生成數字證書

Usage
自己的網站比如在騰訊雲上的，我用的https協議，那麼我需要去申請一個權威的一般瀏覽器都認可的數字證書。然後下載它並配置到我的web伺服器上面。

它可能包含這些內容
ID ：主要內容包含了由某個受信任組織擔保的使用者或公司的相關資訊。
物件的名稱
過期時間
證書釋出者
來自證書釋出者的數字簽名
所有這些資訊都是由一個官方的“證書頒發機構”以數字方式簽發的。

使用數字證書流程

瀏覽器接收到數字證書，需要使用CA的公鑰來驗證簽名，(如果這是一個權威的公共簽名機構，那麼瀏覽器可能就內建了這個CA的公鑰了), 使用CA的公鑰以及傳送者的公鑰解密生成 報文摘要，然後比較摘要是否相同。驗證數字簽名。

HTTPS

1. 客戶端傳送加密請求給伺服器
   

2. 伺服器用自己的私鑰加密資源後(如HTML網頁)，連同本身的數字證書一起傳送給客戶端。
   

3. 客戶端的證書管理器
   

4. 如果數字證書記載的網址與你正在瀏覽的網址不一致，說明這個證書可能被冒用，瀏覽器會發出警告。

5. 如果證書不是受信任的機構頒發的，瀏覽器會發出另外一種警告。
   12306的證書不是受信任的
   

HTTPS怎麼實現安全傳輸的？

建立安全傳輸

HTTPS中， 客戶端首先開啟一條到WEB伺服器443埠的連線。 一旦建立了TCP連線
，客戶端和伺服器就會初始化SSL層，對加密引數進行溝通，並交換金鑰。
握手完成後，SSL初始化就完成了，客戶端就可以將請求報文傳送給安全層了。

重點 SSL握手

傳送已加密的HTTP報文之前，客戶端和伺服器要進行一次SSL握手，這個握手過程中，他們完成：

1. 客戶端傳送列出客戶端密碼能力的客戶端資訊，比如SSL的版本，客戶端支援的金鑰對和客戶端支援的hash方法(壓縮方法)。 client_hello
2. 伺服器響應，伺服器選擇一個兩端都瞭解的金鑰。和伺服器的hash方法。 server_hello
3. 伺服器傳送SSL數字證書 X.509，等待客戶端響應
4. 一旦接受到，客戶端將驗證伺服器的SSL數字證書的有效性。 伺服器也可以請求客戶端的SSL證書(SSL支援雙向)
5. 一旦校驗通過，客戶端就回隨機生成一個用於後面通訊的“對稱密碼”pre_master_secret，用伺服器的公鑰加密。然後傳送給伺服器。
6. 服務端用私有金鑰解密加密後的隨機資料並協商暗號
   得到pre_master_secret，然後雙方利用這個協商得到master_secret。 這個是為了保證資料的安全。
7. 服務端跟客戶端利用mastersecret產生真正的sessionkey，這是一個對稱加密的key。 然後握手結束。

選擇一個兩端都瞭解的密碼
對兩端的身份進行認證。
生成臨時的會話金鑰，加密通道

其實還有SSL雙向握手，這裡就不闡述了。

對比HTTP和HTTPS的傳輸

本質關鍵原因

SSL是一個二進位制的協議，和HTTP完全不同。 流量是在443埠承載的。