SSL &WS-Security--Web Service安全保障

       今天早晨看了一下blog的留言，發(fā)現(xiàn)有位朋友給我留了言，提到了他正在研究SCA，同時也有些困惑，當(dāng)在異構(gòu)分布式環(huán)境的情況下，不論是否使用SCA規(guī)范來實現(xiàn)，都采用Web Service來完成面向服務(wù)的服務(wù)調(diào)用，覺得SCA沒有什么優(yōu)勢可言。其實這是一個誤解，SCA框架規(guī)范并不是一個具體的業(yè)務(wù)場景解決實施規(guī)范，它是一種框架結(jié)構(gòu)性規(guī)范，它的精華部分主要在于：一.將抽象和封裝由對象提升到了業(yè)務(wù)組件模塊 二.框架的可擴展性(也就是因為沒有實現(xiàn)的約束，才會能夠易于擴展)。當(dāng)然這兩點所帶來的好處那就是在這么一個精煉的框架核心規(guī)范下，不斷融入了外界的各種好的技術(shù)和理念，就好比現(xiàn)在的Web2.0最重要的一點特質(zhì)，規(guī)范的只是接口（用于統(tǒng)一交互的管理），開放的是接口下的任何貢獻，主動參與和主動的集成將會使得框架越來越有活力，Spring就是很好的例子。而SCA和Spring的差異我也早在前面的文章中說過，SCA和其他的規(guī)范一樣，并不是一個橫空出世的規(guī)范，是積累在過去的失敗中沉積的產(chǎn)物。最后打了個比方，SCA規(guī)范好比一本菜譜，至于采用什么鍋子，用哪里產(chǎn)的材料都是由廚師自己掌握，這也是架構(gòu)師和程序員需要共同努力將這個規(guī)范實踐的原動力，正確的做事和做正確的事是成敗的兩個關(guān)鍵。言歸正傳，繼續(xù)這次的主題。

在前面的服務(wù)框架工作中，對于Web Service的支持成為了這段時間的重點工作，從開始的壓力測試，Java客戶端的兼容性測試到.net,php客戶端的兼容性測試，WS-Security的集成，服務(wù)框架對于Web Service的支持在需求中逐漸增強。AEP第一期基本完成準(zhǔn)備上線，第二期的需求也已經(jīng)在醞釀中，ASF的第二期功能需求也逐漸的被提出來了，有一點看上去優(yōu)先級比較高，因此我就開始動手先做，那就是SSL。一開始的時候?qū)τ?/span>SSL需求有些誤解，以為是要做Web 服務(wù)器端的SSL，其實我們需要做的是硬件的SSL，只不過“首架”的意思是需要對SSL模式下的客戶端調(diào)用作準(zhǔn)備（的確，客戶端在SSL不論是硬件還是軟件模式下都需要作一定的工作）。后續(xù)將講述一下我在做Web 服務(wù)器端SSL平臺集成的工作和SA專家交流了解的硬件SSL的架構(gòu)策略。

What is SSL

       雖然以前也對SSL有所聞，也常看到IE突然蹦出一個安全提示框，但是對于SSL的具體原理以及結(jié)構(gòu)沒有仔細(xì)看過。既然要用了，還是那個原則，先把原理搞清楚，然后再去實踐。

       SSL(Secure Socket Layer)是一種通信交互協(xié)議，由Netscape公司在1994年制定，主要目的就是確保在web 服務(wù)器和瀏覽器之間數(shù)據(jù)傳輸安全。SSL協(xié)議層是在TCP/IP層和應(yīng)用層之間。當(dāng)前TLS(Transport Layer Security)正在逐漸替代SSL(最新版本v3)。

       SSL協(xié)議分成以下幾部分：

       Record Protocal是SSL的基礎(chǔ)層，SSL所有的上層操作都是基于這個層次，這層主要負(fù)責(zé)消息內(nèi)容的分段，壓縮，加密和數(shù)字摘要等操作。

       Handshake Protocal故名思義就是握手協(xié)議，也是在正式應(yīng)用數(shù)據(jù)傳輸前雙方交換加密設(shè)置以及認(rèn)證的流程規(guī)范協(xié)議。

       Change Cipher Spec Protocol是基于record協(xié)議層通知遠端服務(wù)器修改record協(xié)議層中安全設(shè)置的協(xié)議。

       Alert Protocol是基于record協(xié)議發(fā)送警告到遠端服務(wù)器的協(xié)議。

