This article explores options for embedding and using Secure
Sockets Layer (SSL) in AOLserver. A basic explanation is given of
how the SSL protocol works, what encryption ciphers can be used,
and how server and client certificates can be utilized within
AOLserver. Also discussed is how you can legally use SSL without
paying license fees. When finished you will be able to decide which
option is best for you, what encryption ciphers to use and how to
obtain and compile the encryption codes into AOLserver.

The SSL protocol is a series of steps defining how the client
and the server are to tell each other what encryption ciphers they
support, settle on the cipher suite to use, exchange a shared
secret key by utilizing a public key algorithm, and then use that
secret key to encrypt the traffic between them. Part of this
process usually includes authenticating the server to the client
and the client to the server. The end result of this process is an
encrypted connection between the client and server.

There are three versions of the SSL protocol: SSLv2,
SSLv3 and TLSv1 (Transport Layer Security). Only the first two are
in widespread use in web browsers today.

SSLv2 was the first version of the SSL to be available in a wide
number of browsers. It ensures that all data are encrypted between
the client and the server, that the server is authenticated to the
client, and that the client is (optionally) authenticated to the
server. Your web server should be capable of SSLv2 if you want to
reach the widest audience.

SSLv3 is SSLv2 with security and efficiency fixes plus
enhancements to the protocol. Additions include data compression,
the ability for either client or server to request a re-negotiation
of the shared secret key and ciphers used for communications at any
time and the ability to use certificate chains.

TLSv1 is SSLv3 with minor modifications. It is currently going
through the Internet Engineering Task Force's standardization
process. TLSv1 is expected to become the next iteration of SSL and
is already a part of both RSA's encryption products and
OpenSSL.

Encryption ciphers fall into two main categories: symmetric and
asymmetric. A symmetric cipher uses the same key to encrypt and
decrypt data. DES is an example of a symmetric cipher. An
asymmetric cipher uses two keys that are related to each other such
that data encrypted with one of the keys can only be decrypted with
the other key. RSA is an example of an asymmetric cipher.

The advantage of asymmetric ciphers comes from their ability to
securely share a secret with another party without ever having to
pass that secret in the open. By publishing one of the two keys
generated by an asymmetric cipher and keeping the other key
private, any party can use the published key (called the public key) to encrypt a message that only the
recipient can decrypt.

Asymmetric ciphers are also used in the opposite way: a
recipient can be certain that an encrypted message really did come
from you if your corresponding public key successfully decrypts the
message. This is the basis for digital signatures and is how client
and server certificates are validated by other parties.

A typical SSL session actually requires four encryption ciphers
to establish and maintain the secure connection. Each of the
ciphers fulfills a particular role in the overall process. Some
ciphers are capable of fulfilling more than one of the roles:

In role A the client and server use an asymmetric cipher
(almost always RSA) to establish a shared secret key which will be
used in role three to encrypt and decrypt the traffic between them
using a standard symmetric cipher such as RC4 or DES.

In role B an asymmetric cipher is used (almost always RSA) for
authenticating the other party by way of certificates. A
certificate authority (CA) issues you a certificate that
essentially consists of them signing your public key with their
private key. The authentication occurs when the other party applies
the CA's public key to the certificate; if it successfully decrypts
the CA's signature in the certificate it means the server or
client's public key in the certificate is vouched for by the CA.
Since you are trusting the CA, you implicitly accept that the
server or client you have connected to is who it says it is.

In role C a symmetric cipher is used to encrypt the bulk of
the traffic between the client and server. Symmetric ciphers are
significantly faster than asymmetric ciphers, which are not suited
for bulk encryption requirements. The shared secret key from role
one is used here as the key to encrypt and decrypt the data between
the two parties.

In role D a message digest algorithm
(usually MD5) is used to ensure that the data received has not been
altered in transit. A message digest is essentially a checksum of the message data: the data to be sent is
used as input to the message digest algorithm, which generates a
string of characters that is unique to that set of data. This
unique string is often called a fingerprint
and is attached to the data being sent. The other party takes the
received data, runs it through the same message digest algorithm
and compares the output to the fingerprint that was attached to the
data. If the fingerprints do not match then the data, the
fingerprint or both were altered between transmission and
reception.

I have left out a lot of details here for the sake of clarity
and brevity. If you really want to understand the precise details,
take a look at the resources listed at the end of this article.

