轉: https 單向雙向認證說明_數字證書, 數字簽名, SSL(TLS) , SASL

轉自： http://www.cnblogs.com/mailingfeng/archive/2012/07/18/2597392.html

 

由於項目中要用到TLS +　SASL 來作安全認證層. 因此看了一些網上的資料, 這裏作一個總結.

 1. 首先推薦幾個文章:

 數字證書: http://www.cnblogs.com/hyddd/archive/2009/01/07/1371292.html 

 數字證書和SSL: http://www.2cto.com/Article/201203/121534.html 

 數字簽名: http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html 

 

 2. 數字證書   

 

     2.1 數字證書和CA的簡介

    數字證書是一種權威性的電子文檔。它提供了一種在Internet上驗證您身份的方式，其做用相似於司機的駕駛執照或平常生活中的身份證。它是由一個由權威機構----CA證書受權(Certificate Authority)中心發行的，人們能夠在互聯網交往中用它來識別對方的身份。固然在數字證書認證的過程當中，證書認證中心（CA）做爲權威的、公正的、 可信賴的第三方，其做用是相當重要的。

    CA認證中心是負責簽發，管理，認證數字證書的機構，是基於國際互聯網平臺創建的一個公正，權威，可信賴的第三方組織機構。

 

    全球有不少個CA認證中心, 根CA認證中心表明權威, 它能夠分派數字證書(包括下級CA數字證書 , 用戶數字證書). 

    CA認證中心的關係圖:

       

    2.2 數字證書的組成

     數字證書由CA派發, 包含F證書內容(明文寫明證書的一些信息,包括派發單位,證書全部人等),  A加密算法 , F'數字簽名(派發該證書的CA的數字簽名) , 全部者的公鑰

     這裏要說一下數字簽名的產生過程:

      例如這裏由派發證書的CA生成的數字簽名, 首先, 對證書內容(F)進行hash算法生成摘要, 使用CA本身的私鑰進行RSA加密(或者其餘一種非對稱加密算法A) , 就生成出了數字簽名(F').

    2.3 數字證書的驗證原理

      數字證書經過F , A , F' 三項來驗證證書的真實性和有效性.

      首先咱們要知道下面幾個特色:

      1.數字證書機制默認, 全部者的私鑰是安全的 

      2.根CA的公鑰默認認爲是合法的, 且是爲大多數瀏覽器所知的, 甚至內嵌的. 例如firefox的證書管理器中就內嵌了已知的根CA的公鑰.

      驗證數字證書(包含驗證'證書'和'持有人'的真實有效性)的過程: (*******)

       1. 使用派發證書的CA的公鑰(能夠向CA請求)來對F'解密獲得h1 (hash值)

       2. 對證書內容F進行hash算法獲得h2

       3. 若是h1 == h2 , 那麼證書是真實有效的.

       4. 當證書被證實是真實有效的, 那麼咱們就能夠認爲數字證書中包含的公鑰, 是證書全部人(申請該證書的用戶或者機構)的真實公鑰.

           (從這一點咱們能夠知道, 其實數字證書, 就是爲了保證公鑰的正確性而產生的)

       5. 用此公鑰加密一段信息發送給證書的持有者，若是持有者能發送回（能夠是被私鑰加密，也能夠是明文，沒有關係）被加密的這段信息的話就證實該持有者擁有該證書對應的私鑰，也就是說，該持有者就是該證書的全部者。

 

 

      以上過程(前3步)能夠用下圖說明:

        

 

 

      因爲一個數字證書基於上層的數字證書做驗證，那上層的數字證書又是否合法呢？？這就會出現一直遞歸上去的現象，事實也是這樣的，驗證一個證書是否合法，須要驗證到他的最頂層的根證書是否合法！從其餘的文章弄來的這幅圖很好地表達了這個思想： 　

 

      

 

 

 

   2.4 數字證書組成信息

 

　　1.Certificate(證書)：

　　 (1).Common Name(證書全部人姓名，簡稱CN，其實就是證書的名字，如第一幅圖看到的：ABA.ECOMRoot....)

　　 (2).Version(版本，如今通常是V3了)

　　 (3).Issuer(發證機關)

　　 (4).Validity(有效日期)

　　 (5).Subject(證書信息，你會發現它和Issuer裏面的內容是同樣的)

　　 (6).Subject's Public Key Info(證書全部人公鑰，剛纔所說的公鑰就是這個!)

　　 (7).Extension(擴展信息)

　　 (8).Certificate Signature Algorithm(公鑰加密算法)、

 　　 以上這幾項就是上面所說的證書內容(F)。　

　　2.Certificate Signature Algorithm:

　　  這是描述證書的加密算法，就是上所說的加密算法(A)，看它的Fireld Value，通常會寫：PKCS #1 SHA-1 With RSA Encryption

　　3.Certificate Signature Value:

　　　這記錄的是證書被加密後的結果，至關於上面說講的F'。

 

 

 

 

---

 

3. ssl(tls)  - 傳輸層安全協議

    經過第二節的數字證書說明, 相信你們均可以大體知道數字證書的做用(保證公鑰確實屬於證書全部人)以及驗證的過程.

那麼下面就能夠來看SSL如何結合數字證書進行工做:

    3.1 爲什麼引入SSL

       咱們知道, 傳統的加密技術有2個類型, 一個是對稱加密(例如DES) , 另外一個是非對稱加密(例如RSA). 

其中非對稱加密中有私鑰和公鑰的概念, 十分適合驗證特定對象的真實性和惟一性. 但非對稱加密算法比較複雜, 速度緩慢 , 也很消耗資源, 所以就不適合大數據量的加密.

而對稱加密因爲兩端同用一組密碼,加密和解密算法比較簡單, 適合大數據量加密.

      SSL全稱是 Secure Sockets Layer，它是一種間於傳輸層（好比TCP/IP）和應用層（好比HTTP）的協議. 它經過"握手協議"和"傳輸協議"來解決傳輸安全的問題.

握手協議是基於非對稱加密的，而傳輸協議是基於對稱加密的。根據不一樣的應用，SSL對證書的要求也是不同的，能夠是單方認證（好比HTTP, FTP），也能夠是雙方認證（好比網上銀行）。一般狀況下，服務器端的證書是必定要具有的，客戶端的證書不是必須的。

    3.2 SSL的握手和傳輸 

下面兩張圖片顯示了SSL握手的過程。

          

                          圖3.2.1  SSL握手，單方服務器認證 
                   

 

                             圖3.2.2  SSL握手，雙方認證

 

    

       傳輸過程: 在通訊雙方協商出一個對稱密鑰之後，他們用這個密鑰來加密傳輸的數據。同時爲每一個消息生成時間戳，用此密鑰爲消息和相應的時間戳生成消息認證碼（MAC）。也就是說，每次發送的內容包括
             Encrypt(message) + MAC(message + timestamp)

 

    這麼作有幾個好處： 
       1.    防止消息的篡改 
        所謂消息篡改就是有第三者插在通訊雙方之間，篡改往來的消息。因爲消息是加密的，第三者不能得到消息的內容，可是他能夠閉着眼睛瞎改。若是沒有MAC的話，接受者就沒法判斷此  消息是否被篡改過。 
       2.    防止消息重放 
       消息的重放是隻第三者記錄下通訊雙方的每一次發送的消息，雖然他不能得到消息的內容。可是它能夠經過從新發送客戶端或者服務端的信息來把本身裝成是客戶端或者服務端。若是在MAC裏面加上了時間戳，消息接收方驗證時間戳就能夠阻止消息的重放攻擊。 
SSL的基本思想是用非對稱加密來創建連接（握手階段），用對稱加密來傳輸數據（傳輸階段）。這樣既保證了密鑰分發的安全，也保證了通訊的效率。

 

 

---

 

4. SASL - 簡單認證和安全層 

     SASL是一種用來擴充C/S模式驗證能力的機制認證機制,  全稱Simple Authentication and Security Layer.

     當你設定sasl時，你必須決定兩件事；一是用於交換「標識信 息」（或稱身份證書）的驗證機制；一是決定標識信息存儲方法的驗證架構。

     sasl驗證機制規範client與server之間的應答過程以及傳輸內容的編碼方法，sasl驗證架構決定服務器自己如何存儲客戶端的身份證書以及如何覈驗客戶端提供的密碼。

     若是客戶端能成功經過驗證，服務器端就能肯定用戶的身份， 並藉此決定用戶具備怎樣的權限。

 比較常見的機制；

4.1 plain(較經常使用)

 

   plain是最簡單的機制，但同時也是最危險的機制，由於身份證書（登陸名稱與密碼）是以base64字符串格式經過網絡，沒有任何加密保護措施。所以，使用plain機制時，你可能會想要結合tls。

4.2 login

   login不是其正式支持的機制，但某些舊版的mua使用這種機制，因此cyrus sasl讓你可選擇其是否支持login機制。若是你的用戶仍在使用這類老掉牙的mua，你必須在編譯sasl函數庫時，指定要包含login的支持。 login的證書交換過程相似plain。

4.3 otp

otp是一種使用「單次密碼」的驗證機制。此機制不提供任何加密保護，由於不必－－每一個密碼都只能使用一次，每次聯機都要改用新密碼。smto client必須可以產生otp證書。

4.4 digest-md5(較經常使用)

   使用這種機制時，client與server共享同一個隱性密碼，並且此密碼不經過網絡傳輸。驗證過程是從服務器先提出challenge（質詢）開始， 客戶端使用此challenge與隱性密碼計算出一個response（應答）。不一樣的challenge，不可能計算出相同的response；任何擁 有secret password的一方，均可以用相同的challenge算出相同的response。所以，服務器只要比較客戶端返回的response是否與本身算 出的response相同，就能夠知道客戶端所擁有的密碼是否正確。因爲真正的密碼並無經過網絡，因此不怕網絡監測。

4.5 kerberos

   kerberos是一種網絡型驗證協議。除非你的網絡已經使用kerberos，不然你應該用不到kerberos機制；相對的，若是你的網絡已經架設了kerberos驗證中心，sasl就能完美的將smtp驗證整合進現有的體系。

4.6 anonymous

   anonymous機制對smtp沒有意義，由於smtp驗證的用意在於限制轉發服務的使用對象，而不是爲了造成open relay，sasl之因此提供這種機制，主要是爲了支持其餘協議。
當 客戶端連接到一個支持sasl的郵件服務器時，服務器會以優先級列出可用的機制供客戶端選擇。若是客戶端也支持多鍾機制，則當第一種機制驗證失敗時，客戶 端可能會繼續嘗試第二種機制，直到經過驗證或是全部機制都失敗爲止。若是雙方在一開始就沒法協調出共同的機制，驗證過程就算失敗。
一旦雙方在使用哪一種機制上達成共識，就開始進行驗證過程。實際的交互過程隨機制而定，但一般包含一次或屢次應答過程。驗證協議自己也規定了應答內容的編碼格式。

 

 

  5. 總結 

       數字證書, 是級聯認證派發的, 最上層是根CA認證中心. 數字證書的根本做用, 是爲了保證全部人公鑰的安全性和真實性. 大體認證過程是: 經過CA的公鑰來解出該CA所派發的證書裏面所包含的公鑰(用戶或者機構的). 並經過該公鑰來驗證證書持有人的真實性. (由於持有人並不必定是證書全部人)

 

       經過上面對SSL的分析，咱們能夠看到，SSL並不能阻止別人得到你傳輸的數據，可是因爲你傳輸的數據都是加密過的，別人拿到了毫無用處，同樣能夠保護信 息的安全。還有一點須要強調一下，SSL並不依賴於TCP，它能夠創建在任何可靠的傳輸層協議（好比TCP）之上。也就是說SSL是不能創建在UDP之上 的。這是顯然的，若是傳輸都不可靠，偶爾丟兩個包或者包的順序換一換的話，怎麼保證安全呢？

       SASL是提供一種用戶身份認證機制, 你能夠簡單認爲是用來認證用戶的帳號/密碼是否運行進入系統或者使用系統的服務. 通常較長使用digest-md5, 該種機制下, 密碼能夠不用在網絡上傳輸, 也就不用怕密碼被竊聽.