DEV Community: Jean-Paul Rustom

OAuth 2.0 Explained In Simple Terms (With Visuals)

Jean-Paul Rustom — Fri, 15 Mar 2024 22:08:58 +0000

1- Introduction

In the early stages of human civilization, users would provide their username and password into a web application, and they would get access to anything they wanted.

Today, in our web apps, we have ways to let our users access information in other applications, without sharing credentials.

OAuth 2.0 is like finding a secret door in the back of your favorite website, guarded by a bouncer.

Instead of just handing over your username and password like it's no big deal, OAuth 2.0 insists on a exchanging tokens, redirect URLs, and authorization codes.

In this article we’ll break down OAuth 2.0 into digestible explanations.

2- Concepts

Okay so let’s explain core concepts for this OAuth thing, and for that we’ll refer to the spec’s example.

Let’s say we have JayP, a printing service called Print Express, and Google Drive, which stores JayP’s photos.

JayP wants to print all photos contained in his Google Drive account, using Print Express.

Instead of uploading all photos from Google Drive to Print Express, we can have Print Express access the photos from Google Drive, using OAuth, without using Google Drive’s credentials.

Now let’s explain few terminology.

1- Resource owner

JayP is referred to as the resource owner.

It is an entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

2- Resource server

Google Drive here is the resource server.

The resource server hosts the protected resources, and can accept and respond to protected resource requests using access tokens.

The spec also mentions something called an authorization server.

The authorization server issues access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

The resource server and the authorization server can be the same.

For the sake of this article, we’ll have the authorization server and the resource server be the same, and not separate entities.

3- Client

Print Express is the client.

A client is an application making protected resources requests on behalf of the resource owner and with its authorization.

3- Flows

In this article, we will cover two out of four flows described in the spec.

1- Authorization Code flow

The authorization code flow is arguably the most generic flow which is primarily used in applications where a client secret can be securely stored on a server.

1- The client FE redirects the user to an authorization endpoint from the resource server, where the user can authenticate and provide consent for the client to access their resources.

2- Upon successful authentication and consent, the authorization server responds with a short-lived authorization code.

3- The client, typically the server-side part, exchanges the authorization code for an access token by making a request to a token endpoint provided by the authorization server. This request includes the authorization code, client ID, and client secret.

4- The authorization server validates the authorization code and client credentials.

If successful it responds with an access token, and optionally a refresh token.

The refresh token can be used to request new access tokens from the token endpoint, in case the last access token is expired, without requiring the end user to sign in again.

5- With the obtained access token, the server-side component of the client can make authorized requests to access protected resources from the resource server by providing the access token in the request headers.

In this flow, the front end part of the client, such as a web browser or a mobile app’s UI, may not see the access token, or if there’s a need for the front end to store it, it may receive it as encrypted from the server-side component.

2- Implicit Flow

The implicit flow is aimed for client applications that do not have a server side part, for example a single page javascript application, or a mobile app.

1- The client FE redirects the user to an authorization endpoint from the resource server, where the user can authenticate and provide consent for the client to access their resources.

2- Upon successful authentication and consent, the resource server directly sends back the access token to the client, in the URL, and without the intermediate step of exchanging an authorization code for a token

3- With the access token in hand, the client can now request access to protected resources from the resource server.

In this case the access token will have a shorter lifespan than the one issued in the authorization code flow, and refresh token is not returned.

Since the access token is returned directly, as is, to the front end, this flow is considered less secure.

4- Tokens

Now before ending this article, let’s add few thing regarding the tokens.

Commonly, both access tokens and refresh tokens can be JWTs, which means in this case they will be self contained. You can check our separate article explaining JWTs.

Tokens represent specific scopes (photos, email address, name) and durations of access, granted by the resource owner, and enforced by the resource server.

The access token provides an abstraction layer, replacing the username and password with a single token understood by the resource server. For this reason, issuing access tokens is more restrictive than the authorization grant used to obtain them.

That's it folks ! Here are other interesting topics:

WebSockets Explained Under 10 Minutes (With Visuals)

Jean-Paul Rustom — Sat, 09 Mar 2024 21:30:42 +0000

Use-cases

WebSockets are used in systems where we need to display data in real time and with low latency, such as chatting applications, stocks prices fluctuations, or game leaderboards.

History of HTTP 1.0 & HTTP 1.1

Now before moving forward, let’s step back and talk a little bit about history.

HTTP 1.0 ( 1996 )

In HTTP 1.0, each separate request would have its own TCP connection.

We would open a TCP connection, send a request, and as soon as a response is received, we would close that connection.
For example if we would want to load four images, we would open and close four separate TCP connections, which would kill the performance.

HTTP 1.1 ( 1997 )

Now in HTTP 1.1, things have changed.

We have a new header called Connection: ‘Keep-Alive’.

We can initiate a TCP connection, keep it open, and have multiple requests and responses in this single TCP connection.

Because persistent connections were introduced in HTTP 1.1, WebSockets’ minimum HTTP version should be 1.1.

Polling

Historically, creating web apps that needed bidirectional communication, has required an abuse of HTTP to poll the server for updates.

But sending multiple requests is expensive and could cause server overload.

