12.14 SSL Functionality and a mod_perl Server

If you need SSL functionality,
you can get it by adding the mod_ssl or equivalent Apache-SSL to the
light frontend server (httpd_docs) or the heavy
backend mod_perl server (httpd_perl). The
configuration and installation instructions are given in Chapter 3.

The question is, is it a good idea to add mod_ssl to the backend
mod_perl-enabled server? If your internal network is secured, or if
both the frontend and backend servers are running on the same machine
and you can ensure a safe communication between the processes, there
is no need for encrypted traffic between them.

If this is the situation, you don't have to put
mod_ssl into the already heavy mod_perl server. You will have the
external traffic encrypted by the frontend server, which will
proxypass the unencrypted request and response data internally. This
is depicted in Figure 12-11.

Another important point is that if you put mod_ssl on the backend
server, you have to tunnel back your images to it (i.e., have the
backend serve the images), defeating the whole purpose of having the
lightweight frontend server.

You cannot serve a secure page that includes nonsecure information.
If you fetch over SSL an HTML page containing an
<img> tag that fetches an image from the
nonsecure server, the image is shown broken. This is true for any
other nonsecure objects as well. Of course, if the generated response
doesn't include any embedded objects (e.g., images)
this isn't a problem.

Giving the SSL functionality to the frontend machine also simplifies
configuration of mod_perl by eliminating
VirtualHost duplication for SSL. mod_perl
configuration files can be plenty difficult without the mod_ssl
overhead.

Also, assuming that your frontend machine is underworked anyway,
especially if you run a high-volume web service deploying a cluster
of machines to serve requests, you will save some CPU, as
it's known that SSL connections are about 100 times
more CPU-intensive than non-SSL connections.

Of course, caching session keys so you don't have to
set up a new symmetric key for every single connection improves the
situation. If you use the shared-memory session-caching mechanism
that mod_ssl supports, the overhead is actually rather small, except
for the initial connection.

But then, on the other hand, why even bother to run a full-scale
mod_ssl-enabled server in front? You might as well just choose a
small tunnel/port-forwarding application such as Stunnel or one of
the many others mentioned at http://www.openssl.org/related/apps.html.

Of course, if you do heavy SSL processing, ideally you should really
be offloading it to a dedicated cryptography server. But this advice
can be misleading, based on the current status of crypto hardware. If
you use hardware, you get extra speed now, but
you're locked into a proprietary solution; in six
months or a year software will have caught up with whatever hardware
you're using, and because software is easier to
adapt, you'll have more freedom to change whatever
software you're using and more control of things. So
the choice is in your hands.