SSL / TLS Overview or:

How I Learned to Stop Worrying and Love the CA

Ti Leggett <leggett@mcs.anl.gov>

1.Assumed knowledge
This mini paper assumes you have some knowledge of what TCP is, what
cryptology/cryptography is, and have read Bob Olson's slides on Security in AG2.0. It will give a
brief overview of what SSL/TLS provides, how it works, what a Certificate Authority (CA) is,
and how a CA achieves its goal.

2.What SSL/TLS is
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are essentially the same thing.
SSL was developed at Netscape and has currently settled at SSLv3. TLS is a proposed Internet
Engineering Task Force (IETF) standard based off of SSLv3 with minor enhancements and bug
fixes. SSLv3 is by far more widespread but more and more applications understand TLS each
day. For the duration of this document I assume they are identical and will refer to them simply
as SSL.

The goal of SSL is to provide a secure transport for application protocols/data between two
points, henceforth called Alice and Bob, assuming that a malicious party, henceforth called "the
attacker," has control over the network between. In order for the transport to be secure it should
satisfy three conditions: confidentiality, message integrity, endpoint authentication.
Confidentiality is simply that no one outside is listening to what's going on inside. Message
integrity assures that what's going on inside hasn't been tampered with from outside. Endpoint
authentication is the ability to trust that who you're talking to on the end is who they say they are
and who you think they are.

3.How SSL works

SSL makes use of several security techniques in order to provide a robust and secure transport. It
uses secret key encryption, public key encryption, digests, Message Authentication Codes
(MACs) as well simple techniques to ensure data integrity. An important note is that SSL only
works over reliable protocols such as TCP.

3.1.Secret Key Encryption

Secret key encryption is basically what it sounds like. Imagine in the movies when there's a bar
that's popular but you have to know the password to get in. There's only one password for that
bar, and if you know it you get in no questions asked. What that means is you use a key to
encrypt data. Only that key can be used to decrypt the encrypted data. Because the same key
used to encrypt is used to decrypt it's called also called symmetric encryption. Examples of
symmetric algorithms are RC4, DES, 3DES, and AES among others.

3.2.Public Key Encryption

The theory behind public key encryption is that you have two keys: a public and a private key.
The public key can be given to anyone you want to talk to. The way it works is that you give the
person you want to talk to secretly your public key. That person uses your key to encrypt the data
and sends it back to you. You then use your private key to decrypt the data. The idea is that
anyone can use your public key to encrypt data but only you can decrypt it because you have the
private key. As you can imagine because of this, it's very important to keep your private key safe.
Because a different key is used to encrypt the data than decrypt it it's also called asymmetric
encryption. Examples of asymmetric algorithms are RSA and DH.

3.3.Digests
A digest is a kind of fingerprint for any piece of data. The way a digest works is that given a
piece of variable length data, it generates a fixed length semi-unique hash based on the
characteristics of the data. I say semi-unique because going from any variable length data to a
fixed length string there will be clashes. The object of a digest is to have a length that is long
enough that clashes are not likely given two random pieces of data. Examples of digests are
MD5 and SHA-1.

3.4.MACs
MACs are like digests except that they also take into account a key in the computation, so that
both shared key and data are used to generate the MAC. The most widely used MAC is HMAC.

3.5.Other Techniques
Other techniques used are things like sequence numbers for the records transmitted and messages
that signal the end of transmission as well as relying on the reliable protocol's mechanisms for
delivery. These help to prevent such things as the attacker from inserting random data into the
stream in hopes to confuse and/or intercept the other parties.

3.6.A Simple SSL Connection

 Figure 1. SSL Message Flow