A simpler solution would be to use a single TCP connection for traffic in both directions.

This is what the WebSocket Protocol provides.

Bi-directional Protocol

As previously stated, WebSocket is a stateful bidirectional protocol, built on top of HTTP.

It use a single TCP connection for traffic in both directions.

The connection between client and server will keep alive until it is terminated by client, or by server.

WebSocket uses those default URI schemes, for secure and unsecure connections respectively



wss://jaypmedia.com/socket
ws://jaypmedia.com/socket

WebSocket vs HTTP

Also, WebSocket is not HTTP.
It is, indeed, more complex, and of course more persistent and more lightweight.
It is an independent TCP-based protocol.
Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an HTTP Upgrade Request.

Now don’t get the wrong idea, HTTP is great, but the request response model doesn’t cover bi-directional communication.

Handshake

The WebSocket handshake is the bridge from HTTP to WebSockets.

Client

The WebSocket protocol begins its connection to the server as a simple HTTP request.

In order to start the connection, clients sends an http GET request, that includes at least the following headers:



GET /chat HTTP/1.1

Host: server.jaypmedia.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

If any of these are not included in the HTTP headers, the server should respond with an HTTP error code 400 Bad Request.

The Connection: Upgrade header was introduced in HTTP/1.1 to allow the client to notify the server of alternate means of communication.
The Sec-WebSocket-Key header is used during the WebSocket handshake to ensure that the client and server are speaking the WebSocket protocol.
It is a base64 encoded value that is generated by randomly selecting 16-byte value as a nonce.
The Sec-WebSocket-Version header indicates the version of the WebSocket protocol that the client supports.
If the client is a web browser, it will supply the Origin header.
If the server does not wish to accept connections from this origin, it can choose to reject the connection.
Server will only accept connections from listed origins.

If you are using a browser that supports WebSocket, the whole handshake and the generation of the relevant headers will be handled automatically by using the JavaScript API.

Server

The handshake from the server looks like this:



        HTTP/1.1 101 Switching Protocols

        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

According to the WebSocket spec, the only indication that a connection to the WebSocket server has been accepted is the header field Sec-WebSocket-Accept.
To get its value, the server would concatenate the value of Sec-WebSocket-Key received from the client, with a predefined global unique identifier, defined by the RFC.
Then, the string formed will be hashed, then base64 encoded.

This magic string exists because it will very likely not be used by servers that do not understand WebSockets.

The server responds with a 101 status code.

Any code other than 101 results in an error and means that WebSocket handshake was not completed.

Once the client and server have both sent their handshakes, and if the handshake was successful, then the data transfer part starts.

WebSocket Frames

Now let’s get a little bit deeper, shall we ?

After a successful handshake, clients and servers transfer data back and forth using, at the bit level, a sequence of frames.

There are control frames and data frames.

Control frames communicate state about the WebSocket, for example the close frame which is used for closing connections.

Data frames on the other hand, as their name implies, carry regular application data.

Contrary to control frames, they can be fragmented.

For security reasons and other concerns explained by the RFC, it is required that a client MUST mask all frames that it sends to the server, whether or not TLS is used.

Those concerns are related to proxies in the middle that do not understand WebSockets.

RFC also requires that a server must close a connection if it receives a frame not masked.

On the other hand, a server must not mask frames it sends to the client.

A client will close a connection if it receives a masked frame.

WebSocket Frame Structure

Now let’s zoom a little bit into our frame.

This is how the frame bits structure looks like.

To know the details about what each field means, you can check WebSocket’s spec.

We will go through some fields.

1- FIN (1 bit) — Indicates if this is the final fragment in a message or not.

2- Opcode: (4 bits) Defines the interpretation of the payload data.

0: Continuation frame ( 0 for all frames except the first one )
1: Text Frame
2: Binary Frame
8: Connection Close

3- Mask (1 bit): If set to 1, masking-key is present. Should be one if sending from client.

4- Masking key: ( 0 or 32 bits) The masking key field is present if MASK bit is set to , which means if sent from client.

The masking key is a random key of 4 bytes chosen by the client.

To decode the frame, we XOR its content with the masking key, 4 bytes at a time.

Frame Header size

A WebSocket frame header can be at max 16 Bytes, which is way smaller than a big HTTP header which can reach the size of 16 KiloBytes.

Conclusion

And that’s it ! We’re done with this quick explanation of WebSockets.

Of course, you can try writing your own WebSocket server, or, you know, use already existing libraries that handles all this complexity.

JWT explained in 4 minutes (With Visuals)

Jean-Paul Rustom — Sat, 24 Feb 2024 15:51:40 +0000

Introduction

JWT authentication and session authentication are ways to authenticate users of your web app.
In this article we will explain the details of JWT, its structure along with its pros and cons.
JWT stands for JSON Web Token, and it is a commonly used stateless user authentication standard used to securely transmit information between client and server in a JSON format.
A JWT is encoded and not encrypted by default.
It is digitally signed using a secret key known only to the server.
It can be encrypted, but for this article we will focus on signed non-encrypted tokens.

Structure of JWT

A JSON Web Token consists of 3 parts separated by a period.
The header, the payload, and the signature.
Each section is base64 encoded.

