Forem: Akash Kumar Sikarwar

All about HTTPS (part-4)

Akash Kumar Sikarwar — Sat, 10 Jul 2021 12:35:54 +0000

The differences between HTTPS, SSL and TLS

In the previous post we talked about the handshake process between browser and the server. There we mentioned various terms like HTTPS, SSL and TLS.

It's easy to confuse these terms and use them interchangeably. Let's look into each one and see how they differ.

HTTPS

HTTPS is the secured version of HTTP: HyperText Transfer Protocol. It is the protocol used by your browser and web servers to communicate and exchange information. When that exchange of data is encrypted with SSL/TLS, then we call it HTTPS. The 'S' stands for Secure.

SSL

SSL stands for 'Secure Sockets Layer'. A protocol created by Netscape. It is a dinosaur by Internet standards.
Netscape developed it in the year 1994. It was envisioned as a system that will ensure secure communication between client and server systems on the web. Gradually, the IETF (the Internet Engineering Task Force) picked up the protocol and standardized it as a protocol. Two versions of SSL followed that ironed out the vulnerabilities found in version 1. The current SSL version is SSL 3.0.

If we look at below history, we can assume that IETF seriously attempted to secure online data with robust security at its best.

SSL 1.0 - Due to security flaw, SSL 1.0 was never released.
SSL 2.0 - First public release of it by Netscape in February 1995 but there were design flaws that compelled Netscape to release SSL v.3. However, SSL v.2.0 was deprecated in 2011.
SSL 3.0 - SSL v3 was an upgrade version of earlier version SSL v2.0 that fixed few security design flaws of SSL v2.0 However, SSL v3.0 deemed insecure in 2004 due to the POODLE attack.

TLS

TLS means Transport Layer Security, which is a cryptographic protocol successor of SSL 3.0, which was released in 1999.

TLS 1.0 - TLS 1.0 which was upgrade of SSL v.3.0 released in January 1999 but it allows connection downgrade to SSL v.3.0.
TLS 1.1 - After that, TLS v1.1 was released in April 2006, which was an update of TLS 1.0 version. It added protection against CBC (Cipher Block Chaining) attacks. In March 2020, Google, Apple, Mozilla and Microsoft has announced for deprecation of TLS 1.0 and 1.1 versions.
TLS 1.2 - TLS v1.2 was released in 2008 that allows the specification of hash algorithm used by the client and server. It allows authenticated encryption, which added more support with extra data modes. TLS 1.2 was able to verify length of data based on cipher suite.
TLS 1.3 - TLS v1.3 was released in August 2018 and had major features that differentiate it with its earlier version TLS v1.2 like removal of MD5 and SHA-224 support, require digital signature when earlier configuration used, compulsory use of Perfect forward secrecy in case of public-key based key exchange, handshake messages will now be encrypted after “Server Hello”.

In nutshell, SSL is obsolete and TLS is the new SSL protocol as modern encryption standard being used by everybody. Technically, TLS is more accurate, but everyone knows SSL.

Thanks for reading this. Until next time.

All about HTTPS (part-3)

Akash Kumar Sikarwar — Sat, 10 Jul 2021 09:44:27 +0000

The handshake

In the prev post, we talked about two types of encryption keys algorithms. In this post, let me walk you through the process of the handshake.

When you started reading this article, your browser displayed a green lock in the address bar. How did that happen?

Your browser communicated with dev.to server, where this post is hosted, and they both established a secure connection to transmit messages.
But first, they needed to agree on how to communicate securely. If the negotiation is not successful, your browser lets you know by showing an error or warning. If an agreement is reached, your browser is happy to display a green padlock on the address bar. This process, the negotiation between a browser and a server, is called 'the handshake'. It happens very fast without any delay. Let me help you understand it step by step.

Step 1: Client Hello. Your browser sends a list of SSL/TLS versions and encryption algorithms that it can work with to dev.to server. A fancy word for the encryption algorithm list is 'cipher suite'. And then your browser waits for an answer from dev.to server.

Step 2: Server Hello. Server chooses the best SSL/TLS version and encryption algorithm among the ones browser sent it, and based on its preferences. Server replies with its certificate, which includes its public key, so that it can verify who it is.

Step 3: Client Key Exchange. Your browser checks server's certificate to make sure its legit. It generates a 'pre-master key' so they can both user it later when they generate a unique key. Browser encrypts that pre-master key with server's public key and sends it back to the server.

Step 4: Change Cipher spec. Server uses its private key to decrypt the pre-master key. So far all the communication between them has been in open. They have not secured any messages. They used asymmetric keys (public and private keys) to encrypt the pre-master key so nobody could spy on it. Now they both generate the same 'shared secret' that they are going to use as a symmetric key. Browser sends a test an encrypted test message to which server responds saying everything is OK.

Step 5: Everything is now secured. Now all data going back and forth between your browser and dev.to server is now secured for the rest of the session. Passwords, credit card details(if any), everything.

Simple right? Here is a diagram to help you understand this handshake better.

In the next post, we will try to understand the differences between the terms HTTPS, SSL and TLS we talked about earlier.

All about HTTPS (part-2)

Akash Kumar Sikarwar — Sat, 10 Jul 2021 09:42:53 +0000

Encryption Keys

Welcome to the second post of the series on All about HTTPS.
In the prev post, we talked about why do we need HTTPS connection. In this post we will talk about how the encryption keys work.

HTTPS needs a way to provide privacy, integrity and identification on the web that we talked about last time by converting the plain text into some unreadable data. And that mechanism is called encryption. For that we have two types of encryption algorithms.

