一个用Java改进SSL加密模式的新方案

1 引言
    网络的飞速发展在给人们生活带来便利的同时，也给网络安全带来了越来越多的问题。为了保障网络的安全通讯，各项研究针对安全通讯的不同方面提出了多种协议，其中，网景公司开发的SSL协议较好地解决了点对点的安全通讯，并在其产品Navigator的推动下迅速发展成为安全协议的工业标准之一。
    然而，由于美国出口法律的限制，对中国出口的各项SSL的实现产品都只能完成SSL的弱加密模式。这种弱加密模式已经在研究中被证实存在诸多漏洞，这些漏洞将会给点对点的通讯带来隐患。针对这个问题，我们提出使用Java来实现独立的SSL强加密模式连接的新方案。我们的新方案不依赖于操作系统而独立完成SSL的128位强加密模式，并且可以避免通常Java通讯编程中不能跨越防火墙的问题。在数据通讯过程中，我们的数据先利用自身的128位强加密模式加密，然后通过浏览器的40位弱加密方式进行传输，实际效果比单纯的128位强加密模式更加安全。
    本文下面的" title="面的">面的内容是这样安排的：第2节描述了现有SSL存在的问题" title="存在的问题">存在的问题；在第3节中，我们提出了利用Java Applet改进现有SSL加密模式，实现强加密连接的新方案；新的实现方案" title="实现方案">实现方案与现有的加密模式实现方案的比较在第4节中进行了说明；最后，第5节给出了结论。
2 现有SSL存在的问题
    由网景公司开发出的SSL协议[5]，即安全套接字层协议，非常适用于网络上点对点的安全通讯。目前，通用的SSL被分为强加密模式、国内加密模式、弱加密模式。但是由于美国出口法律的限制，强加密模式被禁止向中国出售。对于Linux系统，影响并不大，因为SSL的加密产品供应商位于加拿大，不必受美国法律的限制。但是我国目前有80%的操作系统使用的是Windows系统，16%使用的是如AIX, Sco Unix, BSD Unix等Unix的美国产品。因此，在国内大多数的网络应用一般使用的128位的SSL加密都是弱加密。现在，已经有了相当多的研究表明弱加密模式的SSL存在诸多漏洞，这对于那些安全性要求较高的通讯系统来说是非常危险的。
3 改进的SSL实现方案
    针对SSL在国内无法实现强加密所带来的问题，我们提出了一个用Java改进安全套接层加密模式的新方案。新方案使用独立的Java Applet[1]-[4]来实现SSL的强加密模式，并且可以跨越防火墙，加密的效果比现有的SSL的128位强加密的实现更加安全。
3.1 改进方案的设计思路
    为了实现SSL强加密的连接，我们必须解决以下4个问题，新的改进方案正是基于这4个方面的考虑提出的。
1) 不同操作系统中的SSL可能有不同版本，如SSL2.0，SSL3.0。由于目前国内的大多数操作系统中的SSL协议只有弱加密模式的实现，因此，我们不能直接利用基于操作系统的通讯方式，比如通讯组件，而必须使SSL实现独立于操作系统以避开操作系统弱加密模式的通讯限制。这样，改进方案必须不依赖于操作系统。我们提出使用Java Applet。
2) 对于Java Applet的SSL连接的实现，最直接的方式就是使用浏览器来实现。这里我们采用统一的XML格式，实现方法如下：

    这个方法使用https指明是通过SSL连接的http。显然，这种方法的安全性依赖于浏览器的SSL。虽然Linux 下面的Mozilla和Kopera等浏览器可以实现128位的强加密模式，但是就目前国内的情况而言，这些浏览器使用的范围较小，因此这种直接利用浏览器实现128位强加密的连接方式并不通用。另一方面，国内使用最为广泛的Navigator，IE等浏览器由于同样受到美国法律限制，也都只能提供40位的加密器。这样，这种直接的简单实现显然不能满足我们的要求；另外，直接利用浏览器对传输的文件类型强加了限制，这对有些试图通过独立的通讯文件格式在客户段和服务器间进行通讯的情况也是不适用的。为此，我们提出的改进方案必须独立完成SSL而不能依赖于浏览器。