Header

The header consists of token type, which is JWT, and the signing algorithm used, such as HMAC SHA256 or RSA.



{ 
  "typ": "JWT",    
  "alg": "HS256"
}

Payload

The payload consists of the claims.
Claims are statements about the user, and additional data.
For example, we have the time the token was issued at.
We also have its expiration time, because tokens should expire.



{
"iss": "example_issuer",
"sub": "user_id123",
"exp": 1644768000,
"iat": 1644744000
}

Signature

The signature is most important part of a JWT.
It is calculated using the header, the payload, and the secret, which are fed to the signing algorithm to use.



signature = HMAC-SHA256(base64urlEncode(header) + "." + base64urlEncode(payload), secret_salt )

Steps

The steps involved in a typical JWT authorization flow are as follows:

1- Authentication: The user signs in using username and password, or using for example Google or Facebook.
The server verifies the provided credentials.

2- Token Generation & sending token to client: The server will generate the JWT and send it to the client, which stores it for future use.

3-Sending the Token to server: When the client wants to access a protected resource on the server, it sends the JWT in the Authorization header of the HTTP request.



axios.get(URL, {
    headers: {
        'Authorization': 'Bearer ' + token,
    },
})

4-Verifying the Token: The server receives the request and verifies the JWT by checking its signature using the secret key that was used to sign it.
If the JWT is valid, the server extracts the information contained in it and uses it to determine what actions the user is authorized to perform.

5- Authorizing the Request: If the user is authorized to access the resource, the server returns the requested data. If the user is not authorized, the server returns an error message.

Advantages

Lightweight
Portable: can be processed on multiple platforms, web and mobile.
JSON parsers are common in most programming languages.
Protected against tampering because of the secret key stored on server side.
The server does not need to store any session information, because of the stateless nature of the JWT token.

Disadvantages

On server side, should manually mark non-expired JWT as invalid on logout. A JWT can still be valid even after it has been deleted from the client.

A method used is token blacklisting, which involves maintaining a list of invalidated tokens on the server side, preventing their reuse for authentication.

For signed non encrypted tokens, we should not store sensitive info because JWT is protected against tampering but can be decoded and read by anyone.
Can provide full access if intercepted. That’s why JWTs on client side should be stored somewhere secure, for example in the browser in an HttpOnly cookie.

My other articles:

What happens when you click a URL - DNS Lookup, TCP Handshake & HTTP (With visuals)

Jean-Paul Rustom — Fri, 16 Feb 2024 19:33:04 +0000

What happens when you type in a url

Okay so what happens when JayP clicks on a url ?

How would the internet take him to his desired website ?

Servers

Before that, what exactly are websites ?

Websites are collections of files, and images, that tell your browser how to display the site.

A special powerful computer connected to the Internet, called a server, stores these files.

Hosting these files on a server makes it reliable, and accessible to anyone anytime.

URL Structure

The URL is an address that shows where a particular page can be found.

The first part corresponds to the protocol used.

A protocol is a set of rules that browser use for communication over the network.

'https' is the secure version of the http protocol.

The second part www.jaypland.com is a domain name.

We use it to reach to the server that is responsible for serving the information for that website.

IP

In order for the web page to be retrieved, the URL needs to be translated into an IP address.

Clients interact through IP addresses which are unique identifiers.

The IP tells to which server to connect.

Actually, every device connected to the internet has a unique IP address.

JayP could use the IP address instead of the URL to get content from a website.

But, think of it for a second, it would be impossible to remember the IP addresses of every website!

That's why domain names were invented.

Now to understand how domain names are converted to IP addresses we need to talk about DNS.

DNS

DNS stands for Domain Name System and it is a huge database where domain names are stored with their corresponding IP addresses

You could think of it as the phone book of the internet.

Now how DNS works is a topic on its own and deserves its separate video, but here is the gist of it.

When JayP clicks on a link, the browser checks its own cache, if the IP is not found then it will check the operating system cache.

If the browser still cannot find the IP address, it will send a DNS query to the DNS resolver specified in the operating system's network settings, which is by default the ISP’s DNS resolver.

The resolver will check its own cache.

If the IP is still not found at any of those cache layers, the resolver will do a recursive DNS lookup.

A recursive DNS lookup asks multiple DNS servers for the DNS record until it is found.

The authoritative name server is responsible for knowing everything about the domain name.

Finally, the resolver gets the IP address associated with the domain name and sends it back to the browser.

Connection with server using TCP

Now once the IP address of the server is found, the browser initiates a connection with it using what is called a ‘TCP 3-way handshake’.

If you want to know more about it, we have a separate video explaining the handshake in details, in our youtube channel.

HTTP

Once the connection is initiated, the browser will send an HTTP Get request to the server to get the webpage.

GET/ jaypland.com



<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>JayPLand</title>
    <link rel="stylesheet" href="styles.css">
</head>

<body style="background-color: #00008B;">
    <h1>JayPLand</h1>
    <span>Where every click is an adventure</span>
    <img src="https://cdn.jaypland.com/jayp.png" alt="JayP Logo">
    <script src="script.js"></script>
</body>

</html>

Then, the rendering engine of the browser starts interpreting and displaying the content.

