Java安全通訊：HTTPS與SSL

 

1. HTTPS概念

        1）簡介   

        HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。這個系統的最初研發由網景公司進行，提供了身分識別驗證與加密通訊方法，現在它被廣泛用於全球資訊網上安全敏感的通訊，例如交易支付方面。

      2）HTTPS和HTTP的區別

　　a. https協議需要到ca申請認證，一般免費認證很少，需要交費。

　　b. http是超文字傳輸通訊協定 (HTTP)，資訊是明文傳輸；https 則是具有安全性的ssl加密傳輸協議。

　　c. http和https使用的是完全不同的串連方式，用的連接埠也不一樣，前者是80，後者是443。

d. http的串連很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路通訊協定，比http協議安全。

      3）HTTPS的作用

      它的主要作用可以分為兩種：一種是建立一個資訊安全通道，來保證資料轉送的安全；另一種就是確認網站的真實性。

　　a． 一般意義上的https，就是伺服器有一個認證。主要目的是保證伺服器就是他聲稱的伺服器，這個跟第一點一樣；服務端和用戶端之間的所有通訊，都是加密的。

　　b. 具體講，是用戶端產生一個對稱的密鑰，通過伺服器的認證來交換密鑰，即一般意義上的握手過程。

　　c. 接下來所有的資訊往來就都是加密的。第三方即使截獲，也沒有任何意義，因為他沒有密鑰，當然篡改也就沒有什麼意義了。

　　d．少許對用戶端有要求的情況下，會要求用戶端也必須有一個認證。

這裡用戶端認證，其實就類似表示個人資訊的時候，除了使用者名稱/密碼，還有一個CA 認證過的身份。因為個人認證一般來說是別人無法類比的，所有這樣能夠更深的確認自己的身份。目前少數個人銀行的專業版是這種做法，具體認證可能是拿隨身碟（即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