Java安全通訊:HTTPS與SSL

1. HTTPS概念 html

        1)簡介    java

        HTTPS(全稱:Hypertext Transfer Protocol over Secure Socket Layer),是以安全爲目標的HTTP通道,簡單講是HTTP的安全版。即HTTP下加入SSL層,HTTPS的安全基礎是SSL,所以加密的詳細內容就須要SSL。這個系統的最初研發由網景公司進行,提供了身份驗證與加密通信方法,如今它被普遍用於萬維網上安全敏感的通信,例如交易支付方面。 web

      2)HTTPS和HTTP的區別 算法

  a. https協議須要到ca申請證書,通常免費證書不多,須要交費。 瀏覽器

  b. http是超文本傳輸協議,信息是明文傳輸;https 則是具備安全性的ssl加密傳輸協議。 tomcat

  c. http和https使用的是徹底不一樣的鏈接方式,用的端口也不同,前者是80,後者是443。 安全

d. http的鏈接很簡單,是無狀態的;HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,比http協議安全。 服務器

      3)HTTPS的做用 網絡

      它的主要做用能夠分爲兩種:一種是創建一個信息安全通道,來保證數據傳輸的安全;另外一種就是確認網站的真實性。 dom

  a. 通常意義上的https,就是服務器有一個證書。主要目的是保證服務器就是他聲稱的服務器,這個跟第一點同樣;服務端和客戶端之間的全部通信,都是加密的。

  b. 具體講,是客戶端產生一個對稱的密鑰,經過服務器的證書來交換密鑰,即通常意義上的握手過程。

  c. 接下來全部的信息往來就都是加密的。第三方即便截獲,也沒有任何意義,由於他沒有密鑰,固然篡改也就沒有什麼意義了。

  d.少量對客戶端有要求的狀況下,會要求客戶端也必須有一個證書。

這裏客戶端證書,其實就相似表示我的信息的時候,除了用戶名/密碼,還有一個CA 認證過的身份。由於我的證書通常來講是別人沒法模擬的,全部這樣可以更深的確認本身的身份。目前少數我的銀行的專業版是這種作法,具體證書多是拿U盤(即U盾)做爲一個備份的載體。

 