If the page has images or videos, the browser will see this and request that they are brought to the web page as well.

And ta daaa...just like that the web page has loaded!

Cipher Suites & AEAD - ChaCha20-Poly1305 Example

Jean-Paul Rustom — Sun, 03 Sep 2023 07:58:49 +0000

For the Animated Interactive Version:

What is a Cipher Suite

Cipher suites in TLS 1.3 are combination of algorithms used for encryption and integrity.

TLS 1.3 has only five possible cipher suites, because it removed all unsecure cipher suites from TLS 1.2.

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_AES_128_CCM_8_SHA256
TLS_CHACHA20_POLY1305_SHA256

In TLS 1.2, separate algorithms were used for encryption and integrity of the messages.

However, in TLS 1.3, all cipher suites use AEAD algorithms.

AEAD stands for Authenticated Encryption with Associated Data.

AEAD algorithms provide both encryption and authentication in a single step, making the process a lot simpler.

For example the cipher suite TLS_CHACHA20_POLY1305_SHA256 uses ChaCha20-Poly1305, as an AEAD cipher, and SHA-256 as a hash function for the Key Derivation Function. (Reminder: Key Derivation Function is used in TLS handshake to derive many keys)

Key Features About CHACHA20

It’s a symmetric key encryption algorithm
Developed by Google
Simple design and implementation, making it faster than AES
Known for its security and high speed.
Generates a stream of pseudo-random bits called the key-stream. This key-stream is then XORed with the plaintext to produce the cipher-text.
Widely Supported

Encryption & Integrity with ChaCha20

Okay, now the fun part.

Let’s visualize how the elegant design of ChaCha20 integrates with Poly1305.

First step is encrypt with CHACHA20.

At a high level, ChaCha20 will take as inputs a shared secret key, a nonce, and a counter.

Think of the nonce and counter as params used to increase the unpredictability and randomness of the cipher text.

The "20" in "ChaCha20" refers to the number of rounds the algorithm goes through to process the data. These rounds involve various operations such as bit manipulations, addition, rotation, and XOR operations.

These exists reduced round versions of ChaCha20 called ChaCha12 and ChaCha8.

Based on these inputs, the ChaCha20 algorithm generates a pseudorandom stream of bits called the key-stream.

Then, this key-stream is XORed with JayP’s plaintext message to produce the cipher text, in other words, the encrypted message.

After that, the encrypted message, and unencrypted associated data such as addresses, ports, timestamps, together with the nonce and the secret key are inputs of POLY1305.

The MAC (Message Authentication Code) algorithm POLY1305 will output a MAC.

The MAC, also referred to as the authentication tag, will be sent along with the encrypted message.

Verification with ChaCha20

Youtube, to decrypt and verify the message, would perform the reverse of the steps explained earlier.

Verification:
- Youtube calculates the authentication tag from the received cipher text, the shared secret key, the associated data, and the nonce.
- The calculated authentication tag is compared to the received authentication tag.
- If they match, Youtube knows that the received message has not been altered.

Decryption:
- The ChaCha20 stream cipher is used with all necessary params to generate the same pseudo random stream, which is XORed with the received cipher text to produce the plaintext.

Also Published here:
Medium

Diffie-Hellman & its Simple Maths Explained in 5 Minutes 🙆🏻‍♂️

Jean-Paul Rustom — Fri, 18 Aug 2023 14:36:55 +0000

Watch the animated version here 👇🏻

What is the discrete logarithm problem ?

In order to understand the Diffie-Hellman algorithm, one must understand the discrete logarithm problem in Maths.

The logarithmic function follows the concept of a trapdoor function. A trapdoor function is easy to compute in one direction, yet difficult to compute in the opposite direction.

Let’s visualize it this way:

Given 2 teaspoons of coffee, 1 teaspoon of sugar and half cup of milk, you can make coffee.

Now given the same coffee, can you guess the exact amounts of coffee, sugar, and milk?

Modulo operation is an operation where the result is the remainder of the division operation performed with two given integers as operands.

We say 13 mod 5 ≡ 3 because 13 = 5 x 2 + 3

What if we want to find x such that 5^x mod 13 ≡ 11 ?

Let’s try many values for x and check after how many tries we find the answer.

After 8 tries, we will find that for x = 8 we will get 5 to the power x mod 13 is 11

Now here is where it gets interesting.

Let’s say we have x ≡ g^y mod p .

But now we have p is a very large prime number (instead of 13) and g and x are also very large numbers (instead of 5 and 11).

And by large, we mean, really large. Imagine for example p being equivalent to 2048 bits

p=292463028894281219037597349727360684779483317376473239399537257843546320734871513839651347201104480199877191389522614785890996622493775440722572336903336882065975199234931879695261910015161305537526235180562475469982005301778126151856278585195545100903316048416565416635315530213841740854981894053524430751990450476315137696784232893772161407889014577329968174019042697407332291644176957214843165640734510101308586892775505187939228207220238747243895829499434176678189216930154964392995431879145409980273938229601680574417474486982384981120906945098803000392061156847661464691587852166635245652933518718150794527

Can you find y given these circumstances?

This is the gist of the discrete logarithm problem, and even with the current generation computers it would take a very long time to solve.

