一.HTTPS的定義

大家在剛開始學習的時候是不是也是非常好奇HTTP與HTTPS之間有什么區(qū)別和聯系，兩者都是應用層協議，而HTTPS是在HTTP的基礎上引入了加密層，從而將HTTP的明文傳輸進行加密，保障數據的安全性

---

---

二.加密與解密

定義：將明文（要傳輸的數據）通過一系列變化轉換成密文的過程就是加密

? ? ? ? ? ?將密文通過密鑰轉換成明文的過程稱為解密

關于加密的原因不用想大家肯定都知道是為了防止信息泄露，那么我們就通過另外一個例子來了解加密的重要性;

假如現在你要下載一個名為A的程序軟件，但當你的請求在網絡中傳輸時，由于是明文傳輸，網絡運營商就可以獲取到你的請求并且可以將其劫持，然后發(fā)送其想要你下載的軟件，然后你就會發(fā)現下載好的內容不對，但是期間就會浪費大量時間與陳本，如果你的下次下載請求還是被劫持，這樣是不是就會非常難受，這就是運營商劫持，這也體現出明文傳輸在網絡中的巨大缺點

如下圖;

下面我們來了解下加密的方式：

對稱加密：

定義：通過單密鑰的加密方式，同一個密鑰可以同時用作信息的加密和解密，，這種加密方法稱為對稱加密， 也稱為單密鑰加密
常見對稱加密算法(了解)： DES、 3DES、 AES、 TDEA、 Blowfish、 RC2 等
特點： 算法公開、 計算量?、 加密速度快、 加密效率?
例如：

密鑰是按位異或，假設原始數據時a，通過密鑰key加密得到b，此時接受端得到b，對b^key就得到a，此時就完成解密，雙方使同一密鑰，當然實際當然不會如此簡單

非對稱加密：

定義：

通過兩個密鑰來進行加密和解密， 這兩個密鑰是公開密鑰（public key， 簡稱公鑰） 和私有密鑰（private key， 簡稱私鑰）

公鑰：是指即使泄露也沒關系的密鑰，而非是指直接公開的密鑰

私鑰;是指不能泄露的密鑰

常見非對稱加密算法(了解)： RSA， DSA， ECDSA
特點： 算法強度復雜、 安全性依賴于算法與密鑰但是由于其算法復雜， 而使得加
密解密速度沒有對稱加密解密的速度快
補充點：

我們是可以用公鑰加密也可以用私鑰加密，當然需要對應的另一個來解密

公鑰和私鑰是配對的. 最大的缺點就是運算速度非常慢， 比對稱加密要慢很多
例如：

假設A持有B給的一把鎖，當其將文件放入柜子時，將柜子鎖上，而鎖可以有多把，也可以給C，但是鑰匙只有B持有，即公鑰是指鎖，私鑰是指鑰匙

---

---

---

三.數據摘要 && 數據指紋

數字指紋(數據摘要),其基本原理是利用單向散列函數(Hash 函數)對信息進行運算,生成一串固定?度的數字摘要。 數字指紋并不是一種加密機制,但可以用來判斷數據有沒有被篡改。
摘要常見算法： 有 MD5、 SHA1、 SHA256、 SHA512 等， 算法把無限的映射成有限， 因此可能會有碰撞（兩個不同的信息， 算出的摘要相同， 但是概率非常低）
摘要特征： 和加密算法的區(qū)別是， 摘要嚴格意義不是加密， 因為沒有解密， 只不
過從摘要很難反推原信息， 通常用來進行數據對比
?

---

---

---

四,HTTPS加密所用的方案

1.只使用對稱加密

如果通信雙方都各自持有同一個密鑰 X， 且沒有別人知道， 這兩方的通信安全當然是可以被保證的（除非密鑰被破解）

我們知道服務器會同時與多個客戶端建立連接，而每一個連接的對稱的密鑰肯定要保證不同，所以每一個連接都需要雙方協商，所以密鑰是不是就要傳輸，從而保證雙方都拿到同一個密鑰來保證通信，但是密鑰如果在傳輸過程中被截獲，雙方的通信是不是就相當于對竊取者透明，如果截取者再對密鑰修改，是雙方的內容必須通過截取者這個中間人，那么信息就會完全泄露而且內容也可能被修改

2.只使用非對稱加密

鑒于非對稱機制，如果服務器將公鑰發(fā)送給客戶端，那么客戶端將信息加密（通過公鑰）傳遞給服務器，服務器就可以通過私鑰解密，這樣看起來信息就不會泄露，那么不妨我們多想想，如果服務器需要將信息發(fā)送客戶端，那么服務器是不是就需要用私鑰加密，但是我們知道公鑰是可以被截取的，那么其他人也可以通過公鑰對服務器發(fā)送的信息進行解密，這樣就會出現信息泄露，所以這種方法也是不安全的

