【計算機網絡】ssl雙向認證和單向認證原理

有朋友在搞一個項目，週末有聊到一些安全性的東西，很天然會想起https，但https究竟如何實施，其原理又是什麼？

 

    基於ssl，通常的應用都是單向認證，若是應用場景要求對客戶來源作驗證也能夠實現成雙向認證。

    網上google一下：

 

    爲了便於更好的認識和理解 SSL 協議，這裏着重介紹 SSL 協議的握手協議。SSL 協議既用到了公鑰加密技術又用到了對稱加密技術，對稱加密技術雖然比公鑰加密技術的速度快，但是公鑰加密技術提供了更好的身份認證技術。SSL 的握手協議很是有效的讓客戶和服務器之間完成相互之間的身份認證，其主要過程以下：
　　① 客戶端的瀏覽器向服務器傳送客戶端 SSL 協議的版本號，加密算法的種類，產生的隨機數，以及其餘服務器和客戶端之間通信所須要的各類信息。
　　② 服務器向客戶端傳送 SSL 協議的版本號，加密算法的種類，隨機數以及其餘相關信息，同時服務器還將向客戶端傳送本身的證書。
　　③ 客戶利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過時，發行服務器證書的 CA 是否可靠，發行者證書的公鑰可否正確解開服務器證書的「發行者的數字簽名」，服務器證書上的域名是否和服務器的實際域名相匹配。若是合法性驗證沒有經過， 通信將斷開；若是合法性驗證經過，將繼續進行第四步。
　　④ 用戶端隨機產生一個用於後面通信的「對稱密碼」，而後用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中得到）對其加密，而後將加密後的「預主密碼」傳給服務器。 
　　⑤ 若是服務器要求客戶的身份認證（在握手過程當中爲可選），用戶能夠創建一個隨機數而後對其進行數據簽名，將這個含有簽名的隨機數和客戶本身的證書以及加密過的「預主密碼」一塊兒傳給服務器。 
　　⑥ 若是服務器要求客戶的身份認證，服務器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，爲客戶提供證書的 CA 是否可靠，發行 CA 的公鑰可否正確解開客戶證書的發行 CA 的數字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗若是沒有經過，通信馬上中斷；若是驗證經過，服務器將用本身的私鑰解開加密的「預主密 碼」，而後執行一系列步驟來產生主通信密碼（客戶端也將經過一樣的方法產生相同的主通信密碼）。
　　⑦ 服務器和客戶端用相同的主密碼即「通話密碼」，一個對稱密鑰用於 SSL 協議的安全數據通信的加解密通信。同時在 SSL 通信過程當中還要完成數據通信的完整性，防止數據通信中的任何變化。 
　　⑧ 客戶端向服務器端發出信息，指明後面的數據通信將使用的步驟⑦中的主密碼爲對稱密鑰，同時通知服務器客戶端的握手過程結束。
　　⑨ 服務器向客戶端發出信息，指明後面的數據通信將使用的步驟⑦中的主密碼爲對稱密鑰，同時通知客戶端服務器端的握手過程結束。
　　⑩ SSL 的握手部分結束，SSL 安全通道的數據通信開始，客戶和服務器開始使用相同的對稱密鑰進行數據通信，同時進行通信完整性的檢驗。