One of the reasons prime numbers are used is to avoid repeating patterns.

For example, let's take p = 12, a non prime number

21 mod 12 = 2
22 mod 12 = 4
23 mod 12 = 8
24 mod 12 = 4 (repeating)
25 mod 12 = 10
26 mod 12 = 2 (repeating)
27 mod 12 = 4 (repeating)
28 mod 12 = 8 (repeating)

For example for p=11, prime number:

21 mod 11 = 2
22 mod 11 = 4
23 mod 11 = 8
24 mod 11 = 5
25 mod 11 = 10
26 mod 11 = 9
27 mod 11 = 7
28 mod 11 = 3
29 mod 11 = 6
210mod 11 = 1

The discrete logarithm problem is the base of the Diffie-Hellman exchange algorithm.

Diffie-Hellman

Diffie-Hellman key exchange can be used to securely exchange a secret key over an insecure network. It works using the concepts of prime numbers and modulo operations.

First, JayP and Joe both agree on two numbers: g, and p, a large prime number. Those will be shared over the public internet.

Then, each of JayP and Joe will generate a random private key which will not be shared over the internet.

After that JayP computes his public key using the formula in the screenshot below, and sends it to Joe.
Similarly, Joe also computes his public key the same way and sends it to JayP.

To recap, until now, both parties have shared over the public internet the params g and p, and their respective public keys. The private keys were not shared. Now let’s see how the shared secret will be derived from these params.

JayP computes the shared secret on his side using the equation shown in the screenshot below.

Joe also computes the shared secret on his side using the same equation.

The secret key they have each calculated independently will be the same.

Why? Well, due to simple maths. Let’s apply substitution of the public keys in each side.

This explains how both JayP and Joe contribute to generating a shared secret value without actually transmitting it.

Given p, g, and y, it is very easy to compute S.

But over the public internet, Chady can only see p and g, and it will be very hard for him to compute y. Computing y is the discrete logarithm problem we just talked about earlier.

In the TLS handshake, the shared secret will be fed into what’s called a key derivation function.

The KDF takes as input the shared secret, and other params such as a salt and some additional app-specific info.

With all these inputs, the KDF will produce many keys, for example the MAC key, and the symmetric key used for data encryption.

Shameless Self Promotion 😨

I'm kickstarting my new YouTube channel, JayPMedia, where I'll be sharing all things web development. If you're keen to learn and grow with me, hit that subscribe button and let's dive into the world of coding and learning 😉

Also published here:

https://medium.com/@jaypmedia/diffie-hellman-its-simple-maths-explained-in-5-minutes-f9061f04557c

HMAC & Message Authentication Codes - Why hashing alone is NOT ENOUGH for Data Integrity 😼

Jean-Paul Rustom — Fri, 11 Aug 2023 21:03:59 +0000

For the animated version 👇🏻

Introduction

Data integrity refers to the validation that data has not been modified or corrupted during transmission. It is an important topic to grasp before explaining TLS. Let’s illustrate it now.

Suppose JayP and Joe are communicating over the public internet. Also, suppose both of them have a symmetric key and they have decided on the symmetric encryption algorithm to use.

Here JayP sends his encrypted message. Encryption means confidentiality, and that no one can understand the message because it is encrypted.

However, that does not mean that a malicious Chady cannot interfere with the message and change it, even though he does not understand it.

Bit-Flipping Attack 😨

For example there is an attack known as bit flipping attack.

Let’s have a bank transaction example to show how damaging this attack can be.

Let’s say JayP is sending 100$ to Joe.

Chady intercepts the message and although he does not understand a thing, he flips some bits and transfers the message to the bank.

When the bank decrypts the message, it may show as 1000$ instead of 100$.

That’s why, in addition to encryption, we need to make sure the data has not been altered.

The problem with hashing 🤔

Back to our previous example.

How can Joe make sure that the message has not been modified ? 🤦🏻‍♂️

The standard approach would be hashing.

Let’s recall how hashing is typically used for data integrity.

Generating a Hash Value:
- JayP will apply a hash function to the data he intends to send, and will generate a fixed size hash value, often referred to as the “digest” or “checksum”, then he will send the data with its hash over the internet. If a single bit of the message is changed then it would output a different hash.
Verification Process:
- When Joe receives JayP’s message, he will apply the same hash function to the message. Then, he compares the computed hash with the received hash. If both match, it indicates that the data has not been altered by a malicious Chady.

However, think for a second. Do you think this is enough?

What do you think a malicious Chady would do to alter the data and still pass the integrity check?

After all, hackers are smarter than that.
Why not, alter the message and also send an altered hash ? How then can Joe know that the hash and the data have been modified ?

HMAC to the rescue 🦸🏻‍♂️

Here comes the role of HMAC.

HMAC stands for Hash Based Message Authentication Code. It is a cryptographic authentication technique that uses a hash function and a secret key.

HMAC = hashFunc(secret key + message)

For HMAC to work, both JayP and Joe should agree on a shared secret and a hash function.

In the TLS handshake article you will understand how the hash function is decided and how the secret key is generated through key exchange protocol.

HMAC Demo

Let’s see the difference now.

