作者：David Youd
翻譯：阮一峯 原文網址：
http://www.youdzone.com/signature.html
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
其他擴展文章：
月光博客：爲什麼12306要安裝根證書http://www.williamlong.info/archives/3461.html
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
其他：
如何保證公鑰不被篡改？
答：將公鑰放在數字證書中，只要證書是可信的，公鑰就是可信的。
公鑰加密計算量太大，如何減少耗用時間？
答：每一次對話（session），客戶端和服務器都生成一個對話密鑰（session key），用它來加密信息，由於“對話密鑰”是對稱加密，所以運算速度非常快，而服務器公鑰只用於加密“對話密鑰”本身，這樣就減少了加密運算的消耗時間。
因此SSL/TLS協議的基本過程是：
1）客戶端向服務器索要並驗證公鑰（握手階段，明文）
2）雙方協商生成“對話密鑰”（握手階段，明文）
3）雙方採用“對話密鑰”進行加密通信
握手階段詳解：
1）客戶端發出請求（ClientHello） 並提供如下信息
a 支持的協議版本，例如TLS 1.0
b 客戶端生成的隨機數，用於生成“對話密鑰”
c 支持的加密方法，例如RSA公鑰加密
c 支持的壓縮方法a 確認使用的加密通信協議版本，如果客戶端與服務器支持版本不一致，服務器關閉加密通信
b 服務器生成的隨機數，用於生成“對話密鑰”
c 確認使用的加密方法
d 服務器證書客戶端驗證服務器證書，若證書問題，顯示警告是否繼續通信。
若證書安全，客戶端從證書中提取公鑰，向服務器發送如下信息：
a 隨機數（用公鑰加密，防止竊聽）【第三個隨機數，又稱"pre-master key"，三個隨機數+加密方法 生成session key】
b 編碼改變通知，表示隨後的信息都將用雙方協商的加密方法和密鑰傳輸
c 客戶端握手結束通知，表示客戶端的握手階段結束，同時包括hash值，供服務器校驗
4）服務器迴應
服務器生成 session key ，併發送如下信息：
a 編碼改變通知，隨後的信息都將使用雙方協商的加密方法和密鑰傳輸
b 服務器握手結束通知，表示服務器的握手階段結束，同時包括hash值，供客戶端校驗//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
1、鮑勃有兩把鑰匙：公鑰和私鑰
2、鮑勃把公鑰送給朋友們：帕蒂、道格、蘇珊，每人一把
3、蘇珊要給鮑勃寫一封保密信件，她寫完後用鮑勃的公鑰加密，就可以達到保密的效果
4、鮑勃收到郵件後，用私鑰解密，就可以看到郵件的內容。
（注意：只要鮑勃的私鑰不泄露，這份郵件就是安全的，即使落在別人手裏，也無法解密）
5、鮑勃給蘇珊回信，決定採用“數字簽名”，他寫完後先用Hash函數，生成信件的摘要(Digest)
6、然後，鮑勃使用私鑰，對這個摘要進行加密，生成“數字證書”(signature)
7、鮑勃將這個簽名，附在信件下面，一起發送給蘇珊
8、蘇珊收件後，取下數字證書，使用鮑勃的公鑰解密，得到郵件的摘要，由此證明，這封信確實是鮑勃發出的。
9、蘇珊再對信件本身使用Hash函數，將得到的結果與上一步得到的摘要進行對比，如果兩者一致，說明郵件未被修改過
10、複雜情況：道格想欺騙蘇珊，他偷偷使用蘇珊的電腦，用自己的公鑰替換鮑勃的私鑰。
此時，蘇珊實際擁有的是道格的公鑰。
因此，道格可以冒充鮑勃，用自己的私鑰做成“數字證書”，寫信給蘇珊，讓蘇珊用假的鮑勃的公鑰進行解密。
11、後來蘇珊發覺不對勁，發現自己無法確定公鑰是否屬於鮑勃。
她想到一個辦法：要求鮑勃去找“證書中心”(certificate authority，簡稱CA)，爲公鑰做認證。
證書中心用自己的私鑰，對鮑勃的公鑰和一些相關信息一起加密，生成數字證書(Digital Certificate)。
12、鮑勃拿到數字證書後，就可以放心給蘇珊寫信了，只要在簽名的同時，附上數字證書即可。
13、蘇珊收信後，用CA的公鑰解開數字證書，就可以拿到鮑勃的真實公鑰，以此判斷數字證書是否鮑勃的。
14、以HTTPS協議爲例，瞭解數字證書的應用，主要用於web加密
15、首先，客戶端向服務器發出加密請求。
16、服務器用自己的私鑰加密網頁後，連同本身的數字證書，一起發送給客戶端
17、客戶端的證書管理器，有“受信任的根證書頒發機構”列表。
客戶端會根據這張列表，查看解開數字證書的公鑰是否在列表之內。
18、如果數字證書記載的網址，與當前瀏覽的網址不一致，就說明該證書可能被毛用，瀏覽器發出警告。
19、如果這張證書不是由受信任的機構頒發的，瀏覽器就會發出另一種警告。
20
總結：公鑰和私鑰是成對的，它們互相解密。
公鑰加密，私鑰解密。
私鑰數字簽名，公鑰驗證。
