一.對稱加密演算法

特點：加密和解密的金鑰相同
問題：網路是不安全的，如何實現金鑰的安全傳輸？

二.RSA : 非對稱加密

特點：傳送方和接收方各持有一對鑰匙(公鑰 和私鑰)，用公鑰（私鑰）加密的資料只有對用的私鑰（公鑰）才能解密。
問題：RSA的速度較慢

三.非對稱加密 + 對稱加密
(1)傳送方或接收方事先生成一個對稱加密演算法的金鑰，用RSA方式安全的傳送給對方；
(2)對方接受到這個金鑰，以後傳送的資料就採用對稱加密的方式傳輸；

四.中間人攻擊
假設A發訊息給B,採用上面的非對稱加密+對稱加密的方式，首先，A要獲取B的公鑰，如果B在傳送給A公鑰時，有個中間人，截獲了B的公鑰，然後把自己的公鑰發給了A，冒充B，那麼A發的訊息就用中間人的公鑰加了密，中間人不就可以解密看到訊息了？

5.你到底是誰？
如何安全的分發公鑰？公鑰是不用保密的，那如何宣告這個公鑰確實是服務端傳送的，而不是別人的？
數字簽名
可以效仿現實中的公證處，服務端把他的公鑰和基本資訊用一個Hash演算法生成一個資訊摘要，這個Hash演算法有個極好的特性，只要輸入資料有一點點變化，那生成的訊息摘要就會有鉅變，這樣就可以防止別人修改原始內容。

可是作為攻擊者的中間人笑了： “雖然我沒辦法改公鑰，但是我可以把整個原始資訊都替換了， 生成一個新的訊息摘要， 你不還是辨別不出來？”

這時就要搬出有公信力的認證中心CA來了，用它的私鑰對訊息摘要加密，形成簽名，這還不算，還把原始資訊和資料簽名合併， 形成一個全新的東西，叫做“數字證書”。

當服務端把他的數字證書發給客戶端的時候，客戶端會用同樣的HASH演算法再次生成訊息摘要，然後用CA的公鑰對數字簽名解密， 得到CA建立的訊息摘要， 兩者一比，就知道有沒有人篡改了！如果沒人篡改， 客戶端就可以安全的拿到服務端的公鑰嘍，有了公鑰， 後序的加密工作就可以開始了。雖然很費勁， 但是為了防範偷窺者，實在是沒辦法啊。

中間人惡狠狠地說： “算你小子狠！ 等著吧，我還有別的招。 對了，我且問你， 你這個CA的公鑰怎麼拿到？　難道不怕我在你傳輸ＣＡ公鑰的時候發起中間人攻擊嗎？　如果我成功的偽裝成了ＣＡ，你這一套體系徹底玩完。”

折騰了半天，又回到了公鑰安全傳輸的問題！

不過轉念一想，想解決雞生蛋，蛋生雞的問題必須得打破這個怪圈才行，服務端必須得信任CA，並且通過安全的的方式獲取他們的公鑰，這樣才能把遊戲玩下去。

這些CA本身也有證書來證明自己的身份，並且CA的信用是像樹一樣分級的，高層的CA給底層的CA做信用背書，而作業系統／瀏覽器中會內建一些頂層的CA的證書，相當於你自動信任了他們。這些頂層的CA證書一定得安全地放入作業系統／瀏覽器當中，否則世界大亂。

6.HTTPS
一個簡化的（例如下圖沒有包含Pre-Master Secret）https流程圖是這樣的， 如果你理解了前面的原理，這張圖就變得非常簡單：