Now the hash function is applied with both the encrypted text and the secret.

After that the generated MAC or message authentication code will be sent along the encrypted text.

Let’s say Chady intercepts and changes the message along with its MAC.

Remember that Chady does not have the secret key and will hash the encrypted message without any additional information.

Joe, after receiving the message, will apply the HMAC function with the message and the secret key.

The Message authentication codes will not match and Joe will know that the message has been tampered.

HMAC is one of many MACs algorithms

So, let’s explain some of the details about MACs and HMAC, because I want you to be familiar with all the terms and to not be confused.

HMAC is an algorithm that generates a Message Authentication Code.

As explained, the message authentication code provides authenticity in addition of integrity, because it uses a secret key, and that’s how it mainly differs with a regular hash.

There exists many algorithms for calculating a message authentication code, and HMAC is just one of them.

Other examples include for example POLY1305.

Message Authentication codes are also used in authenticated encryption, which we will talk about in a separate article.

HMAC advantages in TLS 👍🏻

HMAC is used in the TLS handshake, particularly in the “Finished” messages, where a MAC of the entire handshake up to that point is sent.

HMAC is suitable for TLS for its many advantages:

Flexibility: HMAC can work with a variety of hash functions such as SHA-256 or SHA-3
Standardization: HMAC is widely recognized and standardized, it has its own RFC (RFC2104) published in February 1997. This makes HMAC easier to implement in different environments. It can also be used for example in VPN and IPsec, web application APIs, and payment systems.
Security: HMAC is also considered very secure against common hash functions vulnerabilities, due to the additional complexity introduced by the secret key.

HMAC Security

HMAC's security has been extensively analyzed in the cryptographic community. The HMAC construction has been proven to offer security properties such as pseudorandomness, which means the output of HMAC resembles a random sequence, and unpredictability, which ensures that the output is difficult to predict even if the input is known.

This additional randomness is achieved by the use of fixed strings defined in the HMAC algorithm, called ipad and opad, which are used to modify the key, and a series of steps including XOR operations, data appending, and applying the hash function to achieve the final MAC.

The RFC particularly highlights the resistance against birthday attacks, which is an attack aiming at finding two messages leading to the same hash.

Why does HMAC internally modify the key

Okay so why exactly does HMAC internally modify the key ?

Well, In cryptography, a keys needs to be random so that attackers can’t detect any patterns, because patterns make it easier for hackers to figure out the key.

That’s why the ipad and opad values are critical components in the HMAC computation process, ensuring that the shared secret key is mixed and processed in a specific manner, enhancing the randomness of the key, and strengthening the security of the message authentication process.

So that’s it ! I hope you are enjoying this mini-series about TLS. Don't forget to also check the animated version 😉

Also published here:
https://medium.com/@jaypmedia/hmac-message-authentication-codes-why-hashing-alone-is-not-enough-for-data-integrity-96f636aa0c11

TCP / IP Stack - Oversimplified for Web Developers 🌍🧑🏻‍💻

Jean-Paul Rustom — Thu, 10 Aug 2023 09:11:48 +0000

Here is the animated version for those of you who prefer interactive videos:

Introduction

The TCP / IP model is a conceptual model of how communications are made over the internet, and is consists of 4 layers.

1. The Application Layer

The application layer is the layer that interacts directly with the end user, providing the services and applications that allows user to access and use the network resources.

They are software applications you use on your computer, such as web browsers, email clients and messaging apps.

These use protocols such as:

HTTPS
DNS
SMTP
FTP
SSH

2. The Transport Layer

The transport layer provides data transport services to and from the application layer. It offers two main options for data transportation: reliable and efficient or unreliable and fast.

This layer uses protocols like TCP to provide reliable communication between two devices, and UDP to provide fast but unreliable transmission. (More on these in my other articles)

The transport layer takes the application data (for eg an HTTP POST request) from the application layer and packages it into segments, which are then sent over the internet using port numbers.

3. The Network Layer

This layer is responsible for routing the data across multiple networks and it uses protocols such as the IP protocol.

It takes the data from the transport layer and packages it into packets, which are then sent over the Internet using IP addresses.

Think of it like a postal service that can deliver letters across the globe.

It needs to know the destination and the best route to get there. The Internet layer uses IP addresses to identify different networks and determines the best path for data to travel across them.

The network layer is considered an unreliable protocol as it does not guarantee the delivery of packets or their order. The reliability of communication is achieved by higher protocols such as TCP which use IP as their underlying transport mechanism.

4. The Link Layer

The link layer is responsible for taking the raw bits of data from the physical layer, and organizing them into frames, then moving data between devices that are physically connected.

Think of it like a postman that is delivering letters within the same neighborhood. The postman needs to know the addresses of the sender and the recipient, and also needs to make sure that the letters are properly packaged and labeled.

In the same way, the data link layer uses frames to package data and add information such as source and destination MAC addresses to ensure it gets delivered to the correct device.

TLS Certificates 📝 - Simplified for web developers

Jean-Paul Rustom — Tue, 08 Aug 2023 07:56:21 +0000

Please have a time to check the animated version ;)

Introduction