And explanation of what this means and what's happening at each step:
1. The client (Alice) sends a list of ciphers it supports and a random number generated for
the key generation process
2. The server (Bob) sends back the cipher it has chose, it's public certificate, a random
number it generates for the key generation process, and optionally asks for the client's
public certificate
3. If the the client was asked, it sends its public certificate, verifies the server's identification
validity, generates a random key and encrypts it with the server's public key and sends it
to the server
4. The client generates a MAC of all previous messages using the random key, sends it to
the server and tells the server that all future messages will be encrypted with random key
5. The server independently generates the MAC of all previous messages to verify that no
tampering has been done, and replies that all future messages it will send will be
encrypted with the random key
At this point a secure transport has been setup for application data to flow through encrypted,
authenticated, and as we'll see, verified. When either party is ready to close the connection, it
first notifies the remote party it is doing so and then stops transmission.
In order to verify the application data has not been tampered with, each piece of data transmitted
goes through a hardening process which produces SSL records.
1. The data is broken up into fragments
2. The length of the fragment is calculated
3. A MAC is generated over the fragment and appended to the fragment
4. The fragment and MAC are encrypted with the session's shared random key
 5. A header is appended to the encrypted payload that contains information such as the
length to expect, what type of data, sequence number, etc.
When the remote side receives the record it:
1. Reads the header to know what to expect in the payload
2. Decrypts the payload with the session's shared random key
3. Verifies the fragment has not been tampered with by comparing a MAC it generates over
it to the one supplied
4. Waits for all the records for the piece of data so that it can reassemble it to use

3.7.What we've gained

From this process we've achieved our three goals of security: confidentiality, message integrity,
and endpoint authentication. We've achieved confidentiality from using the a random shared
secret key to handle encryption/decryption. We've achieved message integrity by calculating
MACs over each piece of data and keeping track of the sequences the data should arrive in.
We've achieved endpoint authentication by using one or both end's public key to verify with a
trusted third party that a) we should trust the other end, b) who we think we've connected to is
who we actually connected to and c) who we've connected to is actually who they say they are.
This third party is described in the next section and is known as a Certificate Authority (CA).

For those astute readers out there, you may be wondering why we use a shared secret key to do
the encryption and there's two reasons. First because the key is randomly generate on a per
session basis we have a high degree of confidence that the attacker won't be able to easily guess
it. Second, asymmetric algorithms are computationally expensive compared to symmetric ones.
So then why use asymmetric at all? Because symmetric algorithms depend on a shared key and if
that key is ever compromised, communications between all parties using the shared key are
compromised.

4.What a CA is
The role of the CA is to provide a trusted third party that is responsible for distributing
certificates. It's primary role is to verify that the party asking for the certificate is who they say
they are so that users depending on the CA can believe that the remote host presenting its
certificate is who they say they are. This verification is laid out in the CA's signing policy and
can be as lax as what I call the New Orleans beer philosophy, i.e., if you can ask for it you can
have it, or as strict as a DoD or NSA security clearance. There are many of these trusted CAs
whose business and life-blood it is to verify and sign these certificates. Some of these include
VeriSign and Thawte. In fact, these CA's public certificates are already bundled into your web
browser so that it knows to trust certificates signed by them.
 Figure 2. Example Web Browser Certificate Manager

It is also possible for an organization or group to provide their own CA to sign employee or
group member certificates. By trusting a CA you are trusting all the certificates that it signs to
follow the CA's signing policy guidelines. If after all this, you are curious about how a CA
operates and what to consider to become your own CA, continue reading the next section.

5.How to become a CA
If you're thinking about becoming a CA, there are few things to understand and think about
before doing it. First the organization of trust is hierarchical and ends at a root CA. The root CA
is ultimately responsible for certificate signing, but it can delegate that to lower CAs as in the
figure below.
 Figure 3. CA Hierarchy

As you can see here, Joe's certificate was signed by the root CA and Bob and Alice's were signed
by the sub CA. The sub CA's certificate was signed by the root CA as well.

Now in order to be a CA that can be trusted to any degree you have to layout you guidelines or
signing policy. In this you need to define over what area or virtual organization you'll be
presiding. You'll need to define how you will verify requests for certificates. Probably most
important, you'll need to determine how to securely store your CA's private key and who will
have access to it to sign certificates and how will that access be granted. Let's discuss the easy
parts first.

