I never really cared about how SSL/TLS works. I never knew what a certificate is and what CAs actually do. Why? Because it all happens on top of the transport layer, and developers only need to concern themselves with what occurs in the application layer. I’m familiar with RSA, Diffie-Hellman, and some hashing algorithms. Most network security concepts are built on these foundational cryptography algorithms. I knew the base so I had no interest in delving into what is built on the base. The only practical thing I knew was that HTTPS is for secure sites! I lived happily until last week when I wanted to deploy a service I had written to a Kubernetes cluster at my workplace. There was a REST call to another internal service in my code that worked fine on my local machine but failed in the cluster. It displayed an error containing ‘SSL’ and I had no clue what was wrong since it worked on my local machine. After showing it to a senior colleague, whitout any explanation he told me exactly what to do. It was a straightforward task, but I still wasn’t confident enough. What if another SSL error occurs? I realized that I needed to learn about SSL on my own terms. My preferred method of learning involves thoroughly studying the theory, attempting to answer all the questions that arise, and only after that I understand its entirety; then I try a tool to test it in practice. When you search for SSL online, you often come across numerous non-technical pages created by salespeople peddling their certificate products. Reading these pages didn’t satisfy me. I had to find a good university lecture, and that’s when I stumbled upon this one. I recommend checking out the other lectures in the course; they are genuinely excellent! The instructor provides a definition for lectures with which I totally agree. Alright, enough of the story; I’ll explain what are SSL certificates for in the next paragraph.
Locks used in the real world typically rely on one key; for example, car doors can be opened with the same key they were locked with. There is another type of encryption known as asymmetric encryption, which involves two different keys. In asymmetric encryption, each party possesses a pair of public and private keys. Anyone has access to the public key, but only the owner of the key has access to the private key. A text encrypted with a private key can only be decrypted with the corresponding public key, and vice versa.
If Bob receives a message claiming to be from Alice, he can verify its authenticity by attempting to decrypt it with Alice’s public key. If he succeeds, it means that the message was indeed sent by Alice. When a party encrypts a text with its private key, we say they have “signed” the text. Furthermore, if Bob encrypts a text with Alice’s public key, only Alice can read it. All of this is well and good, but we assumed that Bob knows Alice’s public key. If not, how Alice can share her public key to Bob?
If Bob receive some message claiming to be from Alice, he can check wether it can be opened with Alice’s public key. If it could the it means that the text was really from Alice. If some party encrypts a text with its private key, we say they have signed the text. Furthermore, if Bob encrypts some text with Alice’s public key then only Alice can read the text. It’s all good but how can Alice tell Bob her public key? Alice cannot distribute her public key over an insecure network since anyone in the middle can tamper with the messages. Alice and Bob can physically exchange their keys, but what if that is not possible. If there is a trusted person like Charlie, whom both Alice and Bob trust and have his public key, then Alice can send her public key to Charlie and ask Charlie to forward it to Bob. (Assignment: Is it possible to exchange keys without trusting?)
Now, let’s talk about the internet. How can you be sure that when you send a request through your browser to hnaderi268.blog, it actually goes to hnaderi268.blog? How do you know it’s not some fraudulent site pretending to be hnaderi268.blog? To address this issue, Netscape designed the SSLv2.0 protocol in 1995. After several upgrades and fixes, TLS protocol was introduced, which replaced SSL, though the name SSL remained popular. Network protocols are written in the form of RFCs (Request for comments). RFCs self contain the detail definition of the protocol and enough for those who will implement the protocol. TLSv1.0 version is described in RFC 2246. It is nice to read RFCs! The TLS solution is to have a set of root certificate authorities (CAs) that everyone on the internet trusts. A list of these trusted root certificates is stored on your computer, typically included when you purchase it. When your browser wants to verify a host claiming to be hnaderi268.blog, it requests information from these CAs: “What does your certificate say about who you are?” A certificate is essentially a public key signed by a CA. It can be a root CA or a CA trusted by a root CA, or even a CA trusted by another CA, forming a chain of certificates. After obtaining hnaderi268.blog’s certificate, your browser verifies whether the certificate is trustworthy or not. Furthermore, a certificate contains the host name for which it was issued and an expiration date. Therefore, for your browser to trust a site claiming to be hnaderi268.blog, it needs to find hnaderi268.blog name in the certificate provided. You can see the chain of certificates, common name and expired date of hnaderi268.blog’s certificate in the image below.
In the hnaderi268.blog example, and in most cases, only one party needs to trust the other. However, in a few cases, both the client and the server need to present their certificates to prove their identity. Up until now, we’ve discussed how certificates can be used to authorize servers or clients, but SSL offers more than just certificates.
Encrypting messages using public/private key algorithms is generally slow, making it unsuitable for encrypting large messages over the internet. Symmetrical encryptions are faster.1 With a secure channel established through private/public key encryption, Alice and Bob can share a secret key, enabling them to communicate quickly with an efficient encryption. This sequence of steps, involving presenting certificates and exchanging a secret key, is known as the handshake. Another crucial component of SSL is the Record protocol, which governs communication after the secret key exchange.
The cryptography tool you can use to create and view certificates is OpenSSl. It is installed by default in most versions of MacOS and Linux. You can create a certificate with this command.
$ openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365X.509 is the standard format for certificates. rsa:4096 means that RSA algorithm is used with 4096 bit keys. Your private key is stored in key.pem and cert.pem is the certificate containing your public key. The certificate cerated with this script is called a self-signed certificate because no other authority has signed it. If some host provides your browser a self-signed certificate your browser is going show you a ssl error. You can trust the self signed certificate in your browser properties.
You can view the content of a certificate with this command:
$ openssl x509 -in cert.pem -text- https://preyproject.com/blog/types-of-encryption-symmetric-or-asymmetric-rsa-or-aes ↩︎