ArsDigita Archives
 
 
   
 
spacer

SSL, SSLv3, and Client-side Certificates with AOLserver

by Scott S. Goodwin (scott@scottg.net)

Submitted on: 2000-09-12
Last updated: 2000-09-12

ArsDigita : ArsDigita Systems Journal : One article

Outline

Introduction

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

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.

SSL Versions

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.

Cipher Basics

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.

Ciphers and SSL

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:

  1. key exchange (asymmetric ciphers: RSA for SSLv2, RSA or DH for SSLv3)
  2. authentication (asymmetric ciphers if authentication is required: RSA, DH, DSS; none if authentication is optional)
  3. cipher (symmetric cipher: RC2, RC4, RC5, Triple DES, IDEA and others)
  4. MAC digest (SHA-1, MD5)

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.

Cipher Support in SSLv2

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: 

% openssl ciphers -v 'ALL:-SSLv3:-TLSv1'

RC4-64-MD5        SSLv2 Kx=RSA      Au=RSA  Enc=RC4(64)   Mac=MD5 
DES-CBC3-MD5      SSLv2 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=MD5 
DES-CBC-MD5       SSLv2 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=MD5 
IDEA-CBC-MD5      SSLv2 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=MD5 
RC2-CBC-MD5       SSLv2 Kx=RSA      Au=RSA  Enc=RC2(128)  Mac=MD5 
EXP-RC2-CBC-MD5   SSLv2 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
RC4-MD5           SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5 
EXP-RC4-MD5       SSLv2 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export

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.

Ciphers and the Law

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.

RSA Algorithm

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.

RC2 and RC4 Algorithms

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.

DES and Triple DES

IBM, the owner of the patent for DES, placed DES in the public domain (the patent has now expired anyway).

I could not find a patent on Triple DES so I'm willing to assume that it is also in the public domain.

IDEA

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.

MD5

MD5 was developed by RSA Inc., but I could find no patent information on it. It is openly used by many applications both open source and prepackaged. You can use it freely.

SSL and AOLserver

AOLserver is capable of using SSL via one of two modules: nsssl or nsopenssl.

The nsssl Module

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

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.

Your Options for Legally Using SSL with AOLserver

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.

Obtain A License from RSA Inc.

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.

Purchase Redhat's Apache SSL

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.

Use Only Free or Unpatented, Non-proprietary Ciphers

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: 

DES-CBC3-MD5      SSLv2 Kx=RSA    Au=RSA  Enc=3DES(168) Mac=MD5 
DES-CBC-MD5       SSLv2 Kx=RSA    Au=RSA  Enc=DES(56)   Mac=MD5

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.

Implementing SSL in AOLserver

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.

Compiling nsopenssl

Grab the latest copy of OpenSSL and compile and install it according to the given directions.

Then pull down the nsopenssl module from the AOLserver Modules page or from my site. 

make OPENSSL=/path/to/openssl

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. 

ns_param CipherSuite  "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP"

To disallow use of the restricted ciphers use the following line: 

ns_param CipherSuite  "ALL:!ADH:!RC2:!RC4:!RC5:!IDEA:+HIGH:+MEDIUM:+LOW:+EXP"

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: 

./config \
        no-rc2 no-rc4 no-rc5 no-idea \
        threads \
        --prefix=/p/d/openssl-0.9.5a-clean \
        --openssldir=/p/d/openssl-0.9.5a-clean

Edit the nsopenssl Makefile, comment out this line: 

CFLAGS   =  -I$(OPENSSL)/include

and uncomment this line: 

CFLAGS   =  -I$(OPENSSL)/include -DNO_RC2 -DNO_RC4 -DNO_RC5 -DNO_IDEA

Compile nsopenssl by pointing make to clean OpenSSL library: 

make OPENSSL=/p/d/openssl-0.9.5a-clean
cp nsopenssl.so /your/installed/aolserver/bin

Compiling nsopenssl with BSAFE

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: 

#!/bin/sh

./config \
        threads \
        bsafe \
        -I/p/d/bsafe-4.3/include \
        -L/p/d/bsafe-4.3/lib \
        -lbsafe \
        --prefix=/p/d/openssl-0.9.5a-bsafe4.3 \
        --openssldir=/p/d/openssl-0.9.5a-bsafe4.3

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: 

cd nsopenssl
make OPENSSL=/p/d/openssl-0.9.5a-bsafe4.3 BSAFE=/p/d/bsafe-4.3
cp nsopenssl.so /your/installed/aolserver/bin

Configure nsopenssl by putting something like this in your nsd.tcl file: 

#
# nsopenssl (HTTPS)
#
ns_section "ns/server/${servername}/module/nsopenssl"
ns_param port                443
ns_param hostname            myhost.com
ns_param CertFile            certfile.pem
ns_param KeyFile             keyfile.pem
ns_param Debug               off
ns_param SessionCacheSize    2048
ns_param SessionCacheTimeout 300
ns_param Protocol            "SSLv2, SSLv3, TLSv1"
ns_param CipherSuite         "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP"

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: 

ns_param   nsopenssl      ${bindir}/nsopenssl${ext}

Compiling nsssl

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: Only loads if keyfile.pem and certfile.pem exist.
#set sslmodule              nsssl${ext}  ;# Domestic 128-bit/1024-bit SSL.
set sslmodule              nsssle${ext} ;# Exportable 40-bit/512-bit SSL.
set sslkeyfile   ${homedir}/servers/${servername}/modules/nsssl/keyfile.pem
set sslcertfile  ${homedir}/servers/${servername}/modules/nsssl/certfile.pem

Certificate and key files must exist for the nsssl module to load.

Summary

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.

Credits

Thanks to the following people for their assistance:

  • Stefan Arentz
  • Mark Bixby at Hewlett-Packard
  • Mike Kobar at Lymeware
  • Richard Levitte at OpenSSL.org
  • Kriston J. Rehberg at AOL
  • John Rousseau
  • Daniel P. Stasinski at Karemor

More

Code and Information:

General SSL Information:

asj-editors@arsdigita.com

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.

See http://scottg.net for details.

-- Scott Goodwin, November 21, 2000

For more security info and configuration on Netscape 4.7x browsers, including viewing and disabling SSL v2 and v3 ciphers, select the 'Communicator' -> 'Tools' -> 'Security info' menu option. Then select 'Navigator'.

-- Arjun Sanyal, December 28, 2000

Related Links
spacer