5.1.Your virtual organization

The certificates that SSL can understand are part of what's known as the X.500 class (part of an
ITU standard). Part of the certificate contains the Distinguished Name (DN). The DN is what
uniquely defines the owner of the certificate. So for example the root CA's DN might look like:

C=US,O=Snake Oil,CN=Snake Oil CA

Normally certificates that the CA signs must have a DN that is a subset of the root CA's DN.
Let's enumerate out some of the DNs from the above figure.

Joe:
C=US,O=Snake Oil,CN=Joe
Sub CA:
C=US,ST=AnyState,L=AnyWhere,O=Snake Oil,OU=Oil,CN=Snake Oil CA 1
Bob:
C=US,ST=AnyState,L=AnyWhere,O=Snake Oil,OU=Oil,CN=Bob

Let me explain what some of that means:

C :: Country Code as defined in the X.500 standard
ST :: State/Province
L :: Locality
O :: Organization
OU :: Organizational Unit
CN :: Common Name
The DN can also have other values but I leave it up to the reader to find what those are as well as
what extensions are. For the CA the DN is useful to quickly determine whether the Certificate
Signing Request (CSR) can be signed. If someone submitted a CSR that had the Organization as
"Snake Oil Competitor" (O=Snake Oil Competitor) the Snake Oil CA obviously shouldn't sign it.
If you're familiar with LDAP, you might notice that this all sounds vaguely familiar and that's
because LDAP is in the X.500 family of protocols and makes an obvious candidate for storing a
directory of signed public keys for easy access and querying.

5.2.Verifying certificates
As a CA you need to determine how you will verify CSRs. It can be something as easy as
matching the email address the CSR was sent from or as complex as having the requester
physically come in to prove his or her identity.

5.3.Securing your CA
The CA private key's privacy is tantamount. If un-authorized people have access to it, it
compromises the whole hierarchy of trust. Ideally, you want to have the machine that keeps the
private key off net and locked behind something like a card key access to prevent those not
authorized from gaining access. In order to have a portal for people to submit CSRs to we
introduce a machine called an Registration Authority (RA name taken for OpenCA). This
machine(s) can sit on the net and accept requests and queue them up for an Operator who then:
1. authorizes or denies the requests
2. moves the authorized requests to removable media (i.e., sneakernet),
3. takes them physically to the CA server
4. sign them saving the signed certificates back to the media
5. take it back to the RA server to upload the certificates so that the user can download them
and start using them
Obviously, this can be a large pain to do. If, however, security is not completely required, there
are ways to make this process a bit easier while not losing too much security, though your CA's
private key might be network accessible. You could place your CA server on a secure network
behind a very strict firewall. Access through the firewall should be limited only to the Operators
and only from a closed set of machines. Login access on the server should be limited to the
Operators and must not be clear text, and might in fact make use of a validly signed certificate.
The CA server should not be directly accessible from any externally accessible machine,
especially the RA server. If there is a web interface to the CA server for signing, access to the
web server should be client authenticated via a valid certificate. And most importantly, the CA's
private key should be read only by root and encrypted (i.e., have a passphrase attached to it).

6.Requirements for an AG2.0 CA

While there are some CA software packages out, I've found that they are a) too expensive or b)
not fully functional/buggy. So I've tried to come up with a set of requirements that a CA should
perform and some that would be nice. This is to determine whether our time is better spent
writing our own CA server software or modifying and fixing existing software. These are in no
particular order.
RA and CA should be able to be separated
Should have web interface for both RA and CA
 Web interface should be clearly documented so third party clients can make CSRs
Should be able to do all openssl key generating functions including
self sign CA certificates
export to PEM, PKCS #8, PKCS #12, and .pl12
Be able to generate service certificates, as well as host and user certificates
Be able to generate CRLs
Mail users when certificates are available and make them available online
Make use of client authentication to make Operators more easily recognized
It would be nice if
LDAP support was easily added so users could query for other users
SQL backend for storage of transient and temporal data