Secure Sockets Layer (SSL) in Depth | WLPC Wireless LAN Weekly EP 17

This week we’ve brought back Dave Hutchieson – with his Scottish accent and technical expertise. To share with us details of how SSL works. This is fairly detailed subject – you’ll need the show notes graphics and links to help understand all the details.

Thanks do Dave for his time in researching this subject and sharing his expertise with the rest of us.

Warning! – This is going to get pretty detailed. You might want to listen multiple times.

Symmetric Keys, Public Keys, Private Keys, Certificates and Hashing

General Information

SSL Specific

<hr />

Secure Sockets Layer or SSL

Part 1 Historical Background

In order to get the most from this audiocast, a basic knowledge of symmetric key encryption, public and private key mechanisms, digital certificates and hashing functions is assumed. If this is new material to anyone, or you feel you need a review, please refer to the tutorial weblink included in the show notes.

A ladder diagram showing the step by step processes involved in SSL is also provided in the show notes. It is suggested that this diagram be referred to whilst the audiocast is in progress.

Wireless Security is one of the most complex topics imagineable. One of the biggest problems is the number of acronyms and abbreviations that are in use. There are a number of security mechanisms in use such as  EAP-TLS, EAP-TTLS,EAP- PEAP, EAP-FAST etc etc. It would be nice if there was a common root that could be studied in order to get a foundation for how some of them work. One common type is EAP-TLS. EAP-TLS has it’s roots in TLS or Transport Layer Security. Transport Layer Security in turn, has it’s roots in SSL or Secure Sockets Layer.

I have found that if you have a good understanding of how SSL works, that can provide a stepping stone to understanding many of the more complex wireless security methods such as PEAP.

In this audiocast, we shall look at the SSL protocol in detail. SSL is not only used as a basis for several wireless security protocols but is also used in HTTPS [ Hypertext Transfer Protocol Secure ] which is often used for managing access points in a secure manner.

There are support materials provided in the show notes section, and these have diagrams which may be viewed to accompany the audio portion.

SSL is a very complex protocol and due to time constraints, we will not be able to discuss all the details that are involved. However, it is hoped that by the end of the audiocast, and with the support of the show notes, that you should have a good foundation for further study.

In a future audiocast, we shall look at how TLS was developed from SSL and how EAP-TLS was developed from TLS.

Imagine that you are on holiday and are looking out at the countryside. You decide that there are a number of different places that you want to visit on the landscape. You use a paper map to navigate around the landscape.

In the early 80’s, an English scientist, Tim Berners-Lee developed the foundation of the world wide web. However, it was a young student called Marc Andreessen from the University  of Illinois who developed the first commercial browser. This browser allowed us to navigate  from place to place on the electronic landscape. Thus, his browser allowed you to navigate the electronic network landscape or netscape.

Thus, the term Netscape Navigator came into being.

It wasn’t long before the commercial aspects of the Internet began to be developed. Companies sprouted up all over the place trying to sell goods and services to people. There was a major problem, however, and that was the issue of security. If someone wanted to buy something, that would probably mean that they would have to provide their credit card number over an open line. A method of hiding that number from prying eyes had to be developed. The issue of confidentiality or privacy had to be covered. There was also the problem of having confidence that the company that you are going to buy something from was actually that company and not an imposter. The issue of authentication had to be covered.

It was from this background that the Secure Sockets Layer or SSL was developed.

Part 2 SSL Overview

SSL was designed to work on top of a secure transport layer protocol, such as TCP or Transmission Control Protocol.  We can get a clue about this from the use of the term “sockets” in the phrase SSL.

The designers wanted SSL to accomplish three main goals:

1. To provide privacy of information

2. To provide authentication [ although as we shall see later, this is not always mutual authentication ].

3. To provide a method of message integrity which would allow us to detect if a message had been tampered with on-route from the sender to the destination.

The SSL protocol has two layers which sit on top of a reliable transport protocol. In our discussion, we shall assume that protocol is TCP.

The uppermost layer comprises three sub-protocols:

1. The SSL Handshake Protocol

2. The SSL Change Cipher Spec Protocol

3. The SSL Alert Protocol.

The lowermost layer comprises the SSL Record Protocol

The SSL Record Protocol performs a number of functions. Firstly, it takes the application data and divides it into a number of fragments when necessary. The fragment size should be no more than 16,384 bytes in length.

The specification says that we can compress these fragments. This is rarely if ever carried out in practice due to compression usually having occurred further up the protocol stack.

A Message Authentication Code is then added to each fragment.

Each fragment is now encrypted and an SSL header is added.

The secure, integrity enabled fragments are now passed onto the transport layer.

We will see later how we obtain the keys used for the actual encryption process.

Part 3 SSL In Detail

We shall now look at the three uppermost protocols, the Change Cipher Spec Protocol, the Alert Protocol and the Handshake Protocol.

The Change Cipher Spec Protocol

The Change Cipher Spec Protocol allows us to change from one encryption state to another in an organized manner. We shall see more of this later.

The Alert Protocol