SSL的具體流程圖：

 

       SSL的流程也體現(xiàn)了對于對稱性密鑰和非對稱性密鑰的使用，由于對稱性密鑰加密比非對稱性密鑰加密要快1000倍，那么對稱性密鑰被用來做對內(nèi)容的加密，而非對稱性密鑰用來做傳遞對稱性密鑰的加密手段。

       服務(wù)端所需要具備的是一個擁有服務(wù)端的標(biāo)示，公鑰私鑰對的證書。在握手的流程中，服務(wù)端將帶有公鑰的證書抽取出來發(fā)送給客戶端，客戶端就首先可以判斷證書頒發(fā)者是否屬于本機受信的CA，如果不是，就會類似于IE跳出提示，如果通過了這部分CA認(rèn)證，雙方就可以通過非對稱性加密算法來交換客戶端生成的臨時對稱密碼，進行安全加密信息交互。

軟件SSL的實踐

       因為當(dāng)前所有的單元測試都是通過我提供的ASF模板類，所以啟動的Web Service都是服務(wù)框架中Jetty發(fā)布的Web Service，很輕量級，沒有以往測試Web應(yīng)用的復(fù)雜，不需要單獨去啟動一個Web Container。前期對于WS-Security的集成已經(jīng)使得單元測試可以支持帶WS-Security的Web Service的測試。

       抱著試一試的心理，直接用服務(wù)框架發(fā)布了SSL的Web Service，客戶端調(diào)用了一下，沒有成功，但是錯誤還不能定位是客戶端還是服務(wù)端的問題，因此首先去外部配置了Tomcat來建立了一個SSL服務(wù)端。

Tomcat SSL服務(wù)端的配置：（只需要修改一個文件conf/server.xml）

    <Connector port="8443" maxHttpHeaderSize="8192"

               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

               enableLookups="false" disableUploadTimeout="true"

               acceptCount="100" scheme="https" secure="true"

               clientAuth="false" sslProtocol="TLS" keystoreFile="D:/work/asf/webservice/src/conf.test/keys/alisoft.jks"

               keystorePass="alisoft" keystoreType="jks" truststoreFile="D:/work/asf/webservice/src/conf.test/keys/alisoft.jks"

               truststorePass="alisoft" truststoreType="jks"/>

clientAuth沒有必要配置成為true，不需要重復(fù)反向再認(rèn)證。如果這個值設(shè)為false。其他幾個值就是生成的服務(wù)端證書庫位置及密碼。這里所要注意的就是要求keystore密碼和私鑰密碼一樣，因為只有一個配置密碼的地方，這在生成公鑰密鑰對時兩者密碼寫成一致。這樣就OK了，直接訪問8443端口就能作為https來訪問服務(wù)了。

采用XFire客戶端來做單元測試，代碼如下：

public static void SSLSecurityTest()

         {

                   Service serviceModel = new ObjectServiceFactory().create(IAccountService.class);

                   //https的客戶端代碼需要增加的

                   System.setProperty ( "java.protocol.handler.pkgs" , "com.sun.net.ssl.internal.www.protocol" );

                   System.setProperty ( "javax.net.ssl.keyStore" , "D:/work/asf/webservice/src/conf.test/keys/myisvdemo.jks" );

                   System.setProperty ( "javax.net.ssl.keyStorePassword" , "myisvdemo" );

                   System.setProperty ( "javax.net.ssl.trustStore" , "D:/work/asf/webservice/src/conf.test/keys/myisvdemo.jks" );

                   System.setProperty ( "javax.net.ssl.trustStorePassword" , "myisvdemo" );

                   System.setProperty ("java.protocol.handler.pkgs","com.sun.net.ssl.internal.www.protocol");

                   Security.addProvider ( new com.sun.net.ssl.internal.ssl.Provider());

                  

                  

                   String serviceUrl = "http://localhost:8080/axis2/services/AccountService";

                   String serviceHttpsUrl = "https://localhost:8443/xfire/services/AccountService";

                   String serviceHttpsUrl2 = "https://localhost:8443/axis2/services/AccountService";

                  

                   try

                   {

                            IAccountService service = (IAccountService)serviceFactory.create(serviceModel,serviceHttpsUrl2);

                           

//WS-Security所需要的配置

                            Client client = ((XFireProxy)Proxy.getInvocationHandler(service)).getClient();

                            client.addOutHandler(new DOMOutHandler());

                            Properties properties = new Properties();

                            properties.setProperty(WSHandlerConstants.ENABLE_SIGNATURE_CONFIRMATION, "false");

                            properties.setProperty(WSHandlerConstants.ACTION, WSHandlerConstants.SIGNATURE);

                            //properties.setProperty(WSHandlerConstants.ACTION, WSHandlerConstants.TIMESTAMP);

                            properties.setProperty(WSHandlerConstants.SIG_PROP_FILE, "keys/client.properties");

                            //properties.setProperty(WSHandlerConstants.USER, "myisvdemo");

                            properties.setProperty(WSHandlerConstants.USER, "wenchu");

                            properties.setProperty(WSHandlerConstants.PW_CALLBACK_CLASS, ClientUtPasswordHander.class.getName());

                            //properties.setProperty(WSHandlerConstants.SIG_KEY_ID, "IssuerSerial");//"DirectReference","IssuerSerial","SKIKeyIdentifier"

                            properties.setProperty(WSHandlerConstants.SIG_KEY_ID, "SKIKeyIdentifier");

                            client.addOutHandler(new WSS4JOutHandler(properties));

                            AccountBean[] result = service.getUserAccountList("te", "ta");

                            System.out.println(result.length);          

                   }

                   catch(Exception ex){ex.printStackTrace();}

         }

       這樣保證了客戶端的配置已經(jīng)沒有問題了，因此就主要將ASF框架中的SSL集成進去。由于ASF中集成的是Jetty，因此只需要在Jetty動態(tài)建立Mapping Server的時候，Server的connector為以SslSocketConnector類型來構(gòu)造，這樣就可以響應(yīng)https的部分了，同時也可以在其它端口發(fā)布成為不需要SSL的服務(wù)。這里細(xì)節(jié)就略去了，改造不是很復(fù)雜，只需要對Jetty較為了解即可。不過這里還是要贊一下Jetty，真是輕量級的好東西啊。集成以后再次作單元測試，OK，測試通過。

