HTTPS概念

1）簡介

        HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的[HTTP](http://baike.baidu.com/view/9472.htm)通道听盖，簡單講是HTTP的安全版皆看。即HTTP下加入SSL層货裹，HTTPS的安全基礎是SSL门粪，因此加密的詳細內容就需要SSL毛雇。這個系統的最初研發(fā)由網景公司進行灵疮，提供了身份驗證與加密[通訊](http://baike.baidu.com/view/20429.htm)方法震捣，現在它被廣泛用于[萬維網](http://baike.baidu.com/view/7833.htm)上安全敏感的通訊伍派，例如交易支付方面诉植。

2）HTTPS和HTTP的區(qū)別

• https協議需要到ca申請證書晾腔，一般免費證書很少，需要交費灼擂。
• http是超文本傳輸協議剔应，信息是明文傳輸峻贮；https 則是具有安全性的ssl加密傳輸協議。
• http和https使用的是完全不同的連接方式挂捻，用的端口也不一樣刻撒，前者是80声怔，后者是443
• http的連接很簡單醋火，是無狀態(tài)的狮荔；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸殖氏、身份認證的網絡協議，比http協議安全

3）HTTPS的作用

它的主要作用可以分為兩種：

• 一種是建立一個信息安全通道爵憎，來保證數據傳輸的安全宝鼓；
• 另一種就是確認網站的真實性愚铡。
  一般意義上的https沥寥，就是服務器有一個證書。主要目的是保證服務器就是他聲稱的服務器片橡，這個跟第一點一樣捧书；服務端和客戶端之間的所有通訊经瓷，都是加密的妈踊。具體講廊营，是客戶端產生一個對稱的密鑰露筒，通過服務器的證書來交換密鑰敌卓，即一般意義上的握手過程趟径。 接下來所有的信息往來就都是加密的。第三方即使截獲掌眠，也沒有任何意義蓝丙，因為他沒有密鑰渺尘，當然篡改也就沒有什么意義了鸥跟。少許對客戶端有要求的情況下盔沫，會要求客戶端也必須有一個證書。
  這里客戶端證書腋逆，其實就類似表示個人信息的時候惩歉，除了用戶名/密碼，還有一個CA 認證過的身份上遥。因為個人證書一般來說是別人無法模擬的粉楚，所有這樣能夠更深的確認自己的身份模软。目前少數個人銀行的專業(yè)版是這種做法燃异，具體證書可能是拿U盤（即U盾）作為一個備份的載體继蜡。

SSL簡介

1）簡介

SSL (Secure Socket Layer)為Netscape所研發(fā)稀并，用以保障在Internet上數據傳輸之安全，利用數據加密(Encryption)技術忘瓦，可確保數據在網絡上之傳輸過程中不會被截取及竊聽政冻。它已被廣泛地用于Web瀏覽器與服務器之間的身份認證和加密數據傳輸明场。SSL協議位于TCP/IP協議與各種應用層協議之間苦锨，為數據通訊提供安全支持。

2）SSL提供的服務

• 認證用戶和服務器拉庶，確保數據發(fā)送到正確的客戶機和服務器
• 加密數據以防止數據中途被竊取
• 維護數據的完整性氏仗，確保數據在傳輸過程中不被改變皆尔。

3) SSL協議的握手過程