The Alert Protocol allows warning messages to be passed between the two parties. For example, if an incorrect Message Authentication Code is received, an alert protocol message would be sent from one party to the other.

The Handshake Protocol

The handshake protocol is the meat of the entire system, and is the most crucial component for TLS and EAP-TLS.

Imagine that you are a police officer and your lieutenant tells you that you have to go over to the United Nations to talk to a UN security officer about a very important matter. The officer will be waiting for you at the entrance. Upon arrival, you walk up to him and say “Hello”. He looks at you with puzzled eyes. You realize that your boss has not told you what language he speaks. You say “Guten Tag”. No reponse. You say “Bonjour” no response. You finally say “Buenos Dias”. His eyes light up and he says “Ah, Buenos Dias, como esta usted ?” You shake hands. You show each other your ID badges and start talking.

In social situations, we don’t usually just walk up to someone and start talking. We usually say hello and shake hands. Sometimes we need to establish a common language.

So it is with SSL. Instead of just starting to communicate, hellos need to be said and handshakes need to take place.

There are four main phases to SSL:

1. Negotiation

2. Authentication

3. Key Exchange

4. Ongoing communications

Let’s look at each phase now.


During the negotiation phase, the client and server introduce each other, and decide which encryption, authentication and compression protocols will be used. It should be noted that even though the capability for compression exists in the SSL specification, it is rarely, if ever used.


In the authentication phase, the server proves itself to the client via a digital certificate. The server may also ask the client to prove itself via a digital certificate. It should be noted that in the case of Internet shopping, this is rarely, if ever done.

Key Exchange

In the key exchange phase, a key is exchanged which will be used in creating a master key for encrypted communications. There are several methods by which this can be done, including the Diffie-Hellman method, which I shall discuss in a future audiocast. For now, we shall only discuss what is called the RSA method.

Firstly, the client randomly generates a key called the pre-master secret key [ or PMSK ] by means of a method that will be covered when we discuss SSL in detail a little later on.

Firstly, the client encrypts the PMSK with it’s own private key. This allows the server [ who has a copy of the client’s public key ] to authenticate that the PMSK did indeed come from the client.

The whole assembly [ that is the PMSK encrypted with the client’s private key ] is now encrypted with the server’s public key [ which came via the server’s certificate ] and sent to the server. The server decrypts the package with it’s own private key. This now leaves the original PMSK  which has been encrypted with the client’s private key.

The server decrypts this package with the client’s public key and hence authenticates the original PMSK.

This original key is not the final key in the process, but is used along with some other items to create the final symmetric key, also known as the master key. From the master key, session keys can be derived.

Ongoing Communications

Now that both sides have the symmetric or master key, they can exchange messages in an encrypted manner. Digital signatures can also be provided to help ensure authentication and message integrity.

Now we are now ready to discuss the detailed step by step operation of the SSL handshake protocol.

Step 1. Client Hello

This message begins the entire process.

The Client_Hello message is sent from the Client to the Server. There are four  main things that are included in the message:

1. A random number called ClientHello.Random. This random number will be used to create a key later on in the process. The random number consists of a 32 bit timestamp along with 28 bytes created by a random number generator.

2. A list of cyphersuites and compression methods that the client supports.

3. The highest version of SSL that the client supports

4. A session identifier that indicates whether the client wishes to establish a new connection on the current session or establish a new connection on a new session

The session identifier is useful for “going back” to previous webpages for example.

So what is a cyphersuite ? A cyphersuite consists of a listing of encryption methods, certificates and integrity checking methods. The client cannot just simply say “I am going to use this value of encryption, this certificate and this integrity checking method”. It has to check with the server to see if the server is actually capable of using any of the methods.

Step 2. Server Hello

The Server Hello message is sent from the server to the client. There are four  main things that the message contains:

1. A random number called ServerHello.Random. This number will also be used to create a key later on in the process.

2. The cyphersuite that the server wishes to use, chosen from the list supplied by the client

3. The lowest common value of the version given by the client and the highest that the server supports. For example, if the client suggested 2.0 and the server supports up to 3.0, the 2.0 version would be used.

4.  A session ID number. This number uniquely identifies the current session and helps with security.

The Cipher Suite is made up two main parts:

A. The Key Exchange Method. That is, how the keys will be exchanged. For example, this could be the RSA method, Diffie-Hellman method, etc.

B. The CipherSpec itself, which has fields which tell us the algorithm being used [ for example RC4, DES etc ],

the MAC Algorithm [ for example MD 5 or SHA-1 ]

the Cipher Type [ for example stream cipher or block cipher ]

the HashSize [ for example up to 16 bytes for MD5 and up to 20 bytes for SHA-1 ]

Up to this point, unique random numbers have been exchanged, an encryption method has been agreed to, and a unique session identifying number called the “session ID” has been generated.

Step 3. Server Cerificate

At this point, the server sends the client it’s digital certificate. This point is very important, as not only will the client use a key  provided in the certificate to encrypt messages back to the server, but the certificate provides proof that the server is what it says it is, and not an impostor.

The client will have previously been provided with a public key from the certification authority. This authority could be a reputable organization such as Verisign for example.

