在網際網路安全通訊方式上，目前用的最多的就是https配合ssl和數字證書來保證傳輸和認證安全了。本文追本溯源圍繞這個模式談一談。

名詞解釋

首先解釋一下上面的幾個名詞：

https：在http(超文字傳輸協議)基礎上提出的一種安全的http協議，因此可以稱為安全的超文字傳輸協議。http協議直接放置在TCP協議之上，而https提出在http和TCP中間加上一層加密層。從傳送端看，這一層負責把http的內容加密後送到下層的TCP，從接收方看，這一層負責將TCP送來的資料解密還原成http的內容。

SSL(Secure Socket Layer)：是Netscape公司設計的主要用於WEB的安全傳輸協議。從名字就可以看出它在https協議棧中負責實現上面提到的加密層。因此，一個https協議棧大致是這樣的：

數字證書：一種檔案的名稱，好比一個機構或人的簽名，能夠證明這個機構或人的真實性。其中包含的資訊，用於實現上述功能。

加密和認證：加密是指通訊雙方為了防止銘感資訊在通道上被第三方竊聽而洩漏，將明文通過加密變成密文，如果第三方無法解密的話，就算他獲得密文也無能為力；認證是指通訊雙方為了確認對方是值得信任的訊息傳送或接受方，而不是使用假身份的騙子，採取的確認身份的方式。只有同時進行了加密和認真才能保證通訊的安全，因此在SSL通訊協議中這兩者都被應。

因此，這三者的關係已經十分清楚了：https依賴一種實現方式，目前通用的是SSL，數字證書是支援這種安全通訊的檔案。另外有SSL衍生出TLS和WTLS，前者是IEFT將SSL標準化之後產生的（TSL1.0），與SSL差別很小，後者是用於無線環境下的TSL。

如何加密

常用的加密演算法：

• 對稱密碼演算法：是指加密和解密使用相同的金鑰，典型的有DES、RC5、IDEA（分組加密），RC4（序列加密）；
• 非對稱密碼演算法：又稱為公鑰加密演算法，是指加密和解密使用不同的金鑰（公開的公鑰用於加密，私有的私鑰用於解密）。比如A傳送，B接收，A想確保訊息只有B看到，需要B生成一對公私鑰，並拿到B的公鑰。於是A用這個公鑰加密訊息，B收到密文後用自己的與之匹配的私鑰解密即可。反過來也可以用私鑰加密公鑰解密。也就是說對於給定的公鑰有且只有與之匹配的私鑰可以解密，對於給定的私鑰，有且只有與之匹配的公鑰可以解密。典型的演算法有RSA，DSA，DH；
• 雜湊演算法：雜湊變換是指把檔案內容通過某種公開的演算法，變成固定長度的值（雜湊值），這個過程可以使用金鑰也可以不使用。這種雜湊變換是不可逆的，也就是說不能從雜湊值變成原文。因此，雜湊變換通常用於驗證原文是否被篡改。典型的演算法有：MD5，SHA，Base64，CRC等。

在雜湊演算法（也稱摘要演算法）中，有兩個概念，強無碰撞和弱無碰撞。弱無碰撞是對給定的訊息x，就是對你想偽造的明文，進行運算得出相同的摘要資訊。也就是說你可以控制明文的內容。強無碰撞是指能找到相同的摘要資訊，但偽造的明文是什麼並不知道。

SSL的加密過程：

需要注意的是非對稱加解密演算法的效率要比對稱加解密要低的多。所以SSL在握手過程中使用非對稱密碼演算法來協商金鑰，實際使用對稱加解密的方法對http內容加密傳輸。下面是對這一過程的形象的比喻：

假設A與B通訊，A是SSL客戶端，B是SSL伺服器端，加密後的訊息放在方括號[]裡，以突出明文訊息的區別。雙方的處理動作的說明用圓括號（）括起。

