Secure Socket Layer: Encode and certify with SSLeay
Holger Reif
For many users the SSL protocol is an interesting matter. Since there has been Netscape Navigator, it has been possible - with the help of the Secure Socket Layer - to hide things from the wrong eyes, that's snoopers with packet sniffers, and control where they surf and which files get sent over the Net. However, it's more important that SSL also makes the basic access control (Basic Authentication Scheme) secure. For a long time there were only appropriate Web servers available for a lot of money (> $1000), which above all represents a slimmed down export version of the full American program with a 40 bit encryption key. But there are two exceptions: the Apache and NCSA server can both communicate with Netscape Navigator or a patched Mosaic via SSL. But since then numerous 'Full Crypto Servers' have appeared, with imposing names such as Sioux or Zeus. This article shows how communication with SSL can be used, for example under Linux.
It started in Australia
The solution to the problems with the US American export limitations came from 'down under'. Over a year ago the Australian Eric Young, who, as he himself wrote, was thankful to have found a worthwhile aim for his programming urge, began with the implementation a library for making available all the necessary routines for a SSL application. The project, called SSLeay, went splendidly. Tim Hudson, likewise from the fifth continent, delivered patches for various public domain programs, so that the most important Internet services, WWW, Telnet and FTP, are available with SSL. The library itself is stable, the interface of its routines and the functionality of the provided programs on the other hand are still subject to changes. The thus far provided documentation is quite incomplete, the best documentationcurrently available is the source code itself. Through direct contact to the developers however, bugs can be overcome. There is also help via a mailing list (see the box sources).
Now there are others that use the package. Sameer Parekh (for USA) and Ben Laurie (for the rest of the world) have appropriately modified the source of the Apache server. Christoph Martin from Mainz University has transformed the sources of the BSD Telnet package to SSL MZtelnet. The current version of SSLeay - as this was prepared - carries version number 0.5.1b and runs on various platforms, including Linux. The now available, brand new, version 0.5.2 contains a few new bugs and some problems in working with old applications, so that users who don't want to beta test should wait until the corrected version 0.5.2a is available. Release 0.5.4d is to be recommended as a starting point because in later versions the conversion of the text representation into the certificate's binary PEM format is no longer supported in the way described in the text. For the procedure under version 0.5.1b see the 'new features' box.
After compiling SSLeay (see the note in the box 'a little manual work') the first SSL encrypted transmission can begin. For test purposes the directory apps contains the programs s_server and s_client (from now the directory apps is taken as base). The server program starts on one terminal, on a second one on the same computer, the client. After a successful CONNECT by the client (the error for checking the certificate here can be safely ignored) the server and client can exchange characters. An EOF (Ctrl-D) ends the connection and the server is ready for a new try.
To be able to understand the error a more exact look at the use of certificates (see box 'publically legal') within SSLeay is necessary. Without parameters s_server reads the file server.pem. This contains the certificate as well as the key belonging to it. The first two lines of the file are to be considered as commentary.
subject=/C=AU/SOP=QLD/O=Mincom Pty. Ltd./ OU=CS/CN=SSLeay demo server issuer= /C=AU/SOP=QLD/O=Mincom Pty. Ltd./ OU=CS/CN=CA
The certificate for the 'SSLeay demo server' has obviously been credited to the top level certification office '/AU/QLD/ Mincom Pty. Ltd./CS/CA'. For checking the 'demo server' certificate the client also needs the certificate from 'CA'. So that it finds it, it must either be in /usr/local/ssl/certs, an environment variable called SSL_CERT_DIR must be referenced to the appropriate directory or the directory has to be given explicitly. The certificate necessary for the example test finds the client by the call
s_client -CApath ../certs
This shows that 'SSLeay demo server' is directly licensed by 'SSLeay/rsa test CA' and this again to '/AU/QLD/Mincom Pty. Ltd./CS/CA'. The file belonging to that is called ../certs/testca.pem, as the text output of the certificate registers:
x509 -in ../certs/testca.pem -outform text
The certificate for '/AU/QLD/Mincom Pty. Ltd./CS/CA' (file ../certs/mincomca.pem) has been undersigned by the issuer. It shows the roots of the certification hierarchy with it.
Creating your own certificates
With this knowledge the user can create his own certificate:
genrsa -idea -out my_key.pem -rand \ /var/adm/syslog:~/.pgp/randseed.bin 1024
The chosen key here is made up of 1024 bits, the standard length of 512 bits is too short for serious applications. To get random keys (random in the sense that the conditions that influenced the creation of the key are practically impossible to reconstruct) the user can give several files using the -rand option, whose contents influence the results of the key generation. Suitable candidates for this purpose are, for example, various files from the /pro file system (see below). Whatever, the SSLeay authors will have to build in other possibilities for using a good start value, for example the input of random text by the user by evaluation of the time between two keyboard presses, as known from PGP. The option -idea means that genrsa protects the generated key with the IDEA algorithm. The results is found in the my_key.pem. The secret key for the IDEA encryption is generated by the program from a password that is asked of the user. This password is required for every further access to the protected private key.
The next step is to make the certificate request (a sort of blank certificate). That happens either with the Perl script makecert (see below) or by editing the appropriate template, [#makecert makecert]. The following command helps to explain the meaning of the mysterious numbers, which don't represent more than the object defined in the ASN.1 object hierarchy:
x509 -inform text -in cert -outform text
The lines not available there for the place can be made by the user if required:
= localityName = Ilmenau
makecert asks for certain inputs which it inserts in the request:
sh -c 'makecert 2>my_cert_req.txt'
Enter '. ' to ignore the entry
Country Name [AU]: DE
State or Province [QLD]: Thueringen
locality Name []: Ilmenau
organization Name [Mincom Pty Ltd]: TU Ilmenau
organization Unit Name [CS]: PMI
common Name []: demo server
To validate the certificate in the simplest case it is signed with the private key (self-signed certificate). The certification point later checks this signature before the certificate is confirmed. There is program x509 for this purpose, which is prepared for all work to do with certification.
x509 -inform text -in my_cert_req.txt \ -signkey my_key.pem -out my_cert.pem
Now the user can check the certificate to make sure it has correct syntax and view the changes:
x509 -in my_cert.pem -outform text
The field of public keys (Subject PublicKeyInfo) has been included, as has the signature at the end. The certificate is valid for 30 days from the time of signing.
Checking the validity of the certificate
Any attempt to check the new certificate using verify fails, even though the environment variable for searching for certification is correctly set:
setenv SSL_CERT_DIR `pwd` verify my_cert.pem my_cert.pem: /C=DE/SP=Thueringen/L=Ilmenau/ O=TU Ilmenau/OU=PMI/CN=demo server error 1 at 0:unable to get issuer certificate
Here it's necessary to know how SSLeay gives priority to the chain of certificates with verification. To find a certain certificate verify doesn't check the contents of the certificate present, but creates but using the name input from the publisher of the certificate in question creates a hash value. Afterwards it looks for a file whose name consists of the hash value with a '.0' tagged on the end and checks whether it's the certificate from the designating agent. The suffix '0' is actually a consecutive number which is necessary for the seldom case that the two certificates have the same hash value. The necessary hash (over the name input from the user) is delivered by the program x509. The following instructions create the necessary file name and puts a symbolic link on the actual certificate.
ln -s my_cert.pem `x509 -noout -hash -in my_cert.pem`.0
After that the checking with verify works successfully. The SSL test application can now use the new certificate:
s_server -cert my_cert.pem -key my_key.pem
or
s_client -CApath .
Because the private key is encrypted the server asks for a password at every connection coming in. In a practical application the private key must of course be publicly accessible to the server. To protect this key other measures (such as file access rights) must be used.
Own certification agents possible
When checking the certificate the client points out that it's 'self-signed certificate' whose validity was confirmed by no unordered instance. So a certification agent must be included. A new pair of keys and a new self-signed certificate are required for that. The request file can be obtained using slight changes from my_cert_req.txt.
genrsa -idea -out ca_key.pem -rand
/proc/stat:/proc/meminfo:/proc/interrupts 1024
sed 's/demo server/demo CA/'
my_cert_req.txt > ca_cert_req.txt
x509 -inform text -in ca_cert_req.txt \
-signkey ca_key.pem -out ca_cert.pem
ln -s ca_cert.pem `x509 -noout -hash \
-in ca_cert.pem`.0
Now the 'demo ca' can certify the previous 'demo server' certificate:
x509 -in my_cert.pem -out my_new_cert.pem -CA ca_cert.pem -CAkey ca_key.pem -CAcreateserial -days 365
The option -Cacreateserial is important here. It takes care of the creation of a file that reads the serial number. Every certificate must contain a straight forward serial number from the signed certification agent. That's especially important with the use of take back lists (certificate revocation list, CRL) in which stands that the certificate with a certain serial number is already invalid before the expiry date. The file ca_cert.pem.srl saves the number to be issued next. As standard it gives the file name by tagging on the suffix '.src' to the name of the certificate. The option -CAserial makes it possible to give an alternative file name. The validation fails if the when an appropriate file can't be found. The option -days 365 sets the validity of the certificate to a year, as is clearly shown in the output in the text format:
x509 -in my_new_cert.pem -outform text
So that the separate input of the key data isn't required every time the private key can be attached to the certificate. No safety risk results from that because it isn't in plain text:
cat ca_key.pem>>ca_cert.pem
A test run of the SSL server with the new certificate shows that the client doesn't have any more objections:
s_server -cert my_new_cert.pem -key my_key.pem
To finish with the rsa program, which serves as a filter for processing the RSA keys, can remove the IDEA encryption from the private keys. It reads the key and writes it in the same file. Because the following call doesn't give any code procedure the output is in plain text:
rsa -in my_key.pem -out my_key.pem
It serves as a cosmetic purpose to lengthen the certificate from the certification agent:
x509 -in ca_cert.pem -out ca_cert.pem -CA ca_cert.pem -days 1000
Furthermore to be recommended is saving the certificate in directory /usr/local/ssl/certs and the private keys in /usr/local/ssl/private, because the library functions for verification (and therefore practically all applications) look for them there as standard.
mv ca_cert.pem my_cert.pem my_new_cert.pem *.0 /usr/local/ssl/certs/ mv ca_key.pem my_key.pem /usr/local/ssl/private/
Application programs with SSL-Patch
Now the usage of the most important programs in the basic package have been explained the actual application can be converted. Telnet, FTP and httpd/Mosaic are available as complete source and can be implemented without problems after some small changes (see box 'a little manual work'). Apache is a patch kit used to modify the original sources. For the creating of the self-signed certificates for the server there is a simple and fast way, since version 0.5.1:
cd /usr/local/ssl/certs req -new -x509 -nodes -out servername.pem -keyout servername.pem
Some makefiles already contain the appropriate target for make certificate.
All the applications patched by Tim Hudson expect their certificate and private keys in a file in the directory /usr/local/ssl/certs (or in another, set during the translation of the SSL library) under the name telnetd.pem, ftpd.pem or httpd.pem. Arguments in the command line can overwrite these names. The option -z is common to all applications which follow SSL specific applications and the meaning is about the same in all instances (see box 'SSL specific options'). Tim Hudson has placed great value on backwards compatibility. The SSL connection falls back to a normal, unencrypted connection via a fallback mechanism if it fails - whereby a soft change over to secure applications is possible. The only exception is httpd. This doesn't know any mechanism for changing the security level. It must first be souped up with the option -z ssl. But that's not too tragic as a separate port (443) is envisaged for https URLs.
All the programs have (in contrast to the current Netscape Navigator) the ability for client authentication, with which their identity is checked by means of certificate. ftpg offers a particular treat there: an auto logic based on the user name and owner of the client certificate. In the file /etc/ssl.users there is the following, for example:
reif,ssl:/CE=DE/SP=Thueringen/L=Ilmenau/O=TU Ilmenau/OU=PMI/CN=Holger Reif
This certificate authorises the users 'reif' and 'ssl' with the certificate from Holger Reif for a logic without password. The pre-condition is the input of the options -z certsok and -z verify=1 (oder 2).
MZ-SSLtelnet from Christoph Martin is based on the 4.4BSD Lite version of Telnet. In contrast to Hudson's variant the platform adaptation - thanks to GNU autoconf - takes place conveniently. Simply give configure and it also works with Telnet. In Mainz there are binary files. In the future these sources are to be the jointly cultivated distribution from Tim Hudson and Christoph Martin.
Secure Socket Layer for Web servers
The 'international' version of Apache-SSL (in contrast to the 'international' export version of Navigator with full encryption functionality) is surely the most interesting of the applications introduced here and allows an individual certificate to be used for each virtual server. As well as that a (non standard) mechanism is foreseen, which with help of the certificate carries out client authentication and translates it into a user name of the basic authentication scheme. But this should be viewed as still in the experimental stage. With the expected patches for Apache 1.1 this feature should hopefully function without any problems. The included configuration file httpd.conf gives a good impression of the necessary configuration for SSL mode. For running a really secure server some other conditions need to be observed. A few things to think about are provided by Ben Laurie in the SECURITY file in the Apache SSL directory.
What next? Some paths are already sign posted. SSLeay will indeed develop as the universal package for secure communication and management of certification and easily be sufficient for the demands of SSL. With the ca program (and the ssleay.conf file), currently still in the experimentation stage, genuine certification with take back lists will be realisable in the future. In addition, universal utilities such as asn1parse, des or genrsa are included. The developer of SSLeay, Eric Young, wants to see the extension of further applications (such as talk) to SSL compatibility and sees S-MIME as a worthwhile aim for the future. Certainly there will also be an implementation for SSL 3.0 and the result of the new IETF-WG TLS (Transport Layer Security), which will bring SSL and Microsoft's PCT (Private Communication Technology) down to a common denominator, in the pipeline.
Holger Reif
studies computing at TU Ilmenau. Since 1994 he has been a research assistant in telematics with focus on network services, security and electronic payment systems. (E-Mail: reif@prakinf.tu-ilmenau.de, Homepage)