For our purposes we are only concerned with the protocol
versions and ciphers that web browsers are capable of supporting.
You will want to support SSLv2 unless you are running an intranet
site where you can dictate what browsers will be required to access
your service (or you don't care whether most people can access your
site). SSLv2 is supported by Netscape Navigator 1.x/2.x and higher
and Microsoft Interent Explorer 3.x and higher, which covers most
of the people out there. Newer browsers that support SSLv3 also
support SSLv2.

You can look at the SSLv2 specification to determine what
encryption ciphers are available to that protocol. Alternatively
you can compile OpenSSL and use its ciphers command:

ALL includes all available ciphers; -SSLv3 and -TLSv1 remove these
protocols from the list. What is left is all SSLv2 ciphers supported
by OpenSSL.

The first field is the common name, or alias, of the cipher.
Both BSAFE and OpenSSL use the same aliases. The rest of the fields
are: the protocol that this cipher is used with, the cipher used
for authentication via certificates, the symmetric cipher used for
encrypting the traffic between client and server, and the message
authentication cipher.

There is a lot of confusion regarding the legal use of
encryption algorithms. Here is what I have been able to find out
about the legal status of the key encryption algorithms that can be
utilized by the SSLv2 protocol.

The patent for the RSA algorithm is owned by RSA Security
Incorporated (RSA Inc.). This patent was to expire on 20 September
2000; however, RSA Inc. placed the RSA algorithm into the public
domain on 6 September 2000 and it can be used by anyone in the
world without a license.

The RC2 and RC4 algorithms were developed by RSA Inc. The RC4
algorithm is probably the most commonly used cipher for encrypting
traffic between the web browser and server, followed by RC2.

I have read comments from others online who claim you need a
license from RSA Inc. to use RC2 and RC4 in the U.S. RSA Inc.
claims RC2 and RC4 as proprietary, not patented, algorithms. I'm
not sure how that affects its use in OpenSSL within the U.S. If the
algorithms were reverse-engineered, it is possible that both RC2
and RC4 can be used legally.

I asked Ulf Moeller, an OpenSSL developer, about RC2's legal
status, to which he replied:

The algorithm is completely unencumbered, the name "RC2" is a
trademark. It used to have the same status as RC4 (unpatented,
leaked trade secret), but it has since been publicly documented by
RSA in RFC 2268.

When asked about RC4's legal status, he responded:

RC4 is not patented. The name "RC4" is a trademark (not a
problem if you just use it on internal webservers), and the
algorithm used to be a trade secret. It was published in one of the
leading cryptography reference books, so it clearly is no longer
secret, but the description in the book is based on an anonymously
published source code that was probably obtained by reverse
engineering RSA software in violation of the license. Lots of
people are using RC4 without any trouble, but if you want to be
careful, consult a lawyer.

IDEA is a block cipher, an alternative to DES, that employs
128-bit keys. The patent on IDEA is owned by Ascom Tech AG, a Swiss
company and expires a long, long time from now. Although IDEA is
supported by SSLv2, I did not find it in the list of supported
ciphers for the Netscape 4.7 browser, so it's probably best to
avoid using it.

nsssl is supported by the AOLserver development team. It is only
capable of SSLv2, cannot handle client certificates and does not
give you the ability to configure which cipher suites to allow or
disallow from within the AOLserver configuration file. Finally, it
requires RSA's BSAFE library version 3.x, 4.x or 5.x.

The AOLserver binary distributions come with a precompiled copy
of the nsssl module called nsssle. This is the exportable SSL
module and is only capable of weak 40-bit encryption. The source
code distribution comes with the nsssl source code but lacks the
BSAFE encryption libraries needed to compile it.

AOL has a license from RSA Inc. to distribute an unlimited
number of copies of the 128-bit/1024-bit nsssl.so module to anyone
who asks as long as they assert that they are US citizens and are
not nationals or agents of foreign governments to which encryption
is embargoed, and do not intend to export or make the file
available to such individuals or countries.

If you fulfill these requirements you may request a binary copy
of the 128-bit module from AOL by sending email to
nsssl-request@aolserver.com. You will receive a message back with
questions you must respond to such as your organization's name and
tax identification number and what platforms you are requesting the
binary module for, as well as further instructions.

The response time is about five business days, but AOL asks that
you allow six weeks before resubmitting your request. You may also
have to wait up to six weeks if your request is for a platform not
readily available to the AOLserver development team.

