Apache based WebDAV Server with LDAP and SSL
Prev

6. Implementing and using SSL to secure WebDAV traffic

Security of the data stored on a file server is very important these days. Compromised data can cost thousands of dollars to company. In the last section, we compiled LDAP authentication module into the Apache build to provide a Authentication mechanism. However HTTP traffic is very insecure, and all data is transferred in clear text - meaning, the LDAP authentication (userid/passwd) will be transmitted as clear text as well. This create a problem. Anyone can sniff these userid/passwd and gain access to DAV store. To prevent this we have to encrypt HTTP traffic, essentially HTTP + SSL or HTTPS. Anything transferred over HTTPS is encrypted, so the LDAP userid/passwd can not be sniffed. HTTPS runs on port 443. The resulting build from the last section's compilation process will have Apache to listen to both port 80 (normal HTTP) and 443 (HTTPS). If you are just going to use this server for DAV, then I will highly suggest that you close port 80. In this section of the HOWTO I will provide some information regarding SSL and maintaining SSL on a WebDAV server. However this is a not limited to a DAV server, it can be used on any web server.

6.1. Introduction to SSL

SSL (Secure Socket Layer) is a protocol layer that exists between the Network Layer and Application layer. As the name suggest SSL provides a mechanism for encrypting all kinds of traffic - LDAP, POP, IMAP and most importantly HTTP.

The following is a over-simplified structure of the layers involved in SSL.
+-------------------------------------------+ | LDAP | HTTP | POP | IMAP | +-------------------------------------------+ | SSL | +-------------------------------------------+ | Network Layer | +-------------------------------------------+

6.1.1. Encryption algorithms used in SSL

There are 2 kinds of encryption algorithms used in SSL.

Public-Private Key Crytography - Initiating SSL connection: This algorithm is used for initiating the SSL session. In this algorithm, the encryption must be performed using the Public Key, and the decryption can only be performed using the Private Key. The Web-server holds the private Key, and sends the Public key to the client. The public key is sent to the client in a certificate.

The client request content from the Web Server using HTTPS.
The web server responds with a Certificate which includes the server's public key.
The client check to see if the certificate has expired.
Then the client checks if the Certificate Authority that signed the certificate, is a trusted authority listed in the browser. This explains why we need to get a certificate from a a trusted CA.
The client then checks to see if the Domain Name of the web server matches the Comman Name (CN) on the certificate?
If everything is successful the SSL connection is initiated.

Symmetric Cryptography - Actuall transmission of data: After the SSL connection has been established, Symmetric cryptography is used to encrypting data. Public-Private Key cryptography is CPU cycle intensive, so Symmetric cryptography is used. In symmetric cryptography the data can be encrypted and decrypted using the same key. The Key for symmetric cryptography was exchange in the initiation process.

6.2. Test Certificates

While compiling Apache we created a test certificate. We used the makefile provided by mod_ssl to create this custom Certificate. We used the command:
# make certificate TYPE=custom

This certificate can be used for testing purposes.

6.3. Certificates for Production use

For production use you will need a certificate from a CA. CA or Certificate Authorities are certificate vendors, who are listed as a Trusted CA in user's browser client. As mentioned in the Encryption Algorithms section, if the CA is not listed as a trusted authority, your user will get a warning message when trying to connect to a secure location.

6.4. How to generate a CSR

CSR or Certificate Signing Request must be sent to the trusted CA for signing. This section discusses howto create a CSR, and send it to the CA of your choice.

cd /usr/local/apache/conf/
/usr/local/ssl/bin/openssl req -new -nodes -keyout private.key -out public.csr

At this point you will be asked several about your server location, to generat the Certificate Signing Request

Note: You Common Name is the DNS name of your webserver e.g. dav.server.com . If you put in anything else, it will NOT work. Remember the passwd that you use, for future reference.

Once the process is complete, you will have private.key and a public.csr . At this pointe the public.key is not encrypted. To encrypt"

mv private.key private.key.unecrpyted
/usr/local/ssl/bin/openssl rsa -in private.key.unecrpyted -des3 -out private.key

6.5. Removing passphrase from the RSA Private Key

RSA Private Key stored on the webserver is usually encrypted, and you need a passphrase to parse the file. That is why you are prompted for a passphrase when start Apache with modssl:

# apachectl startssl Apache/1.3.23 mod_ssl/2.8.6 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order to read them you have to provide us with the pass phrases. Server your.server.dom:443 (RSA) Enter pass phrase:

Encrypting the RSA Private Key is very important. If somebody gets hold of the you "Unencrypted RSA Private Key" he/she can easily impersonate your webserver. If the Key is encrypted, the hacker can not do anything without the passphrase.

However encrypting the Key can sometimes be nuisance, since you will be prompted for a passphrase everytime you start the web-server. Specially if you are using rc scripts to start the webserver at boot time, the prompt for passphrase creates problems.

You can get rid of the passphrase prompt easily by decrypting the Key. However make sure that no one can hold of this Key. I would recommend Hardening and Securing guidelines be followed before decrypting the Key on the webserver.

To decrypt the Key:

First make a copy of the encrypted key

# cp server.key server.key.cryp

Then re-write the key with encryption. You will be prompted for the original encrypted Key passphrase

# /usr/local/ssl/bin/openssl rsa -in server.key.cryp -out server.key read RSA key Enter PEM pass phrase: writing RSA key

One way to secure the decrypted Private Key is to make readable only by the root:
# chmod 400 server.key

6.6. Trusted Certificate Authorities

The following is list of Certificate Authorities that are trusted by the various browsers: