In this article I am going to outline what SSL is, its building blocks and how it works.

SSL

So what is it?

SSL stands for Secure Socket Layer, but that still probably doesn’t mean a lot, so what is it or what does it do?

  • It’s a mechanism for securing a communication channel.
  • It’s a method of verifying the identity of the key owner.

Securing the channel

Why do we need a secure channel, don’t we have passwords for that?

Passwords are a means of authentication, which will verify a user is who they claim to be, however if the channel on which the passwords are transmitted is not secure they can be intercepted and the identity of the user will be compromised and someone else could then authenticate as said user.

Take this scenario as an example:

User A is logging in to server X on the network. Somewhere else on the network a hacker has connected and is using a packet sniffer, a tool for capturing network packets containing data such as HTTP traffic, with which they are looking for the user credentials of people authenticating over insecure channels such as plain HTTP.

Lets say I was logging in to my mail server webmail.register.it via plain HTTP and that my username is blah@blah.com below is a screen shot of a packet capture using the Wireshark packet sniffer tool:

If I had logged in to the mail server over HTTPS the hacker would not have been able to see my username blah@blah.com and password “test1234” as the packets would have been encrypted.

So how do we secure the communication channel?

  1. While setting up the connection to the server it passes your browser its public key and specifies the encryption algorithms it can use.
  2. Your browser then determines the strongest common algorithm and creates a symmetric key that both parties can then use for encryption and decryption.
  3. Your browser then encrypts a message containing the algorithm to use and the shared key using the asymmetric public key of the server and sends this back to the server.
  4. The server decrypts this message with its private key and now both parties know the algorithm to be used and the shared symmetric key for both encryption and decryption.
  5. A TCP socket connection is now made and communication over this socket is encrypted using the shared key between the two parties.

Verification of Identity

So we have now seen how the channel is secured but we still need to understand how the identity of the server is verified.

Four conditions need to be checked to verify the identity of the key owner:

  1. The hostname of the server must be verified.
  2. The certificate or one of its signatories has to be signed by a third party that is known to be trusted.
  3. None of the certificates in the chain must have expired.
  4. None of the certificates in the chain must have been revoked.

So lets look at these one by one.

Hostname Verification

I’ll use an example of something called a Man-In-The-Middle attack.

I connect to server X over SSL or at least I think I have. The server presents me with a certificate that isn’t for server X but for server Y. If I do not verify the hostname against the certificate name, Server Y could have used DNS poisoning or some other means to fake being server X and is using his own certificate to fool you into believing the connection is secure. However you are now passing private information to some unknown party.

Therefore a check should always be made to make sure that both the hostname and the certificate name match. This still does not guarantee you are talking to the desired server if the other conditions have not been met.

Certificate Signatures

If in the above Man-In-The-Middle attack, server Y had used a self signed certificate i.e. one that someone had created for themselves, the verifying the certificate name against the hostname would give a positive result but the certificate would still not really be the proper certificate for server X.

So how do we get around this issue? Well there are a number of bodies around the world called Certificate Authorities that before issuing certificates carry out certain checks on the companies or individuals that have requested the certificates. Examples of these are Verisign, Thawte and Digicert, there are many more.

When issuing certificates they will sign these certificates using their own certificates, vouching for the authenticity / identity of the individual or company requesting the certificate. The certificates of these Certificate Authorities are considered to be trusted and most operating systems and virtual machines will include a collection of these certificates in a repository. They can then be retrieved to check that the certificate the server presented has been signed by some trusted authority.

So if server X’s certificate has been signed by one of these authorities, before the certificate was issued, we know that certain checks were carried out. However server X’s certificate may not have been signed directly by one of these authorities but by some other body that itself has been verified by one of these authorities. So to check for a valid signature we must check if somewhere within the chain of signatories certificates there is a certificate for an authority that we trust.

If this is all in order then we still have a couple of checks left to do.

Expired Certificates

We also need to check that none of the certificate in the chain have expired. Expired certificates may be out of date because the company is no longer in existence or for any number of other reasons to it is always a good idea not to trust expired certificates.

Revoked Certificates

Our last check is to verify that none of the certificates in the chain has been revoked, either because the company has been found untrustworthy, the certificate was compromised in some way such as theft etc. etc.

If all of the above checks have had positive results then we can pretty much be certain that the connection can be trusted. This is not 100% certain because someone could be taking advantage of ZERO-Day bugs or vulnerabilities and may have compromised the certificate and be using it before anyone has had a chance to react. Generally though you can rely on these checks being sufficient.

Server Authentication and Client Authentication

Server Authentication

So far we have only covered the most common case which is Server authentication, where the end user is verifying the identity of the server.

  • Only the server certificate is used.
  • Only the identity of the server is validated.

The sequence of events for server authentication can be seen in the diagram below:

The user requests a resource from the server using HTTPS which communicates on TCP port 443, the server retrieves its public key from the key store and supplies it during the handshake to the user’s browser. The users browser then checks its validity and if everything is ok completes the handshake sending back the shared key which is used to open the SSL tunnel for secure communication.

Client Authentication

There is another case though called client authentication or sometimes referred to as mutual authentication. In this case the server also verifies the user.

  • Both the server and the client use certificates.
  • The identity of both parties is verified.

The sequence of events for client authentication can be seen in the diagram below:

It is much the same as that for server authentication only upon verification of the server certificate the client then sends his public key to the server for verification before the SSL tunnel is opened.

The advantages of SSL are:

  • Identity is established.
  • Data cannot be stolen in transit.

Keystores

To round off this article a word on Keystores.

By convention where trusted certificates are stored is called a Trust Store and by convention where private keys are stored is called a Key Store

Physically they may be the same container. Although in this way a single password would be required to access both certificates and keys.