為什么需要加密，因為HTTP是明文傳輸，不安全。
對稱加密
瀏覽器和服務器使用同一個密鑰進行加密和解密。沒有該密鑰不能獲取到傳輸的內容。看似是正確的沒有錯誤。但是怎么保證該密鑰能安全的讓雙方知道呢，服務器生成密鑰發送給瀏覽器的過程中是有可能被截獲該密鑰的。有的人可能會想，如果瀏覽器一開始就有該密碼就可以了，但是你想想讓瀏覽器去保存所有HTTPS網站的密鑰?這不現實吧。
非對稱加密
瀏覽器和服務器同時擁有公鑰和私鑰，公鑰用來加密，私鑰用來解密。公鑰是可以在網絡中傳輸的。
過程是這樣的：
瀏覽器擁有公鑰A和私鑰A',服務器擁有公鑰B和私鑰B'
瀏覽器向服務器發送請求時，服務器明文傳輸公鑰B給瀏覽器。
瀏覽器用公鑰B進行加密發送給服務器，服務器收到后用私鑰B'進行解密，因為只有服務器有該密鑰B',所以是安全的。
同理，服務器向瀏覽器傳輸的道路上用瀏覽器的公鑰加密，瀏覽器收到后用瀏覽器的私鑰進行解密。
這樣兩條路的安全都可以保證是安全的了(其實是不安全的)
先拋開非對稱加密的不安全性不說來談談為什么HTTPS不是用的這種加密？
很簡單，這種方式太過於繁瑣和耗時，效率不高。而對稱加密算法則比這快的多，那么我們可不可以使用兩者的結合呢？
非對稱加密+對稱加密
HTTPS真正采用的是這種加密方式。
大致的過程就是使用非對稱加密的方式傳送密鑰，那么該密鑰就是雙方就安全的得到了，也就是說使用非對稱加密來使得雙方安全拿到密鑰。這個過程可以自己想象一下。
這樣是不是很完美的解決了安全問題和效率問題？答案是否，因為這樣同樣存在安全問題，也就是上面提到的非對稱加密通用存在安全問題
中間人攻擊
在非對稱加密的過程中，服務器向瀏覽器發送公鑰的過程是明文的，這個通道上的公鑰是可以被中間人獲取到的，假設這個公鑰被獲取到了，然后中間人自己偽造一個公鑰和私鑰。將自己偽造的公鑰傳給瀏覽器，而瀏覽器用偽造的公鑰加密后傳回服務器的途中被中間人獲取，然后用偽造的私鑰解密，這樣數據就被獲取到了，而中間人同樣有服務器的公鑰，同時也可以和服務器進行交互。
上面暴露的問題是瀏覽器根本不知道公鑰是不是服務器的，那么有沒有什么辦法來證明公鑰是不是服務器的呢？答案是有
數字證書
使用HTTPS的網站需要向CA機構申請一份數字證書來證明來保證該公鑰是歸誰所持有的。所以服務器和瀏覽器通信時可以下發給瀏覽器數字證書。瀏覽器可以從證書中獲取到公鑰。
但是同樣存在問題，因為證書同樣會被中間人獲取到，同樣可以偽造。真令人頭大，怎么樣都不行了？那是不是有可以防止偽造數字證書的方法呢？答案是有的。
數字簽名
把證書內容生成一份簽名，對比內容和簽名是否一致來判斷是否被篡改了消息。大概步驟：
CA機構擁有公鑰和私鑰
CA機構對證書明文哈希
對哈希后的值用私鑰哈希得到數字簽名。
這樣將明文+數字簽名組成一份數字證書頒發給網站。
那么怎么驗證信息有沒有被篡改呢
驗證
瀏覽器拿到證書后，得到了明文信息和數字簽名信息。
瀏覽器使用CA的公鑰匙解密拿到哈希的信息。
使用哈希算法對明文進行加密與解密得到的哈希信息進行比對，如果不等則說明被篡改了。
那么中間人是否能夠篡改簽名呢？答案是想屁吃。他不是CA機構信任的，所以沒有服務器的私鑰)