Let's say JayP wants to connect to youtube.com over the public internet. Before any communication occurs, some concerns will arise:
How can he verify that he is indeed communicating with youtube ? (Authentication)
How can JayP know that no one has intercepted his message ? (Confidentiality)
Also, how can he be sure that no one altered the message? (Integrity)

Well, let's tackle each problem separately.
First of all, JayP should verify the identity of Youtube. For that, he needs Youtube's public key. The public key represents youtube's identity.

The Problem

The problem is, attackers have come up with ways to intercept a request from one computer to another computer on the Internet and launch a man in the middle attack. With this kind of attack, our attacker Chady would inject his own public key and have JayP think he is communication with Youtube, while actually he is communicating with Chady.

Now you may think, scary, isn't it? Imagine what could be possible with this kind of attack, from stealing personal information such as login credentials or credit card details, to malware distribution or other malicious goals.
How then, can JayP be sure that the public key he received comes really from Youtube?
That's where digital certificates come in. (TADAAA)

They ensure that the public key is indeed coming from Youtube, and not from a malicious Chady. Actually, digital certificates can be used not only for HTTPS, but also for mails, IOT, and VPN…

Information Inside TLS Certificate

A digital certificate will contain many information, let's explore the most important ones.

Issuer is the third party which signed this certificate, we'll get into it in a bit. Some basic information will include the Common Name, the organization and the country.
Of course, a digital certificate will also include its Validity, with two critical fields, not before and not after
The Subject is the owner of the certificate and would be Youtube in our case. The subject will contain information such as common name, address, and most importantly, the public key.
Lastly, a digital certificate include its Signature. This is the signature signed by the issuer that proves that this certificate is authentic.

Who signs the digital certificate ?

Digital certificates are signed by entities called certificate authorities (for example DigiCert, Comodo, Symantec, Google Trust Services).
But wait, what are certificate authorities?
Well, in a nutshell, Certificate Authorities are trusted third-party organizations responsible for issuing digital certificates.

Certificate authorities have their own public and private keys. From that, let's explain how signatures are made.
The previously mentioned information contained in a digital certificate will be hashed using for eg SHA-256 algorithm.
After the hash is generated, the certificate authority encrypts the hash using its private key using RSA asymmetric key encryption. This encrypted hash is the signature of a certificate, and can only be decrypted using the certificate authority's public key. Anyone with the public key of the certificate authority which has signed this certificate can decrypt and verify that the certificate is authentic and has not been tampered.

When the browser receives the certificate, it will hash all the information on its side using the same hash algorithm, in this example, SHA-256. Then, it decrypts the signature using the certificate authority's public key to have the hash received from the certificate authority.
If both hashes match, then the browser can confirm that this certificate is truly coming from the claimed certificate authority.

Hierarchies for Certificate Authorities

There exists hierarchies for certificate authorities, the root certificate authority and the intermediate certificate authority.

These root CA does not actually directly issue any digital certificates for servers. It only issues digital certificates for intermediate CAs that act on its behalf. The intermediate CAs can either issue digital certificates for another intermediate CA, or for a server directly.

Hence, There is a chain of trust, from the root CA to the server.
Operating systems come bundled with a trust store, which is a list of trusted root certificate authorities. This list is maintained by the companies that make operating systems such as Apple and Microsoft. They all require a root certificate authority to undergo one or more audits proving their trustworthiness and validity.

How does all of this fit into the picture ? Let's visualize the whole process from the start.

First of all, let's assume youtube.com is a brand new startup. Understanding the need to be secure on a publicly available internet, Youtube would have to own a trusted digital certificate, and present it to its visitors.

Step 1: Youtube goes shopping for a digital certificate

First of all, Youtube goes searching for an intermediate certificate authority. Remember that intermediate certificate authorities are middlemen between servers and root certificate authorities. In the case of Youtube, Google has its own certificate authority called Google Trust Services.

After picking an intermediate CA, Youtube makes a certificate signing request. The certificate signing request will contain information that will be included in Youtube's digital certificate, such as common name, organization, and most importantly the public key of Youtube. Youtube will send the certificate signing request to the intermediate CA.

The intermediate certificate authority will verify the CSR containing information about the owner also referred to as the subject. Then, it adds field like issuer information, which is information about the intermediate certificate, and the validity, then signs all these information as explained previously in the signing process. After signing, the intermediate certificate authority will send back the digital certificate for youtube.

Youtube can now attach its newly bought digital certificate to its web servers.

Step 2: JayP connects to youtube.com to watch fitness videos

When he will connect to Youtube, Youtube will send its own certificate and certificates of intermediate certificate authorities. The root certificate authority will not be sent because it is available on JayP's Operating System.
Youtube's certificate will include the issuer information, which is the intermediate certificate authority. The browser will hence know that this certificate is signed by Google Trust Services Intermediate Certificate Authority, and will have its certificate. Any digital certificate will contain information, and a signature, as explained previously.
The browser will hash all the information to obtain their hash value. Then, it will decrypt the signature using the issuer's public key, in other words, the intermediate certificate authority's public key. Again, remember that the signature can only be decrypted using the issuer's public key. After that the browser will compare the two hash values, if they are the same, then this part of the chain is verified, and the browser will move on verifying the intermediate certificate authority, because as explained, intermediate certificate authorities are not trusted directly by the operating systems.