　　雙向認證 SSL 協議的具體過程
　　① 瀏覽器發送一個鏈接請求給安全服務器。 
　　② 服務器將本身的證書，以及同證書相關的信息發送給客戶瀏覽器。 
　　③ 客戶瀏覽器檢查服務器送過來的證書是不是由本身信賴的 CA 中心所簽發的。若是是，就繼續執行協議；若是不是，客戶瀏覽器就給客戶一個警告消息：警告客戶這個證書不是能夠信賴的，詢問客戶是否須要繼續。
　　④ 接着客戶瀏覽器比較證書裏的消息，例如域名和公鑰，與服務器剛剛發送的相關消息是否一致，若是是一致的，客戶瀏覽器承認這個服務器的合法身份。 
　　⑤ 服務器要求客戶發送客戶本身的證書。收到後，服務器驗證客戶的證書，若是沒有經過驗證，拒絕鏈接；若是經過驗證，服務器得到用戶的公鑰。 
　　⑥ 客戶瀏覽器告訴服務器本身所可以支持的通信對稱密碼方案。
　　⑦ 服務器從客戶發送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公鑰加過密後通知瀏覽器。 
　　⑧ 瀏覽器針對這個密碼方案，選擇一個通話密鑰，接着用服務器的公鑰加過密後發送給服務器。
　　⑨ 服務器接收到瀏覽器送過來的消息，用本身的私鑰解密，得到通話密鑰。 
　　⑩ 服務器、瀏覽器接下來的通信都是用對稱密碼方案，對稱密鑰是加過密的。 
　　上面所述的是雙向認證 SSL 協議的具體通信過程，這種狀況要求服務器和用戶雙方都有證書。單向認證 SSL 協議不須要客戶擁有 CA 證書，具體的過程相對於上面的步驟，只需將服務器端驗證客戶證書的過程去掉，以及在協商對稱密碼方案，對稱通話密鑰時，服務器發送給客戶的是沒有加過密的 （這並不影響 SSL 過程的安全性）密碼方案。 這樣，雙方具體的通信內容，就是加過密的數據，若是有第三方攻擊，得到的只是加密的數據，第三方要得到有用的信息，就須要對加密的數據進行解密，這時候的 安全就依賴於密碼方案的安全。而幸運的是，目前所用的密碼方案，只要通信密鑰長度足夠的長，就足夠的安全。這也是咱們強調要求使用 128 位加密通信的緣由。

 

     通常web應用都是採用單向認證的，緣由很簡單，用戶數目普遍，且無需作在通信層作用戶身份驗證，通常都在應用邏輯層來保證用戶的合法登入。

     但若是是企業應用對接，狀況就不同，可能會要求對client（相對而言）作身份驗證。這時須要作雙向認證。

 

 

     用java簡單試了一下如何搭建一個https站點， tomcat 6 https 單向認證，網上google一下，例子不少，這裏就不貼出來了，而後瀏覽器測試。

     

     繼續瀏覽此網站，能夠正式訪問。 服務器搭建，應該是沒問題了。 可是這個警告是怎麼回事？ 仍是應該再瞭解一下的。

     這個證書是本身作的，用jdk的工具keytool 很容易能夠搞出一個(不懂請google)， 瀏覽器很明顯不信任這個服務器發過來的證書(公鑰)。 這裏還須要瞭解一下，瀏覽器是如何信任一個證書的。

     1 瀏覽器 https: 訪問一個網站

     2 網站服務器會發給瀏覽器 一個證書

     3 瀏覽器驗證證書有效性：

        3.1 證書與訪問域名是否匹配，證書是否還在已經有效期內。

        3.2 證書的路徑。

              如圖：

              
              
              證書是否由 瀏覽器(客戶端) 所信任的機構認證。 若是在，則經過，不然給用戶本身選擇。

              本身折騰的證書沒給第三方認證，確定彈warn， 因而乎出現了第一個圖。

              
              

    有了以上的基礎知識，網上再找一下，本身寫一個簡單的java程序，要實現，https順利訪問（無warn）

    easy， 把這個證書設置爲本身信任的就ok.

    經過jdk的keytool 產生對應證書，並導入到truststore，生成一個文件(該文件存儲了信任的證書)。在java程序中指定truststore對應的文件。

 

public static void main(String[] args) throws Exception {  
        System.setProperty("javax.net.ssl.trustStore", "C:/Java/Tomcat/conf/client.truststore" );  
        new testhttpspostdata().testIt();  
    }  
  
    private void testIt() {  
        String postdata="data=testpostdata";  
        String https_url = "https://localhost:8443/examples/jsp/getpost.jsp";  
        URL url;  
        try {  
  
            url = new URL(https_url);  
            HttpsURLConnection con = (HttpsURLConnection) url.openConnection();  
            System.out.println("ready post data");  
            con.setDoOutput(true);  
            con.setRequestMethod("POST");  
            con.getOutputStream().write(postdata.getBytes());  
            con.getOutputStream().flush();  
            con.getOutputStream().close();  
           
            // dumpl all cert info  
            print_https_cert(con);  
            //  
            //System.out.println( con.getLocalPrincipal().toString() );  
            System.out.println( con.getPeerPrincipal().toString() );  
                         
            // dump all the content  
            print_content(con);                   
            // dump all the content  
            print_content(con);  
  
        } catch (MalformedURLException e) {  
            e.printStackTrace();  
        } catch (IOException e) {  
            e.printStackTrace();  
        }  
    }  

 

    一個週末，學了一些東西，值得mark一下。

 

    ps: 有一篇好文章，有助於深刻理解。

    http://www.williamlong.info/archives/2058.html