3.雙方同時進行非對稱加密

服務器持有私鑰S和公鑰S'，客戶端持有私鑰C和公鑰C'，雙方同時將公鑰發(fā)送給對方，然后這樣是不是就看起來可以實現通信并且保證安全

這種方法首先最嚴重的問題是效率太低了，并且其實也無法保證安全，后面會講，而在網絡通信時，時間是非常重要的，所以也不是最優(yōu)解

4.非對稱加密和對稱加密
服務器持有私鑰S和公鑰S'，當客戶端發(fā)送https請求時，服務器將公鑰發(fā)送給客戶端，客戶端得到公鑰后，生成對稱加密的密鑰X，然后利用公鑰加密X，發(fā)送給服務器，服務器通過私鑰S解密，得到對稱加密的密鑰X，然后雙方就可以通過來進行對稱加密

由于對稱加密效率遠高于非對稱加密，該方案在后續(xù)過程中一直使用對稱加密，效率明顯提高，那么這種方法是否安全？

如果中間人將后序信息竊取是無法破解的，但是如果中間人在服務器發(fā)送公鑰S'時就對信息截取并將原本發(fā)送給客戶端的公鑰S'修改成中間人自己的公鑰M'，這樣客戶端收到公鑰M’,然后將X發(fā)送給中間人，這樣中間人就毫不費力的截取到對撐加密的密鑰，后續(xù)的所有信息還是回完全泄露。

目前來看所有的組合是都存在問題的，那么該如何破局呢？

---

---

---

五.證書與簽名

服務器在使用HTTPS之前去CA認證一份數字證書，證書中包含了服務器的諸多信息以及公鑰，然后服務器將證書發(fā)送給瀏覽器，瀏覽器得到證書后可以得到對應的公鑰，然后雙方即可進行通信，下面我們就來一一認識具體的細節(jié)：

1.證書的申請：

服務器生成一個公鑰S’和私鑰S，然后將自身的諸多信息發(fā)送給CA認證機構，注意：私鑰是不發(fā)送的，公鑰要發(fā)送給CA，CA機構對信息進行審核，然后生成一份包含服務器公鑰的證書

對于證書：大家可以看成一個結構化的字符串里面包含了以下信息:
? 證書發(fā)布機構
? 證書有效期
? 公鑰
? 證書所有者
? 簽名
? ......
2.簽名的理解：

當CA機構得到服務器的申請時，會在自身生成一個公鑰A'，私鑰A，然后將服務器發(fā)送的數據形成一份散列值，然后將散列值通過A進行加密形成簽名。如果此時在將數據和簽名整合，就會形成一份數字簽名的數據，后面CA的公鑰A會發(fā)送給瀏覽器，此時就可以通過將簽名解密和數據形成的散列值進行對比，此時就可以確定數據是否合法，當然這些我們后面會講，這里簡單提下，這個過程叫驗證
現在我們知道了證書的相關概念，那么我們是否可以通過證書來實現安全的網絡傳輸呢？

---

---

---

六.非對稱加密+對稱加密+證書機制

首先，當瀏覽器對一個服務器明文發(fā)送一個請求時，服務器會將一份經過CA機構認證的證書發(fā)送給瀏覽器，證書中包含了服務器的公鑰S，然后在瀏覽器端將數據散列值和簽名用公鑰解密得到的散列值進行對比，如果相等，說明得到的是安全的數據，然后客戶端生成一個對稱加密的密鑰X，然后通過證書中的服務器公鑰進行加密，發(fā)送給服務器，服務器通過私鑰解密得到密鑰X，然后雙方就可以對稱加密通信

現在問題來了，該方法是如何保證通信安全的呢？

我們知道非對稱加密和對稱加密的組合只有在服務器第一次發(fā)送響應時可以被中間人截取信息，那么證書機制如何保證這個過程的安全呢？

首先，當服務器發(fā)送的證書被中間人截獲后，其可能已經得到了對應的公鑰，所以可以對其解包，得到數據和簽名，但是簽名由于其根本不掌握對應的私鑰是無法修改的，當用戶進行驗證時，如果中間人對數據做過修改，散列值和簽名解密得到的內容是無法做到相等的。

此時你可能好奇，中間人不可以用自己的私鑰重新生成一份簽名，然后和數據整合形成一份證書嗎？

問題來了，我客戶端為什么要認中間人的公鑰呢？如果我不認中間人對應的公鑰是不是就無法做到對簽名解密，那么肯定是網絡傳輸中出現了問題，客戶端直接丟棄該內容即可

通過以上方案就可以實現網絡通信的安全保障了

最后，感謝大家的支持！！！