Introduction

My goal with this series was to explain how SSL works and the basics you need to know to setup a server and certificates correctly. I won’t try to dig deeper on the algorithms, but more on the high level message exchange between client and server.

I think most developers are more or less used about HTTP clients complaining about SSL certificates and we just think they are too strict. Sometimes we write code to ignore some of these certificate error messages without understanding the potential risks. Since I had enough of that, I’ve decide to dig a little bit deeper and understand how it works and my intention here is to publish my conclusions.

Why SSL?

Simple. To transfer data safely between client and server. By safely, I mean, encrypted.

This simple statement breaks down to some other concerns:

• Is the client speaking with the right server? Is there someone in the middle?
• Can someone sniff the communication between client and server?

Asymmetric Encryption in a nutshell

Before we move forward, it is important to understand some basics about asymmetric encryption.

In traditional symmetric algorithms, you have a single key to encrypt and decrypt the file. A good example would be the blowfish algorithm (one of the most popular and easy to use). You take a chunk of bytes and apply the key. Whoever sees the message would not understand, but knowing the key, you apply the decryption algorithm and you have the original information back. Simple, but, you need to communicate the key somehow.

In an asymmetric algorithms you have a public and private key. The idea behind an asymmetric algorithm is: if someone wants to talk to me, I give them my public key. They encrypt the information with that public key and I decrypt with private key. The algorithm is implemented in a way that way you can only decrypt the information with the private key.

Security certificates will contain (not exclusively) keys. The private certificate (usually with an .ppk extension) will have the private key and should never be sent to anyone else. The certificate files, as we know it (usually .cer extension) will have the public key.

How SSL works

At high level, the following happens:

• The client starts the communication to a server (https://something).
• The client sends some information about “how” it wants to speak with the server. Which algorithms it uses, protocol versions, compression, etc.
• The server sends its certificate (containing a public key).
• The client decides if the certificate is authentic or not. The certificate must be signed by a Certificate Authority (CA) which its root certificate must be in its “trusted list” (I’ll explain more about how this is done next).
• The client computes a symmetric key, encrypts using the server public key and sends back to the server (this step may change depending on algorithm).
• The server decrypts the symmetric key using its private key.
• The client start sending all communication encrypted with the symmetric key. This is done for performance reasons, since asymmetric algorithms are slower than symmetric ones.

How the client validates if the server is who it claims to be?

How a certificate is issued and signed?

• The server (the http server), generates a certificate, in other words, a pair of public and private keys.
• The public key of this certificate is sent to a Certificate Authority (CA)
• The CA signs this certificate (more about this later).
• The CA sends back the certificate (.cer file) with the digital signature contained.

How the digital signature works?

I’ll answer this in 3 levels. Depending on your mood you can pick one:

• Beginner: Some mathematical magic.
• Intermediate:
• The CA knows a magic number. It is a very complex number based on some prime numbers.
• Knowing this magic number you can apply a mathematical procedure that will generate the digital signature.
• Validating that the digital signature without knowing that magical number is a problem that can be computed using few resources.
• Generating the magical number based on the other information provided is a problem that can’t be computed using a lot of resources. If you don’t believe in this, read the “hard” answer. If you crack this, you are going to be very famous. If you know this number, you can “impersonate” the CA.
• Hard:
• When I was doing my research do write this, I found this article: The first few milliseconds of https. If you want to dig deeper, that is the way to go. Disclaimer: The session not “too” scary guide to RSA is pretty scary. At least for me.

Okay, I know that the certificate was signed by a Certificate Authority. So what?

When you install your OS, browser, environment. You also install a list of “Root certificates” which are commonly known as trusted organisations. It is like public notarial services (if the country you live does have notarial services). If they say that that certificate is valid, it is valid.

And here comes the important thing. If you trust your CA, you trust all certificates signed by them. That’s why breaking that digital signature, or knowing the magic number matters.

Conclusion

In this part, some of the basic mechanics of how SSL works was covered. Next we will explore warning messages and what they mean.