You face two hurdles if you want to compile the nsssl module
yourself. First, you must obtain the BSAFE library. To compile the
nsssl module you will need to have RSA's BSAFE library version 3.x,
4.x or 5.x. AOL is not allowed to distribute the BSAFE library,
only precompiled executables that incorporate the library into
them. We were able to convince RSA Inc. to send us the BSAFE SDK,
maybe you can too.

The second hurdle is financial: when you are finished compiling
your application with BSAFE and are ready to use it, you must
purchase a license from RSA Inc. to do so.

The nsopenssl module was written by Stefan Arentz for a
pre-release of AOLserver 3.0 and requires the OpenSSL library. It
can handle SSLv3, SSLv2 and TLSv1, has client certificate support
and options to allow and disallow cipher suites and protocols via
the AOLserver configuration file.

Client certificates verify the client's identity to the server.
Using client certificates allows you to authenticate people connecting
to your site without having to maintain account passwords. This may be
useful for intranet sites where you can mandate client certificate
usage, but client certificates are not widespread enough for use with
public web sites. Another possibility is giving client certificates to
your web service administrators and making them mandatory for access
to administrative parts of your web service. The biggest drawback is
that client certificates must be installed into the web browser for
this to work though, making it an inconvenient to deploy.

There are two paths for embedding and using SSL within
AOLserver: with the BSAFE library and without it.

If you have the BSAFE library you will be able to use the nsssl
or nsopenssl module within AOLserver. nsssl requires the BSAFE
library. Although nsopenssl only works with OpenSSL, OpenSSL can be
patched to use the BSAFE library instead of its own encryption
ciphers.

If you don't have the BSAFE libary your only choice is to use
nsopenssl with the OpenSSL library.

To be absolutely sure you're running SSL legally you should
purchase a license and get a copy of the BSAFE library from RSA
Inc. to compile into your web server. There is no easy and
inexpensive way to do this. RSA Inc. is not interested in the
retail market; their focus is licensing their products to software
and hardware companies that will embed their code into applications
that will then be sold to the end-user. When we approached them to
purchase a license so we could run their BSAFE code in our web
servers they quoted us a price of US$15,000.

I have talked to an RSA Inc. representative, Ken LaFrankie,
about the possibility of having RSA Inc. create an inexpensive
end-user license and downloadable BSAFE library for those who want
to compile their own web servers. He replied that RSA doesn't have
the resources to create a marketing team and technical support for
end-users. My response was put it online, purchasable via credit
card, and have no tech support aside from the manuals, which could
also be online. He said he would bring it up at their next internal
meeting, but that was three months ago, and I haven't heard back
from him.

I don't know what the market for an end-user license would be, but
I would gladly pay up to $100 one. If you'd like to bend Ken's ear you
can call him at (703) 288-9300 extension 313, or email him at
klafrankie@rsasecurity.com.

