1 The SSL Protocol
Here we provide a short introduction to the SSL protocol. We only consider those part of the protocol that are important from a programming point of view.
For a very good general introduction to SSL and TLS see the book rescorla.
Outline:
- Two types of connections - connection: handshake, data transfer, and shutdown - SSL/TLS protocol - server must have certificate - what the the server sends to the client - client may verify the server - server may ask client for certificate - what the client sends to the server - server may then verify the client - verification - certificate chains - root certificates - public keys - key agreement - purpose of certificate - references
1.1 SSL Connections
The SSL protocol is implemented on top of the TCP/IP protocol. From an endpoint view it also has the same type of connections as that protocol, almost always created by calls to socket interface functions listen, accept and connect. The endpoints are servers and clients.
A serverlistens for connections on a specific address and port. This is done once. The server then accepts each connections on that same address and port. This is typically done indefinitely many times.
A client connects to a server on a specific address and port. For each purpose this is done once.
For a plain TCP/IP connection the establishment of a connection (through an accept or a connect) is followed by data transfer between the client and server, finally ended by a connection close.
An SSL connection also consists of data transfer and connection close, However, the data transfer contains encrypted data, and in order to establish the encryption parameters, the data transfer is preceded by an SSL handshake. In this handshake the server plays a dominant role, and the main instrument used in achieving a valid SSL connection is the server's certificate. We consider certificates in the next section, and the SSL handshake in a subsequent section.
1.2 Certificates
A certificate is similar to a driver's license, or a passport. The holder of the certificate is called the subject. First of all the certificate identifies the subject in terms of the name of the subject, its postal address, country name, company name (if applicable), etc.
Although a driver's license is always issued by a well-known and distinct authority, a certificate may have an issuer that is not so well-known. Therefore a certificate also always contains information on the issuer of the certificate. That information is of the same type as the information on the subject. The issuer of a certificate also signs the certificate with a digital signature (the signature is an inherent part of the certificate), which allow others to verify that the issuer really is the issuer of the certificate.
Now that a certificate can be checked by verifying the signature of the issuer, the question is how to trust the issuer. The answer to this question is to require that there is a certificate for the issuer as well. That issuer has in turn an issuer, which must also have a certificate, and so on. This certificate chain has to have en end, which then must be a certificate that is trusted by other means. We shall cover this problem of authentication in a subsequent section.
1.3 Encryption Algorithms
An encryption algorithm is a mathematical algorithm for encryption and decryption of messages (arrays of bytes, say). The algorithm as such is always required to be publicly known, otherwise its strength cannot be evaluated, and hence it cannot be used reliably. The secrecy of an encrypted message is not achieved by the secrecy of the algorithm used, but by the secrecy of the keys used as input to the encryption and decryption algorithms. For an account of cryptography in general see schneier.
There are two classes of encryption algorithms: symmetric key algorithms and public key algorithms. Both types of algorithms are used in the SSL protocol.
In the sequel we assume holders of keys keep them secret (except public keys) and that they in that sense are trusted. How a holder of a secret key is proved to be the one it claims to be is a question of authentication, which, in the context of the SSL protocol, is described in a section further below.
Symmetric Key Algorithms
A symmetric key algorithm has one key only. The key is used for both encryption and decryption. Obviously the key of a symmetric key algorithm must always be kept secret by the users of the key. DES is an example of a symmetric key algorithm.
Symmetric key algorithms are fast compared to public key algorithms. They are therefore typically used for encrypting bulk data.
Public Key Algorithms
A public key algorithm has two keys. Any of the two keys can be used for encryption. A message encrypted with one of the keys, can only be decrypted with the other key. One of the keys is public (known to the world), while the other key is private (i.e. kept secret) by the owner of the two keys.
RSA is an example of a public key algorithm.
Public key algorithms are slow compared to symmetric key algorithms, and they are therefore seldom used for bulk data encryption. They are therefore only used in cases where the fact that one key is public and the other is private, provides features that cannot be provided by symmetric algorithms.
Digital Signature Algorithms
An interesting feature of a public key algorithm is that its public and private keys can both be used for encryption. Anyone can use the public key to encrypt a message, and send that message to the owner of the private key, and be sure of that only the holder of the private key can decrypt the message.
On the other hand, the owner of the private key can encrypt a message with the private key, thus obtaining an encrypted message that can decrypted by anyone having the public key.
The last approach can be used as a digital signature algorithm. The holder of the private key signs an array of bytes by performing a specified well-known message digest algorithm to compute a hash of the array, encrypts the hash value with its private key, an then presents the original array, the name of the digest algorithm, and the encryption of the hash value as a signed array of bytes.
Now anyone having the public key, can decrypt the encrypted hash value with that key, compute the hash with the specified digest algorithm, and check that the hash values compare equal in order to verify that the original array was indeed signed by the holder of the private key.
What we have accounted for so far is by no means all that can be said about digital signatures (see schneierfor further details).
Message Digests Algorithms
A message digest algorithm is a hash function that accepts an array bytes of arbitrary but finite length of input, and outputs an array of bytes of fixed length. Such an algorithm is also required to be very hard to invert.
MD5 (16 bytes output) and SHA1 (20 bytes output) are examples of message digest algorithms.
1.4 SSL Handshake
The main purpose of the handshake performed before an an SSL connection is established is to negotiate the encryption algorithm and key to be used for the bulk data transfer between the client and the server. We are writing the key, since the algorithm to choose for bulk encryption one of the symmetric algorithms.
There is thus only one key to agree upon, and obviously that key has to be kept secret between the client and the server. To obtain that the handshake has to be encrypted as well.
The SSL protocol requires that the server always sends its certificate to the client in the beginning of the handshake. The client then retrieves the server's public key from the certificate, which means that the client can use the server's public key to encrypt messages to the server, and the server can decrypt those messages with its private key. Similarly, the server can encrypt messages to the client with its private key, and the client can decrypt messages with the server's public key. It is thus is with the server's public and private keys that messages in the handshake are encrypted and decrypted, and hence the key agreed upon for symmetric encryption of bulk data can be kept secret (there are more things to consider to really keep it secret, see rescorla).
The above indicates that the server does not care who is connecting, and that only the client has the possibility to properly identify the server based on the server's certificate. That is indeed true in the minimal use of the protocol, but it is possible to instruct the server to request the certificate of the client, in order to have a means to identify the client, but it is by no means required to establish an SSL connection.
If a server request the client certificate, it verifies, as a part of the protocol, that the client really holds the private key of the certificate by sending the client a string of bytes to encrypt with its private key, which the server then decrypts with the client's public key, the result of which is compared with the original string of bytes (a similar procedure is always performed by the client when it has received the server's certificate).
The way clients and servers authenticate each other, i.e. proves that their respective peers are what they claim to be, is the topic of the next section.
1.5 Authentication
As we have already seen the reception of a certificate from a peer is not enough to prove that the peer is authentic. More certificates are needed, and we have to consider how certificates are issued and on what grounds.
Certificates are issued by certification authorities (CAs) only. They issue certificates both for other CAs and ordinary users (which are not CAs).
Certain CAs are top CAs, i.e. they do not have a certificate issued by another CA. Instead they issue their own certificate, where the subject and issuer part of the certificate are identical (such a certificate is called a self-signed certificate). A top CA has to be well-known, and has to have a publicly available policy telling on what grounds it issues certificates.
There are a handful of top CAs in the world. You can examine the certificates of several of them by clicking through the menus of your web browser.
A top CA typically issues certificates for other CAs, called intermediate CAs, but possibly also to ordinary users. Thus the certificates derivable from a top CA constitute a tree, where the leaves of the tree are ordinary user certificates.
A certificate chain is an ordered sequence of certificates, C1, C2, ..., Cn, say, where C1 is a top CA certificate, and where Cn is an ordinary user certificate, and where the holder of C1 is the issuer of C2, the holder of C2 is the issuer of C3, ..., and the holder of Cn-1 is the issuer of Cn, the ordinary user certificate. The holders of C2, C3, ..., Cn-1 are then intermediate CAs.
Now to verify that a certificate chain is unbroken we have to take the public key from each certificate Ck, and apply that key to decrypt the signature of certificate Ck-1, thus obtaining the message digest computed by the holder of the Ck certificate, compute the real message digest of the Ck-1 certificate and compare the results. If they compare equal the link of the chain between Ck and Ck-1 is considered to unbroken. This is done for each link k = 1, 2, ..., n-1. If all links are found to be unbroken, the user certificate Cn is considered authenticated.
Trusted Certificates
Now that there is a way to authenticate a certificate by checking that all links of a certificate chain are unbroken, the question is how you can be sure to trust the certificates in the chain, and in particular the top CA certificate of the chain.
To provide an answer to that question consider the perspective of a client, which have just received the certificate of the server. In order to authenticate the server the client has to construct a certificate chain and to prove that the chain is unbroken. The client has to have a set of CA certificates (top CA or intermediate CA certificates) not obtained from the server, but obtained by other means. Those certificates are kept locally by the client, and are trusted by the client.
More specifically, the client does not really have to have top CA certificates in its local storage. In order to authenticate a server it is sufficient for the client to posses the trusted certificate of the issuer of the server certificate.
Now that is not the whole story. A server can send an (incomplete) certificate chain to its client, and then the task of the client is to construct a certificate chain that begins with a trusted certificate and ends with the server's certificate. (A client can also send a chain to its server, provided the server requested the client's certificate.)
All this means that an unbroken certificate chain begins with a trusted certificate (top CA or not), and ends with the peer certificate. That is the end of the chain is obtained from the peer, but the beginning of the chain is obtained from local storage, which is considered trusted.