SSL 協議既用到了公鑰加密技術又用到了對稱加密技術慷蠕，對稱加密技術雖然比公鑰加密技術的速度快食呻，可是公鑰加密技術提供了更好的身份認證技術仅胞。SSL 的握手協議非常有效的讓客戶和服務器之間完成相互之間的身份認證，其主要過程如下：
　∮笆蕖①客戶端的瀏覽器向服務器傳送客戶端SSL 協議的版本號，加密算法的種類讹开，產生的隨機數旦万，以及其他服務器和客戶端之間通訊所需要的各種信息。
　∩桶搿②服務器向客戶端傳送SSL 協議的版本號断箫，加密算法的種類仲义，隨機數以及其他相關信息，同時服務器還將向客戶端傳送自己的證書赵颅。
　〗让③客戶利用服務器傳過來的信息驗證服務器的合法性商蕴，服務器的合法性包括：證書是否過期绪商，發(fā)行服務器證書的CA 是否可靠辅鲸，發(fā)行者證書的公鑰能否正確解開服務器證書的“發(fā)行者的數字簽名”独悴，服務器證書上的域名是否和服務器的實際域名相匹配刻炒。如果合法性驗證沒有通過，通訊將斷開树瞭；如果合法性驗證通過晒喷，將繼續(xù)進行第四步凉敲。
　∷峦④用戶端隨機產生一個用于后面通訊的“對稱密碼”阻塑，然后用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中獲得）對其加密叮姑，然后傳給服務器。
　≡耪印⑤服務器用私鑰解密“對稱密碼”(此處的公鑰和私鑰是相互關聯的群嗤，公鑰加密的數據只能用私鑰解密，私鑰只在服務器端保留骇径。詳細請參看： http://zh.wikipedia.org/wiki/RSA%E7%AE%97%E6%B3%95)破衔，然后用其作為服務器和客戶端的“通話密碼”加解密通訊晰筛。同時在SSL 通訊過程中還要完成數據通訊的完整性读第，防止數據通訊中的任何變化怜瞒。
　“愫摺⑥客戶端向服務器端發(fā)出信息逝她，指明后面的數據通訊將使用的步驟⑤中的主密碼為對稱密鑰黔宛，同時通知服務器客戶端的握手過程結束臀晃。
　〗榻佟⑦服務器向客戶端發(fā)出信息座韵，指明后面的數據通訊將使用的步驟⑤中的主密碼為對稱密鑰踢京，同時通知客戶端服務器端的握手過程結束瓣距。
　〉竿琛⑧SSL 的握手部分結束逻杖，SSL 安全通道的數據通訊開始，客戶和服務器開始使用相同的對稱密鑰進行數據通訊荸百，同時進行通訊完整性的檢驗管搪。

配置服務器端證書

為了能實施SSL更鲁，一個web服務器對每個接受安全連接的外部接口(IP 地址)必須要有相應的證書(Certificate)澡为。關于這個設計的理論是一個服務器必須提供某種合理的保證以證明這個服務器的主人就是你所認為的那個人媒至。這個證書要陳述與這個網站相關聯的公司谷徙，以及這個網站的所有者或系統管理員的一些基本聯系信息拒啰。
　　這個證書由所有人以密碼方式簽字谋旦，其他人非常難偽造册着。對于進行電子商務(e-commerce)的網站甲捏，或其他身份認證至關重要的任何商業(yè)交易司顿，認證書要向大家所熟知的認證權威(Certificate Authority (CA))如VeriSign或Thawte來購買。這樣的證書可用電子技術證明屬實化漆。實際上猎提，認證權威單位會擔保它發(fā)出的認證書的真實性锨苏，如果你信任發(fā)出認證書的認證權威單位的話伞租，你就可以相信這個認證書是有效的葵诈。
　　關于權威證書的申請，請參考：http://www.cnblogs.com/mikespook/archive/2004/12/22/80591.aspx
　　在許多情況下理疙，認證并不是真正使人擔憂的事窖贤。系統管理員或許只想要保證被服務器傳送和接收的數據是秘密的贰锁，不會被連接線上的偷竊者盜竊到豌熄。慶幸的是锣险，Java提供相對簡單的被稱為keytool的命令行工具，可以簡單地產生“自己簽名”的證書囱持。自己簽名的證書只是用戶產生的證書纷妆，沒有正式在大家所熟知的認證權威那里注冊過掩幢，因此不能確保它的真實性。但卻能保證數據傳輸的安全性芯丧。

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

1)生成證書

• a. 在命令行下執(zhí)行：
  　　%Java_home%\bin\keytool -genkey -alias tomcat -keyalg RSA
  　　在此命令中缨恒，keytool是JDK自帶的產生證書的工具骗露。把RSA運算法則作為主要安全運算法則萧锉，這保證了與其它服務器和組件的兼容性述寡。
  這個命令會在用戶的home directory產生一個叫做" .keystore " 的新文件鲫凶。在執(zhí)行后螟炫，你首先被要求出示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

客戶端代碼實現

在Java中要訪問Https鏈接時井辜，會用到一個關鍵類HttpsURLConnection；參見如下實現代碼：

   // 創(chuàng)建URL對象
        URL myURL = new URL("https://www.sun.com");
 
        // 創(chuàng)建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的時候和正常瀏覽器訪問一樣，仍然會驗證服務端的證書是否被信任（權威機構發(fā)行或者被權威機構簽名）；如果服務端證書不被信任土砂，則默認的實現就會有問題序臂，一般來說，用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中燎孟，有一個信任管理器類負責決定是否信任遠端的證書烹俗，這個類有如下的處理規(guī)則：

• 1)若系統屬性javax.net.sll.trustStore指定了TrustStore文件蕉鸳，那么信任管理器就去jre安裝路徑下的lib/security/目錄中尋找并使用這個文件來檢查證書勉失。
• 2)若該系統屬性沒有指定TrustStore文件告匠，它就會去jre安裝路徑下尋找默認的TrustStore文件裸诽，這個文件的相對路徑為：lib/security/jssecacerts埂蕊。3)若jssecacerts不存在撇寞，但是cacerts存在（它隨J2SDK一起發(fā)行，含有數量有限的可信任的基本證書），那么這個默認的TrustStore文件就是lib/security/cacerts。

那遇到這種情況，怎么處理呢牺汤？有以下兩種方案：

• 1)按照以上信任管理器的規(guī)則溶其，將服務端的公鑰導入到jssecacerts契沫，或者是在系統屬性中設置要加載的trustStore文件的路徑嫡秕；證書導入可以用如下命令：keytool -import -file src_cer_file –keystore dest_cer_store调违；至于證書可以通過瀏覽器導出獲得泳挥；
• 2)、實現自己的證書信任管理器類，比如MyX509TrustManager，該類必須實現X509TrustManager接口中的三個method贞间；然后在HttpsURLConnection中加載自定義的類，可以參見如下兩個代碼片段吭从，其一為自定義證書信任管理器熔吗，其二為connect時的代碼：

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();

}
}
// 創(chuàng)建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();
// 創(chuàng)建URL對象
 URL myURL = new URL("https://ebanks.gdb.com.cn/sperbank/perbankLogin.jsp");
// 創(chuàng)建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();
}　

對于以上兩種實現方式颁褂，各有各的優(yōu)點糜值，第一種方式不會破壞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