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.
Figure 12-11. mod_proxy enabled-Apache with SSL and mod_perl-enabled Apache
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.
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.