It might be legal to purchase a copy of
Redhat Apache SSL (or any other packaged web server that comes with
a license to run RSA's software), put it on the shelf to collect
dust and compile RSA's BSAFE library into AOLserver.

The license agreement for Redhat's Apache SSL product gives you the
right to run the RSA Software on one computer, but does not
specify what operating system or web server application must be
used. It requires that you use the RSA Software only to secure
the communications between the web server and web browser via the
HTTPS protocol. This license agreement comes from Redhat, not RSA
Inc. If you decide to go this route, you still have to obtain the
BSAFE library.

It is possible to legally run SSL without paying any license fees
and without breaking any laws while supporting most of the SSL-capable
browsers by using nsopenssl. There are two cipher suites available in
SSLv2 that are unencumbered by patents or proprietary restrictions:
DES and Triple DES.

The DES and Triple DES ciphers are listed in the output from the
ciphers command we performed earlier:

You can force nsopenssl to use only these two ciphers by removing
the proprietary or patented ciphers from the OpenSSL library at
compile time or by specifying what ciphers to allow from within the
nsd.tcl configuration file.

Pull down AOLserver 3.1 and compile it by doing a make at the
top level of the source directory. AOLserver will install into
/usr/local/aolserver by default. You can override this by
specifying a PREFIX parameter:

make install PREFIX=/your/pathname

After that is completed you can compile and install one or more
of SSL options below.

If you want to run only the unrestricted ciphers you have two
options: configure nsopenssl to not use those ciphers in the
nsd.tcl file or compile OpenSSL without support for those
ciphers.

It is easier to alter the configuration file. The default
CipherSuite parameter shown next uses all ciphers except
non-authenticating ones (e.g. ADH), prefers RC4 and RSA algorithms
over all others and will use the highest strength possible with
SSLv3 or TLSv1. It will only use export ciphers and SSLv2 if that
is all the client can handle.

To find out what ciphers are being used for a session, connect
to your HTTPS port with Netscape, right-click on the page and
select View Info. This will tell you what cipher is being used to
encrypt the traffic between your client and server, among other
things.

Do not use Microsoft's Internet Explorer for this purpose. You can
right-click on the page and choose Properties which purports to tell
you what cipher you're connecting with, but it continues to give the
cipher used on the first connection to the site even after you change
the CipherSuite parameter, restart the web server and reload the
page. You have to completely exit MSIE and restart to get an accurate
result. Precious time wasted thanks to Microsoft, again.

If you want to be absolutely certain you aren't using restricted
ciphers, remove them from OpenSSL completely. To do this compile
and install OpenSSL with these parameters:

To build nsopenssl with BSAFE you must first build OpenSSL with
BSAFE. Pull down and unpack OpenSSL 0.9.5a and the Lymeware's OpenSSL BSAFE patch.

tar xzf openssl-0.9.5a.tar.gz
tar xzf openssl095a_bsafe_patch.tar.gz

Change into the OpenSSL directory and apply the BSAFE patch from
there:

cd openssl-0.9.5a
patch -p1 < ../OpenSSL-0.9.5a_BSAFE_patch

You will need to tell OpenSSL where the BSAFE include files and
library are, and where you want OpenSSL to be installed. If you
follow the README that comes with the BSAFE patch you need to check
the bsafe_install script to ensure the paths are correct before you
run it. I prefer to run config myself and usually put all of the
config parameters into a separate file and then run it through the
shell:

Run make, run the OpenSSL self-tests and then install the
library and executables:

make
make test
make install

Grab the latest nsopenssl module and unpack it so that the
nsopenssl source directory is at the same level as the aolserver
source directory.

Run make inside of nsopenssl and copy the resulting nsopenssl.so
binary to your server's installation directory. You must point to
the BSAFE library even though it has been compiled into OpenSSL; if
you don't, you'll receive unresolved symbol errors at run time when
you connect via HTTPS. I have modified nsopenssl's Makefile so that
you can compile with BSAFE by passing another argument to make:

Note that nsopenssl uses its own port parameter; it doesn't use
the httpsport parameter that you'll find at the top of your nsd.tcl
file. You can specify the timeout and session cache size or comment
out these links and take the defaults in the code.

Make sure the nsopenssl module is being loaded by placing this
line in the modules section:

The nsssl module was merged with nssock as of AOLserver 3.1 and
is built at compile time if you pass make the appropriate
parameters.

To compile the export version of nsssl with RSA's BSAFE 3.x
library:

make BSAFE=/path/to/bsafe/library

If you are using a newer version BSAFE add a parameter
specifying such. BSAFE 4.x and 5.x are supported:

make BSAFE=/path/to/bsafe/library BSAFE_VERSION=-DBSAFE4

To compile the domestic module add the SSL_DOMESTIC
parameter:

make BSAFE=/path/to/bsafe/library SSL_DOMESTIC=1

The export version is called nsssle.so and the domestic is
nsssl.so. Copy the shared object to the installed server's bin
directory. If you use the domestic version make sure you uncomment
the nsssl line in the nsd.tcl configuration file and comment out
the nsssle line:

nsssl is the AOL-supported solution for implementing SSL in
AOLserver but lacks SSLv3 capability and cannot handle client
certificates. The binary copy that comes with the distribution is
weak, 40-bit encryption, though you can request a binary copy of
the 128-bit version for your platforms directly from AOL.

nsopenssl is the only solution that has full SSLv3 capability and
client certificate support. With nsopenssl you have the flexibility to
use RSA's BSAFE or OpenSSL's library and the ability to run SSLv2
completely unencumbered by license fees or restrictions.

Reader's Comments

For nsopenssl: once you've generated the certificate and key files, put them in a new directory in the aolserver/modules directory called nsopenssl. Name them certfile.pem and keyfile.pem. (This info is from Scott)

-- Jade Rubick, September 29, 2000

The nsopenssl module is now considered (by me) to be production-quality. Testing still needs to be done on Solaris, but it passes with flying colors on Linux. I've added client certificate support and a Tcl interface.

S.Y.'s guide to setting up a self-signed certificate- One of S.Y.'s excellent how-to articles, this shows how to self-sign a certificate for Aolserver. It does not appear to be supported, but it worked for me. This link works, where his earlier one does not. (contributed by Jade Rubick)