1. Symmetric key algorithm
In this scenario, there is only one type of key to encrypt and decrypt a message. Lets try to understand this by taking a simple example. Before sending the message to Bob, Alice encrypted the message with a key. You can think of the encryption process like putting the message in a box and locking the box with a key. Only the person that has a copy of the key can open the box and read the message.
This guarantees that the box cannot be opened until it reaches the person with the right key. When Bob gets the box, he uses his key to open it and read the message. It's important that the key is kept private. You should not share the key in plain text, or send it with the box. Remember, anyone with the key can open the box. Using the box is a nice visual to understand encryption, but it's really oversimplifying it. In reality, anyone looking at the message without the key only sees nonsense text like below.

To decrypt a message, we just need to apply the same steps, but in reverse order.

The encryption key is mixed in with the message, so even if you know the encryption algorithm, without the key, the message is still nonsense.
One main issue with symmetric keys is that they are hard to share. You have to be super careful with how you distribute the key. This brings us to the next topic of discussion asymmetric keys.

2. Asymmetric keys algorithm
This time instead of one like in symmetric, we have two keys. One key is public, the other one is private. They are paired and work together. Share your public key with anyone. Send it in plain text, make stickers, tattoos. Anything you want! It's public!. Alice is sending his public key to Bob and now Bob is sending a message back to Alice encrypting it with Alice's public key. In other words, Bob puts the message in a box and locks it with Alice's public key. Bob can now use his private key to read the message. That's the main idea. Only the private key can open a box locked with the public key pair. Alice uses Bob's public key to send him another message. This is great not only for privacy, but also for identification since we know for sure that only the owner of the 2 keys can open the message.

Next, we'll be looking at how symmetric and asymmetric keys play a role when we connect to a site with SSL. See you in the next post.

All about HTTPS (part-1)

Akash Kumar Sikarwar — Sat, 10 Jul 2021 09:41:12 +0000

Why do we even need HTTPS protocol?

When you arrived at this post, do you see any green pad lock on your address bar of the browser just in front of dev.to? Let me tell you what is it and why is it there?

This green lock represents that the site is using HTTPS as its protocol and is relatively more secure than when it is not there.

We need HTTPS for mainly three reasons:

1. Privacy
Lets talk about Privacy first. Lets say we have three people Alice, Bob and Candice. Alice is trying to send messages to Bob and the message is not encrypted meaning plain text. If we don't have HTTPS an evil person like Candice who is jealous of their friendship can listen on the communication and also can capture the messages potentially for doing evil things.

Privacy means that no one can eavesdrop on your messages. The green padlock on the URL bar of our browser tells us that there is no one watching over our shoulder.

2. Integrity
Second comes Integrity. Lets suppose when Alice sends another message to Bob unencrypted saying some nice words, but before it reaches Bob Candice intercepts the message and updates it with bad words about Bob and forwards to him, ruining their friendship. This is called man-in-the-middle attack.

Integrity means that the message is not manipulated on the way to its destination.

3. Identification
Lets take the same example from above. Identification means that Bob can check that this message is indeed coming from Alice. A digital signature attached to a message can identify the sender. And when you are browsing the web, identification means that the site that you are visiting is indeed the one you think it is.
HTTPS, via SSL certificates, ensures you are connected exactly with the receiver you would expect. This SSL certificate is valid and has been issued by a legitimate Certificate Authority. You are good to go.

Now that we know the why, the next step is to understand symmetric and asymmetric encryption.

Github pages for your simple web projects

Akash Kumar Sikarwar — Mon, 05 Jul 2021 20:35:48 +0000

Before you buy a domain or subscribe to a hosting service, you should probably think about if you even need them. Why?, you ask. Then probably you should not skip this post.

Too many steps
What stops most of the people to start their first web project is the hesitation to go through all the steps starting from selecting a hosting service from various choices available, selecting the plan and then go through all the actual hosting steps, which generally never happens smoothly.

Costly
Then comes the money part which is the second most popular hurdle to have your own website. Buying a domain name, could sometimes be expensive especially for students who need to save money more than anybody. Also, most of the hosting services charge some amount to customers to keep running their business.

Security and reliability
For simple projects like personal website, this is important but many would agree that it is essential for business. We are always hearing news about data breaches on hosting services even on some popular services like hostinger etc.

For all the above problems, there is one useful feature of Github yet unknown to many.

Github Pages allows you to host your simple web project/website directly from your Github repository. It means you can make your website live for the world to see without bearing the hosting pain!

Note: Github Pages works only for static websites.

By definition: A static website contains Web pages with fixed content. Each page is coded in HTML and displays the same information to every visitor. These are the most basic type of website and are the easiest to create. Unlike dynamic websites, they do not require any Web programming or database design. A static site can be built by simply creating a few HTML pages and publishing them to a Web server.

The major examples of static websites are as follows:

Documentation
Developing Cache
Website presentation
Communication cache-scrapping buffer
Forms
Newsletter Contents
Disaster page
Recovery from disaster status
Landing page/scales
Blogs

If you are wondering what could be achieved with a static website, go through below link, you will be amazed(found this while surfing web randomly).
https://www.covid19india.org/
Github repo: https://github.com/covid19india/covid19india-react

Although, there are a lot of similar/better alternatives to github pages like Netlify, but probably you may never need it.

For more information on github pages: https://pages.github.com/

Although there are a lot of articles already on github actions, I will also be posting an article on how to use it.