（1） 對稱加密加密與解密使用的是同樣的密鑰，所以速度快，但由於需要將密鑰在網絡傳輸，所以安全性不高。
（2） 非對稱加密使用一對密鑰，公鑰與私鑰，所以安全性高，但加密與解密速度慢。
（3） 解決的辦法是將對稱加密的密鑰使用非對稱加密的公鑰進行加密，然後發送出去，接收方使用私鑰進行解密得到對稱加密的密鑰，然後雙方可以使用對稱加密來進行溝通。
對稱密鑰算法非常適合於快速並安全地加密數據。但其缺點是，發件人和收件人必須在交換數據之前先交換機密密鑰。結合使用加密數據的對稱密鑰算法與交換機密密鑰的公鑰算法可產生一種既快速又靈活的解決方案。
基於公鑰的密鑰交換步驟如下：
發件人獲得收件人的公鑰。
發件人創建一個隨機機密密鑰(在對稱密鑰加密中使用的單個密鑰)。
發件人使用機密密鑰和對稱密鑰算法將明文數據轉換爲暗文數據。
發件人使用收件人的公鑰將機密密鑰轉換爲暗文機密密鑰。
發件人將暗文數據和暗文機密密鑰一起發給收件人。
收件人使用其私鑰將暗文機密密鑰轉換爲明文。
收件人使用明文機密密鑰將暗文數據轉換爲明文數據。
同樣，這些步驟是由啓用 PKI 的應用程序(如 Microsoft Outlook)來完成的，並且對用戶來說是透明的。
https中 通過server 的證書來交換密鑰，這個過程是明文的還是加密的？這個過程被人截獲後不怕被人拿到密鑰從而破解整個https？
系統中會預先安裝好證書，進行https通訊前會覈對公鑰是否在傳輸中被篡改。只有不信任一些不可靠證書，通訊才能安全。
https:
服務器 用RSA生成公鑰和私鑰
把公鑰放在證書裏發送給客戶端，私鑰自己保存
客戶端首先向一個權威的服務器檢查證書的合法性，如果證書合法，客戶端產生一段隨機數，這個隨機數就作爲通信的密鑰，我們稱之爲對稱密鑰，用公鑰加密這段隨機數，然後發送到服務器
服務器用密鑰解密獲取對稱密鑰，然後，雙方就已對稱密鑰進行加密解密通信了
===============================================================
摘要：本文用圖文的形式一步步還原HTTPS的設計過程，進而深入瞭解原理。
A在向B進行通信時，如果是以明文的方式進行通信，中間qieting者會獲得雙方的傳輸的數據hello。
HTTPS要解決如下問題：
A發給B的hello消息包，即使被中間人攔截到了，也無法得知消息的內容
如何做到安全
這個問題，很多人馬上就想到了各種加密算法，什麼對稱加密、非對稱加密、DES、RSA、XX、。。。。
做到安全的最終目的：
A與B通信的內容，有且只有A和B有能力看到通信的真正內容
對於解決方案，很容易就想到了對消息進行加密。
A與B這樣的簡單通信模型，我們很容易做出選擇：
這就是對稱加密算法，其中圖中的密鑰S同時扮演加密和解密的角色。
只要這個密鑰S不公開給第三者，同時密鑰S足夠安全，就可以解決通信的安全問題。
但是，在WWW環境下，我們的Web服務器的通信模型沒有這麼簡單：
如果服務器端對所有的客戶端通信都使用同樣的對稱加密算法，無異於沒有加密。那怎麼辦呢？即能使用對稱加密算法，又不公開密鑰？
答案是：Web服務器與每個客戶端使用不同的對稱加密算法：
如何確定對稱加密算法
首先需要解決服務器端怎麼告訴客戶端該使用哪種對稱加密算法問題。
可以通過協商。
但是，你協商的過程是沒有加密的，還是會被中間人攔截。那再對這個協商過程進行對稱加密好了，但是對協商過程加密的加密還是沒有加密，怎麼辦？再加密不就好了……進入了雞生蛋蛋生雞的問題了。
如何對協商過程進行加密
密碼學領域中，有一種稱爲“非對稱加密”的加密算法，特點是私鑰加密後的密文，只要是公鑰，都可以解密，但是公鑰加密後的密文，只有私鑰可以解密。私鑰只有一個人有，而公鑰可以發給所有的人。
雖然服務器端向A、B……的方向還是不安全的，但是至少A、B向服務器端方向是安全的。
解決了協商加密算法的問題：使用非對稱加密算法進行對稱加密算法協商過程。
到這裏明白了爲什麼HTTPS同時需要對稱加密算法和非對稱加密算法。
協商什麼加密算法
要達到Web服務器針對每個客戶端使用不同的對稱加密算法，同時，也不能讓第三者知道這個對稱加密算法是什麼，該怎麼解決？
使用隨機數，就是使用隨機數來生成對稱加密算法。這樣就可以做到服務器和客戶端每次交互都是新的加密算法、只有在交互的那一該才確定加密算法。
到這裏明白了爲什麼HTTPS協議握手階段會有這麼多的隨機數。
如何得到公鑰
仔細思考下，如果使用非對稱加密算法，客戶端A，B需要一開始就持有公鑰，否則無法進行加密。
所以需要解決A，B客戶端安全的獲得公鑰問題。
可以有以下方案：
方案1. 服務器端將公鑰發送給每一個客戶端
方案2. 服務器端將公鑰放到一個遠程服務器，客戶端可以請求得到
選擇方案1，因爲方案2又多了一次請求，還要另外處理公鑰的存放問題。
公鑰被調包了怎麼辦
對於方案1如果服務器端發送公鑰給客戶端時，被中間人調包了，怎麼辦？
通過下圖來理解：
顯然，讓每個客戶端的每個瀏覽器默認保存所有網站的公鑰是不現實的。
使用第三方機構的公鑰
公鑰被調包的問題出現，是因爲我們的客戶端無法分辨返回公鑰的人到底是中間人，還是真的服務器。這其實就是密碼學中提的身份驗證問題。
使用數字證書來解決，不能直接將服務器的公鑰傳遞給客戶端，而是第三方機構使用它的私鑰對我們的公鑰進行加密後，再傳給客戶端。客戶端再使用第三方機構的公鑰進行解密。
假如下圖是設計的第一版“數字證書”，證書中只有服務器交給第三方機構的公鑰，而且這個公鑰被第三方機構的私鑰加密了：
如果能解密，就說明這個公鑰沒有被中間人調包。因爲如果中間人使用自己的私鑰加密後的東西傳給客戶端，客戶端是無法使用第三方的公鑰進行解密的。
話到此，我以爲解決問題了。但是現實中HTTPS，還有一個數字簽名的概念，我沒法理解它的設計理由。
仔細思考，其實第三方機構不可能只給你一家公司製作證書，它也可能會給中間人這樣有壞心思的公司發放證書。這樣的，中間人就有機會對你的證書進行調包，客戶端在這種情況下是無法分辨出是接收的是你的證書，還是中間人的。因爲不論中間人，還是你的證書，都能使用第三方機構的公鑰進行解密。像下面這樣：
第三方機構向多家公司頒發證書的情況：
客戶端能解密同一家第三機構頒發的所有證書：
最終導致其它持有同一家第三方機構證書的中間人可以進行調包：
這個問題需要使用數字簽名技術。
.....