Web Security: Encryption & Authentication

by Paul Weinstein

First published: May 2001 for Daemon News.
Republished No. 5, July 2001 edition of FreeBSD Press.

SSL, developed by Netscape Communications, and TLS, the open-standard replacement for SSL, are the two protocols that add encryption and authentication onto the TCP/IP stack. This article summarizes the basic concepts used in implementing a secure website with SSL/TLS.

SSL/TLS has two main features:

  • Ciphers; which enable the encryption of data between two parties (a client and a server).

  • Digital Certificates; which provide the authentication of the two parties (a client and a server).

There are two types of ciphers:

  • Asymmetric (public-key ciphers)

  • Symmetric (secret-key ciphers)

Symmetric ciphers use a single key for both encrypting and decrypting data. In this case , the encrypted data is secure only if the key can be securely distributed to both parties.

In asymmetric encryption a key pair, consisting of a public key and private key, is used to encrypt and decrypt data. The public key encrypts, but cannot be used to decrypt. Only the private key can decrypt the data, thus data encoded with the public key is secure as long as the private key stays secure. The advantage is that you can freely distribute your public key; you don't risk the security of your data as long as you keep your private key secure.

Used alone, both ciphers have their shortcomings. Symmetric encoded data can be secure only so long as the key used is secured, while asymmetric encoded data require a longer processing time. SSL/TLS works around these limitations by using both types of ciphers, first using asymmetric cipher to securely exchange the symmetric key and then using symmetric key to transfer the data.

Along with the type of cipher being used, the cipher size or strength also plays a role in secure transactions. Commonly found 40- and 56-bit web browsers are considered weak since these key sizes can be cracked in a short time period (approximately one week) using current computer processing power. (These weak browsers are common due to the U.S. regulations on exportation of strong encryption and hopefully will become less common with the recent changes made by the U.S. Government.) The stronger, 128-bit strength ciphers are not uncrackable, but involve a larger time and resource commitment that reduces the usefulness of the data being sought. (For example: If I encode my credit card using a weak cipher someone can crack it and go shopping within a week. If I use a strong cipher the cost of resources need to crack the code would involve more time and money then that which would be gain from stealing my little credit card). Most SSL/TLS-enabled web servers allow for customization of what ciphers and key sizes can and cannot be used while a connection is made.

Digital Certificates allow authentication of the parties engaged in a secure transaction. There are two types of certificates:

  • Server Certificates

  • Client Certificates

Both types of certificates are in the X.509 format and are issued by Certificate Authorities (CAs) that act as a trusted third party, verifying the identity of the first two parties. The type of certificate simply identifies the party in question; the client certificate identifies the client and the server certificate identifies the server. Certificates contain some of the following information:

  • A serial number

  • Name of the CA

  • Period the certificate is valid for

  • Identifying information of the party in question, such as name, street address and/or email address

  • Subject's public key

  • A "signature" from the issuing CA

While server certificates are required in an SSL/TLS transaction, client certificates are not and the server can use other less secure methods, such as htaccess, to authenticate and restrict access.

Certificates can be self-signed, but that causes most browsers to issue a warning to the user that the browser doesn't recognize the signer. More commonly, sites use certificates from Client Authorities (CAs), which as noted before act as a third party verifying the identity of the certificate owner. Two types of certificate authorities issue digital certificates:

  • Public CAs, like Verisign, Thawte or Equifax, is recognized as trusted by most web browsers and servers by default. A certificate issued by a public CA is usually used when no other relation exists between the first two parties

  • Private CAs, are not recognized as trusted, by default, but can be configured as such. Used where some kind of trust relationship already exists in an exclusive group such as an employee and the employer. For example, a company can set up a private CA to authenticate access to company information

Using all of this information we can see how a trusted, secure transaction can take place using SSL/TLS.

1) The client requests a secure transaction (by accessing a URL with https) and lets the server know what ciphers and key sizes it can handle.

2) The server sends the requested server certificate, which which contains the server's public key in a "package" that has been encrypted by a CA. The CA is a "trusted third party," someone whose public key is known by the client. It also sends a list of ciphers and key sizes in order of priority.

3) A) The client generates a new symmetric "session" key based on the priority list sent by the server.
    B) The client also compares the CA that issued the certificate to its list of trusted CAs, verifies that the certificate has not expired, and that the certificate's being used by the server that is listed in the certificate (For example, it compares the URL it used to start the request with the URL that's listed in the certificate).

4) The client encrypts a copy of the new session key it generated with the public key of the server.

5) The client then sends the new encrypted key to the server.

6) The server decrypts the new session key with its own private key.

7) At this point, both the client and server have the same secured session key which can now be used to encrypt and decrypt the rest of the requested data. If the server wishes to verify the client it will now ask for the client certificate.

If, for example, a customer wished to purchase some items from an online store with a credit card, the customer knows that

  • The communication with the store is secure, so that no one can collect the customer's information while that data is in transit.

  • The server on the other end, decrypting the data is in fact the online store , and the customer information will in fact be used to process the order.

In another example an employee can access the corporate Intranet/Extranet from their home or office and that:

  • The communication between with the company is secure, so that no one can collect the company information while it's in transit

  • The server on one end of decryption is in fact the company server and the information is valid.

  • The client on the other end of decryption is in fact an employee and that the information has not been compromised.

SSL/TLS is a powerful protocol that not only allows secure, encrypted transactions, but also enables authentication of both parties engaged in the transaction. For more information about Apache and SSL/TLS take a look at http://www.modssl.org.


References:

Engelschall, Ralf User Manual mod_ssl Version 2.8 30 Jan. 2001 www.modssl.org/docs/2.8