SSL: What Does It Buy Me?
Arthur Donkers In this implementation of the security column, I will look at SSL, the protocol used by many Web servers to secure communications. One of the most important requirements for e-commerce applications is the security of the communications channel between the client and the server. This security feature is used for two purposes. First, it is used to encrypt the communications between the client and the server. This prevents eavesdropping by any party between the client and server. The second purpose is authentication, both for the server and the client. It is very important to be able to establish and verify, beyond any reasonable doubt, the identity of the communicating party. This security feature can be realized by using SSL. SSL stands for Secure Socket Layer and can be considered an addition on top of the standard BSD-based socket library as available on UNIX, NT, Windows 95, and other platforms. SSL features SSL uses a so-called trusted third-party model for authentication purposes. This means that a party other than the two involved in the communication process will vouch for the identity of one or both parties. This vouching party is trusted by both parties as being reliable and secure. Hence the name "trusted third party". An example of such a third party is Verisign (http://www.verisign.com), which has made it its business to be reliable, secure, and trustworthy. In most cases when you connect to a secured Web server, you will find that the server certificate has been signed by Verisign. (Later in this article, the certificates will be explained in full.) So, how does SSL support you in building a secure connection between your browser and a Web server? As stated before, SSL is an addition on top of normal sockets. It is used when a connection is established, for exchanging data and for tearing down a connection. Each of these steps in the life of a socket will be described below. In this description, it is assumed that only the server uses a certificate for authentication purposes. Later, I will explain what needs to be done when client authentication is needed as well. Step 1: Establishing a Connection In the first step, a client seeks to connect to a server supporting SSL. It should be clear that the server listens on a specific port for a secure service, and possibly on another port for a non-secure version of the same service. An example of this is the http port (80), which is used for normal connections and the https (443) port which is used for secured connections. During the first phase of the connection, the client requests the certificate from the server. This certificate contains the public key of the server, plus a digital signature that has been "signed" by the trusted third party. The client then checks the validity of the certificate by decrypting the signature with the public key of the trusted third party. If it matches the other information in the certificate, it is accepted as a "good" certificate. Note that most modern browsers have a number of trusted third parties built-in. The signing keys of these parties have been programmed into the browser, so you need not install them yourself. However, if your certificate has been signed by another party, you must first accept this signing authority before you can accept the signed certificate itself. Figures 1a and 1b shows screenshots of the information pertaining to a secure connection to a Web site. Figures 2, 3, and 4 show a number of dialog screens used when connecting to a server whose certificate has been signed by an unrecognized certification authority (CA). After establishing the identity of the server via its certificate, the client and server engage in a dialog to establish an encryption key for that particular session. This encryption key is different for each session and is normally generated by some sort of random number generator. The exchanging of the key is done by means of a public key key change algorithm (e.g., Diffie Hellman). Step 2: Exchanging Data When exchanging data, the session key and, in most cases, a secret key algorithm (such as RC4, RC5, or DES) are used. The reason for using a secret key algorithm is performance. Under normal circumstances, a secret key algorithm offers better throughput, even in streaming mode, than a public key algorithm. And since the session key has been established using a dedicated algorithm, this key is only known to the client and server. All data exchanged between the client and server is encrypted, in both directions. Step 3: Tearing Down the Connection Once all data has been exchanged, the connection is closed. All session keys are destroyed, and all buffers and memory are freed. SSL Uses On the Internet, SSL is typically used for connecting to secured Web sites. Your browser will show you this by some sort of closed key or padlock indicating a secured connection. If you have a secured connection, you can look at the server certificate, usually by clicking on the key. You will see not only the server information, but also who has signed the certificate. SSL is used to make sure that the Web server you are talking to is really that server. This is very useful if you wish to order products via this Web site and provide credit card information. It is essential to check the certificate when you visit a new, secured Web server. You must make sure you are talking to the right Web server. Can I Roll My Own SSL? Because of export regulations and other restrictions I will not go into, U.S. companies are not allowed to export strong encryption software. This means that Web server software that supports 128-bit encryption can only be used for domestic use. Does this mean that people outside of the United States cannot use strong SSL? Luckily no, there are other companies outside the United States that offer strong SSL software, even for free! The best example of this is SSLeay, written by two people in Australia. You can find more information on SSLeay at: http://www.cryptsoft.com. You can download this software and build your own SSL library. There are even patches available to extend Apache with this strong crypto software, so you can build your own favorite Web server with SSL. Note that once you have downloaded this software, you are not allowed to export it from the United States. Silly or what? There are also patches available on the Internet to "upgrade" your export grade browser to full featured strong encryption. This software can be found at http://www.fortify.net. Use at your own risk. Taking It One Step Further Although server side SSL security gives your visitors confidence in your identity as a server, it will not restrict access to your Web server. Any browser that supports SSL will be able to connect to your server. If you wish to restrict access, or even further, establish a closed user group, you can use client side certificates. You can configure most Web servers to request a certificate from the client before granting access to a part of the document tree. These certificates are used to identify the user trying to connect to your server. These client side certificates are stored on the machine running the browser. Under normal circumstances, these certificates are stored encrypted (at least the private key anyway), and the user needs to supply a password before the browser can open the certificate. This client certificate can sometimes be generated on the Web server itself, sometimes the webmaster has made special pages that enable a new user to request a certificate from the Web server. This request is then received by the webmaster or someone else within the organization. This certificate request needs to be signed by a trusted party. This can be a trusted third party, Verisign, however, for client certificates, it is common for an organization to do its own signing. It has a very limited CA (Certification Authority) that can be used to sign the client certificates. This makes it easier for the organization to issue and revoke client certificates. Client Certificates If you want to build your own client certificates, here is a short recipe on how to do that. Note that client certificates for Netscape and MSIE are different, and you need different pages and scripts for each of these browsers. The steps below are based on the installation of a client certificate on a Netscape browser. For this experiment, I have written a small Web server in Perl that recognizes some extensions in a Web page. If it encounters the statement %exec, it will execute the program specified after the %exec clause, and all output of that program will be included in the page. The program is also capable of adding parameters to this %exec (or in the page itself) by adding %<variable>% to the page. The name of the variable can be a built-in variable of the server, or the variable from a FORM. If you keep this in mind, you can "read" the Web pages presented below. All SSL software is SSLeay 0.9.0b. The main page of this experiment is shown in Listing 1. Installing a ROOT Certificate To use your own client certificates, signed by your own CA, you must first install a ROOT certificate so your browser can accept any certificates signed by your CA. This is the first link in the main page. Clicking on this link will execute the Perl program shown in Listing 2. This Perl program will open the cacert.pem file, calculate the size of the certificate, and send it to the browser. If you take a closer look, you will see that the HTTP header contains "Content-Type: application/x-x509-ca-cert\n". This tells the browser that the page does not contain regular HTML, but a base64-encoded CA certificate. Requesting a Client Certificate After installing the ROOT certificate, the user will follow the next link of the main page. The user must fill out a form that will request all necessary information and even generate a public/private key pair for the certificate. The private key is stored in the browser database, encrypted with a password (see Figures 5 and 6). Listing 3 shows the HTML code for this form. Most interesting is the following input element of the form:
<keygen name="SPKAC" challenge="keygen"></font> </keygen> This is Netscape specific, but will force the browser to generate a keypair. Signing the Client Certificate After the certificate information is confirmed, it must be signed with the ROOT certificate. For this experiment, I programmed this to be done from the Web page by calling a special Perl script is shown in Listing 4. This is a straightforward script, it gathers all information from the FORM, and call the CA program as it is available in the SSLeay package. After the certificate is signed, it is stored with a serial number, which is presented to the user. He or she can then request the client certificate via this number and install it in the browser. Installing the Client Certificate Listing 5 contains the Perl script for installing the client certificate. It looks very similar to the cacert installation program. The main difference is the content-type header. For a client certificate this is:
"Content-Type: application/x-x509-user-cert\n"; After installing this certificate, it can be used in controlling access to specific parts of the document tree. This is specific for the Web server software. Note that all of this software is purely experimental and used as proof of concept. It should not be used for production purposes; it lacks the necessary authentication and security measures. Conclusion You can use SSL not only for authenticating a server, but also for building a closed user group by using client certificates. With a little effort, you can even issue your own client certificates.
About the Author
Arthur Donkers graduated from the Delft University of Technology with a degree in Electrical Engineering and a major in Computer Architecture. Since then he has worked for a number of major software houses in the Netherlands. His primary field of interest is in datacommunications, especially the security aspects involved. He now is the founder and owner of Le Reseau, a company specializing in security-related issues for UNIX, OpenVMS and Windows NT, and the application of Linux in corporate environments.
|