SSL

 

This web page is a brief look at SSL - I got involved in something connected withh SSL, so these are some brief notes about SSL and the interaction between a client and a server.

It is written around a web browser and a web server, but it is probably relevant elsewhere.

 

The overview

SSL is a mechanism for setting up a secure communication medium between a client and a server. It is normally the browser that would instigate, or request, an SSL connection.

SSL is a connection orientated mechanism, a session is set-up between the client and the server, and can be used for as long as the client requires.

After the client has got all the information or the interaction that it requires, the connection is closed down.

 

Protocol stack

The normal protocol stack for http looks something like 


        http

        tcp

        ip

        data link layer

        physical layer

SSL adds another layer, so in simple terms, the stack now looks more like 


        http

        SSL

        tcp

        ip

        data link layer

        physical layer

For normal http, data is carried on TCP port 80. In order to distinguish it from normal http traffic, http on SSL is usually carried on TCP port 443.

http over SSL is known as https.

There is another type of secure http, which is s-http - this is not a connection orientated mechanism, it is connectionless, and is designed for one-off transmission of data. As soon as the web page has been transmitted and received, it ceases to exist. I don`t look at s-http on this web page.

 

Encryption

SSL uses two kinds of encryption

In symmetric encryption, a secret key is known to both the sender and the receiver of the message. The sender uses the secret key to encrypt a message, sends the message to the receiver, and the receiver uses the same key to un-encrypt the message. As long as only the sender and the receiver know what the secret key is, in theory, they have a secure means of communication.

However in a client/server environment where there are possibly millions of clients, it would be impractical to use this form of secure communication on its own. Either the whole world would have to know what the secret key is, which means it is not very secret, or else the server would have to store millions of secret keys, one for each client.

So we move on to the second form of encryption used in SSL - public key encryption.

In public key encryption, the server generates two keys - a private key, and a public key. These two keys work as a pair - one is used to encrypt messages, the other is used to de-encrypt messages.

An important part of the public key encryption mechanism is the fact that a message that has been encrypted with the public key cannot be un-encrypted with the public key again - it just doesn`t do it. The only way to un-encrypt a message that has been encrypted with the public key is to use the corresponding private key.

And the other way around as well.

So in SSL, the server has the public key and the private key. The server will send the public key to any client that asks for it.

The client generates its own symmetric key, and then encrypts it using the public key it received from the server, and sends this off to the server.

The server un-encrypts the symmetric key using its private key, and now the client and the server both know a secret symmetric key, so can have a secure two way communication.

Once the communication has been completed, the SSL connection is closed down, and the secret symmetric key is discarded.

 

Public keys and certificates

However this isn`t the whole story - as there is a problem - how does the client know that it is talking to the right server.

The user put the URL into the browser address window, and pressed return. The browser goes off and starts to talk to the server.

But the initial request from the browser to the server is in clear text - so using some kind of man-in-the-middle attack, it is straightforward for someone to intercept the request, and connect the client to a false server. The browser will not know, it gets sent a public key, and starts to use it.

Another possibility is DNS highjacking - when the browser does a DNS look-up for the server IP address, a false IP address is sent back to the client, and the browser starts to talk to a false server.

SSL therefore uses certificates to prove that the server is the real thing.

In essence, the owner of the server applies to a Certificate Authority to be issued with a Certificate which proves the authenticity of the public key.

A Certificate Authority is really just an organisation that sets itself up to create and sell certificates.

The Certificate Authority examines the credentials of the owner of the server, and if it is satisfied that the owner of the server is who they say they are, they will be issued with a Certificate.

The certificate is sent to the client along with the public key. Most modern browsers have built in to them a list of known Certificate Authorities - so when the browser sees that the Certificate Authority is one of the Authorities it knows about, it accepts that the certificate, and therefore the public key, is genuine. If the browser does not know about the Certificate Authority that issued the Certificate, it generates warning messages for the user.

In Firefox 3, you can see the list of Authorities by going to Preferences / Advanced / Encryption / View Certificates / Authorities.

Thinking a bit more about this - there would appear to be a weakness here - the browser assumes that a certificate and public key are genuine because it has been issued by a Certificate Authority that the browser knows about. But what is to stop the owner of a false server from setting up the false server to issue the same certificate that should belong to a real server. It is afterall easily obtained. In fact it shouldn`t be a weakness, because the false server would not have the private key which only exists on the real server, and is never transmitted to anyone. Without this private key, the false server can`t un-encrypt any data from the client, which data the client has encrypted with the public key.

There is another weakness - in this case, a real one - if a rogue organisation can "persaude" a user to accept a rogue certificate that has in fact not been authorised by a Certificate Authority, then once it is in the browser list, the browser will thereafter accept any similar certificate and public key without worrying about it. Users often ignore security pop-ups, because they don`t understand them, so maybe it wouldn`t be too difficult for the rogue organisation to achieve this.

 

Public Key Infrastructure

Although an organisation can set itself up to issue certificates, there is an infrastructure that oversees their activities, and certifies them as a Certificate Authority.

This infrastructure is known as the Public Key Infrastructure, and there are several parts to it - essentially they are -

 

Digests, or hashes

Another security mechanism that is built into SSL is the use of digests. A digest is a summary - so when a message is sent, the sender creates a summary of the message, and adds it on to the tail of the message. A digest is also known as a hash.

When the receiver receives the message, it uses the same rules to create its own hash of the message, and then compares the two hashes - if they are the same, the message is just as the sender sent it. If the hashes are different, then the message has been corrupted or deliberately altered.

The significant thing about a hash is that it is done in such a way that it is not possible to recreate the original message from the hash.

This mechanism therefore should prevent a man-in-the-middle attack during which an intruder tries to read or alter the message.

There are two commonly used methods of producing the hash -

        - MD5 is a 128 bit hash

        - SHA-1 is a 160 bit hash

 

Setting up the connection

Putting all this together, we get the following somewhat simplified view of the negotiation that occurs between the client and the server, in order to set up a secure SSL connection.

Once the SSL connection has been set up, the browser talks to the server using the normal http protocol, which is sitting above the SSL layer.

 

More on the protocol stack

There is in reality quite a lot of communication involved between the clent and the server - I used wireshark to monitor the data traffic between a client and a server in setting up an SSL connection and downloading just the first page, which was little more than a login box - there were over 1500 packets involved.

It also involves more protocols than have been listed above - a more complete view of the protocol stack is something like

  


           SSL         SSL change      SSL alert       http
        handshake     cipher spec      protocol
        protocol       protocol

   
                                  SSL

                                  tcp

                                  ip

                             data link layer

                             physical layer

 

Another weakness of SSL

There is another weakness of SSL - once the random symmetric key has been set up and shared between the client and the server, this key is used for all subsequent conversations between the client and the server, until the connection is closed down.

However it is a known weakness of encryption that repeated transmission of data that has been encrypted using the same key can allow someone evesdropping on the conversation to work out the key.

A more secure process would be to force the client and the server to renegotiate a new symmetric key on a regular basis during the conversation - this would result in it being a lot more difficult to work out the key.

 

 

 

 

 

website design by ron-t

 

website hosting by freevirtualservers.com

 

© 2024   Ron Turner

 

+                                   +  

 

Link to the W3C website.   Link to the W3C website.