Figure 1.
Background
The SSL protocol was developed by Netscape Corp. and was quickly adopted
by several web server and browser applications. The most current manifestation
is SSLv3.0 with both the Transport Layer Security (TLS) protocol and Quantum
Cryptography hot on its heels. SSL is just that, a protocol. It is not
software in its own right. Applications are designed around this protocol.
When you talk about SSL your really dealing with many aspects of
the security puzzle. This includes encryption, digital certificates, authentication,
message digest, and digital signature topics. These may be independent
of each other or interrelated depending on the particular application.
Encryption/Decryption
Encryption involves the processing of data in a manner which makes
it nearly impossible, if not impractical to extract its original form.
Most secure web transactions involve some form of encryption although not
all. Encryption tries to prevent so called "man in the middle attacks"
whereby information in transit can be manipulated for the lesser good of
the original communicants. In an ironic twist, most of the "work horse"
encryption algorithms are in the public domain and freely investigated.
The power of these algorithms is the irreversibility of data from its encrypted
to its original state without the benefit of an encryption "key".
With all its mathematical rigor and complexity, the field of encryption's
soft spot is the secure distribution of the key itself. Sure you can throw
it on a floppy and give it to your friend and thats probably the most full
proof method but it doesn't scale to widespread use. If you think
of security in its purest sense the key must never be compromised nor compromisable.
The use of keys is what diffentiates so called "symmetric" and "asymmetric" encryption. When a single key both encrypts and decrypts messages this is known as symmetric encryption. In contrast many implementations utilize 2 keys where one key is used to encrypt the data the other to decrypt it. This applies in reverse also. This defines the concept of "public/private" key pairs and is known as asymmetric encryption.
Digital Certificates
Digital Certificates have been around a while but have not really caught
on with the masses. They are indeed optional as a component of a Web security
solution but will probably gain popularity in the future, especially with
recent changes in the law which honor web signing as legally enforceable.
Certificates are small binary files which contain a standardized set of
data structures which can be accessed by systems designed around the SSL
protocol. Both browsers and web server software can be configured to utilize
certificates to facilitate secure communications.
The different types of certificates include personal certificates, server certificates, and certifying authority(CA) and attribute.
- A personal certificate is issued to an individual. It vouches for their correct name, geographical location, corporate affiliation and other optionally specified info. It is used as an authentication mechanism in S/MIME communication and can be used for authentication to access Web sites if they require it. The certificate is particular to a given email address.
- A server certificate is issued for a particular URL and would be used by web server software (Apache e.g.) to enable support of secure communications.
- A signing certificate is what a so called certification authority would use to sign a certificate signing request (CSR)
- An attribute certificate is a newer form of certificate that leverages the x509v3 extension capability where custom data is included in the certificate.
Figure 1.
The process of generating a certificate on an official level, is rather tedious. It involves providing personal information to a certification authority corporation such as VeriSign. You generate a public/ private key using their website most likely and then submit a certificate signing request within which is your public key. They perform background verification of the information, and if all goes well they sign your certificate signing request with their CA certificate. The result returned to your is a personal or web server certificate that will work with those public and private keys.
Figure 2.
When you "install" this certificate in your browser you now have a working
private and public key that can be used for secure communication. If its
a server certificate you would tell Apache to use this certificate to enable
https communications with clients. Note, browsers come preconfigured to
recognize select certification authorites as valid. (See Figure 3). You
will have to consciously force acceptance of a certificate with an unrecognized
CA.
Figure 3
Message Digest
Main Entry: 1di?gest
Pronunciation: 'dI-"jest
1 : a summation or condensation of a body of information:
Message Digests are yet another piece of the SSL security puzzle. Your certificate addresses the ability to encrypt data and provide substantial authentication that you are who you say you are. But how can you be sure that what you sent is what was received by the web server or individual on the other end. This is what a message digest addresses. A digest is a short (~16 byte) code representation of the message contents. It has the characteristic that if any bit from the input changes then every output bit of the digest has at least a 50% chance of changing. The digest is often appended to the message contents so that the recipient (application) can confirm that the data is intact. The digest algoritm to be used is negotiated along with the encryption technique during the SSL Handshake. The predominant techniques in use are MD5 and SHA-1, with HMAC anticipated as their successor.
Interestingly you can emulate message digest functionality with a Cipher Feedback encryption technique. In this case the last block is consider the message digest.
Message Digests have various uses.
Digital Signature
A digital signature combines some of the previous topics. A signature
is the encryption of a message digest using your private key. The use of
your private key allows others with your public key to decrypt the data.
If decryption is successful, that strongly suggests that you are the one
who encrypted it. The digest ensures the integrity of what you signed.
Conceivably the you or the other party could check that the document as
signed, yeilds a digest equivalent to that received in the signature.
SSL Handshake
An SSL session is established by following a handshake sequence between
client and server, as shown in Figure 1. This sequence may vary, depending
on whether the server is configured to provide a server certificate or
request a client certificate. Though cases exist where additional handshake
steps are required for management of cipher information, this example summarizes
one common scenario.
The elements of the handshake sequence, as used by the client and server,
are:
1.Client Hello indicates supported cipher suites and a 32 byte random value to be used later for key creation. A 32 byte session id is optional if client wishes to use keying data from a previous connection.
2.Server Hello indicates the selected cipher suite and a 32 byte random value
3.Server sends its Certificate containing its public key, client therefore can now encrypt to the server public key.
4.Server may send the Certificate Request message indicating it wants the clients certificate
5.Server sends the ServerHelloDone as a transition point.
6.The client sends the ClientKeyExchange message which contains a pre-master secret( 48 byte random string), encrypted with the servers public key. The client random, server random and the premaster string all contribute to the establishment of the master secret which is independently derived at the server and at the client. The master secret is then further processed again along with the client random and server random values to form a key "block". This key block is then subdivided amongst the algorithm mechanisms which need keying data. (encryption,digest, initialization vector)
7. The client then issues the ChangeCipherSpec message which says that all subsequent messages will be encrypted with the previously established key.
8. The client then sends the Finished message which contains both a MD5 and SHA-1 digest of the negotiated master secret, all handshake messages concatenated, and some necessary padding.
9. The server sends its own ChangeCipherSpec message which servers same purpose as clients.
10. The server sends its own Finished messageSee tables 3.8 and 3.13 for details of the CipherSuite and Key Derivation.
Serving up Security
So now we know a bit about the SSL, lets talk about some of the details
of what makes things happen at the server. First off, lets take a step
backwards and mention there are some baby steps along the way that dont
involve an SSL enabled web server at all.
Basic Authentication
Maybe you dont really need encryption, you just want to let certain
individuals access your content. Basic authentication, otherwise known
as good old "user/password" comes built in (or buildable-in)
with most web servers. Apache has several runtime directives related to
this which can appear in its http.conf or access.conf file.
require
[user1 user2 user3] [valid_user]
where
a valid user is determined by a password file as indicated by the AuthUserFile
directive
require ["some
group name"]
where group is defined by some file per the AuthGroupFile "somefilename"
AuthType [Basic, Digest]
AuthName ["some realm name"]
Digest Authentication
This is a little fancier and begins to bring in aspects of SSL. The
password in this case is encrypted when transmitted. The server generates
a random string and sends it to the browser, the browser then encrypts
the string with the user password and returns that to the server. In parallel
the server takes the stored password and encrypts it with its random string.
The result is compared with that received from the browser. The password
on its own has never been conveyed.
Certificate Authentication
This is really the whole ball of wax at work for SSL. It and
requires some additional configuration of your web server. For instance,
in the case of Apache we need to build with the mod_ssl module. There are
several Apache runtime directives related to SSL.
SSLCipherSuite
SSLCertificateFile
SSLCertificateKeyFile
SSLCACertificateFile
SSLRequire
many more...
The mod_ssl also opens up a myriad of environment variables which are available to CGI and perhaps mod_perl enabled scripts.
SSL-related variables
HTTPS SSL_CLIENT_M_VERSION SSL_SERVER_M_VERSION
SSL_CLIENT_M_SERIAL SSL_SERVER_M_SERIAL
SSL_PROTOCOL
SSL_CLIENT_V_START SSL_SERVER_V_START
SSL_SESSION_ID SSL_CLIENT_V_END
SSL_SERVER_V_END
SSL_CIPHER
SSL_CLIENT_S_DN SSL_SERVER_S_DN
SSL_CIPHER_EXPORT SSL_CLIENT_S_DN_C
SSL_SERVER_S_DN_C
SSL_CIPHER_ALGKEYSIZE SSL_CLIENT_S_DN_ST
SSL_SERVER_S_DN_ST
SSL_CIPHER_USEKEYSIZE SSL_CLIENT_S_DN_L
SSL_SERVER_S_DN_L
SSL_VERSION_LIBRARY SSL_CLIENT_S_DN_O
SSL_SERVER_S_DN_O
SSL_VERSION_INTERFACE SSL_CLIENT_S_DN_OU
SSL_SERVER_S_DN_OU
many more ....
Quantum Cryptography
This technology leverages the laws of quantum physics to generate and
protect the transfer of an encryption key. It relies on the behaviour of
photons and their ability to pass through these filters. The challenges
with the solution are in the ability to maintain the photon orientation
over large distances and in different mediums. Refer to the article cited
in the Reference section if your interested.
http://www.modssl.org
mod_ssl is the Apache module which extends Apache's API to the ssl
protocol.
http://www.oreilly.com/catalog/websec
I used this as my primary reference. Its getting dated so you might
want to wait for a 2nd edition.
http://www.rtfm.com
This book is a detailed treatment of SSL and provides some C and Java
SSL examples.
http://www.wiley.com/compbooks/catalog/11709-9.htm
This seems to be the defacto book that is often sited.
http://newscientist.co.uk/ns/19991002/quantumcon.html
An interesting article on the field of quantum cryptography.