https3种实现方式

2024年5月31日发(作者：)

https 3种实现方式

HTTPS实际是SSL over HTTP, 该协议通过SSL在发送方把原始数据进行加密，在接收方解

密，因此，所传送的数据不容易被网络黑客截获和破解。本文介绍HTTPS的三种实现方法。

方法一 静态超链接

这是目前网站中使用得较多的方法，也最简单。在要求使用SSL进行传输的Web网页链接中直接标

明使用HTTPS协议，以下是指向需要使用SSL的网页的超链接：

需要说明的是，在网页里的超链接如果使用相对路径的话，其默认启用协议与引用该超链接的网页或资源

的传输协议相同，例如在某超链接“HTTPS://192.168.100.100/ok/”的网页中包含如下两个超

链接：

那么，第一个链接使用与“HTTPS://192.168.100.100/ok/”相同的传输协议HTTPS，第

二个链接使用本身所标识的协议HTTP。

使用静态超链接的好处是容易实现，不需要额外开发。然而，它却不容易维护管理; 因为在一个完全

使用HTTP协议访问的Web应用里，每个资源都存放在该应用特定根目录下的各个子目录里，资源的链

接路径都使用相对路径，这样做是为了方便应用的迁移并且易于管理。但假如该应用的某些资源要用到

HTTPS协议，引用的链接就必须使用完整的路径，所以当应用迁移或需要更改URL中所涉及的任何部分

如：域名、目录、文件名等，维护者都需要对每个超链接修改，工作量之大可想而知。再者，如果客户在

浏览器地址栏里手工输入HTTPS协议的资源，那么所有敏感机密数据在传输中就得不到保护，很容易被

黑客截获和篡改！

方法二 资源访问限制

为了保护Web应用中的敏感数据，防止资源的非法访问和保证传输的安全性，Java Servlet 2.2规

范定义了安全约束（Security-Constraint）元件，它用于指定一个或多个Web资源集的安全约束条件；

用户数据约束（User-Data-Constraint）元件是安全约束元件的子类，它用于指定在客户端和容器之间

传输的数据是如何被保护的。用户数据约束元件还包括了传输保证（Transport-Guarantee）元件，它规

定了客户机和服务器之间的通信必须是以下三种模式之一：None、Integral、Confidential。None表示

被指定的Web资源不需要任何传输保证；Integral表示客户机与服务器之间传送的数据在传送过程中不

会被篡改; Confidential表示数据在传送过程中被加密。大多数情况下，Integral或Confidential是使

用SSL实现。

这里以BEA的WebLogic Server 6.1为例介绍其实现方法，WebLogic是一个性能卓越的J2EE服

务器，它可以对所管理的Web资源，包括EJB、JSP、Servlet应用程序设置访问控制条款。假设某个应

用建立在Weblogic Server里的/mywebAPP目录下，其中一部分Servlets、JSPs要求使用SSL传输，

那么可将它们都放在/mywebAPP/sslsource/目录里，然后编辑/secureAPP/Web-INF/文件，

通过对的设置可达到对Web用户实现访问控制。

当Web用户试图通过HTTP访问/sslsource目录下的资源时，Weblogic Server就会查找

里的访问约束定义，返回提示信息：Need SSL connection to access this resource。资源访问限制与

静态超链接结合使用，不仅继承了静态超链接方法的简单易用性，而且有效保护了敏感资源数据。然而，

这样就会存在一个问题： 假如Web客户使用HTTP协议访问需要使用SSL的网络资源时看到弹出的提示

信息: Need SSL connection to access this resource，大部分人可能都不知道应该用HTTPS去访问

该网页，造成的后果是用户会放弃访问该网页，这是Web应用服务提供商不愿意看到的事情。

方法三 链接重定向

综观目前商业网站资源数据的交互访问，要求严格加密传输的数据只占其中一小部分，也就是说在一

个具体Web应用中需要使用SSL的服务程序只占整体的一小部分。那么，我们可以从应用开发方面考虑

解决方法，对需要使用HTTPS协议的那部分JSPs、Servlets或EJBs进行处理，使程序本身在接收到访

问请求时首先判断该请求使用的协议是否符合本程序的要求，即来访请求是否使用HTTPS协议，如果不

是就将其访问协议重定向为HTTPS，这样就避免了客户使用HTTP协议访问要求使用HTTPS协议的Web

资源时，看到错误提示信息无所适从的情况，这些处理对Web客户来说是透明的。

实现思想是：首先创建一个类，该类方法可以实现自动引导Web客户的访问请求使用HTTPS协议，

每个要求使用SSL进行传输的Servlets或JSPs在程序开始时调用它进行协议重定向，最后才进行数据

应用处理。

J2EE提供了两种链接重定向机制。第一种机制是RequestDispatcher接口里的forward()方法。使

用MVC(Model-View-Controller)机制的Web应用通常都使用这个方法从Servlet转移请求到JSP。但

这种转向只能是同种协议间的转向，并不能重定向到不同的协议。第二种机制是使用

HTTPServletReponse接口里的sendRedirect()方法，它能使用任何协议重定向到任何URL，例如：

