Web应用中使用SSL的实现方式

Web应用中使用SSL的实现方式

本文只是个人的一个学习笔记，暂作一个记录吧

发展背景

Internet的迅猛发展，信息的快速通达使得企业拥有了一个商机无限的广阔发展空间，由于互联网是一个完全开放的网络，使得在其上传输的各种数据面临种种被窃听和丢失的危险。目前在互联网上很多Web应用，尤其是那些电子商务应用，如网上银行，网上超市，股票和债券的在线交易以及软件的付费下载等，都需要在Web服务器和客户端浏览器之间传输机密敏感数据，这些数据包括了信用卡号，密码，银行帐号等高度私隐数据，如果这些数据给别人截获或篡改就会对客户和网站造成不可估量的损失。

为了保护这些敏感数据在*传送过程中的安全*，全球许多知名企业采用 SSL（Secure Socket Layer）的加密机制。 SSL是Netscape公司所提出來的安全保密协议，在浏览器（比如Internet Explorer、Netscape Navigator）和WWW服务器（如Netscape的Netscape Enterprise Server 、ColdFusion Server等等）之间构造的安全通道来进行数据传输，SSL运行在TCP/IP层之上、应用层之下，为应用程序提供加密数据通道，它采用了RC4、MD5，以及RSA等加密演算法，使用40 位的密钥，合适与对于商业信息的加密。同时，Netscape公司相应开发了HTTPS协议并内置于其浏览器中，HTTPS实际上就是SSL over HTTP，它使用默认端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。HTTPS协议使用SSL在发送方把原始数据进行加密，然后在接受方进行解密，加密和解密需要发送方和接受方通过交换共知的密钥来实现，因此，所传送的数据不容易被网络黑客截获和解密。

然而，加密和解密过程需要耗费系统大量的开销，严重降低机器的性能，有关测试数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十分之一。假如为了安全保密，将一个网站所有的Web应用都启用SSL技术来加密，并使用HTTPS协议进行传输，那么该网站的性能和效率将会大大降低，而且没有这个必要，因为一般来说并不是所有数据都要求那么高的安全保密级别，所以，我们只需对那些涉及敏感机密数据的交互处理使用HTTPS协议，这样就做到鱼与熊掌兼得。下面由简单到复杂分步介绍三种具体实现方法 。

方法一、静态超链接

这是目前网站中使用得比较多的做法，也是相对最简单的。我们在要求使用SSL进行传输的WEB应用或网页的链接中直接标明使用HTTPS协议，以下是指向需要使用SSL的网页的超链接：

<a href=”https://192.168.100.100/ok/securePage.jsp”>SSL例子</a>

需要说明一下的是，在网页里的超链假如使用相对路径的话，其默认启用协议与引用该超链的网页或资源的传输协议相同，例如在某超链https://192.168.100.100/ok/login.jps的网页中包含如下两个超链：

<a href=”./bessl/exam.jsp”>SSL链接</a>

<a href=”http://192.168.100.100/notssl/index.jsp”>非SSL链接</a>

那么，第一个链接使用和https://192.168.100.100/ok/login.jps相同传输协议https，第二个链接使用本身所标识协议http。

使用静态超链的方法，好处是很容易实现，不需要额外的开发工作。

然而，容易实现并不等于容易维护管理。因为在一个完全使用http协议访问的Web应用里，每个资源都存放在该应用所特定根目录下的各个子目录里，资源的链接路径都使用相对路径，这样做是为了方便应用的迁移并且易于管理。但假如，该应用某些资源要用到https协议的话引用的链界就必须使用完整的路径，所以当应用迁移或需要更改URL中所涉及的任何部分如：域名，目录，文件名等，维护者都需要每个超链的改，工作量之大可想而知。

再者，使用静态链的存在一个很大的问题，如果客户在浏览器URL里手工输入使用http协议访问要求使用https协议的资源，那么所有敏感机密数据在传输中就会得不到保护，很容易被黑客截获和篡改！

方法二、资源访问限制

为了保护WEB应用中的敏感数据，防止资源的非法访问和保证传输的安全性，JAVA Servlet 2.2规范定义了:

