Chapter 10, "Protecting Data in Transit," focused on how Secure Shell (ssh) prevents nosey users (local or remote) from capturing your system passwords with sniffers. This greatly enhances your internal network's security.
However, if you deploy your Linux system as an electronic commerce server, you must also provide your customers and support staff with secure connections from their Web clients in the outside world to your server. That's what this chapter is all about.
Despite early market projections, electronic commerce was no overnight success. Initially, this was due to the public's unfamiliarity with the Internet, but it eventually became clear that before online commerce could really take hold, Web-based communication had to be secure. Plainly, users were reticent to send credit card data over the Internet, with good reason.
By default, Web-based communication had several weaknesses:
HTTP offers no encryption mechanism, and therefore third parties can sniff traffic between clients and the server. Thus, the user's session offers little or no privacy.
HTTP is a stateless protocol: It doesn't store information on users, and therefore it cannot verify a user's identity.
HTTP provides no means to authenticate an ongoing session. Hence, it cannot determine whether a third, untrusted party has hijacked the current session.
To address these shortcomings, Netscape Communications developed the Secure Sockets Layer Protocol or SSL.
Secure Sockets Layer (SSL) is a three-tiered method that employs RSA and DES authentication and encryption, as well as additional MD5 integrity checking. Using these methods, SSL addresses all three issues inherent in Web-based communication:
At connection time, the client and server define and exchange a secret key, which is used to encrypt transiting data. Hence, even though SSL traffic can be sniffed, it is encrypted and therefore difficult to unravel.
SSL supports public key cryptography, so the server can authenticate users using popular schemes like RSA and the Digital Signature Standard (DSS).
The server can verify the integrity of ongoing sessions using message digest algorithms, like MD5 and SHA. Thus, SSL can guard against third parties hijacking a session.
SSL protects data through two layers and two steps. In the first, the client and server perform a handshake (similar to the TCP handshake). During this process, they exchange keys and then establish and synchronize a cryptographic state between them. Next, SSL takes application data (in the record layer) and encrypts it. Later, on the receiving end, this process is executed in reverse. As explained in the SSL Protocol Internet Draft:
SSL is a layered protocol. At each layer, messages may include fields for length, description, and content. SSL takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, and reassembled, then delivered to higher level clients.
(From The SSL Protocol, Version 3.0. Alan O. Freier (Netscape Communications), Philip Karlton (Netscape Communications), Paul C. Kocher (Independent Consultant), at http://home.netscape.com/eng/ssl3/ssl-toc.html.)
Note
SSL can also (as of version 3.0) verify a user's identity on the client end. To learn more, please see the SSL 3.0 specification, located at http://home.netscape.com/eng/ssl3/3-SPEC.HTM.
These features make SSL an excellent tool for securing electronic commerce transactions between a server under your control and unknown clients.
This chapter will take you through SSL installation and implementation.
SSL does have a significant security history, beginning in September 1995, when two Berkeley students—Ian Goldberg and David Wagner—announced that they had cracked Netscape's random number generator scheme.
This news rocked the electronic commerce community and prompted sensational media coverage. Here's an excerpt from a NY Times article by John Markoff titled "Security Flaw Is Discovered in Software Used in Shopping":
A serious security flaw has been discovered in Netscape, the most popular software used for computer transactions over the Internet's World Wide Web, threatening to cast a chill over the emerging market for electronic commerce. The flaw, which could enable a knowledgeable criminal to use a computer to break Netscape's security coding system in less than a minute, means that no one using the software can be certain of protecting credit card information, bank account numbers, or other types of information that Netscape is supposed to keep private during online transactions.[*]
Although Netscape quickly addressed the issue, the story serves as a sobering reminder that even excellent security tools can fail because of flawed implementation.
Goldberg and Wagner began their analysis in the dark, chiefly because Netscape held back source code on certain vital elements of SSL. The students therefore reverse-engineered the code, and in the process, they discovered a major flaw in how Netscape generated random numbers.
Random numbers have always been a problem in cryptography, even when functions used to derive them are fundamentally sound. This is because it is very difficult to generate a truly random number. In this context, the term random refers to a quality with minimal predictability. In science and nature, many systems and cycles that initially appear to be chaotic or random do in fact have observable predictability. Often, the key to recognizing that predictability, or recognizing a pattern in a seemingly patternless phenomenon, is time.
Note
A simple example of recognizing a pattern could involve children playing jump rope with two ropes. Here, you have several variables: two ropes and two children with two arms each. As they twirl and twist the ropes, it might seem to you that the number of revolutions per minute and the positional relationships between the ropes at any given time are random, or even chaotic. They're probably not. If you sample many uninterrupted hours of play with these same two children and two ropes, over time a discernable pattern will likely emerge.
Indeed, deriving truly random numbers is such a difficult process that scientists have turned to unconventional means. For example, some researchers have focused their studies on chaos theory, the mathematical study of chaotic structures. Perhaps the most interesting, offbeat step in this direction is the use of lava lamps to generate random numbers. To see such a project in action, visit LavaRand at SGI: http://lavarand.sgi.com/.
Meanwhile, to compensate for our current inability to computationally create truly random numbers without help from outside chaotic systems, programmers rely on a rather complex parlor trick. Instead of trying to derive a random number from natural phenomena, programmers use functions that generate normal numbers and subject them to mathematical operations so complicated that the average human cannot perceive the observable predictability within them. The resulting number is, for all purposes, random enough. Or is it?
Much depends on the steps that programmers take to derive this random—or more appropriately, pseudo-random—number. Every number has a starting point or seed source, and depending on your initial seed source, your so-called pseudo-random number may be fundamentally flawed from the start.
For instance, suppose that you derived your seed source from standard multiplication tables, 1×1 to 9×9. Here, you'd have 89 possible numbers, or multiplication values, to choose from. Anyone could quickly identify all 89 combinations, even without pen and paper. Your resulting number, therefore, would never be random enough. This was essentially at the heart of SSL's first vulnerability.
Goldberg and Wagner determined that Netscape was using three values to generate the seed source for the initial secret key:
A process ID (PID)
A parent process ID (PPID)
The time, in seconds and microseconds
Because local users can easily obtain process IDs on UNIX and Linux, Goldberg and Wagner needed only to ascertain the time. And, as they explained in their paper "Randomness and the Netscape Browser: How secure is the World Wide Web?", this was not very difficult:
Most popular Ethernet sniffing tools (including
tcpdump) record the precise time they see each packet. Using the output from such a program, the attacker can guess the time of day on the system running the Netscape browser to within a second.
(From "Randomness and the Netscape Browser: How secure is the World Wide Web?", Ian Goldberg and David Wagner, Dr. Dobb's Journal, 1996. http://www.ddj.com/articles/1996/9601/9601h/9601h.htm)
This effectively gave them the time in seconds. (Milliseconds, as they pointed out, were a trivial issue at best because there are only one million milliseconds per unit, a infinitesimally small range to search given today's computing power.) The end result was that Goldberg and Wagner could crack Netscape's early SSL in less than a minute in some cases.
Note
Different programming languages offer different means of pseudo-random number generation. Perl offers a generic rand, while C offers rand() and srand() (available from stdlib.h). See their respective man pages for more information.
If you're interested in seeing the old SSL attack in action, get an old 40-bit version of Netscape and run this code against SSL encrypted traffic: http://www.geocities.com/SiliconValley/Lakes/8760/crypt/unssl.c.txt. The code will extract the 16-byte master key for that session.
In 1997, various researchers, including Edward Felten's team at Princeton and Frank O'Dwyer of Rainbow Diamond Limited, determined that SSL-enabled browsers were vulnerable to Hyperlink Spoofing and man-in-the-middle attacks:
In hyperlink spoofing, the attacker generates hyperlinks that lead the user's client to believe that a secure connection to a secure server has been made, when in fact the connection is to another server, secure or otherwise. Learn more in O'Dwyer's paper, "Hyperlink Spoofing: An Attack on SSL Server Authentication," located at http://www.brd.ie/papers/sslpaper/sslpaper.html.
In a man-in-the-middle attack, the attacker redirects the user's client to a bogus "secure" server. The user's client dutifully connects, unaware that the destination is a copy of a legitimate Web site. Learn more in Felten's paper, titled "Web Spoofing: An Internet Con Game," located at http://ncstrl.cs.princeton.edu/Dienst/UI/2.0/Describe/ncstrl.princeton%2fTR-540-96.
Finally, SSL's more recent security history (June 1998) involved a peripheral issue: a vulnerability in RSA Laboratories' Public-Key Cryptography Standard #1 (PKCS#1). The flaw allowed attackers to recover information from SSL-encrypted sessions. The flaw has since been fixed. To get an excellent overview of how it worked, get Daniel Bleichenbacher's paper titled "Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1," available at http://www.bell-labs.com/user/bleichen/papers/pkcs.ps.
Despite these early problems, though, SSL ultimately emerged as the de facto standard for securing connections between Web clients and servers, and today many SSL implementations exist. Some of these are commercial, but as a Linux user you'll want a free SSL implementation with open source. Hence, this chapter focuses on Apache-SSL with SSLeay.
To install Apache-SSL, you'll need three things:
Apache 1.2.6 or better and source
SSLeay, available at ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/SSLeay-0.8.1b.tar.gz.
The Apache-SSL patches (
apache_1_2_6+ssl_1_17_tar.gzfor this example), available at ftp://ftp.ox.ac.uk/pub/crypto/SSL/Apache-SSL/.
You're probably wondering why I chose Apache 1.2.6 (or better) for this example. Here's why: Before writing Maximum Linux Security, I researched the things that irked readers most about consumer-oriented, mass-produced computer books. The number one gripe, it turned out, was that many such books contained installation procedures that readers could not easily reproduce. Often, code and configuration examples simply didn't work.
So, with this book, I resolved to test each example vigorously. If I found that a software author's installation procedure did not work smoothly, or if configuration of the same utility gave varied results on different Linux distributions or versions, I chucked it.
During testing, I found that SSleay's results substantially varied in version 0.9. To ensure that all readers could get a crack at setting up Apache-SSL error-free, I chose SSLeay version 0.8 instead. 0.8 worked equally well on multiple systems—old and new, a.out and ELF, Caldera and Red Hat—and it posed few installation and configuration problems.
However, I'm not suggesting that you should use Apache 1.2.6 and SSLeay 0.8 in an enterprise (or other sensitive) environment. Instead, I merely offer this example to familiarize a broader spectrum of users with Apache-SSL. After you skim through this step-by-step setup (or perhaps implement it), you'll fly through installations of newer versions that will undoubtedly be released after this book is printed. (Essentially, I offered this example strictly because I know that it will work on your system.)
Note
Note that SSLeay is free and legal for all non-commercial use. However, several legal issues are worthy of note. If you intend to use SSLeay for commercial purposes, you may need to obtain a license from RSA regarding use of RSA libraries. (The same is true if you compile in RC4 support.) Also, IDEA may carry legal issues when used in Europe. If you have any doubts, consult an attorney, or at least see the SSLeay FAQ at http://www.psy.uq.oz.au/~ftp/Crypto/.
To unpack SSLeay, copy SSLeay-0_8_1b_tar.gz to /usr/src, unzip the compressed file, and un-tar the archive:
cp SSLeay-0_8_1b_tar.gz /usr/src cd /usr/src gunzip SSLeay-0_8_1b_tar.gz tar-xvf SSLeay-0_8_1b_tar
SSLeay will extract to /usr/src/SSLeay-0.8.1b/. Next, change to that directory and run Configure:
cd /SSLeay-0.8.1b perl ./Configure linux-elf
Note that the preceding example is for Linux ELF systems only. If your architecture or target is different, start Configure without arguments and it will print a wide range of options:
# perl ./Configure Usage: Configure [-Dxxx] [-Lxxx] [-lxxx] os/compiler pick os/compiler from: BC-16 BC-32 FreeBSD NetBSD-sparc NetBSD-x86 SINIX-N VC-MSDOS VC-NT VC-W31-16 VC-W31-32 VC-WIN16 VC-WIN32 aix-cc aix-gcc alpha-cc alpha-gcc alpha400-cc bsdi-gcc cc debug debug-irix-cc debug-linux-elf dgux-R3-gcc dgux-R4-gcc dgux-R4-x86-gcc dist gcc hpux-cc hpux-gcc hpux-kr-cc irix-cc irix-gcc linux-aout linux-elf nextstep purify sco5-cc solaris-sparc-cc solaris-sparc-gcc solaris-sparc-sc4 solaris-usparc-sc4 solaris-x86-gcc sunos-cc sunos-gcc unixware-2.0 unixware-2.0-pentium
Note that in addition to architecture and binary targets, you can also set other options at the Configure command line, including
DES_PTR—Use this option to specify that during the build, you want to use pointer arithmetic instead of default array lookups in the DES incrypto/des/des_locl.h.DES_RISC1—Use this option to specify a differentDES_ENCRYPTmacro that helps reduce register dependencies (a good choice for RISC architecture). This will often produce faster performance on RISC processors.-DNO_BF—Use this option to build SSLeay without Blowfish support.-DNO_DES—Use this option to build SSLeay without DES/3DES support.-DNO_IDEA—Use this option to build SSLeay with no IDEA support.-DNO_MD2—Use this option to build SSLeay without MD2 support.-DNO_RC2—Use this option to build SSLeay with no RC2 support.-DNO_RC4—Use this option to build SSLeay with no RC4 support.
Note
Other, more obscure options also exist. For example, you can specify to use int instead of long in DES if need be. Check the SSLeay documentation for more information.
After you define your architecture and options, run Configure. In response, it will print out a brief summary of your pre-make configuration. Here's an example:
[root@linux7 SSLeay-0.8.1b]# perl Configure linux-elf CC =gcc CFLAG =-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -Wuninitialized EX_LIBS= BN_MULW=asm/x86-lnx.o DES_ENC=asm/dx86-elf.o asm/cx86-elf.o BF_ENC =asm/bx86-elf.o THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4_INDEX mode BF_PTR2 used
I recommend clipping and pasting these values into a temporary file. Some options on certain Linux systems can trigger a bad make. You may be forced to change them later, so it's nice to have them handy in that event.
Next, run make:
make
The make will take several minutes, but if you have ANSI C support installed, you shouldn't have any problems here. You'll know that you have a successful make when you see this message:
NOTE: The OpenSSL header files have been moved from include/*.h
to include/openssl/*.h. To include OpenSSL header files, now
to include/openssl/*.h. To include OpenSSL header files, now
directives of the form
#include <openssl/foo.h>
should be used instead of #include <foo.h>.
These new file locations allow installing the OpenSSL header
files in /usr/local/include/openssl/ and should help avoid
conflicts with other libraries.
To compile programs that use the old form <foo.h>,
usually an additional compiler option will suffice: E.g., add
-I/usr/local/ssl/include/openssl
or
-I/openssl-0.9.3a/include/openssl
to the CFLAGS in the Makefile of the program that you want to compile
(and leave all the original -I...'s in place!).
Please make sure that no old OpenSSL header files are around:
The include directory should now be empty except for the openssl
subdirectory.
After you verify that the make was successful, run this command:
make rehash
Finally, try a test, like this:
make test
Here you may encounter problems. On some systems, the optimization flags in the Makefile will cause the test to fail. If that happens, edit the Makefile and remove the optimization flag from the CLFAGS option line.
Depending on your system's configuration, the relevant line will be either line 59 or 60, whichever is not commented out:
CFLAG= -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -Wuninitialized
Here is the optimization flag to remove:
-03
After you remove the optimization flag, start again (make clean; make) and everything should be fine.
Caution
On Caldera OpenLinux 1.2, even if you change the -03 optimization flag, the make test will fail during the randtest procedure. Apparently, SSLeay doesn't like 1.2's random. I tried compiling several different versions of SSLeay on OpenLinux 1.2, without success. However, the packages compiled cleanly and without event on Red Hat 5.1. I can only conclude that the problem is with OpenLinux 1.2 and not SSLeay. The solution is to obtain a more recent version of OpenLinux.
You'll know when your make test is clean because you'll see this message:
Signed certificate is in newcert.pem newcert.pem: OK make[1]: Leaving directory '/SSLeay-0.9.0b/test' SSLeay 0.9.0b 29-Jun-1998 built on Wed Jun 30 01:20:01 PDT 1999 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int) blowfish(ptr2) C flags:gcc -DL_ENDIAN -DTERMIO -DBN_ASM -O3 -fomit-frame-pointer -m486 -Wall -Wuninitialized -DSHA1_ASM -DMD5_ASM -DRMD160_ASM
Once you verify that your test was successful, install the package, like this:
make install
Next, copy apache_1_2_6_tar.gz (or a later version) to /usr/src and unpack it:
cp apache_1_2_6_tar.gz /usr/src cd /usr/src gunzip apache_1_2_6_tar.gz tar -xvf apache_1_2_6_tar
Apache will unpack to /usr/src/apache-1.2.6/. After you verify that it unpacked correctly, copy apache_1_2_6+ssl_1_17_tar.gz to /usr/src/apache-1.2.6 and unpack it:
cp apache_1_2_6+ssl_1_17_tar.gz /usr/src/apache-1.2.6 cd /usr/src/apache-1.2.6 gunzip apache_1_2_6+ssl_1_17_tar.gz tar -xvf apache_1_2_6+ssl_1_17_tar
This should unpack the following files:
ben.pgp.key.asc—The author's PGP public key.EXTRAS.SSL—Documentation on extra features.md5sums—MD5 checksums for these files (usingmd5sum).md5sums.asc—The author's detached signature ofmd5sums.README.SSL—A brief overview.SECURITY—Reflections on SSL and security.src/apache_ssl.c—An extra module for Apache.SSLconf/conf/access.conf—An empty Apache access configuration file.SSLconf/conf/httpd.conf—A samplehttpd.conffile.SSLconf/conf/mime.types—A samplemime.typesconfiguration file.SSLconf/conf/srm.conf—An emery Apachesrmconfiguration file.
After verifying that the files have unpacked properly, and before compiling Apache, apply the supplied patch, like this:
patch -p1 < SSLpatch
Next, change to /usr/src/apache-1.2.6/src/, copy Configuration.tmpl to Configuration, and open Configuration for editing. In it (among other possible things), you must change the SSL_BASE variable. This tells Apache where to find the SSL libraries during compilation. To change that value, open Configuration and go to line 63. It should look like this:
#SSL_BASE= /u/ben/work/scuzzy-ssleay6
Change this to the SSLeay source directory. For this example, I changed mine to this:
SSL_BASE=/usr/src/SSLeay-0.8.1b
Once you set the SSL_BASE variable and exit, you're ready to make Apache:
make
To verify that your make went smoothly, check /usr/src/apache_1.2.6/src for the following file:
-rwxr-xr-x 1 root root 543482 Jun 30 04:00 httpsd
If it exists, you're in business. Time to move on to certificate generation.
Before you can generate a certificate, you must first configure ssleay.cnf. To do so, change to /usr/local/ssl/lib/. Here's what the file looks like by default:
# SSLeay example configuration file. # This is mostly being used for generation of certificate requests. # RANDFILE = $ENV::HOME/.rnd #################################################################### [ ca ] default_ca = CA_default # The default ca section #################################################################### [ CA_default ] dir = ./demoCA # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number crl = $dir/crl.pem # The current CRL private_key = $dir/private/cakey.pem# The private key RANDFILE = $dir/private/.rand # private random number file x509_extensions = x509v3_extensions # The extensions to add to the cert default_days = 365 # how long to certify for default_crl_days= 30 # how long before next CRL default_md = md5 # which md to use. preserve = no # keep passed DN ordering # A few difference way of specifying how similar the request should look # For type CA, the listed attributes must be the same, and the optional # and supplied fields are just that :-) policy = policy_match # For the CA policy [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional # For the 'anything' policy # At this point in time, you must list all acceptable 'object' # types. [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional #################################################################### [ req ] default_bits = 1024 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes attributes = req_attributes [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = AU countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Some-State localityName = Locality Name (eg, city) 0.organizationName = Organization Name (eg, company) 0.organizationName_default = Internet Widgits Pty Ltd # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default = CryptSoft Pty Ltd organizationalUnitName = Organizational Unit Name (eg, section) #organizationalUnitName_default = commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 40 [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 unstructuredName = An optional company name [ x509v3_extensions ] nsCaRevocationUrl = http://www.cryptsoft.com/ca-crl.pem nsComment = "This is a comment" # under ASN.1, the 0 bit would be encoded as 80 nsCertType = 0x40 #nsBaseUrl #nsRevocationUrl #nsRenewalUrl #nsCaPolicyUrl #nsSslServerName #nsCertSequence #nsCertExt #nsDataType
You must determine what these values should be. Some will be hard-coded into your certificate and displayed when visitors connect. However, you can set just a few and define the rest in interactive mode when you generate your certificate. For example, you could use a brief file, like this:
# The following variables are defined. For this example I will
#populate the various values
[ req ]
default_bits = 512 # default number of bits to use.
default_keyfile = testkey.pem # Where to write the generated keyfile
# if not specified.
distinguished_name= req_dn # The section that contains the
# information about which 'object' we
# want to put in the DN.
attributes = req_attr # The objects we want for the
# attributes field.
encrypt_rsa_key = no # Should we encrypt newly generated
# keys. I strongly recommend 'yes'.
# The distinguished name section. For the following entries, the
# object names must exist in the SSLeay header file objects.h. If they
# do not, they will be silently ignored. The entries have the following
# format.
# <object_name> => string to prompt with
# <object_name>_default => default value for people
# <object_name>_value => Automatically use this value for this field.
# <object_name>_min => minimum number of characters for data (def. 0)
# <object_name>_max => maximum number of characters for data (def.
inf.)
# All of these entries are optional except for the first one.
[ req_dn ]
countryName = Country Name (2 letter code)
countryName_default = AU
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Queensland
Once you define your desired options, return to /usr/src/apache_1.2.6/src and issue the following command:
make certificate
Here, SSLeay will walk you through the process interactively:
[root@linux7 apache_1.2.6]# cd /usr/src/apache_1.2.6/ [root@linux7 apache_1.2.6]# cd src [root@linux7 src]# make certificate /usr/src/SSLeay-0.8.1b/apps/ssleay req -config /usr/src/SSLeay-0.8.1b/crypto/conf/ssleay.cnf -new -x509 -nodes -out ../SSLconf/conf/httpsd.pem -keyout ../SSLconf/conf/httpsd.pem; ln -sf ../SSLconf/conf/httpsd.pem ../SSLconf/conf/'/usr/src/SSLeay-0.8.1b/apps/ssleay x509 -noout -hash < ../SSLconf/conf/httpsd.pem'.0 Using configuration from /usr/src/SSLeay-0.8.1b/crypto/conf/ssleay.cnf Generating a 512 bit RSA private key ..................+++++ ....+++++ writing new private key to '../SSLconf/conf/httpsd.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]: State or Province Name (full name) [Queensland]:California Locality Name (eg, city) []:Malibu Organization Name (eg, company) [Mincom Pty Ltd]:Macmillan Publishing Organizational Unit Name (eg, section) [MTR]:SAMS Common Name (eg, YOUR name) []:Anonymous Email Address []:[email protected]
This will generate your certificate (httpsd.pem) and place it here:
/usr/src/apache_1.2.6/SSLconf/conf/httpsd.pem
You're nearly done. Now you need to configure httpsd's startup files.
You'll find sample configuration files (access.conf-dist, httpd.conf-dist, and srm.conf-dist) in /usr/src/apache_1.2.6/conf. These files are actually empty in some SSLeay distributions, but don't worry. In many respects, you can set options in these files precisely as you would for a normal Apache install.
The directives and options that differ from standard Apache values point to various resources (like your certificate). Here's a very lightweight example:
ServerType standalone Port 80 Listen 443 User webssl Group webssl ServerAdmin [email protected] ServerRoot /var/httpd/ ErrorLog logs/error_log TransferLog logs/access_log PidFile logs/httpd.pid ServerName linux7.samshacker.net MinSpareServers 3 MaxSpareServers 20 StartServers 3 SSLCACertificatePath /var/httpd/conf SSLCACertificateFile /var/httpd/conf/httpsd.pem SSLCertificateFile /var/httpd/conf/httpsd.pem SSLLogFile /var/httpd/logs/ssl.log SSLCacheServerPort 8080 SSLCacheServerPath /usr/src/SSLeay-0.8.1b SSLSessionCacheTimeout 10000
Note that in order for the server to find your certificates, you must specify the correct directory and ensure that the certificates are actually there. For example, if you define this as your certificate file:
SSLCertificateFile /var/httpd/conf/httpsd.pem
you must copy httpsd.pem from here:
/usr/src/apache_1.2.6/SSLconf/conf/httpsd.pem
/var/httpd/conf/httpsd.pem
Lastly, before installing httpsd to its final resting place (and cleaning up), you should test your server. To do so, issue the httpsd command plus the -f flag defining your configuration file's location. For example:
httpsd -f /var/httpd/conf/httpd.conf
or
httpsd -f /usr/src/apache_1.2.6/conf/httpd.conf
In response, httpsd will start up:
./httpsd -f /usr/src/apache_1.2.6/conf/httpd.conf Reading certificate and key for server linux7.samshacker.net:8080 PID 1342
To test-drive your new Apache-SSL server, crank up Netscape Communicator and connect to the port you assigned httpsd to. If your server is running correctly, Netscape will notify you with a New Cite Certificate window. Please see Figure 15.1.
Choose Next to examine details about the certificate. In response, Netscape Communicator will report the certificate's owner, signer, and encryption strength. Please see Figure 15.2.
To see expanded certificate information, choose More Info. Here, Communicator will display the identity, distinguished name, location, and duration of validity for the current certificate. Please see Figure 15.3.
Because it doesn't initially recognize the certificate, Communicator will next prompt you to accept or decline it for the current sessions. Please see Figure 15.4.
If you choose to accept the certificate, Netscape will advise you that even though the current session will be encrypted, it may not necessarily protect you from fraud. And by default, Netscape highlights the option to notify you whenever you send data to the server. Please see Figure 15.5.
Finally, when you accept the certificate, Netscape will notify you that the current session is being encrypted but that you can later decide not to trust the certificate. Please see Figure 15.6.
Fine-tuning your Apache-SSL configuration works in precisely the same manner as with traditional Apache. In fact, from a configuration viewpoint, Apache-SSL takes nothing away but instead adds several features. For example, in addition to traditional Apache environment variables, Apache-SSL supports SSL-centric environment variables. These are summarized in Table 15.1.
Table 15.1. Apache-SSL Environment Variables
You can grab and display these environment variables from CGI scripts in the usual way. For example, from a PERL script:
print "$ENV{'SSL_CLIENT_CERT'}
";
print "$ENV{'SSL_CIPHER'}
";
or, in C:
char *myvariable
myvariable=getenv("SSL_CLIENT")
And finally, Apache-SSL supports several SSL-centric configuration directives, the majority of which go into httpd.conf, access.conf, or .htaccess. These are summarized in Table 15.2.
Table 15.2. Apache-SSL Directives
If you're planning to use Linux to establish an electronic commerce server, you should obtain certificates from a recognized certificate authority—a trusted third party that issues certificates and verifies their authenticity. Such certificates can greatly enhance your firm's credibility and help it meet the often-stringent requirements to be an electronic commerce trading partner.
Pricing schemes vary, but nearly all established certificate authorities demand that you produce legal proof that you're authorized to use your firm's legal business name in transactions. Typical examples are
Here are some established certificate authorities:
Entrust Technologies offers one-year SSL certificates for $299.00. (Interestingly, Entrust claims that some 40 million root certificates from their competitors will expire within Web clients on December 31, 1999. Entrust's will not.) Learn more at http://www.entrust.net/products/index.htm.
EuroSign is the European Certification Authority. According to its Web site, EuroSign is still becoming organized. Learn more at http://www.eurosign.com/.
GTE offers the GTE CyberTrust SSL certificate (with a free demo version) for $99.00 for six months. Check it out at http://www.cybertrust.gte.com/cybertrust/index.html.
The Thawte Consulting Certification Division offers personal and server certificates. SSL Server certificates are $125.00 a year, and personal certificates are free. However, some words of warning: Thawte asks for very personal data, including your driver's license, passport, social security number, date of birth, and home address. This isn't my cup of tea (obviously), but because of Thawte's stringent requirements, their certificates are well-accepted and offer high assurance. Check out Thawte's services at http://www.thawte.com/certs/.
VeriSign is probably the best-known certificate authority and offers SSL certificates for 50 different Web servers (including Apache-SSL using SSleay). VeriSign's Secure Site option (standard SSL) is $349.00 for the first year. Find out more at http://www.verisign.com/server/index.html.
Xcert International provides digital certificate services primarily to business and government entities. Learn more at http://www.xcert.com/software/index.html.
Apache-SSL is not the only available SSL implementation, but it's an excellent learning tool. Not only can you learn how to secure Web-based electronic commerce transactions, but because the SSLeay source is open, you can also see how various algorithms are used in authentication.
Note
Although SSL is the prevailing system today for encrypting client-to-server interaction, other secure transaction standards and protocols exist. One is Secure Electronic Transaction, or SET, a system sponsored by IBM, MasterCard, and Visa. SET (designed specifically for credit-card transactions) emerged with much fanfare and has been a favorite of banks, credit card companies, and other large financial institutions.
However, SET has not yet taken the Internet by storm. One contributing factor is that in SET transactions, all participants know their trading partners' identities. (Each participant possesses a personal or business digital certificate.) But SET offers some advantages from a consumer's viewpoint. Consumers are issued a wallet, a helper application that stores and transmits their verified identities and financial information to SET-enabled remote servers. In this respect, a SET transaction resembles whipping out your wallet or pocketbook to pay for goods. I personally don't like it, but depending on your field, SET could be a suitable electronic commerce solution for you. To learn more, find the full SET specification at http://www.setco.org/set_specifications.html.
Finally, to learn more about SSL, check out the following resources.
Analysis of the SSL 3.0 Protocol, David Wagner and Bruce Schneier. This paper offers an in-depth look at SSL's protocol and its security implications. It's at http://www.counterpane.com/ssl.html.
Introducing SSL and Certificates. This document describes the fine points of SSL certificates. It's at http://www.ultranet.com/~fhirsch/Papers/cook/ssl_intro.html.
Securing Communications on the Intranet and Over the Internet, Taher Elgamal, Jeff Treuhaft, and Frank Chen, Netscape Communications Corporation. This document offers good coverage of SSL, authentication, and certificates. It's at http://www.go-digital.net/whitepapers/securecomm.html.
The Secure Sockets Layer Protocol and Applications, Allan Schiffman, Terisa Systems, Inc. Schiffman offers a comprehensive slide presentation. It's at http://www.terisa.com:80/presentations/ams/ssl/index.htm.
The SSLeay Certificate Cookbook. This document covers how to set up SSLeay to use it as a certificate authority, and how to create and install server and client certificates. It's at http://www.ultranet.com/~fhirsch/Papers/cook/ssl_cook.html.
The SSL-Talk FAQ. The Secure Sockets Layer Discussion List FAQ v1.1.1 offers answers to many questions about SSL's protocol, design, and implementation. It's at http://www.consensus.com/security/ssl-talk-faq.html.
SSL-based solutions are excellent when you're protecting client-to-server interaction. However, in enterprise environments, you may need something that focuses more on protecting network-to-network interaction. For this, you'll almost certainly want IPSEC.
IPSEC is the Internet Protocol Security Option, a system that applies encryption and session integrity checking for IP datagrams. Originally developed for sensitive environments like defense networks, IPSEC is now used to shield data traveling between two or more networks and is a key component of virtual private networks.
Note
VPN technology allows companies with leased lines to form a closed and secure circuit between themselves over the Internet. In this way, such companies ensure that data passed between them and their counterparts is secured via encryption and shielded from third parties. Many firms save thousands of dollars a year this way by eliminating their leased lines.
IPSEC is superior to competing solutions in many ways. For example, because IPSEC performs encryption and authentication at the packet level, it is largely platform- and application-neutral. This has wide implications because IPSEC can transparently protect many different kinds of network traffic.
Currently, there are three free IPSEC implementations to choose from:
FreeS/WAN (Secure Wide Area Network)—A project to deliver an IPSEC and IKE implementation for Linux.
NIST Cerberus—An IPSEC reference implementation for Linux; a fully operational IPSEC that provides host-to-host, host-to-router, and router-to-router IPSEC services.
Linux x-kernel IPSEC from the University of Arizona—This project is no longer active, but source code is still available. Learn more at http://www.cs.arizona.edu/security/hpcc-blue/linux.html.
Establishing IPSEC-enabled network interaction is beyond the scope of this book. The subject could easily demand a separate volume, devoted strictly to this. But if you're interested in how IPSEC works, go to the source: http://www.ietf.org/ids.by.wg/ipsec.html.
SSL is sufficient to protect your client-to-server traffic from third-party eavesdropping, and you can even use SSL libraries to enable other applications with SSL functionality. But sometimes, the folks driving the client are the enemy. In this case, SSL cannot protect you. Instead, you must rely on secure programming techniques to shield your server from attack. That's what the next chapter is all about.