How does SSL work?

Lately, I have been dealing with SSL certificates on one of the projects I am working on and I have done a fair deal of research on the topic. However, I don’t want all the knowledge I collected from multiple sources to go to waste. So, I decided to summarize it in the following post.

What’s SSL?

Roughly speaking, SSL (or the newer TLS) is a protocol that runs on top of TCP and below HTTP (or rather HTTPS) and allows clients to securely communicate with a server. An example of this communication is a browser (the client) sending the user’s credit card information to a remote web server which processes a payment.

Prerequisite knowledge

There are a few concepts you have to be familiar with before you dive into the details. Please read them carefully and use this section as a reference while reading the rest of the post:

  • Public-key cryptography is a system where an issuer publishes an encryption key to the public (public key) and keeps a second encryption key secret (secret key). Any data encrypted with the private key can be decrypted with the public key and vice-versa. There are two functions that can be achieved with this system:
    • Authentication or Digital Signature where the issuer uses the private key to encrypt a message and the resulting encrypted text serves as their signature. The issuer then shares the (message, signature) pair with a receiver who possesses the issuer’s public key. The receiver can verify the identity of the issuer by decrypting the signature using the public key and matching it with the message. Only the issuer would have been able to produce the signature since they are the only ones with knowledge of the private key.
    • One-way secret communication where a receiver can use the public key to encrypt secret data and share it with the issuer. Only the issuer will be able to decrypt and access the secret data since they are the only ones with knowledge of the secret key.
  • Digital Certificate is an electronic document that allows an entity (web server for instance) to share the data necessary for a separate entity to securely exchange secret data with that entity. Typically, a digital certificate includes identifying information about the entity, a digital signature of the issuing certificate authority to prove the origin of the certificate and a public key to be used for one-way secret communication.
  • Certificate Authority (CA) is an entity that issues digital certificates. Certificate authorities are trusted entities who verify the identity of less trusted entities and subsequently issue digital certificates for them. The issued digital certificates can then be trusted by clients who want to establish secure communications with less trusted entities since they trust the certificate authority. The clients use the CA’s digital signature included in the certificate of the less trusted entity to verify the certificate actually came from the CA and subsequently trust it.
  • Certificate Signing Request (CSR) is an electronic document used by entities to request a signed digital certificate from a certificate authority (CA). The CSR includes the requesting entity’s identifying information (common name, domain, country etc.) and the entity’s public key. The CA is responsible for verifying the requesting entity’s information before issuing a certificate.

How does SSL work?

There are two main parts of an SSL handshake. First, the client initiates the communication with the server and verifies its identity:

  1. The client sends some information (serial number, cipher settings, etc.) to initiate the communication with the server.
  2. The server responds with similar information and shares its digital certificate with the client. The digital certificate includes the server’s identifying information (e.g. domain name for websites), its public key and the Certificate Authority’s digital signature.
  3. The client keeps a list of Certificate Authorities with their corresponding public keys in its trust store. When the client receives the digital certificate from the server, it retrieves the CA’s digital signature and verifies it using the CA’s public key.
  4. The client can now trust the data in the digital certificate since it trusts the CA which signed the certificate. And that certificate includes the server’s identifying information. If the server faked their information, the digital signature (computed by the CA) wouldn’t match the content of the certificate. The client can now use the server’s public key to start a one-way secure communication.

Once the client verifies the identity of the server, it starts the process of exchanging the secret key:

  1. The client generates a pre-master secret key, encrypts it with the server’s public key and shares it with the server.
  2. The server uses their private key to decrypt pre-master secret key. Only the server can access the pre-master secret key since they are the only ones with knowledge of the private key.
  3. Both the client and server then use the pre-master secret key and cipher settings to generate a symmetric master secret key.
  4. Finally, the client and server use the master secret key to generate session keys used for secure communication.

Website example

The SSL protocol is critical for websites that handle sensitive user data. Secure communications between a browser and a web server which supports SSL follow the steps described in the previous section with the browser being the client and the web server being the server. Also, in order for users to trust a website accessed through a browser, the website has to provide a digital certificate that the browser can verify. Such digital certificate should include the domain name of the website as well as the digital signature of a certificate authority (CA) that the browser trusts. So, the owner of the website has to obtain a digital certificate from a CA.

Before the owner of a website registers with a CA, they have to generate a public and private key pair on the web server. They then register the public key with a CA using a certificate signing request (CSR). In addition to the public key, the CSR includes the domain name and other identifying information about the owner. The CA then uses the CSR to issue a signed digital certificate. The CA’s signature serves as a way to certify and associate ownership of the digital certificate and the domain name. Finally, the website’s owner publishes the certificate on the web server.

When a user visits a website over HTTPS, the browser and the web server perform the SSL handshake described in the previous section. In summary:

  1. The browser receives the website’s digital certificate and looks into its trust store for the public key of the certificate authority (CA) that issued the digital certificate. If the CA isn’t listed in the trust store, it displays a security warning to the user.
  2. The browser then verifies the CA’s digital signature included in the digital certificate and the website’s domain name. First, the browser decrypts the digital signature using the CA’s public key (from the trust store) and makes sure the hash of the certificate matches the decrypted signature. Second, the browser makes sure the visited website’s domain is among the list of domain names included in the certificate. If either fails, it displays a security warning to the user.
  3. Now that the browser knows that the website is who they claim they are, it uses the website’s public key included in the digital certificate to initiate the exchange of secret encryption keys. The encryption keys are subsequently used to perform a secure communication between the browser and the web server.

Conclusion

The description above is by no means an ultimate detailed guide to SSL. It doesn’t cover all the details and concepts associated with SSL and may contain mistakes. However, it provides a structured explanation of the steps involved in an initial SSL handshake and includes an illustrative example.

BigIntegerCPP – C++ Big Integer Library

Today, I completed the first version of BigIntegerCPP, a C++ Big Integer Library. It is meant to be an equivalent of Java’s BigInteger Class. The main purpose of this library is to perform basic arithmetic operations on integers which would not normally fit in a 64 bits integer (unsigned long long).

It took me some time to turn my own code into something publishable to the public. It definitely wasn’t as easy as I expected. The source code is now downloadable from my github account. Feel free to fork the project and add your own code. You can also download the source code directly as a zip file.

The library was built to be used intuitively as if you are doing regular integers arithmetic. First, create the integers you are planning to perform the operations on:

BigInteger a("35742549198872617291353508656626642567");
BigInteger b("1298074214633706835075030044377087");

The addition and multiplication can be then performed naturally:

BigInteger c = a + b;
BigInteger d = a * b;

The library supports the C++ ostream operator “<<“. So, a code to display the big integers would look something like this:

cout << a << " + " << b << " = " << c << endl;
cout << a << " * " << b << " = " << d << endl;

Be aware that this is the very first version of the library. Therefore, I cannot guarantee any level of quality in terms of correctness or efficiency. I will appreciate it if you report any bugs you find in the comments and include the test case where the library failed.

Music is Math

This weekend I came across otomata: an automated music generator. It’s basically a simple interface where you input a random initial state that consists of marked squares. The squares will then move around the grid and generate music beats. The generator employs a cellular automaton in a fashion similar to the game of life.

Although it seems that any combination will be both acoustically and visually appealing, here are a couple of fun combinations to try:

The title is inspired from the name of this song by Boards of Canada and years of listening to Chillout Music 🙂