security-constraint（安全约束）元件，它用于指定一个或多个WEB资源集的安全约束条件；

user-data-constraint（用户数据约束） 元件是security-constraint元件的子类，它用于指定在客户端和容器之间传输的数据是如何被保护的。user-data-constraint元件还包括了transport-guarantee（传输保证）元件，它规定了客户机和服务器之间的通讯必须是以下三种模式之一：NONE、INTEGRAL、CONFIDENTIAL。其中：

NONE表示被指定的Web资源不需要任何传输保证；

INTEGRAL表示客户机服务器之间传送的数据在传送过程中不会被篡改；

CONFIDENTIAL表示数据在传送过程中不被篡改和获得。

大多数情况下，INTEGRAL 或CONFIDENTIAL是使用SSL(Security Socket Layer)加密套接字协议层来实现的。

示例

这里以BEA的WebLogic Server 6.1为例介绍其实现方法，WEBLOGIC是一个性能卓越的J2EE服务器，它可以对所管理的WEB资源，包括EJB、JSP（JavaServer Page）、SERVLET应用程序设置访问控制条款，这里只介绍对WEB用户实现访问控制的做法。假设我们手头上有某应用建立在weblogic server里的/mywebAPP目录，其中一部分servlets、JSPs是要求使用SSL传输的，那么我们就将它们都放在/mywebAPP/sslsource/目录里。接下来，我们编辑/secureAPP/WEB-INF/web.xml文件，通过对web.xml的设置可达到对WEB用户实现访问控制的目的。以下是个web.xml文件的例子：

<web-app>
<security-constraint>
<web-resource-collection>
<web-resource-name>SecureAPP</web-resource-name>
<description>App using https</description>
<url-pattern>/ sslsource
String desiredScheme = HTTPS;
String usingScheme = userRequest.getScheme();
String redirectString = null;
if ( !desiredScheme.equals(usingScheme)) {
StringBuffer url = HttpUtils.getRequestURL(userRequest);
url.replace(0, usingScheme.length(), desiredScheme );
redirectString = url.toString();
}
if( redirectString != null ){
try{
ourResponse.sendRedirect(
ourResponse.encodeRedirectURL(redirectString));
return;
}catch(Exception ioe){
}
}
return;
}
}

例如，某WEB用户使用http协议访问要求使用https协议的资源BeSslServlet，敲入URL：http://192.168.100.100/BeSslServlet，我们在执行BeSslServlet时首先使用ProcessSslServlet．processSsl（）进行重定向到：https://192.168.100.100/BeSslServlet，然后 BeSslServlet与客户浏览器之间就通过https协议进行数据传输。

以上介绍的仅是一个最简单的例子，该例子是为了让我们对这种重定向的方法有个初步的认识和概念。假如要真正在WEB应用中实现起来，我们还必须考虑如下几个问题：

● 在WEB应用中常常会用到GET或Post方法，访问请求的URL中就会带上一些查询字串，这些字串是我们使用getRequesUrl()所获取不到的，而且在重定向之后会丢失，所以必须在重定向之前将它们加入新的URL里。我们可以使用request.getQueryString()来获取GET的查询字串，对于Post的Request参数，我们可以把他们转换成查询串再进行处理。

● 某些WEB应用的请求中会使用到对象来作为其属性，我们必须在重定向之前将这些属性保存在该session中，以便重定向后使用。

● 大多数浏览器会把对同一个主机使用不同端口访问当作对不同的主机访问一样，分用不同的session，为了使重定向后保留使用原来的session，我们必须对应用服务器的cookie 域名中进行相应设置。

以上的问题均可在程序设计中解决，这里就不细说。

通过程序自身实现协议重定向，我们就可以把要求严格保护的那部分资源与其他普通数据从逻辑上分开处理，使得要求使用SSL的资源和不需要使用SSL的资源各取所需，避免浪费网站的系统资源，提高了网站的工作效率，又加强了对敏感数据的传输保护。

转载自：http://lean1252.blog.163.com/blog/static/3181375520079911313829/