direct(“HTTPS://192.168.100.100/order”);

此外，我们还需使用到Java Servlet API中的两个方法：ServletRequest接口中的getScheme()，

它用于获取访问请求使用的传输协议；HTTPUtils类中的getRequestUrl()，它用于获取访问请求的URL，

要注意的是该方法在Servlet 2.3中已被移到HTTPServletRequest接口。

以下是实现协议重定向的基本步骤：

1. 获取访问的请求所使用的协议；

2. 如果请求协议符合被访问的Servlet所要求的协议，就说明已经使用HTTPS协议了，不需做任何

处理；

3. 如果不符合，使用Servlet所要求的协议(HTTPS)重定向到相同的URL。

例如，某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里。我们可以使用ryString()来获取GET的查询字串，对于Post的Request

参数，可以把它们转换成查询串再进行处理。

● 某些Web应用请求中会使用对象作为其属性，必须在重定向之前将这些属性保存在该Session中，

以便重定向后使用。

● 大多数浏览器会把对同一个主机的不同端口的访问当作对不同的主机进行访问，分用不同的

Session，为了使重定向后保留使用原来的Session，必须对应用服务器的Cookie 域名进行相应的设置。

以上问题均可在程序设计中解决。

通过程序自身实现协议重定向，就可以把要求严格保护的那部分资源与其他普通数据从逻辑上分开处

理，使得要求使用SSL的资源和不需要使用SSL的资源各取所需，避免浪费网站的系统资源。

java应用 tomcat中实现https安全连接的方法

SSL, 或者Secure Socket Layer，是一种允许web浏览器和web服务器通过一个安全的连接进行交流

的技术。这意味着将被发送的数据在一端被翻译成密码，传送出去，然后在另一端解开密码，再进行处理。

这是一个双向的过程，也就是浏览器和服务器都需要在发送数据之前对它们进行加密。

SSL协定的另一个重要方面是认证(Authentication)。这就是说，在你开始试图通过一个安全连接与

一个web服务器交流的时候，这个服务器会要求你的浏览器出示一组证件，通过“鉴定”的方式来证明这

就是你所声明的网站。

在某些情况下，服务器还会要求你的web浏览器的认证书，证明你就是你所说的那个人。这就是所知

的“客户认证”，尽管实际情况中，更多地用在商务-对-商务(B2B)交易，而不是对个人用户。

但大多数有SSL功能的web服务器不要求客户认证(Client Authentication)。

证书

为了能实施SSL，一个web服务器对每个接受安全连接的外部接口(IP 地址)必须要有相应的证书

(Certificate)。关于这个设计的理论是一个服务器必须提供某种合理的保证以证明这个服务器的主人就是

你所认为的那个人。这个证书要陈述与这个网站相关联的公司，以及这个网站的所有者或系统管理员的一

些基本联系信息。

这个证书由所有人以密码方式签字，其他人非常难伪造。对于进行电子商务(e-commerce)的网站，或

其他身份认证至关重要的任何商业交易，认证书要向大家所熟知的认证权威(Certificate Authority (CA))

如VeriSign或Thawte来购买。这样的证书可用电子技术证明属实。实际上，认证权威单位会担保它发出

的认证书的真实性，如果你信任发出认证书的认证权威单位的话，你就可以相信这个认证书是有效的。

在许多情况下，认证并不是真正使人担忧的事。系统管理员或许只想要保证被服务器传送和接收的数

据是秘密的，不会被连接线上的偷窃者盗窃到。庆幸的是，Java提供相对简单的被称为keytool的命令行

工具，可以简单地产生“自己签名”的证书。自己签名的证书只是用户产生的证书，没有正式在大家所熟

知的认证权威那里注册过，因此不能确保它的真实性。但却能保证数据传输的安全性。

认证也许很重要，也许不重要，完全决定于网站的需要。

用Tomcat来配置SSL主要有下面这么两大步骤：

一、生成证书

1、 在命令行下执行：

%Java_home%binkeytool -genkey -alias tomcat -keyalg RSA

将生成的key放入指定目录：

JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA -keystore C:

在此命令中，keytool是JDK自带的产生证书的工具。把RSA运算法则作为主要安全运算法则，这保

证了与其它服务器和组件的兼容性。

这个命令会在用户的home directory产生一个叫做" .keystore " 的新文件。在执行后，你首先被

要求出示keystore密码。Tomcat使用的默认密码是" changeit "(全都是小写字母)，如果你愿意，你可

以指定你自己的密码。你还需要在配置文件里指定自己的密码，这在以后会有描述。

2、 你会被要求出示关于这个认证书的一般性信息，如公司，联系人名称，等等。这些信息会显示给

那些试图访问你程序里安全网页的用户，以确保这里提供的信息与他们期望的相对应。

3、 你会被要求出示密钥(key)密码，也就是这个认证书所特有的密码(与其它的储存在同一个

keystore文件里的认证书不同)。你必须在这里使用与keystore密码相同的密码。(目前，keytool会提示

你按ENTER键会自动帮你做这些)。

如果一切顺利，你现在就拥有了一个可以被你的服务器使用的有认证书的keystore文件。

二、配置tomcat

第二个大步骤是把secure socket配置在$CATALINA_HOME/conf/文件里。$CATALINA_HOME

代表安装Tomcat的目录。一个例子是SSL连接器的元素被包括在和Tomcat一起安装的缺省文

件里。它看起来象是这样：

$CATALINA_HOME/conf/

< -- 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

应用程序。只不过指令需要像下面这样：localhost:8443