??? 網絡的飛速發(fā)展在給人們生活帶來便利的同時，也給網絡安全帶來了越來越多的問題。為了保障網絡的安全通訊，各項研究針對安全通訊的不同方面提出了多種協(xié)議，其中，網景公司開發(fā)的SSL協(xié)議較好地解決了點對點的安全通訊，并在其產品Navigator的推動下迅速發(fā)展成為安全協(xié)議的工業(yè)標準之一。
??? 然而，由于美國出口法律的限制，對中國出口的各項SSL的實現(xiàn)產品都只能完成SSL的弱加密模式。這種弱加密模式已經在研究中被證實存在諸多漏洞，這些漏洞將會給點對點的通訊帶來隱患。針對這個問題，我們提出使用Java來實現(xiàn)獨立的SSL強加密模式連接的新方案。我們的新方案不依賴于操作系統(tǒng)而獨立完成SSL的128位強加密模式，并且可以避免通常Java通訊編程中不能跨越防火墻的問題。在數(shù)據(jù)通訊過程中，我們的數(shù)據(jù)先利用自身的128位強加密模式加密，然后通過瀏覽器的40位弱加密方式進行傳輸，實際效果比單純的128位強加密模式更加安全。
??? 本文下面的" title="面的">面的內容是這樣安排的：第2節(jié)描述了現(xiàn)有SSL存在的問題" title="存在的問題">存在的問題；在第3節(jié)中，我們提出了利用Java Applet改進現(xiàn)有SSL加密模式，實現(xiàn)強加密連接的新方案；新的實現(xiàn)方案" title="實現(xiàn)方案">實現(xiàn)方案與現(xiàn)有的加密模式實現(xiàn)方案的比較在第4節(jié)中進行了說明；最后，第5節(jié)給出了結論。
2?現(xiàn)有SSL存在的問題
??? 由網景公司開發(fā)出的SSL協(xié)議[5]，即安全套接字層協(xié)議，非常適用于網絡上點對點的安全通訊。目前，通用的SSL被分為強加密模式、國內加密模式、弱加密模式。但是由于美國出口法律的限制，強加密模式被禁止向中國出售。對于Linux系統(tǒng)，影響并不大，因為SSL的加密產品供應商位于加拿大，不必受美國法律的限制。但是我國目前有80%的操作系統(tǒng)使用的是Windows系統(tǒng)，16%使用的是如AIX, Sco Unix, BSD Unix等Unix的美國產品。因此，在國內大多數(shù)的網絡應用一般使用的128位的SSL加密都是弱加密?，F(xiàn)在，已經有了相當多的研究表明弱加密模式的SSL存在諸多漏洞，這對于那些安全性要求較高的通訊系統(tǒng)來說是非常危險的。
3?改進的SSL實現(xiàn)方案
??? 針對SSL在國內無法實現(xiàn)強加密所帶來的問題，我們提出了一個用Java改進安全套接層加密模式的新方案。新方案使用獨立的Java Applet[1]-[4]來實現(xiàn)SSL的強加密模式，并且可以跨越防火墻，加密的效果比現(xiàn)有的SSL的128位強加密的實現(xiàn)更加安全。
3.1?改進方案的設計思路
??? 為了實現(xiàn)SSL強加密的連接，我們必須解決以下4個問題，新的改進方案正是基于這4個方面的考慮提出的。
1)?不同操作系統(tǒng)中的SSL可能有不同版本，如SSL2.0，SSL3.0。由于目前國內的大多數(shù)操作系統(tǒng)中的SSL協(xié)議只有弱加密模式的實現(xiàn)，因此，我們不能直接利用基于操作系統(tǒng)的通訊方式，比如通訊組件，而必須使SSL實現(xiàn)獨立于操作系統(tǒng)以避開操作系統(tǒng)弱加密模式的通訊限制。這樣，改進方案必須不依賴于操作系統(tǒng)。我們提出使用Java Applet。
2)?對于Java Applet的SSL連接的實現(xiàn)，最直接的方式就是使用瀏覽器來實現(xiàn)。這里我們采用統(tǒng)一的XML格式，實現(xiàn)方法如下：
??? 這個方法使用https指明是通過SSL連接的http。顯然，這種方法的安全性依賴于瀏覽器的SSL。雖然Linux 下面的Mozilla和Kopera等瀏覽器可以實現(xiàn)128位的強加密模式，但是就目前國內的情況而言，這些瀏覽器使用的范圍較小，因此這種直接利用瀏覽器實現(xiàn)128位強加密的連接方式并不通用。另一方面，國內使用最為廣泛的Navigator，IE等瀏覽器由于同樣受到美國法律限制，也都只能提供40位的加密器。這樣，這種直接的簡單實現(xiàn)顯然不能滿足我們的要求；另外，直接利用瀏覽器對傳輸?shù)奈募愋蛷娂恿讼拗?，這對有些試圖通過獨立的通訊文件格式在客戶段和服務器間進行通訊的情況也是不適用的。為此，我們提出的改進方案必須獨立完成SSL而不能依賴于瀏覽器。
3)?為獨立完成SSL實現(xiàn)，我們使用Java的Socket類。這樣又遇到了防火墻的問題。我們知道，為了安全和效率方面的考慮，很 多服務器都會放在防火墻之后。這樣，當我們試圖通過Applet直接連接時，我們無法繞過這個防火墻而打開在防火墻后面的連接服務。解決防火墻的一個常用辦法就是使用可信賴的代理?？墒俏覀冎繱ocket類無法接入配置信息，也就是說我們不能在Socket類中設置代理。為了解決這個矛盾，在改進的SSL連接方案中，我們必須考慮使用其他類使我們可以配置連接。
4)?在我們的Applet實現(xiàn)SSL強加密模式的連接方案中，我們使用URLConnection類建立到服務器的連接。具體URLConnection類的連接如下：
URL serv_con = new URL (https://Communications.CAP/sccure”);
URLConnection serv_fork1 = serv_con.openConnection();
InputStream instr = serv_fork1.getInputStream();
OutputStream outstr = serv_fork1.getOutputStream();
綜合上面所述的這些因素，我們提出了一個新的SSL強加密模式的Java實現(xiàn)方案，該方案改進了目前國內的SSL的加密模式，充分考慮到了SSL連接的通用性和安全性，具體的實現(xiàn)在接下來的一節(jié)里描述。
3.2?新方案的具體實現(xiàn)
??? 假設我們要越過防火墻使用SSL的128位強加密模式連接其后面的CAP服務器。我們使用Applet自身完成的128位強加密加上瀏覽器40位的弱加密來共同實現(xiàn)改進的SSL實現(xiàn)方案，具體方案圖如圖1所示：
??? 首先，我們利用類java.net.URLConnection通過一個可信賴的代理來跨越防火墻打開CAP的連接服務；然后，通過Applet的SSLConnection完成128位的SSL強加密模式；接著，我們利用瀏覽器的40位弱加密方式的SSL對加密后的數(shù)據(jù)進行傳送。這樣的雙重加密不但可以實現(xiàn)128位強加密(實際上的加密性能優(yōu)于128位的強SSL加密模式)而且可以通過可信賴的代理服務器跨越防火墻，無論在方案的普適性或是其安全性方面都比通常的SSL連接要好的多" title="的多">的多。當然，這些優(yōu)點也是以犧牲了一定的系統(tǒng)資源為代價的。改進方案的一些特性如下：
1)以128位IDEA作為對稱加密器；2)以RSA作為交換密匙算法；3)設置會話緩存加快連接；4)MD5作為內部哈希算法；5)不大于40Kbytes的jar文件，如果為了系統(tǒng)運行的更快，可以按需要根據(jù)各個IDS所在的操作系統(tǒng)利用JIT重新編譯成本地代碼以提高性能；6)可以在任何操作平臺上運行。
4 改進前后SSL方案的比較
??? 由于改進的SSL連接方案是通過Applet來實現(xiàn)的，因此，這個方案的SSL與通常的SSL相比較也有一些不同之處，我們對這些不同的說明如下：
1)?改進方案中將通用的SSL中由SSL服務器提供認證的部分取消，而直接將SSL服務器的公共密匙編碼到Applet中去。因為一個Applet在任何情況下只能也只需要連接到其下載Applet的服務器上去，所以這樣簡化并不影響通用性，并且可以為Applet可以節(jié)省大量的空間，去除了為解析X.509認證的ASN.1部分，大大地減小了Applet的大小。
2)?同理，由于公共密匙被直接編碼到Applet中，認證過程被取消，從而使因公共密匙交換無效產生的SSL握手信息ServerKeyExchange也被取消，這個改變不會帶來其他影響。
3)?客戶端" title="客戶端">客戶端的認證過程也被取消了，因為Applet受安全限制不能直接讀寫本地文件系統(tǒng)，因此，本地的證書和私有密匙就不能讀出。為了認證與CAP建立連接的各個客戶端，我們將本地PIN碼直接提交到Applet中，由于我們使用強加密模式進行所有的數(shù)據(jù)傳輸，因此，這樣做不會帶來安全方面的漏洞。
4)?SSL3.0提供的多會話緩存技術也被簡化了。因為每個Applet只與CAP服務期建立一個連接，所以改進的SSL實現(xiàn)方案不必處理多連接的情況。
5?結論
??? 本文針對目前國內大多數(shù)SSL實現(xiàn)由于受美國法律限制只能提供弱加密模式的缺點提出了一個新的使用Java Applet來改進SSL強加密模式的方案。該方案利用SSLConnection類實現(xiàn)128位的SSL強加密模式，同時又使用瀏覽器內部的40位弱加密模式進行二次加密，從而使得所建立的連接更加安全。在新的改進方案中，我們利用URLConnection類配置代理服務器跨越防火墻，使得該方案適用范圍更廣，實用性更強。
參考文獻
[1]?Java Development Kit, Sun Microsystems, http://www.javasoft.com/products/jdk
[2]?JavaScript, Netscape, http://developer.netscape.com/tech/javascript/index.html
[3]?Java Applet Security, Javasoft, http://java.sun.com/security/SRM.html
[4]?Java Applets, Sun Micro, http://www.javasoft.com/applets/index.html
[5]?SSL, Netscape, http://home.netscape.com/eng/ssl3/index.html
[6]?HTTP, W3C, http://www.w3.org/Protocols/
[7]?HTML, W3C, http://www.w3.org/MarkUp/
[8]?URLConnection, JDK Doc,
[9]?Java Archive, Sun Microsystems, http://www.javasoft.com/products/jdk/1.1/docs/guide/jar/index.html
[10]?Signed JAR files, Sun Microsystems, http://java.sun.com/secuirty/signExample/
[11]?JDK Version, Sun Microsystems, http://java.sun.com/products/OV_jdkProduct.html
[12]?Java Activator, Sun Microsystems, http://www.javasoft.com/products/activator/index.html
[13]?Active X, Microsoft, http://www.microsoft.com/com/default.asp
[14]?PlugIn, Netscape, http://home.netsape.com/plugins
SSL Applet, IAIK, http://jcewww.iaik.tu-graz.ac.at/Applet/Applet.html