At this stage, we have to carefully distinguish between the two public keys mentioned:

The first public key has been provided by the certificate authority, that is, an independent certifier, who basically says: “If you can validate the certificate that you have just received from your server using the public key that I provided to you, you can be certain that the server is who he says he is”

Once the certificate has been verified, the client extracts the server’s public key from the certificate. This key is very important. Any messages encrypted with this key can only be decrypted by the server using it’s own private key.

Step 4 Server Key Exchange

A server-key-exchange message may be sent in this step. Only some  systems require this. In our example of using regular RSA, we do not require this step.

Step 5 Client Certificate Request

In this step, the server may request a certificate from the client via a certificate_request_message. This message has two areas of interest. Firstly a certificate type parameter. The certificate type would cover RSA or Diffie-Hellman for example.

The second item concerns certificate authorities. This would give a list of the distinguished names of certificate authorities whom the server deems to be “reliable”.

Step 6 Server Hello Done

At this point, the Server Hello Done Message is sent from the server to the client. This is the end of the first phase of the proctocol exchange.

To summarize:

Hello messages have been sent from the client and server.

An encryption method and other security parameters have been agreed to.

The client has it’s own random number and that of the server.

The server has it’s own random number and that of the client.

A certificate has been sent from the server to the client, and possibly one from the client to the server.

The public key of the server has been extracted from the server’s certificate, ready for use in the second phase.

A point to note: there are no formal first and second phases in the TLS specification. I have simply broken up the process into two parts in order to, hopefully, make the process easier to undertstand. In a future audiocast, I’ll be covering another EAP method which does have two officially defined phases.

Step 7 Client Certificate

In this step, if the server has requested  a certificate, then the client will send one.

In the classic case of SSL being used in HTTPS for internet transactions with say an on-line clothing company, the customer or client would not normally have to provide any formal identification with the exception of say a credit card number. This is obviously somewhat a problem , as it means that fraud could and in fact does occur.

Step 8 Client Key Exchange

In common with many other security protocols, a true master secret key is not sent between the two parties. Instead, a key called the pre-master secret is created and sent from the client to the server. This pre-master secret will then be used at both ends of the link to create a master secret key.

A random number is generated at the client and this number is referred to as the pre-master secret key or PMSK

Firstly, the client encrypts the PMSK with it’s own private key. This private key is known only to the client.

This allows the server [ who has a copy of the client’s public key ] to authenticate that the PMSK did indeed come from the client.

The whole assembly [ that is the PMSK encrypted with the client’s private key ] is now encrypted with the server’s public key [ which came via the server’s certificate ] and sent to the server via a client_key_exchange message.

The server decrypts the package with it’s own private key.

The server’s private key should be known only to the server. This now leaves the original PMSK  which has been encrypted with the client’s private key.

The server decrypts this package with the client’s public key and hence authenticates the original PMSK.

At this stage, both sides have the pre-master secret key. In the next part, the actual or master secret key will be calculated at both ends of the link.

The master secret is calculated using a complex hash function involving the pre-master secret, the ClientHello.Random and the ServerHello.Random variables or nonces that were described earlier. The master key is 48 bytes in length. From the master key, a number of other keys are derived. These keys are used for encrypting data sent by the server, for MAC operations performed by the server, for encrypting data sent by the client and for MAC operations performed by the client. Initialization Vector values are produced for the situation in which block ciphers in CBC mode are used.

Step 9 Client Certificate Verification

A  certificate_verify message is sent if the client previously provided a certificate to the server. This message is only used with certificates that have signing capabilities.

Step 10 Change Cipher Spec

It should be noted that the Change Cipher Spec protocol is a separate protocol from the handshake protocol. It has been included here due to it’s critical  function within the handshake protocol itself.

SSL keeps a record of two states called the current state and the pending state. We can think of these two states as “Conditions that are happening now” and “Conditions that will happen later”.

When SSL is first initialized, both states are zero. Once the master key is established, that key is used for a pending state. Both sides end up with a pending encryption process waiting in the wings so to speak.

The pending Cipherspec is copied into the current Cipherspec. We just need some form of agreement between both ends as to when to begin implementing the encryption.  This occurs in the next step.

Step 11 Finished

The finished message is used to tell the other end that the key exchange and authentication procedures were successful. This message is encrypted with one of the newly produced keys, and authenticated as well.

Once the server receives the encrypted finished message from the client, it is able to send it’s own change_cipher_spec and finished messages in steps 12 and 13 of the process.

Finally we are able to encrypt any data that needs  to be sent from either party.

That was quite a lot of material, but the core of the whole process [ as for many other security protocols ] consists of :

Negotiation,  Authentication,  Key Exchange and  Ongoing Communications

In the show notes section, I have included an interesting trace of a client to server communication process

I hope that this audiocast was useful, and thank you for listening.

We’d love to have you subscribe to our RSS feed – just click the button in the upper right corner of the web page. Until next week, thanks for listening!

If you have any feedback on the show – please drop an e-mail to

Subscribe To The Wireless LAN Weekly Podcast:
Zune iTunes RSS Feed