<?xml version="1.0"?>

<document url="./ssl.xml">

<properties>


<title>Secure Socket Layer and Web Applications - Apache Struts</title>

</properties>

<body>

<section href="ssl" name="Secure Socket Layer and Web Applications"/>

<section href="overview" name="Overview">

<p>
Many web applications, especially those deployed for e-commerce, necessitate the
transmission of sensitive data between the web server and the client browser.  This data
may include passwords, credit card numbers, bank account numbers or any other
information that users would not want to divulge to the general public. To protect
sensitive data during transmission, application developers typically use the Secure
Sockets Layer (SSL) and its companion protocol, HTTP over Secure Sockets Layer
(HTTPS). HTTPS employs SSL to protect data by encrypting it at the source, be it the
server or the client, and decrypting it at the destination. This prevents anyone monitoring
Internet data transmissions from easily capturing this data. The client and server
exchange public keys to enable encryption and decryption to occur.
</p>

<p>
The encryption/decryption process comes at a performance price, however. The
throughput of data for a web server transmitting via HTTPS is often as little as one-tenth
that of data transmission via HTTP. For this reason, it is undesirable to deploy an entire
web application under SSL. For fastest performance, it is best to deploy a web
application under HTTP and employ HTTPS only for those pages and processes that
transmit sensitive data.
</p>

</section>

<section href="mixing" name="Mixing Protocols in Web Applications">

<p>
Switching back and forth between the two protocols can require hard-coding the protocol
and full URL in every link to each resource in the web application. This creates an
ongoing maintenance headache for developers each time a server name changes or secure
protocol requirements change for resources in the web app.
</p>

<p>
Another significant hazard is that there is nothing to prevent a user from specifying the
wrong protocol by manually entering a URL into the browser. The penalty for manually
specifying HTTPS for a page or servlet that does not require HTTPS is reduced
performance. Far worse is the penalty for manually specifying HTTP for non-secure
access of a page that does require HTTPS: public exposure of sensitive data.
</p>

</section>

<section href="help" name="Help from Deployment Descriptor">

<p>
To help overcome the problem of non-secure access of sensitive data, the Java Servlet
Specification (versions 2.2 and 2.3) defines the transport-guarantee element of the
web.xml deployment descriptor file. The transport-guarantee element must specify one
of three types of protection for communication between client and server: NONE,
INTEGRAL, or CONFIDENTIAL. For most containers a specification of INTEGRAL
or CONFIDENTIAL is treated as a requirement for SSL usage. Web application
containers will prevent users from accessing web resources over HTTP if they have been
so specified.
</p>

<p>
The implementation for blocking HTTP access to web resources specified as INTEGRAL
or CONFIDENTIAL varies from container to container. If a user attempts to access such
a resource over HTTP, some containers will present that user with an error message
instructing them to use the HTTPS protocol for accessing the requested resource. Other
containers will actually redirect the request using the HTTPS protocol, but then continue
using the HTTPS protocol for all subsequent requests, even those for resources with a
transport-guarantee specification of NONE.
</p>

</section>

<section href="sslext" name="The sslext Struts Extension">

<p>
An extension to Struts 1.1, named sslext, helps solve many of these issues for Struts
developers. It extends the ActionConfig class, RequestProcessor, and Plugin classes to
define a framework where developers may specify the transmission protocol behavior for
Struts applications. Within the Struts configuration file, developers specify which action
requests require HTTPS transmission and which should use HTTP. Developers can also
specify whether to redirect "improperly-protocoled" requests to the correct protocol.
</p>

<p>
In addition to these extensions, the &lt;html:link> and the &lt;html:form> tags have been
extended. In these extensions, the Struts actions specified in either of these tags are
analyzed to determine the protocol that should be used in requesting that action. The
HTML generated by these tags will specify the proper protocol. An additional custom
tag is defined for allowing users to specify the transmission protocol for an individual
JSP. This is most often used for form-based authentication pages.
</p>

<p>
The sslext library may be obtained from <a href="http://sslext.sourceforge.net">
http://sslext.sourceforge.net</a>
</p>

</section>

<section href="legacy" name="Legacy Browser Issue">

<p>
One additional complication faced by developers of web applications is that some
browsers (e.g. pre-6.0 versions of Netscape Navigator) will treat requests to different
protocols and ports on the same server as requests to different domains. This causes
these browsers to initiate a new session each time a different protocol or port is specified
in a request. This problem can only be solved at the container level. Some containers
have a "session domain" or "cookie domain" configuration parameter to allow the session
to be shared across different servers in the same domain. As an example, the Weblogic
Server has a "CookieDomain" property configured in its weblogic.xml deployment
descriptor. Thankfully, the effects of this problem are diminishing as people upgrade
their browsers to the current versions.
</p>

</section>

<section href="containers" name="Configuring Containers for SSL">

The procedure for configuring SSL for a container will be specific to that container.  The
procedure for enabling SSL for Tomcat can be found
<a href="http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html">here</a>.

</section>

</body></document>