3) 为独立完成SSL实现，我们使用Java的Socket类。这样又遇到了防火墙的问题。我们知道，为了安全和效率方面的考虑，很多服务器都会放在防火墙之后。这样，当我们试图通过Applet直接连接时，我们无法绕过这个防火墙而打开在防火墙后面的连接服务。解决防火墙的一个常用办法就是使用可信赖的代理。可是我们知道Socket类无法接入配置信息，也就是说我们不能在Socket类中设置代理。为了解决这个矛盾，在改进的SSL连接方案中，我们必须考虑使用其他类使我们可以配置连接。
4) 在我们的Applet实现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实现方案，该方案改进了目前国内的SSL的加密模式，充分考虑到了SSL连接的通用性和安全性，具体的实现在接下来的一节里描述。
3.2 新方案的具体实现
    假设我们要越过防火墙使用SSL的128位强加密模式连接其后面的CAP服务器。我们使用Applet自身完成的128位强加密加上浏览器40位的弱加密来共同实现改进的SSL实现方案，具体方案图如图1所示：

    首先，我们利用类java.net.URLConnection通过一个可信赖的代理来跨越防火墙打开CAP的连接服务；然后，通过Applet的SSLConnection完成128位的SSL强加密模式；接着，我们利用浏览器的40位弱加密方式的SSL对加密后的数据进行传送。这样的双重加密不但可以实现128位强加密(实际上的加密性能优于128位的强SSL加密模式)而且可以通过可信赖的代理服务器跨越防火墙，无论在方案的普适性或是其安全性方面都比通常的SSL连接要好的多" title="的多">的多。当然，这些优点也是以牺牲了一定的系统资源为代价的。改进方案的一些特性如下：
1)以128位IDEA作为对称加密器；2)以RSA作为交换密匙算法；3)设置会话缓存加快连接；4)MD5作为内部哈希算法；5)不大于40Kbytes的jar文件，如果为了系统运行的更快，可以按需要根据各个IDS所在的操作系统利用JIT重新编译成本地代码以提高性能；6)可以在任何操作平台上运行。
4 改进前后SSL方案的比较
    由于改进的SSL连接方案是通过Applet来实现的，因此，这个方案的SSL与通常的SSL相比较也有一些不同之处，我们对这些不同的说明如下：
1) 改进方案中将通用的SSL中由SSL服务器提供认证的部分取消，而直接将SSL服务器的公共密匙编码到Applet中去。因为一个Applet在任何情况下只能也只需要连接到其下载Applet的服务器上去，所以这样简化并不影响通用性，并且可以为Applet可以节省大量的空间，去除了为解析X.509认证的ASN.1部分，大大地减小了Applet的大小。
2) 同理，由于公共密匙被直接编码到Applet中，认证过程被取消，从而使因公共密匙交换无效产生的SSL握手信息ServerKeyExchange也被取消，这个改变不会带来其他影响。
3) 客户端" title="客户端">客户端的认证过程也被取消了，因为Applet受安全限制不能直接读写本地文件系统，因此，本地的证书和私有密匙就不能读出。为了认证与CAP建立连接的各个客户端，我们将本地PIN码直接提交到Applet中，由于我们使用强加密模式进行所有的数据传输，因此，这样做不会带来安全方面的漏洞。
4) SSL3.0提供的多会话缓存技术也被简化了。因为每个Applet只与CAP服务期建立一个连接，所以改进的SSL实现方案不必处理多连接的情况。
5 结论
    本文针对目前国内大多数SSL实现由于受美国法律限制只能提供弱加密模式的缺点提出了一个新的使用Java Applet来改进SSL强加密模式的方案。该方案利用SSLConnection类实现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

通知公告

编辑观点

理事会

参考资料

凡《网络安全与数据治理》（原《信息技术与网络安全》）录用的文章，如作者没有关于汇编权、翻译权、印刷权及电子版的复制权、信息网络传播权与发行权等版权的特殊声明，即视作该文章署名作者同意将该文章的汇编权、翻译权、印刷权及电子版的复制权、信息网络传播权与发行权授予本刊，本刊有权授权本刊合作数据库、合作媒体等合作伙伴使用。同时，本刊支付的稿酬已包含上述使用的费用，特此声明。

作者投稿

在线期刊

下载中心

信网杯

《网络安全与数据治理》（原《信息技术与网络安全》）编辑部