2.SSL簡介

  1)簡介

  SSL (Secure Socket Layer)爲Netscape所研發,用以保障在Internet上數據傳輸之安全,利用數據加密(Encryption)技術,可確保數據在網絡上之傳輸過程當中不會被截取及竊聽。它已被普遍地用於Web瀏覽器與服務器之間的身份認證和加密數據傳輸。SSL協議位於TCP/IP協議與各類應用層協議之間,爲數據通信提供安全支持。

  2)SSL提供的服務

  a.認證用戶和服務器,確保數據發送到正確的客戶機和服務器

  b.加密數據以防止數據中途被竊取

  c.維護數據的完整性,確保數據在傳輸過程當中不被改變。

  3) SSL協議的握手過程

  SSL 協議既用到了公鑰加密技術又用到了對稱加密技術,對稱加密技術雖然比公鑰加密技術的速度快,但是公鑰加密技術提供了更好的身份認證技術。SSL 的握手協議很是有效的讓客戶和服務器之間完成相互之間的身份認證,其主要過程以下:

  ①客戶端的瀏覽器向服務器傳送客戶端SSL 協議的版本號,加密算法的種類,產生的隨機數,以及其餘服務器和客戶端之間通信所須要的各類信息。

  ②服務器向客戶端傳送SSL 協議的版本號,加密算法的種類,隨機數以及其餘相關信息,同時服務器還將向客戶端傳送本身的證書。

  ③客戶利用服務器傳過來的信息驗證服務器的合法性,服務器的合法性包括:證書是否過時,發行服務器證書的CA 是否可靠,發行者證書的公鑰可否正確解開服務器證書的「發行者的數字簽名」,服務器證書上的域名是否和服務器的實際域名相匹配。若是合法性驗證沒有經過,通信將斷開;若是合法性驗證經過,將繼續進行第四步。

  ④用戶端隨機產生一個用於後面通信的「對稱密碼」,而後用服務器的公鑰(服務器的公鑰從步驟②中的服務器的證書中得到)對其加密,而後傳給服務器。

  ⑤服務器用私鑰解密「對稱密碼」(此處的公鑰和私鑰是相互關聯的,公鑰加密的數據只能用私鑰解密,私鑰只在服務器端保留。詳細請參看: http://zh.wikipedia.org/wiki/RSA%E7%AE%97%E6%B3%95),而後用其做爲服務器和客戶端的「通話密碼」加解密通信。同時在SSL 通信過程當中還要完成數據通信的完整性,防止數據通信中的任何變化。

  ⑥客戶端向服務器端發出信息,指明後面的數據通信將使用的步驟⑤中的主密碼爲對稱密鑰,同時通知服務器客戶端的握手過程結束。

  ⑦服務器向客戶端發出信息,指明後面的數據通信將使用的步驟⑤中的主密碼爲對稱密鑰,同時通知客戶端服務器端的握手過程結束。

  ⑧SSL 的握手部分結束,SSL 安全通道的數據通信開始,客戶和服務器開始使用相同的對稱密鑰進行數據通信,同時進行通信完整性的檢驗。

       

 

3.配置服務器端證書

  爲了能實施SSL,一個web服務器對每一個接受安全鏈接的外部接口(IP 地址)必需要有相應的證書(Certificate)。關於這個設計的理論是一個服務器必須提供某種合理的保證以證實這個服務器的主人就是你所認爲的那我的。這個證書要陳述與這個網站相關聯的公司,以及這個網站的全部者或系統管理員的一些基本聯繫信息。

  這個證書由全部人以密碼方式簽字,其餘人很是難僞造。對於進行電子商務(e-commerce)的網站,或其餘身份認證相當重要的任何商業交易,認證書要向你們所熟知的認證權威(Certificate Authority (CA))如VeriSign或Thawte來購買。這樣的證書可用電子技術證實屬實。實際上,認證權威單位會擔保它發出的認證書的真實性,若是你信任發出認證書的認證權威單位的話,你就能夠相信這個認證書是有效的。

  關於權威證書的申請,請參考:http://www.cnblogs.com/mikespook/archive/2004/12/22/80591.aspx

  在許多狀況下,認證並非真正令人擔心的事。系統管理員或許只想要保證被服務器傳送和接收的數據是祕密的,不會被鏈接線上的偷竊者盜竊到。慶幸的是,Java提供相對簡單的被稱爲keytool的命令行工具,能夠簡單地產生「本身簽名」的證書。本身簽名的證書只是用戶產生的證書,沒有正式在你們所熟知的認證權威那裏註冊過,所以不能確保它的真實性。但卻能保證數據傳輸的安全性。

  用Tomcat來配置SSL主要有下面這麼兩大步驟:

  1)生成證書

  a. 在命令行下執行:

  %Java_home%\bin\keytool -genkey -alias tomcat -keyalg RSA

  在此命令中,keytool是JDK自帶的產生證書的工具。把RSA運算法則做爲主要安全運算法則,這保證了與其它服務器和組件的兼容性。

這個命令會在用戶的home directory產生一個叫作" .keystore " 的新文件。在執行後,你首先被要求出示keystore密碼。Tomcat使用的默認密碼是" changeit "(全都是小寫字母),若是你願意,你能夠指定你本身的密碼。你還須要在server.xml配置文件裏指定本身的密碼,這在之後會有描述。

  b .你會被要求出示關於這個認證書的通常性信息,如公司,聯繫人名稱,等等。這些信息會顯示給那些試圖訪問你程序裏安全網頁的用戶,以確保這裏提供的信息與他們指望的相對應。

  c.你會被要求出示密鑰(key)密碼,也就是這個認證書所特有的密碼(與其它的儲存在同一個keystore文件裏的認證書不一樣)。你必須在這裏使用與keystore密碼相同的密碼。(目前,keytool會提示你按ENTER鍵會自動幫你作這些)。

  若是一切順利,你如今就擁有了一個能夠被你的服務器使用的有認證書的keystore文件。

  2) 配置tomcat

  第二個大步驟是把secure socket配置在$CATALINA_HOME/conf/server.xml文件裏。$CATALINA_HOME表明安裝Tomcat的目錄。一個例子是SSL鏈接器的元素被包括在和Tomcat一塊兒安裝的缺省server.xml文件裏。它看起來象是這樣:

