HTTPS加密過程

為什麼需要加密

因為htpp的內容都是明文傳輸的，明文資料會經過中間**伺服器、路由器等多個物理節點，如果資訊在傳輸過程中被劫持，傳輸的內容就完全暴露了，所以我們需要對資訊進行加密

使用對稱加密

首先來了解一下對稱加密：對稱加密就是傳送方和接收方都使用同乙個金鑰，那麼我們可以使用對稱加密技術對我們傳輸的資訊進行加密嗎

如果通訊雙方都各自持有同一金鑰，且沒有人知道，這兩方的通訊安全當然是可以被保證的，然而最大的問題就是這個金鑰怎麼讓傳輸的雙方知道，且同時不被別人知道，直接傳輸公鑰是不現實的，因為在傳輸公鑰也是明文傳輸，也可以把公鑰劫持，然後使用公鑰進行解密操作

使用非對稱加密

現在有兩把金鑰，通常一把叫做公鑰，一把叫做私鑰，用公鑰加密的內容必須用私鑰才能解開，同樣，私鑰加密的內容只有公鑰能解開。

考慮這麼乙個場景：

上述過程只能保證了瀏覽器——>伺服器傳輸的單方面安全性，而伺服器——>瀏覽器的資料傳輸安全性還是沒有得到保證

使用改良的非對稱加密

我們同時在瀏覽器和伺服器設定一對公鑰和金鑰，雙方各自獲取對方的公鑰，然後使用對方的公鑰進行加密，到達後，再使用私鑰進行解密，保證了雙向的資料傳輸安全性

非對稱加密+對稱加密

對於非對稱加密來對傳輸資料傳輸資料的方法來說，確實能保證資料的安全性，但是非對稱加密演算法非常耗時，那麼我們可以使用非對稱+對稱加密的方法，減少非對稱加密使用的次數

考慮上面的過程，似乎既能對資料進行加密操作，也能減少非對稱加密的使用次數，那麼這樣還存在的問題是什麼呢？

因為伺服器將自己的公鑰傳輸給瀏覽器a的過程是明文傳輸，那麼中間人就能擷取該公鑰，然後將該公鑰換成自己的，然後瀏覽器使用中間人的公鑰進行加密，中間人獲取到了瀏覽器的公鑰，以後就能對瀏覽器傳送的資料進行解密了

數字證書

**在使用https前，需要向ca機構（授權認證中心）

申請頒發乙份數字證書，數字證書裡有證書持有者、證書持有者的公鑰資訊，伺服器把證書傳輸給瀏覽器，瀏覽器從證書裡取公鑰就行了，證書就如身份證一樣，可以證明「該公鑰對應該**」。然而這裡又有乙個顯而易見的問題，證書本身的傳輸過程中，如何防止被纂改，換句話說，即如何證明證書本身的真實性？

數字簽名

我們把證書內容生成乙份「簽名」，比對證書內容和簽名是否一致就能察覺是否被纂改。這種技術就叫做「數字簽名」，數字簽名是為了防止證書被修改

數字簽名的製作過程：

為什麼這樣的驗證能說明證書可信呢（即證書明文資訊中的公鑰為什麼可以保證是伺服器的公鑰呢）？

中間人可能纂改證書資訊嗎

證書資訊是明文傳輸的，所以中間人是可以獲取到該證書原文的，假設他修改了證書資訊，但是由於他沒有ca機構的金鑰，所以無法得到數字簽名，那麼當瀏覽器進行驗證時，就會出現數字簽名解密後的值和原文hash後的值不一致，此時瀏覽器就知道證書已被纂改

中間人有沒有可能將證書換掉

假設有另外乙個**b也拿到了ca機構認證的證書，然後它成為中間人，劫持了**a傳給瀏覽器的證書，然後替換成自己的證書，傳給瀏覽器，之後瀏覽器錯誤的拿到b的證書，就會將自己的公鑰傳給b，造成漏洞

其實這是不可能發生的，因為ca機構頒發的證書包含了**的資訊，包括網域名稱，而且是不可更改的，瀏覽器把證書裡的網域名稱與自己請求的網域名稱比對一下就知道有沒有被掉包了