.Net的客戶端測試

       最后就需要對.net所SSL的測試，由于.net客戶端已經(jīng)在上次配置了policy作為WS-Security的配置，按照常理來說應(yīng)該不需要再配置證書之類的東西了，就嘗試著做了一下，在建立Web Reference的時候會有提示說證書授權(quán)的認(rèn)證不符合要訪問的地址的身份，這個可以忽略。然后接下去測試了一下，就總是提示無法建立TLS/SSL的交互通道，查了一下，只需要加入下面一句話即可：

System.Net.ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };

它的作用就是接受所有的證書，也就是在我們SSL中的流程中，檢查證書CA是否受信這部分省略，就好比我們訪問一些非受信證書的網(wǎng)站跳出的提示框我們點擊確認(rèn)一樣。

到此為止，應(yīng)用服務(wù)器的SSL配置和測試就基本結(jié)束了。后面要談到的就是硬件SSL的結(jié)構(gòu)和設(shè)計。

硬件SSL結(jié)構(gòu)設(shè)計

       首先為什么要使用SSL來加密呢，干脆用WS-Security就好了，而且WS-Security有著很多SSL所無法做到的特性（不基于傳輸層，保障非點對點的安全傳輸，部分加密等等）。但是在前面的壓力測試中明顯可以看到還沒有用到加密，僅僅是簽名服務(wù)器的CPU消耗就成倍的增長，可見對于性能的影響。同時上面提到的應(yīng)用服務(wù)器SSL，其實也是類似于WS-Security，消耗比較大。因此就提出了硬件SSL的設(shè)計。

       這里主要提了兩種，第二種也是現(xiàn)在SA比較推薦的。

一．              為應(yīng)用服務(wù)器增加獨立的SSL加速卡，例如roadcom CryptoNetXM卡，SSL加速卡的作用在于能夠?qū)?yīng)用服務(wù)器處理SSL的工作獨立完成，讓應(yīng)用服務(wù)器專心處理應(yīng)用請求，使得應(yīng)用服務(wù)器性能不受影響。

 

圖 SSL加速卡部署圖

       由于許多服務(wù)器使用的是不同的加密數(shù)據(jù)，因此管理這樣一個Web服務(wù)器組會花費比較大并且復(fù)雜。同時傳統(tǒng)的負(fù)載均衡陣列中每一個處理加密服務(wù)器要求有一個SSL加速卡和數(shù)字證書，而證書是被CA簽署過的一個電子認(rèn)證標(biāo)識，在加密通信方面提供了一致性的驗證，這樣對于CA的電子認(rèn)證標(biāo)識管理也是很復(fù)雜的一件事，因此產(chǎn)生了第二種設(shè)計模式。

二．              將SSL基礎(chǔ)結(jié)構(gòu)與BIG-IP結(jié)合

BIG-IP是一個運行有BIG-IP負(fù)載均衡軟件的服務(wù)器，它通過SSL加速卡實現(xiàn)了SSL的off-loading，同時還可以實現(xiàn)應(yīng)用層和IP層的負(fù)載均衡。通過SSL終結(jié)，前端的BIG-IP負(fù)責(zé)SSL的集中處理以及同時將處理后的請求負(fù)載均衡到各個應(yīng)用服務(wù)器上，這樣既降低了SSL證書管理成本，也減少了Web服務(wù)器組的管理復(fù)雜性。