$CATALINA_HOME/conf/server.xml

複製代碼
< -- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --> < !-- < Connector port="8443" minProcessors="5" maxProcessors="75" enableLookups="true" disableUploadTimeout="true" acceptCount="100" debug="0" scheme="https" secure="true"; clientAuth="false" sslProtocol="TLS"/> -->
複製代碼

  Connector元素自己,其默認形式是被註釋掉的(commented out),因此須要把它周圍的註釋標誌刪除掉。而後,能夠根據須要客戶化(本身設置)特定的屬性。通常須要增長一下keystoreFile和keystorePass兩個屬性,指定你存放證書的路徑(如:keystoreFile="C:/.keystore")和剛纔設置的密碼(如:keystorePass="123456")。關於其它各類選項的詳細信息,可查閱Server Configuration Reference。

  在完成這些配置更改後,必須象從新啓動Tomcat,而後你就能夠經過SSL訪問Tomcat支持的任何web應用程序。只不過指令須要像下面這樣:https://localhost:8443

 

4.客戶端代碼實現

  在Java中要訪問Https連接時,會用到一個關鍵類HttpsURLConnection;參見以下實現代碼:

複製代碼
// 建立URL對象  URL myURL = new URL("https://www.sun.com"); // 建立HttpsURLConnection對象,並設置其SSLSocketFactory對象  HttpsURLConnection httpsConn = (HttpsURLConnection) myURL.openConnection(); // 取得該鏈接的輸入流,以讀取響應內容  InputStreamReader insr = new InputStreamReader(httpsConn.getInputStream()); // 讀取服務器的響應內容並顯示  int respInt = insr.read(); while (respInt != -1) {
            System.out.print((char) respInt);
            respInt = insr.read();
        }
複製代碼

  在取得connection的時候和正常瀏覽器訪問同樣,仍然會驗證服務端的證書是否被信任(權威機構發行或者被權威機構簽名);若是服務端證書不被信任,則默認的實現就會有問題,通常來講,用SunJSSE會拋以下異常信息:

?
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building 
?
failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

  上面提到SunJSSE,JSSE(Java Secure Socket Extension)是實現Internet安全通訊的一系列包的集合。它是一個SSL和TLS的純Java實現,能夠透明地提供數據加密、服務器認證、信息完整性等功能,可使咱們像使用普通的套接字同樣使用JSSE創建的安全套接字。JSSE是一個開放的標準,不僅是Sun公司才能實現一個SunJSSE,事實上其餘公司有本身實現的JSSE,而後經過JCA就能夠在JVM中使用。

  關於JSSE的詳細信息參考官網Reference:http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html
  以及Java Security Guide:http://java.sun.com/j2se/1.5.0/docs/guide/security/

  在深刻了解JSSE以前,須要瞭解一個有關Java安全的概念:客戶端的TrustStore文件。客戶端的TrustStore文件中保存着被客戶端所信任的服務器的證書信息。客戶端在進行SSL鏈接時,JSSE將根據這個文件中的證書決定是否信任服務器端的證書。在SunJSSE中,有一個信任管理器類負責決定是否信任遠端的證書,這個類有以下的處理規則:
1)若系統屬性javax.net.sll.trustStore指定了TrustStore文件,那麼信任管理器就去jre安裝路徑下的lib/security/目錄中尋找並使用這個文件來檢查證書。
2)若該系統屬性沒有指定TrustStore文件,它就會去jre安裝路徑下尋找默認的TrustStore文件,這個文件的相對路徑爲:lib/security/jssecacerts
3)若jssecacerts不存在,可是cacerts存在(它隨J2SDK一塊兒發行,含有數量有限的可信任的基本證書),那麼這個默認的TrustStore文件就是lib/security/cacerts

  那遇到這種狀況,怎麼處理呢?有如下兩種方案:
  1)按照以上信任管理器的規則,將服務端的公鑰導入到jssecacerts,或者是在系統屬性中設置要加載的trustStore文件的路徑;證書導入能夠用以下命令:keytool -import -file src_cer_file –keystore dest_cer_store;至於證書能夠經過瀏覽器導出得到;
  2)、實現本身的證書信任管理器類,好比MyX509TrustManager,該類必須實現X509TrustManager接口中的三個method;而後在HttpsURLConnection中加載自定義的類,能夠參見以下兩個代碼片斷,其一爲自定義證書信任管理器,其二爲connect時的代碼:


