HTTPS，你比HTTP多了個S

在說HTTP前，必定要先介紹一下HTTP，這傢伙應該不用過多說明了，你們天天都在用，每一次HTTP請求，都是一次TCP鏈接。遺憾的是，請求的內容在TCP報文中是明文傳輸的，任何人截取到請求均可以讀取其中的內容，安全性欠缺。

 

一.數據加密

爲了防止請求內容被人竊取，在網絡傳輸的路上咱們作不了手腳，那就只能對傳輸的數據報文上作手腳了。對報文內容進行加密就是其中的一種方法。

有一種加密算法叫作對稱加密算法，即加密和解密使用同一個祕鑰，使用這種算法對請求數據進行加密，中間人由於沒有祕鑰，沒法讀取其中的內容。可是，使用這種算法進行加密，確定要贊成祕鑰，那祕鑰在網絡中傳輸一樣存在被竊取的風險啊。

這時，出現了新的加密算法：非對稱加密算法，它有兩把鑰匙，一把叫私鑰，是隻有本身知道的，另外一個叫公鑰，能夠發到互聯網山，隨便誰均可以看到，也就是說，傳輸過程當中即便被別人看到也無所謂。這時，A向B發消息時，能夠先用B的公鑰對數據進行加密，B收到消息後再使用本身的私鑰進行解密，中間即便被竊取了，由於沒有對應的祕鑰，也沒法對了數據進行解密。

可是，非對稱加密算法要比對稱加密算法慢上許多。一個折中的辦法，先使用非對稱加密算法來傳輸對稱加密的祕鑰，以確保祕鑰安全送達，以後就可使用對稱加密算法來加密數據報文了。

 

二.中間人劫持

你覺得如今能夠高枕無憂了嗎？你覺得你能夠放心安全的進行通訊了嗎？天真。

假設，你如今正在和A通訊，來自靈魂的拷問：你怎麼能肯定和你通訊的人是A呢？

咱們假設，通訊正常進行。在通訊開始傳輸公鑰的時候，請求被中間人C劫持了。C講A的公鑰換成本身的公鑰發給了你，在你發送請求後，再講你的信息解密，使用A的公鑰進行加密，發送給A。這樣，在你和A看來好像是在和彼此通訊，其實全部的信息都通過了C，全部的信息都被C盡收眼底。

那麼如何保證收到的公鑰是A的呢？完犢子了，又回到開始的問題了，如何保證祕鑰在網絡中安全的傳輸。但此次，加密彷佛救不了咱們了，咱們必需要確保收到的祕鑰確實是A發來的，也就是說報文沒有別中途篡改過。

 

三.數字證書

你其實沒法保證報文內容的關鍵，在於咱們對於收到的公鑰沒法肯定有沒有被人修改過，那若是有一個咱們信任的中間人S來傳輸這個公鑰就能夠了。問題來了，D的公鑰傳輸中一樣存在被修改的問題，拿到再找其餘人來傳輸S的公鑰麼？這要下去簡直沒完沒了，徹底就是三次握手的翻版。

問題的根源是什麼？咱們沒有一個能夠信任的公鑰，那麼解決辦法也很粗暴，咱們在本地保存一個絕對信任的公鑰，它不是經過互聯網來獲取的，而是預裝在系統中的，也就是系統/瀏覽器預置的頂層CA證書。

這些預裝信任的內容，就是CA證書。經過CA獲取A的公鑰時，得到的數字證書大概長這樣：

當收到證書後，咱們對信息經過童謠的hash算法計算出信息摘要，在用CA的公鑰對數字簽名進行解密，若解密後的信息摘要與咱們計算的摘要相同，則能夠認爲信息沒有被人修改過。驗證流程以下：

難道這樣就不拍別人篡改了麼？不怕。由於咱們已經拿到CA的公鑰了，這是沒有問題的。中間人由於沒有CA的私鑰，及時截取到信息，也沒法對修改後的內容進行加密並生成對應的數字簽名。

這樣一來，信息的傳輸問題算是暫時告一段落了。（不知道何時就冒出了新的安全問題，畢竟道高一尺魔高一丈）

 

四.總結

到這裏，HTTPS介紹完畢，以上大概就是HTTPS的所有內容了。HTTPS的一次請求，大概流程以下：

1. 瀏覽器發出HTTPS請求

2. 服務器講本身的數字證書返回

3. 瀏覽器用預置的CA來驗證證書，若沒有問題，順利拿到公鑰

4. 瀏覽器生成對稱加密算法的祕鑰，經過服務器的公鑰進行加密，將報文發送給服務器

5. 服務器用本身的私鑰進行解密，獲得對稱加密的祕鑰

6. 能夠開始用得到的對稱加密祕鑰進行通訊了