Okay now the browser will verify the certificate of Google Trust Intermediate Certificate Authority. This intermediate certificate is signed by Google Trust Services Root Certificate authority.
Please note that before this step, we could have many intermediate certificate authorities between the end certificate and the root certificate, and for each part of the chain the same verification process will happen.

In our example, we will just stick to one.
The signature of the certificate of the intermediate certificate authority will be verified with the public key of the root certificate authority, as previously.
When reaching the root certificate authority, that's where the chain ends. The root certificate authority, which is self signed, will be available in JayPee's operating system's trust store.

That's it! The browser, after this verification, will display a nice looking lock icon, like the one in your browser. Now it is guaranteed that the communication is really with Youtube, and that it is safe (HOORAY)

Three types of Domain Certificates

Before we wrap up, we will shortly explain three main types of TLS certificates.

1) Single Domain Certificate

A single domain certificate is designed to secure a single fully qualified domain name. It means that the certificate is valid only for one specific domain and does not cover any subdomains or additional domains. For example, for the domain "www.youtube.com," a single domain certificate would secure only that domain and not any other variations like "academy.youtube.com" or "blog.youtube.com"
Use cases: Single domain certificates are ideal when you have a single website or web application that does not require additional subdomains. They are the most straightforward and cost-effective option for securing a specific domain.

2) Wildcard Certificate

Next we have a wildcard certificate, which is a type of TLS certificate issued for a main domain and all its subdomains using a single certificate. The wildcard character asterix is used in the Common Name (CN) field or Subject Alternative Name (SAN) field to indicate that any subdomain under the specified domain is covered. For example, if you have a wildcard certificate for ".youtube.com," it would secure "youtube.com," "academy.youtube.com," blog.youtube.com", and so on.
Use cases: Wildcard certificates saves you from having to manage and renew individual certificates for each subdomain. However, it's essential to note that wildcard certificates only cover one level of subdomains. For instance, a wildcard certificate for "*.youtube.com" would not cover "academy.blog.youtube.com."

3) Multi-Domain (SAN) Certificate

A multi-domain certificate, also known as a Subject Alternative Name certificate, allows you to secure multiple unrelated domains within a single certificate. Each domain or subdomain to be secured is listed in the Subject Alternative Name (SAN) extension of the certificate.
For example, Google and other large companies would use these multi-domain certificates.
One of the main benefits would be a Simplified Certificate Management: Google operates a lot of web services and applications, each with its own domain or subdomain. Using multi-domain certificates allows them to consolidate the management of certificates for multiple domains or subdomains into a single certificate. This streamlines the process of certificate issuance, renewal, and monitoring.

In my next article I will discuss encryption with TLS

DEV Community: Jean-Paul Rustom

OAuth 2.0 Explained In Simple Terms (With Visuals)

1- Introduction

2- Concepts

1- Resource owner

2- Resource server

3- Client

3- Flows

1- Authorization Code flow

2- Implicit Flow

4- Tokens

That's it folks ! Here are other interesting topics:

WebSockets Explained Under 10 Minutes (With Visuals)

Use-cases

History of HTTP 1.0 & HTTP 1.1

HTTP 1.0 ( 1996 )

HTTP 1.1 ( 1997 )

Polling

Bi-directional Protocol

WebSocket vs HTTP

Handshake

Client

Server

WebSocket Frames

WebSocket Frame Structure

Frame Header size

Conclusion

More topics with visuals:

JWT explained in 4 minutes (With Visuals)

Introduction

Structure of JWT

Header

Payload

Signature

Steps

Advantages

Disadvantages

What happens when you click a URL - DNS Lookup, TCP Handshake & HTTP (With visuals)

What happens when you type in a url

Servers

URL Structure

IP

DNS

Connection with server using TCP

HTTP

Cipher Suites & AEAD - ChaCha20-Poly1305 Example

For the Animated Interactive Version:

What is a Cipher Suite

Key Features About CHACHA20

Encryption & Integrity with ChaCha20

Verification with ChaCha20

Diffie-Hellman & its Simple Maths Explained in 5 Minutes 🙆🏻‍♂️

Watch the animated version here 👇🏻

What is the discrete logarithm problem ?

Diffie-Hellman

Shameless Self Promotion 😨

HMAC & Message Authentication Codes - Why hashing alone is NOT ENOUGH for Data Integrity 😼

For the animated version 👇🏻

Introduction

Bit-Flipping Attack 😨

The problem with hashing 🤔

HMAC to the rescue 🦸🏻‍♂️

HMAC Demo

HMAC is one of many MACs algorithms

HMAC advantages in TLS 👍🏻

HMAC Security

Why does HMAC internally modify the key

TCP / IP Stack - Oversimplified for Web Developers 🌍🧑🏻‍💻

Introduction

1. The Application Layer

2. The Transport Layer

3. The Network Layer

4. The Link Layer

TLS Certificates 📝 - Simplified for web developers

Please have a time to check the animated version ;)

Introduction

The Problem

Information Inside TLS Certificate

Who signs the digital certificate ?

Hierarchies for Certificate Authorities