複製代碼
package test; import java.io.FileInputStream; import java.security.KeyStore; import java.security.cert.CertificateException; import java.security.cert.X509Certificate; import javax.net.ssl.TrustManager; import javax.net.ssl.TrustManagerFactory; import javax.net.ssl.X509TrustManager; public class MyX509TrustManager implements X509TrustManager { /* * The default X509TrustManager returned by SunX509. We'll delegate * decisions to it, and fall back to the logic in this class if the * default X509TrustManager doesn't trust it. */ X509TrustManager sunJSSEX509TrustManager;
    MyX509TrustManager() throws Exception { // create a "default" JSSE X509TrustManager.  KeyStore ks = KeyStore.getInstance("JKS");
        ks.load(new FileInputStream("trustedCerts"),
            "passphrase".toCharArray());
        TrustManagerFactory tmf =
        TrustManagerFactory.getInstance("SunX509", "SunJSSE");
        tmf.init(ks);
        TrustManager tms [] = tmf.getTrustManagers(); /* * Iterate over the returned trustmanagers, look * for an instance of X509TrustManager. If found, * use that as our "default" trust manager. */ for (int i = 0; i < tms.length; i++) { if (tms[i] instanceof X509TrustManager) {
                sunJSSEX509TrustManager = (X509TrustManager) tms[i]; return;
            }
        } /* * Find some other way to initialize, or else we have to fail the * constructor. */ throw new Exception("Couldn't initialize");
    } /* * Delegate to the default trust manager. */ public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { try {
            sunJSSEX509TrustManager.checkClientTrusted(chain, authType);
        } catch (CertificateException excep) { // do any special handling here, or rethrow exception.  }
    } /* * Delegate to the default trust manager. */ public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { try {
            sunJSSEX509TrustManager.checkServerTrusted(chain, authType);
        } catch (CertificateException excep) { /* * Possibly pop up a dialog box asking whether to trust the * cert chain. */ }
    } /* * Merely pass this through. */ public X509Certificate[] getAcceptedIssuers() { return sunJSSEX509TrustManager.getAcceptedIssuers();
    }
} // 建立SSLContext對象,並使用咱們指定的信任管理器初始化  TrustManager[] tm = { new MyX509TrustManager() };
        SSLContext sslContext = SSLContext.getInstance("SSL", "SunJSSE");
        sslContext.init(null, tm, new java.security.SecureRandom()); // 從上述SSLContext對象中獲得SSLSocketFactory對象  SSLSocketFactory ssf = sslContext.getSocketFactory(); // 建立URL對象  URL myURL = new URL("https://ebanks.gdb.com.cn/sperbank/perbankLogin.jsp"); // 建立HttpsURLConnection對象,並設置其SSLSocketFactory對象  HttpsURLConnection httpsConn = (HttpsURLConnection) myURL.openConnection();
        httpsConn.setSSLSocketFactory(ssf); // 取得該鏈接的輸入流,以讀取響應內容  InputStreamReader insr = new InputStreamReader(httpsConn.getInputStream()); // 讀取服務器的響應內容並顯示  int respInt = insr.read(); while (respInt != -1) {
            System.out.print((char) respInt);
            respInt = insr.read();
        }
複製代碼

  對於以上兩種實現方式,各有各的優勢,第一種方式不會破壞JSSE的安全性,可是要手工導入證書,若是服務器不少,那每臺服務器的JRE都必須作相同的操做;第二種方式靈活性更高,可是要當心實現,不然可能會留下安全隱患;

 

  參考文獻:        

  http://baike.baidu.com/view/14121.htm

  http://zh.wikipedia.org/wiki/RSA%E7%AE%97%E6%B3%95

  http://blog.csdn.net/sfdev/article/details/2957240

  http://blog.csdn.net/cyberexp2008/article/details/6695691

相關文章
相關標籤/搜索