一、http協議
http協議是一種網絡傳輸協議，規定了瀏覽器和服務器之間的通信方式。位於網絡模型中的應用層。（盜圖小灰。ヾ(◍°∇°◍)ﾉﾞ）
但是，它的信息傳輸全部是以明文方式，不夠安全，很容易被人攔截，篡改傳輸內容。
篡改后：
二、使用對稱加密方式
為了保證通信的安全，瀏覽器和服務之間約定使用一種對稱加密的方式通信。在信息發送之前，使用相同的秘鑰對數據進行加密和解密。
這種方式的數據雖然在網絡中是以密文呈現，但是在首次發送秘鑰時，確實以明文方式發送，很容易被人截取，然后解密通信數據。仍然存在很大的安全隱患，所以一般采用非對稱加密方式來發送對稱加密的秘鑰。
三、使用非對稱加密方式
非對稱加密包含一組秘鑰，公鑰和私鑰，明文可以用公鑰加密，用私鑰解密，並且只能用私鑰解密，不能用公鑰解密；也可以用私鑰加密，公鑰解密，並且只能有公鑰解密。
如下過程實現發送對稱加密秘鑰：
1、瀏覽器生成一個隨機秘鑰。
2、瀏覽器向服務器請求公鑰。
3、服務器向瀏覽器發送它的公鑰。
4、瀏覽器接收服務器發送的公鑰，並使用公鑰加密隨機生成的對稱加密秘鑰，發送給服務器。
5、服務器接收瀏覽器發送的數據，用自身私鑰解密，得到，對稱加密秘鑰。
6、至此，瀏覽器和服務器可以使用對稱加密秘鑰相互通信。
但是，這種方式仍然存在安全隱患：即在第3步和第4步之間，中間人在服務器發送公鑰給瀏覽器時，截斷數據，並修改成自己的公鑰發送給瀏覽器。這時瀏覽器無法驗證公鑰的准確性。只會使用接收到的公鑰把對稱秘鑰加密，發送出去。這時，中間人截斷數據，使用自己的私鑰解密，得到對稱秘鑰，並使用服務器的公鑰重新加密對稱秘鑰，發送給服務器。然后，瀏覽器和服務器在毫不知情的情況下，使用對稱秘鑰進行通信。但中間人由於已經掌握了對稱秘鑰，所以可以輕松解密通信數據。
這里很明顯存在一個身份驗證的問題，只要能讓瀏覽器驗證得到的公鑰來源，對稱秘鑰就可以安全發送。這就需要數字證書了。
四、使用https數字證書保證數據安全
我們已經知道，非對稱加密需要身份驗證，那么數字證書如何驗證身份？
首先，數字證書是第三方機構（CA），給網站辦法的唯一身份證明，就像身份證，該證書包含兩個主要部分，一是明文信息（包含服務器的公鑰，和服務器本身的信息，及第三方機構的信息。用於傳遞服務器公鑰，和生成消息摘要，驗證信息是否被篡改），二是數字簽名。
數字簽名如何生成，將服務器網址的相關信息，先使用hash算法生成消息摘要，然后將消息摘要使用CA的私鑰加密。（注意，ca的私鑰，服務器是不知道的，它只有數字簽名）
瀏覽器在收到證書之后如何驗證，首先使用ca的公鑰解密數字簽名，生成相應的消息摘要；同時使用相同的hash算法，處理服務器網址，生成消息摘要。將兩份消息摘要進行對比，完全相同即可驗證服務器的公鑰的未被篡改。
ca認證流程圖：
下圖是一份證書：
下圖中的指紋即時數字簽名。
當瀏覽器請求公鑰時，服務端不單單發送公鑰，而是發送包含公鑰的數字證書。
瀏覽器如何解密：瀏覽器已經維護了所有知名的第三發機構，在接收到證書時
1、首先查看是否在有效期內，若失效則不再發送隨機對稱秘鑰；
2、找到第三方機構名稱，通過對照找到第三發機構公鑰，解密數字簽名，得到一個hash1值。
3、通過同樣的方式，根據服務端網址等信息，使用簽名算法，生成hash2.
4、將hash1和hash2，對比，如果相同，則身份驗證成功。
5、身份驗證成功后，使用同樣的機構公鑰解密網站公鑰。
6、瀏覽器使用解密后的公鑰發送對稱秘鑰給服務端。
補充： 1、數字簽名和網站公鑰都是經過機構秘鑰加密過的，所以數字簽名驗證成功，即可保證網站公鑰的准確性。
2、如果中間人將數字證書換成自己的數字證書，則會因為網站地址不同而導致驗證數字簽名失敗。
五、SSL安全層
https的主體思想是在，tcp/ip模型上加了ssl層，上述的安全驗證就是載ssl層完成的。
