淺談https\ssl\數位憑證

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

名詞解釋

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

• https：在http(超文字傳輸通訊協定 (HTTP))基礎上提出的一種安全的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內容加密傳輸。下面是對這一過程的形象的比喻（摘自http://blog.chinaunix.net/u2/82806/showart_1341720.html）：

假設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.B使用數位憑證把自己的公開金鑰和其他資訊封裝起來發送A，A驗證B的身份，下面會談到A是如何驗證的。

2.A產生了了加密金鑰、加密初始化向量和hmac密鑰是雙方用來將明文摘要和加密的。加密初始化向量和hmac密鑰首先被用來對明文摘要（防止明文被篡改），然後這個摘要和明文放在一起用加密金鑰加密後傳輸。

3.由於只有B有私密金鑰，所以只有B可以解密ClientKeyExchange訊息，並獲得之後的通訊密鑰。

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的用戶端“敏感”些。具體設定方法為（winserver2003）：

進入管理員工具->認證機構->右擊某個認證服務下的“撤銷憑證”目錄->屬性：

按圖中的設定，將CRL發布周期改為1天。

 

IIS中部署基於數位憑證的https網站

在IIS6中構建一個https網站需要如下幾個關鍵步驟：

• 安裝CA認證服務：此步驟不是必要的。如果網路中還沒有那台主機安裝過CA認證服務，或者確實需要建個新的CA認證服務，那麼就需要在某台主機上安裝CA認證服務。這是windows內建的功能，預設不安裝。如果裝了，就意味這這台主機具有頒發認證的能力，只要安裝有這台主機的根憑證的用戶端會信任這台主機頒發的認證。在windows server 2003中的安裝步驟，詳見http://jeffyyko.blog.51cto.com/28563/140518
• 向CA認證服務提交認證申請，並將獲得的認證跟網站綁定：詳見http://jeffyyko.blog.51cto.com/28563/141322
• 要求用戶端匯入根憑證，以使用戶端信任該認證：詳見http://jeffyyko.blog.51cto.com/28563/142280

 

認證與密鑰

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

綁定私密金鑰和不綁定私密金鑰的認證

從認證持有人是否擁有認證的私密金鑰，可以把認證分為兩種：如，當我們的本機擁有認證的私密金鑰時如左圖，否則如右圖：

可以看到，左表徵圖識了“你擁有與該認證相匹配的私密金鑰”，而右圖沒有。對於需要與https網站綁定的認證必須是左圖的形式，分發給用戶端安裝的應該是右圖的形式，而不該是左圖的形式。

 

對於左圖的認證可以將還有匯出含有私密金鑰的.pfx格式，用於備份認證或者分發，步驟如下：

 

選擇同時匯出私密金鑰

 

這裡輸入的密碼在重新安裝的時候要輸入，所以要comfirm一下。

選擇一個檔案存放，尾碼自動為.pfx

 

 

對於普通的認證，不能匯出含有私密金鑰的.pfx形式，只能匯出下面三種格式：

 

總結

本文總結了https/ssl/數位憑證的相關基本概念，闡述了ssl協議的實現原理，闡述了數位憑證在其中扮演的角色。

勞動果實，轉載請註明出處：http://www.cnblogs.com/P_Chou/archive/2010/12/27/https-ssl-certification.html