• A：我想和你安全的通話，我這裡的對稱加密演算法有DES,RC5,金鑰交換演算法有RSA和DH，摘要演算法有MD5和SHA。
• B：我們用DES－RSA－SHA這對組合好了。這是我的證書，裡面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發給A）。
• A：（檢視證書上B的名字是否無誤，並通過手頭早已有的數字的證書驗證了B的證書的真實性，如果其中一項有誤，發出警告並斷開連線，這一步保證了B的公鑰的真實性）
• （產生一份祕密訊息，這份祕密訊息處理後將用作對稱加密金鑰，加密初始化向量和hmac的金鑰。將這份祕密訊息-協議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的訊息。由於用了B的公鑰，保證了第三方無法竊聽）
• 我生成了一份祕密訊息，並用你的公鑰加密了，給你（把ClientKeyExchange發給B）
• 注意，下面我就要用加密的辦法給你發訊息了！
• （將祕密訊息進行處理，生成加密金鑰，加密初始化向量和hmac的金鑰）
• [我說完了]
• B：（用自己的私鑰將ClientKeyExchange中的祕密訊息解密出來，然後將祕密訊息進行處理，生成加密金鑰，加密初始化向量和hmac的金鑰，這時雙方已經安全的協商出一套加密辦法了）
• 注意，我也要開始用加密的辦法給你發訊息了！
• [我說完了]
• A: [我的祕密是...]
• B: [其它人不會聽到的...]

從上面的過程可以看到，SSL協議是如何用非對稱密碼演算法來協商金鑰，並使用金鑰加密明文並傳輸的。還有以下幾點補充：

1. 1.B使用數字證書把自己的公鑰和其他資訊包裝起來發送A，A驗證B的身份，下面會談到A是如何驗證的。
2. 2.A生成了了加密金鑰、加密初始化向量和hmac金鑰是雙方用來將明文摘要和加密的。加密初始化向量和hmac金鑰首先被用來對明文摘要（防止明文被篡改），然後這個摘要和明文放在一起用加密金鑰加密後傳輸。
3. 3.由於只有B有私鑰，所以只有B可以解密ClientKeyExchange訊息，並獲得之後的通訊金鑰。
4. 4.事實上，上述過程B沒有驗證A的身份，如果需要的話，SSL也是支援的，此時A也需要提供自己的證書，這裡就不展開了。在設定IIS的SSL Require的時候，通常預設都是igore client certification的。

數字證書

由上面的討論可以知道，數字證書在ssl傳輸過程中扮演身份認證和金鑰分發的功能。究竟什麼是數字證書呢？

簡而言之數字證書是一種網路上證明持有者身份的檔案，同時還包含有公鑰。一方面，既然是檔案那麼就有可能”偽造”，因此，證書的真偽就需要一個驗證方式；另一方面，驗證方需要認同這種驗證方式。

對於第一個需求，目前的解決方案是，證書可以由國際上公認的證書機構頒發，這些機構是公認的信任機構，一些驗證證書的客戶端應用程式：比如瀏覽器，郵件客戶端等，對於這些機構頒發的證書完全信任。當然想要請這些機構頒發證書可是要付”到了斯”的，通常在windows部署系統的時候會讓客戶端安裝我們自己伺服器的根證書，這樣客戶端同樣可以信任我們的證書。

對於第二個需求，客戶端程式通常通過維護一個”根受信任機構列表”，當收到一個證書時，檢視這個證書是否是該列表中的機構頒發的，如果是則這個證書是可信任的，否則就不信任。

證書的信任

因此作為一個https的站點需要與一個證書繫結，無論如何，證書總是需要一個機構頒發的，這個機構可以是國際公認的證書機構，也可以是任何一臺安裝有證書服務的計算機。客戶端是否能夠信任這個站點的證書，首先取決於客戶端程式是否匯入了證書頒發者的根證書。下圖說明了這個流程：

有時一個證書機構可能授權另一個證書機構頒發證書，這樣就出現了證書鏈。

IE瀏覽器在驗證證書的時候主要從下面三個方面考察，只要有任何一個不滿足都將給出警告：

• 證書的頒發者是否在”根受信任的證書頒發機構列表”中
• 證書是否過期
• 證書的持有者是否和訪問的網站一致

另外，瀏覽器還會定期檢視證書頒發者公佈的”證書吊銷列表”，如果某個證書雖然符合上述條件，但是被它的頒發者在”證書吊銷列表”中列出，那麼也將給出警告。每個證書的CRL Distribution Point欄位顯示了檢視這個列表的url。儘管如此，windows對於這個列表是”不敏感”的，也就是說windows的api會快取這個列表，直到設定的快取過期才會再從CRL Distribution Point中下載新的列表。目前，只能通過在證書頒發服務端儘量小的設定這個有效期（最小1天），來儘量使windows的客戶端”敏感”些。

要實現ssl加密通訊，必須要雙方協商金鑰，ssl採用的是非對稱加密來實現金鑰交換。在這個過程中，服務端向客戶端傳送的公鑰就包含在證書中。客戶端將自己生成的金鑰用公鑰加密，服務端用於公鑰匹配的私鑰解密。因此，可以想到的是，服務端儲存了一個私鑰，並且也與https的站點綁定了。