DEV Community: Pavankumar Hegde

DNS Explained: Navigating the Web's Address Book!

Pavankumar Hegde — Wed, 22 Nov 2023 16:36:45 +0000

Introduction
Understanding DNS
- What is DNS?
- How DNS Works
- DNS Server Types
- Types of DNS Queries
- DNS Lookup Steps
- DNS caching
DNS Record Types
- A record
- AAAA record
- CNAME record
- MX record
- TXT record
- NS record
- SOA record
- SRV record
- PTR record
- CAA record
- DNSKEY record
- CERT record
- DCHID record
- DMARC record
- DKIM record
- SPF record
Advanced DNS Concepts
- DNS Zone
- Anycast DNS
- Recursive DNS
- Primary vs. secondary DNS
- Reverse DNS

Introduction

Welcome to the world of Domain Name System (DNS), a fundamental component of the internet that translates human-friendly domain names into machine-readable IP addresses. In this guide, we'll delve into the intricacies of DNS, exploring its architecture, record types, and common issues.

The Domain Name System (DNS) is a vital component of the internet infrastructure, serving as a decentralized naming system. It plays a crucial role in translating human-friendly domain names into machine-readable IP addresses. DNS operates primarily over UDP (User Datagram Protocol) on port 53 for regular queries and TCP (Transmission Control Protocol) on the same port for more extensive data transfers, such as zone transfers.

Working at the application layer of the Internet Protocol suite, DNS follows a hierarchical structure that includes the root domain, top-level domains (TLDs), second-level domains, and subdomains. The resolution process begins when a user enters a domain name in a web browser, triggering a series of queries to DNS servers. These servers work in a hierarchical manner until the IP address associated with the domain is found.

Understanding DNS

What is DNS?

The Domain Name System (DNS) is the phonebook of the Internet. Humans access information online through domain names, like cisco.com or google.com. Web browsers interact through Internet Protocol (IP) addresses. DNS translates domain names to IP addresses so browsers can load Internet resources.

Each device connected to the Internet has a unique IP address which other machines use to find the device. DNS servers eliminate the need for humans to memorize IP addresses such as 192.168.1.1 (in IPv4), or more complex newer alphanumeric IP addresses such as 2400:cb00:2048:1::c629:d7a2 (in IPv6).

How DNS Works?

The process of DNS resolution involves converting a hostname (such as www.example.com) into a computer-friendly IP address (such as 192.168.1.1).
An IP address is given to each device on the Internet, and that address is necessary to find the appropriate Internet device - like a street address is used to find a particular home.
When a user wants to load a webpage, a translation must occur between what a user types into their web browser (example.com) and the machine-friendly address necessary to locate the example.com webpage.
In order to understand the process behind the DNS resolution, it’s important to learn about the different hardware components a DNS query must pass between.
For the web browser, the DNS lookup occurs "behind the scenes" and requires no interaction from the user’s computer apart from the initial request.

DNS Server Types

DNS recursor : The recursor can be thought of as a librarian who is asked to go find a particular book somewhere in a library. The DNS recursor is a server designed to receive queries from client machines through applications such as web browsers. Typically the recursor is then responsible for making additional requests in order to satisfy the client’s DNS query.

Root nameserver : The root server is the first step in translating (resolving) human readable host names into IP addresses. It can be thought of like an index in a library that points to different racks of books - typically it serves as a reference to other more specific locations.

TLD nameserver : The top level domain server (TLD) can be thought of as a specific rack of books in a library. This nameserver is the next step in the search for a specific IP address, and it hosts the last portion of a hostname (In example.com, the TLD server is “com”).

Authoritative nameserver : This final nameserver can be thought of as a dictionary on a rack of books, in which a specific name can be translated into its definition. The authoritative nameserver is the last stop in the nameserver query. If the authoritative name server has access to the requested record, it will return the IP address for the requested hostname back to the DNS Recursor (the librarian) that made the initial request.

Types of DNS Queries

3 types of DNS queries:

Recursive query - In a recursive query, a DNS client requires that a DNS server (typically a DNS recursive resolver) will respond to the client with either the requested resource record or an error message if the resolver can't find the record.

Iterative query - in this situation the DNS client will allow a DNS server to return the best answer it can. If the queried DNS server does not have a match for the query name, it will return a referral to a DNS server authoritative for a lower level of the domain namespace. The DNS client will then make a query to the referral address. This process continues with additional DNS servers down the query chain until either an error or timeout occurs.

Non-recursive query - typically this will occur when a DNS resolver client queries a DNS server for a record that it has access to either because it's authoritative for the record or the record exists inside of its cache. Typically, a DNS server will cache DNS records to prevent additional bandwidth consumption and load on upstream servers.

DNS Lookup Steps

A user types ‘example.com’ into a web browser and the query travels into the Internet and is received by a DNS recursive resolver.
The resolver then queries a DNS root nameserver (.).
The root server then responds to the resolver with the address of a Top Level Domain (TLD) DNS server (such as .com or .net), which stores the information for its domains. When searching for example.com, our request is pointed toward the .com TLD.
The resolver then makes a request to the .com TLD.
The TLD server then responds with the IP address of the domain’s nameserver, example.com.
Lastly, the recursive resolver sends a query to the domain’s nameserver.
The IP address for example.com is then returned to the resolver from the nameserver.
The DNS resolver then responds to the web browser with the IP address of the domain requested initially.

Once the 8 steps of the DNS lookup have returned the IP address for example.com, the browser is able to make the request for the web page:

The browser makes an HTTP request to the IP address.
The server at that IP returns the webpage to be rendered in the browser.

DNS caching

The purpose of caching is to temporarily stored data in a location that results in improvements in performance and reliability for data requests. DNS caching involves storing data closer to the requesting client so that the DNS query can be resolved earlier and additional queries further down the DNS lookup chain can be avoided, thereby improving load times and reducing bandwidth/CPU consumption. DNS data can be cached in a variety of locations, each of which will store DNS records for a set amount of time determined by a time-to-live (TTL).

Modern web browsers are designed by default to cache DNS records for a set amount of time. The purpose here is obvious; the closer the DNS caching occurs to the web browser, the fewer processing steps must be taken in order to check the cache and make the correct requests to an IP address. When a request is made for a DNS record, the browser cache is the first location checked for the requested record.

In Chrome, you can see the status of your DNS cache by going to chrome://net-internals/#dns.

DNS Record Types

Some most important types of DNS record

1. A record: The "A" stands for "address" and this is the most fundamental type of DNS record: it indicates the IP address of a given domain.

2. AAAA record: DNS AAAA records match a domain name to an IPv6 address. DNS AAAA records are exactly like DNS A records, except that they store a domain's IPv6 address instead of its IPv4 address.

3. CNAME record: A "canonical name" (CNAME) record points from an alias domain to a "canonical" domain. A CNAME record is used in lieu of an A record, when a domain or subdomain is an alias of another domain. All CNAME records must point to a domain, never to an IP address. Imagine a scavenger hunt where each clue points to another clue, and the final clue points to the treasure. A domain with a CNAME record is like a clue that can point you to another clue (another domain with a CNAME record) or to the treasure (a domain with an A record).

4. MX record: A DNS 'mail exchange' (MX) record directs email to a mail server. The MX record indicates how email messages should be routed in accordance with the Simple Mail Transfer Protocol (SMTP, the standard protocol for all email). Like CNAME records, an MX record must always point to another domain.

5. TXT record: The DNS ‘text’ (TXT) record lets a domain administrator enter text into the Domain Name System (DNS). The TXT record was originally intended as a place for human-readable notes. However, now it is also possible to put some machine-readable data into TXT records. One domain can have many TXT records.

6. NS record: NS stands for ‘nameserver,’ and the nameserver record indicates which DNS server is authoritative for that domain (i.e. which server contains the actual DNS records). Basically, NS records tell the Internet where to go to find out a domain's IP address. A domain often has multiple NS records which can indicate primary and secondary nameservers for that domain. Without properly configured NS records, users will be unable to load a website or application.

7. SOA record: The DNS ‘start of authority’ (SOA) record stores important information about a domain or zone such as the email address of the administrator, when the domain was last updated, and how long the server should wait between refreshes.

8. SRV record: The DNS "service" (SRV) record specifies a host and port for specific services such as voice over IP (VoIP), instant messaging, and so on. Most other DNS records only specify a server or an IP address, but SRV records include a port at that IP address as well. Some Internet protocols require the use of SRV records in order to function.

9. PTR record: The Domain Name System, or DNS, correlates domain names with IP addresses. A DNS pointer record (PTR for short) provides the domain name associated with an IP address. A DNS PTR record is exactly the opposite of the 'A' record, which provides the IP address associated with a domain name.

DNS PTR records are used in reverse DNS lookups. When a user attempts to reach a domain name in their browser, a DNS lookup occurs, matching the domain name to the IP address. A reverse DNS lookup is the opposite of this process: it is a query that starts with the IP address and looks up the domain name.

10. CAA record: This is the ‘certification authority authorization’ record, it allows domain owners state which certificate authorities can issue certificates for that domain. If no CAA record exists, then anyone can issue a certificate for the domain. These records are also inherited by subdomains.

11. DNSKEY record: The ‘DNS Key Record’ contains a public key used to verify Domain Name System Security Extension (DNSSEC) signatures.

12. CERT record: The ‘certificate record’ stores public key certificates.

13. DCHID record: The ‘DHCP Identifier’ stores info for the Dynamic Host Configuration Protocol (DHCP), a standardized network protocol used on IP networks.

14. DMARC record: Domain-based Message Authentication Reporting and Conformance (DMARC) is a method of authenticating email messages. A DMARC policy tells a receiving email server what to do after checking a domain's Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records, which are additional email authentication methods.

DMARC and other email authentication methods are necessary in order to prevent email spoofing. Every email address has a domain, which is the portion of the address that comes after the "@" symbol. Malicious parties and spammers sometimes try to send emails from a domain that they are not authorized to use — like someone writing the wrong return address on a letter. They may do this to try to trick users (as in a phishing attack), among other reasons.

15. DKIM record: DomainKeys Identified Mail (DKIM) is a method of email authentication that helps prevent spammers and other malicious parties from impersonating a legitimate domain.

All email addresses have a domain — the part of the address after the "@" symbol. Spammers and attackers may try to impersonate a domain when sending emails to carry out phishing attacks or other scams.

16. SPF record: A sender policy framework (SPF) record is a type of DNS TXT record that lists all the servers authorized to send emails from a particular domain. A DNS TXT (“text”) record lets a domain administrator enter arbitrary text into the Domain Name System (DNS). TXT records were initially created for the purpose of including important notices regarding the domain, but have since evolved to serve other purposes.

Advanced DNS Concepts

DNS Zone:

The DNS is broken up into many different zones. These zones differentiate between distinctly managed areas in the DNS namespace. A DNS zone is a portion of the DNS namespace that is managed by a specific organization or administrator. A DNS zone is an administrative space which allows for more granular control of DNS components, such as authoritative nameservers. The domain name space is a hierarchical tree, with the DNS root domain at the top. A DNS zone starts at a domain within the tree and can also extend down into subdomains so that multiple subdomains can be managed by one entity.

A common mistake is to associate a DNS zone with a domain name or a single DNS server. In fact, a DNS zone can contain multiple subdomains and multiple zones can exist on the same server. DNS zones are not necessarily physically separated from one another, zones are strictly used for delegating control.

For example, imagine a hypothetical zone for the cloudflare.com domain and three of its subdomains: support.cloudflare.com, community.cloudflare.com, and blog.cloudflare.com. Suppose the blog is a robust, independent site that needs separate administration, but the support and community pages are more closely associated with cloudflare.com and can be managed in the same zone as the primary domain. In this case, cloudflare.com as well as the support and community sites would all be in one zone, while blog.cloudflare.com would exist in its own zone.

DNS zones are basically administrative units that divide the domain name space in the Domain Name System (DNS). They help in managing and delegating domain names within a specific portion of the overall domain. There are different types of DNS zones, such as:

1. Primary Zone: This is the original read/write copy of the zone, and it is the authoritative source for the zone's information.

2. Secondary Zone: This is a read-only copy of the primary zone. It is used for backup and fault tolerance. If the primary DNS server fails, the secondary server can still provide domain information.

3. Stub Zone: This type of zone contains only a subset of the entire DNS namespace. It is used to resolve names between separate DNS namespaces.

4. Forward Lookup Zone: This zone is used to resolve domain names to IP addresses. It is the most common type of zone.

5. Reverse Lookup Zone: This zone is used to resolve IP addresses to domain names.

Each of these zones plays a specific role in the DNS hierarchy and helps ensure efficient and reliable domain name resolution.

Anycast DNS:

In Anycast, one IP address can apply to many servers. Anycast DNS means that any one of a number of DNS servers can respond to DNS queries, and typically the one that is geographically closest will provide the response. This reduces latency, improves uptime for the DNS resolving service, and provides protection against DNS flood DDoS attacks.

Typically, any device or server that connects directly to the Internet will have a unique IP address. Communication between network-connected devices is 1-to-1; each communication goes from one specific device to the targeted device on the other end of the communication. Anycast networks, in contrast, allow multiple servers on the network to use the same IP address, or set of IP addresses. Communication with an Anycast network is 1-to-many.

Ordinarily, an IP address functions like a street address: it specifies the one specific location where the message is going. But suppose a friend had multiple residences around the country. Imagine a letter addressed to one of her houses could go to any one of those other houses based on which one was closest to the sender, even though the letter was addressed to a house in another city. This is sort of how Anycast routing works: one IP address can be associated with multiple locations.

Recursive DNS:

A recursive DNS lookup is where one DNS server communicates with several other DNS servers to hunt down an IP address and return it to the client. This is in contrast to an iterative DNS query, where the client communicates directly with each DNS server involved in the lookup. While this is a very technical definition, a closer look at the DNS system and the difference between recursion and iteration should help clear things up.

Primary vs. secondary DNS:

What is a primary DNS server?

DNS, or the Domain Name System, translates domain names into IP addresses so users can easily navigate to sites on the Internet without having to memorize long, specific strings of numbers and letters.

In this system, a primary DNS server is a server that hosts a website’s primary zone file. This is a text database file that contains all of the authoritative information for a domain, including its IP address, the identity of the domain administrator, and various resource records. Resource records list domain names alongside their corresponding IP addresses, and can take several different forms:

A record: Directs a domain to an IPv4 address
AAAA record: Directs a domain to an IPv6 address
MX record: Assigns a mail server to a domain
NS record: Identifies authoritative DNS servers for a domain

Primary servers are also responsible for making any necessary changes to a zone’s DNS records. Once the primary server has completed the update, it can then pass along change requests to the secondary servers.

What is a secondary DNS server?

Primary DNS servers contain all relevant resource records and handle DNS queries for a domain. By contrast, secondary DNS servers contain zone file copies that are read-only, meaning they cannot be modified. Instead of getting their information from local files, they receive pertinent information from a primary server in a communication process known as a zone transfer.

Zone transfers become more complicated when they are completed between multiple secondary servers. If several secondary servers are in use, one may be designated as a higher-tier secondary server so that it is capable of replicating zone file copies to the remaining pool of secondary servers.

Reverse DNS:

A reverse DNS lookup is a DNS query for the domain name associated with a given IP address. This accomplishes the opposite of the more commonly used forward DNS lookup, in which the DNS system is queried to return an IP address.

Standards from the Internet Engineering Task Force (IETF) suggest that every domain should be capable of reverse DNS lookup, but as reverse lookups are not critical to the normal function of the Internet, they are not a hard requirement. As such, reverse DNS lookups are not universally adopted.

Conclusion

we've delved into the intricate world of DNS, uncovering its pivotal role as the internet's address book. From the hierarchical structure guiding our online navigation to the seamless translation of user-friendly domain names into machine-readable IP addresses, DNS stands as a silent yet indispensable force shaping our digital experiences.

As we explored the protocol's reliance on both UDP and TCP, with the familiar port 53 orchestrating the flow of data, it became evident that DNS is more than a mere naming system; it's a dynamic network facilitator. Its caching mechanisms enhance efficiency, and the use of resource records provides a nuanced understanding of domain configurations.

In the ever-evolving landscape of the internet, grasping the fundamentals of DNS is akin to possessing a map in an uncharted territory. Our journey has unraveled the complexities, empowering us to navigate with a newfound appreciation for the invisible threads weaving the web together. Whether optimizing DNS performance or addressing security concerns, the significance of this protocol echoes in every click, reaffirming its status as an indispensable cornerstone of our online existence.

Congratulations! You've now gained a comprehensive understanding of DNS and its role in making the internet accessible.Feel free to ask questions or share your experiences in the comments below.

Contact Me

LinkedIn: Pavankumar Hegde
GitHub: Pavankumar Hegde

Feel free to reach out for collaborations, questions, or just to say hello!

References

SSL Handshake: A Comprehensive Guide to SSL/TLS Protocols

Pavankumar Hegde — Sun, 19 Nov 2023 08:14:25 +0000

Overview
History
Client Hello
Server Hello
Certificate
Server Key Exchange
Server Hello Done
Client Key Exchange
Change Cipher Spec
Finished
Change Cipher Spec
Finished
Conclusion and References
Contact Me
References
Recent Blog Post

Overview

If you have ever browsed an HTTPS URL through a browser, you have experienced the SSL handshake. Even though might not notice it, the browser and the website is creating an HTTPS connection using a one-way SSL handshake.

The main purpose of an SSL handshake is to provide privacy and data integrity for communication between a server and a client. During the Handshake, the server and client will exchange important information required to establish a secure connection.

There are two types of SSL handshakes described as one-way SSL and two-way SSL (Mutual SSL). The difference between those two is that in one-way SSL, only the client validates the identity of the server whereas in two-way SSL, both server and client validate the identity of each other. Usually, when we browse an HTTPS website, one-way SSL is used where only our browser (client) validates the identity of the website (server). Two-way SSL is mostly used in server-to-server communication where both parties need to validate the identity of each other.

During an SSL handshake, the server and the client follow the below set of steps.

History

The Secure Sockets Layer (SSL) protocol was first introduced by Netscape in 1994. The Internet was growing and there was a need for transport security for web browsers and for various TCP protocols. Version 1.0 of SSL was never released because it had serious security flaws. The first official release of SSL, version 2.0, was out in 1995. The final version of the SSL protocol, SSL 3.0, was released in November 1996.

In 2011, the Internet Engineering Task Force (IETF) announced that SSL version 2.0 is deprecated. IETF recommended SSL v2 to be completely abandoned because according to a document that they released (RFC 6176) the protocol has several major deficiencies. These included using MD5 for message authentication, lack of protection for handshakes, using the same key for message integrity and encryption, and easy session termination. In June 2015, IETF also announced that SSL 3.0 is deprecated. As stated in a document released by IETF (RFC 7568), any TLS version is more secure than all versions of SSL. SSL also cannot use features of the TLS protocol such as Authenticated Encryption with Additional Data (AEAD), Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA), stateless session tickets, a datagram mode of operation (DTLS) and application-layer protocol negotiation.

The current version of TLS, TLS 1.3, was released in August 2018 (RFC 8446). It took IETF 10 years and 28 drafts to complete. This time, the protocol underwent some major changes with the focus on simplicity. Several unsafe technologies were removed, including SHA-1, MD5, RC4, DES, and 3DES. The protocol was streamlined for better performance: the handshake now requires only one round-trip (in some cases even zero). Other changes include encryption of SNI information for better privacy and a new signature standard (RSA-PSS). All modern browsers support TLS v1.3.

Now that we've traversed the rich history of SSL/TLS, let's shift our focus to a more granular exploration. Join me as we delve into the anatomy of SSL handshake messages, dissecting each step to uncover the inner workings of secure communication. Buckle up for a journey through the nuances of the SSL/TLS handshake process, where every message contributes to the robust framework of online security. It's time to decode the language of secure connections and empower ourselves with a comprehensive understanding of SSL/TLS handshake messages.

Client Hello

The client will send the information that will be required by the server to start an HTTPS connection.

The first message is called the “ClientHello.”
This message lists the client’s capabilities so that the server can pick the cipher suite that the two will use to communicate.
It also includes a large, randomly picked prime number called a “client random.”
The ClientHello message is always the first message sent in a new handshake. It’s used to communicate client capabilities and preferences to the server.
Clients send this message at the beginning of a new connection, when they wish to renegotiate, or in response to a server’s renegotiation request (indicated by a HelloRequest message).

Server Hello

The server politely responds with a “SeverHello” message. In this message it tells the client what connection parameters it has selected from the provided list and returns its own randomly selected prime number called a “server random.”
If the client and server do not share any capabilities in common, the connection terminates. Server Hello will be as follows.

Certificate

In the “Certificate” message, the Server sends its SSL certificate chain (which includes its leaf certificate and intermediate certificates) to the client.
To provide authentication to the connection an SSL certificate is signed by a CA, which allows the client to verify that the certificate is legitimate.
Upon receipt, the client performs several checks to authenticate the certificate. This includes checking the certificate’s digital signature, verifying the certificate chain, and checking for any other potential problems with the certificate data (expired certificate, wrong domain name, etc).
The client will also make sure the server has possession of the certificate’s private key. This is done during the key exchange/generation process.

** Certificate chain
chain [0] = [
[
 Version: V3
 Subject: CN=server, OU=ID, O=IBM, L=Hursley, ST=Hants, C=GB
 Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

Key: Sun RSA public key, 2048 bits
 modulus: 17397562757879783124811507432494159361243533796048391161052829821122241422546147907779583980536886743765496985274573369668302996974964349098220930856827026983442125212118340479175872257401994146576001849503528844021528618702289642320157895787705650513758990004411195572445830613057931701313142946380207623174021376881040589912594451781207558263630010509870784494298596448861811827669869221033031956053367890915692918086795954628465637743034777850129818069833958463245749899713073673871721233098662285260745282530972322499603703844901496085490388703767606182211892402117158287170480970610942364235511256363933850852797
 public exponent: 65537
 Validity: [From: Sat Jul 28 09:08:48 IST 2018,
 To: Sun Jul 28 09:08:48 IST 2019]
 Issuer: CN=server, OU=ID, O=IBM, L=Hursley, ST=Hants, C=GB
 SerialNumber: [ 7d834874]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C7 24 EA C3 1E 3E 58 8E BD E3 AE A9 17 01 00 51 .$…>X……..Q
0010: B0 83 D4 68 …h
]
]
]
 Algorithm: [SHA256withRSA]
 Signature:
0000: 4B FA 93 D8 56 78 05 D8 89 BC 2A 3A B6 C3 7F A5 K…Vx….*:….
0010: 03 D8 56 3B E6 9F 0B 17 B5 A2 61 AE 43 46 A4 85 ..V;……a.CF..
0020: 3F 60 2E 04 41 0D C2 7A 35 0D 56 F5 FE 9D 05 51 ?`..A..z5.V….Q
0030: 4A 0B BB 5B 30 ED 85 AF 1C 95 13 15 7D A0 2C DE J..[0………,.
0040: B4 A1 7A D0 5D E4 C0 91 37 C2 ED 37 39 65 7D 02 ..z.]…7..79e..
0050: B5 A4 72 FF EB 6C D5 F4 FD BC 32 FD 9F C8 3A 49 ..r..l….2…:I
0060: 53 64 F8 C6 A0 D6 DB 89 2C 36 60 97 8B 33 8F 95 Sd……,6`..3..
0070: 18 9C 1A F2 F8 F1 66 5E F3 0B 76 54 08 AB A9 88 ……f^..vT….
0080: 5D E9 2D 6B AE 6D 98 09 57 A0 2A 9E C6 6B 89 53 ].-k.m..W.*..k.S
0090: 8E B3 58 C3 8D 73 C5 D3 58 2F 68 F0 4E 0A EF 29 ..X..s..X/h.N..)
00A0: 54 95 00 34 6A C4 D2 56 22 64 05 F9 9F A4 81 44 T..4j..V"d…..D
00B0: 44 77 95 A7 86 5A D3 EE EA 8E 06 19 ED 94 F1 83 Dw…Z……….
00C0: F4 A1 F4 A0 76 94 02 40 30 C0 95 6A F2 4F 32 BB ….v..@0..j.O2.
00D0: 79 A2 1B 40 F5 EB 37 5B B7 0C FA 18 DE 04 18 7D y..@..7[……..
00E0: 5A 1A 95 D7 E7 00 4C 7F 3C 71 CE 8E 03 07 BD 50 Z…..L.<q…..P
00F0: 6D 49 52 75 66 D2 CA 45 AB B8 EE B1 C2 C9 72 8A mIRuf..E……r.
]
***

Server Key Exchange

This is an optional message, only needed for certain key exchange methods (Diffie-Hellman) that require the server provides additional data.

*** ECDH ServerKeyExchange
Signature Algorithm SHA256withRSA
Server key: Sun EC public key, 256 bits
  public x coord: 49880139518100326927648337356136531406906846853753693344570844017045565963249
  public y coord: 95714017526253024568876509155195989984116809887282783483716821451591048546410
  parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)

Server Hello Done

The “Server Hello Done” message tells the client that it has sent over all its messages.

Client Key Exchange

This message needs to be sent by the client following the Client Certificate message. If the client certificate is not being presented (in one-way SSL), the client key exchange message should be sent after the client receives the ServerHelloDone message.
As we all know the data transferred between the server and the client in an HTTPS connection will be encrypted. Symmetric encryption[7] is being used for this purpose as the computational cost is much lower than Asymmetric encryption. In order to use symmetric encryption, there needs to be a common key between the two ends. The purpose of this message is to generate that common key between that client and the server without exposing to an outsider.
There are two client key exchange methods described in the TLS v1.2 spec. They are RSA[8] and Diffie-Hellman.
If RSA is used as the key exchange algorithm, the client generates a 48-byte pre-master secret. The client encrypts the pre-master secret by the public key of the certificate and sends to the server. Only the server will have the corresponding private key to decrypt and get the client generated pre-master secret.
If Diffie-Hellman is used, the Diffie-Hellman parameters are transmitted to allow both client and server to generate the same pre-master secret.
After that, both sides will generate a master secret using the pre-master secret and the master secret will be used to generate the symmetric key for encrypting the session data

Change Cipher Spec

The “Change Cipher Spec” message lets the other party know that it has generated the session key and is going to switch to encrypted communication.

Finished

The “Finished” message is then sent to indicate that the handshake is complete on the client side. The Finished message is encrypted, and is the first data protected by the session key. The message contains data (MAC) that allows each party to make sure the handshake was not tampered with.

Change Cipher Spec

Now it’s the server’s turn to do the same. It decrypts the pre-master secret and computes the session key. Then it sends its “Change Cipher Spec” message to indicate it is switching to encrypted communication.

Finished

The server sends its “Finished” message using the symmetric session key it just generated, it also performs the same check-sum to verify the integrity of the handshake. ...

Conclusion

we've embarked on a journey through the intricate landscape of SSL/TLS handshake messages, unraveling the complexities that underpin secure Internet communication. From the initial ClientHello to the conclusive Finished messages, each handshake step plays a pivotal role in establishing a secure connection between clients and servers.

Understanding these messages not only provides insight into the robust security mechanisms employed by SSL/TLS protocols but also empowers developers and cybersecurity enthusiasts to make informed decisions in implementing and optimizing secure communication.

As we navigate the digital realm, the SSL/TLS handshake stands as a guardian, ensuring that our data remains confidential, integral, and secure. The handshake's dance may seem complex, but its significance in fortifying the foundations of online security cannot be overstated.

For those eager to delve deeper into the world of SSL/TLS or explore related topics, references abound. Feel free to continue the exploration, building upon the knowledge gained here to bolster your understanding of cybersecurity essentials.

Thank you for joining me on this journey through the SSL/TLS handshake. As technology evolves, so does the importance of robust security practices. May your future endeavors in the digital landscape be secure and your connections always encrypted.

Contact Me

LinkedIn: Pavankumar Hegde
GitHub: Pavankumar Hegde

Feel free to reach out for collaborations, questions, or just to say hello!

References

Recent Blog Post

Happy reading and exploring the fascinating world of cybersecurity and technology!😎👍

What is IPsec? | How IPsec VPNs Work Explained!!

Pavankumar Hegde — Mon, 13 Nov 2023 14:40:24 +0000

Lesson Contents

IKE (Internet Key Exchange)
-IKE Phase 1
- Main Mode
- Aggressive Mode
- IKE Phase 2
- Quick Mode
Conclusion

IKE (Internet Key Exchange)

IPsec (Internet Protocol Security) is a framework that helps us to protect IP traffic on the network layer. Why? because the IP protocol itself doesn’t have any security features at all. IPsec can protect our traffic with the following features:

1. Confidentiality: by encrypting our data, nobody except the sender and receiver will be able to read our data.

2. Integrity: we want to make sure that nobody changes the data in our packets. By calculating a hash value, the sender and receiver will be able to check if changes have been made to the packet.

3. Authentication: the sender and receiver will authenticate each other to make sure that we are really talking with the device we intend to.

As a framework, IPsec uses a variety of protocols to implement the features I described above. Here’s an overview:

IPsec can be used on many different devices, it’s used on routers, firewalls, hosts, and servers. Here are some examples of how you can use it:

Between two routers to create a site-to-site VPN that “bridges” two LANs together.
Between a firewall and Windows host for remote access VPN.
Between two Linux servers to protect an insecure protocol like telnet.

IPsec is pretty complex and there are a lot of different ways to implement it. In this lesson, I will start with an overview and then we will take a closer look at each of the components.

Before we can protect any IP packets, we need two IPsec peers that build the IPsec tunnel.

Introduction to ISAKMP protocol

The protocol used in IPSec for key management is called ISAKMP/Oakley. ISAKMP stands for the Internet Security Association and Key Management Protocol. It is a protocol platform used for key management. It defines the procedure and packet formats for negotiating, establishing, modifying, and deleting SAs. ISAKMP messages can be transmitted via the TCP or UDP transport protocol. Port number 500 of TCP and UDP are reserved for ISAKMP protocol. The initial version of ISAKMP mandated the use of the Oakley protocol. Oakley is based on the Diffie Hellman key exchange protocol.

So first, we will discuss the Oakley and then will discuss the ISAKMP.

Oakley protocol

Oakley protocol is a refined version of the Diffie Hellman key exchange protocol. Diffie Hellman offers two main features the creation of secret keys as and when required and no requirement for any pre-existing infrastructure. However, the Diffie Hellman key exchange protocol also has some problems. Oakley protocol is designed to solve these problems.

Features of Oakley are as follows:

It enables the exchange of Diffie Hellman public key values
To defeat the congestion attacks, it implements a mechanism which is called cookies.
To defeat the man-in-the-middle attack, it provides an authentication mechanism.

Below are the approaches that are taken by the Oakley protocol to solve the problems of the Diffie Hellman key protocol.

1. Authentication: Oakley protocol supports three authentication mechanisms which follow

Digital signatures: Generation of a message digest and its encryption with the private key of the sender.
Public key encryption: Encryption of information such as the user ID of the sender and the public key of the receiver.
Secret key encryption: Key derived by using some out-of-band mechanism.

2. dealing with congestion attacks: to defeat the congestion attack, Oakley uses the cookie concept. In this type of attack, an attacker forges the source address of another legitimate user and sends a public Diffie Hellman key to another legitimate user. Then the receiver performs some calculations to calculate the secret key. Several calculations. Performed rapidly one after another causing the congestion of the victim’s computer. To defeat this, each side in Oakley must send the pseudo-random number, which is called a cookie, in the initial message, which the other side must acknowledge. This acknowledgment must be repeated in the first message of the Diffie key exchange protocol. If an attacker forges the source address, he does get the acknowledgment cookie from the victim, and her attacks fail.

3. ISAKMP: This protocol defines the procedure and the format for establishing, maintaining, and deleting the SA information. ISAKMP message contains an ISAKMP header followed by one or more payloads. The entire block is encapsulated inside the transport segment.

> ISAKMP Header

To establish an IPsec tunnel, we use a protocol called IKE (Internet Key Exchange).

There are two phases to build an IPsec tunnel:

IKE Phase 1
IKE Phase 2

IKE Phase 1

In IKE phase 1, two peers will negotiate about the encryption, authentication, hashing, and other protocols that they want to use and some other parameters that are required. In this phase, an ISAKMP (Internet Security Association and Key Management Protocol) session is established. This is also called the ISAKMP tunnel or IKE phase 1 tunnel.

The collection of parameters that the two devices will use is called a SA (Security Association).

The main purpose of IKE Phase 1 is to establish a secure tunnel that we can use for IKE Phase 2.

We can break down Phase 1 in three simple steps:

Step 1: Negotiation

The peer that has traffic that should be protected will initiate the IKE phase 1 negotiation. The two peers will negotiate about the following items:

Hashing: we use a hashing algorithm to verify the integrity, we use MD5 or SHA for this.

Authentication: each peer has to prove who he is. Two commonly used options are a pre-shared key or digital certificates.

DH (Diffie Hellman) group: the DH group determines the strength of the key that is used in the key exchange process. The higher group numbers are more secure but take longer to compute.

Lifetime: how long does the IKE phase 1 tunnel stand up? the shorter the lifetime, the more secure it is because rebuilding it means we will also use new keying material. Each vendor uses a different lifetime, a common default value is 86400 seconds (1 day).

Encryption: what algorithm do we use for encryption? For example, DES, 3DES, or AES.

Step 2: DH Key Exchange

Once the negotiation has succeeded, the two peers will know what policy to use. They will now use the DH group that they negotiated to exchange keying material. The end result will be that both peers will have a shared key.

Step 3: Authentication

The last step is that the two peers will authenticate each other using the authentication method that they agreed upon on in the negotiation. When the authentication is successful, we have completed IKE phase 1. The end result is a IKE phase 1 tunnel (aka ISAKMP tunnel) which is bidirectional. This means that both peers can send and receive on this tunnel.

The three steps above can be completed using two different modes:

Main mode
Aggressive mode

Main mode uses six messages while aggressive mode only uses three messages. Main mode is considered more secure. Let’s take a look at closer look at both modes.

Main Mode

IKEv1 main mode uses 6 messages. I will show you these in Wireshark and I’ll explain the different fields.

- Message 1

The initiator (peer that wants to build the tunnel) will send the first message. This is a proposal for the security association. Above you can see that the initiator uses IP address 192.168.12.1 and is sending a proposal to the responder (peer we want to connect to) 192.168.12.2. IKE uses UDP port 500 for this. In the output above you can see an initiator SPI (Security Parameter Index), this is a unique value that identifies this security association.

We can see the IKE version (1.0) and that we are using main mode. The domain of interpretation is IPsec and this is the first proposal. In the transform payload, you can find the attributes that we want to use for this security association.

- Message 2

When the responder receives the first message from the initiator, it will reply. This message is used to inform the initiator that we agree upon the attributes in the transformed payload. You can also see that the responder has set its own SPI value.

- Message 3

Since our peers agree on the security association to use, the initiator will start the Diffie Hellman key exchange. In the output above you can see the payload for the key exchange and the nonce.

- Message 4

The responder will also send his/her Diffie Hellman nonces to the initiator, our two peers can now calculate the Diffie Hellman shared key.

- Message 5

The last two messages are encrypted so we can’t see its contents anymore. These two are used for identification and authentication of each peer. The initiator starts.

- Message 6

And above we have the 6th message from the responder with its identification and authentication information. IKEv1 main mode has now been completed and we can continue with IKE phase 2.

Before we continue with phase 2, let me show you aggressive mode first.

Aggressive mode

IKEv1 aggressive mode only requires three messages to establish the security association. It’s quicker than main mode since it adds all the information required for the DH exchange in the first two messages. Main mode is considered more secure since identification is encrypted, aggressive mode does this in clear text.

Let’s take a look at the different messages.

- Message 1

The first message is from the initiator (192.168.12.1) to the responder (192.168.12.2). You can see the transformed payload with the security association attributes, DH nonces, and the identification (in clear text) in this single message.

- Message 2

The responder now has everything it needs to generate the DH shared key and sends some nonces to the initiator so that it can also calculate the DH shared key. It also calculates a hash that is used for authentication.

- Message 3

Both peers have everything they need, the last message from the initiator is a hash that is used for authentication.

Note: PFS is optional and forces the peers to run the DH exchange again to generate a new shared key in each IKE phase 2 quick mode.

IKE Phase 2

Quick Mode

The IKE phase 2 tunnel (IPsec tunnel) will be actually used to protect user data. There is only one mode to build the IKE phase 2 tunnel which is called quick mode.

Just like in IKE phase 1, our peers will negotiate about a number of items:

IPsec Protocol: do we use AH or ESP?
Encapsulation Mode: transport or tunnel mode?
Encryption: what encryption algorithm do we use? DES, 3DES or AES?
Authentication: what authentication algorithm do we use? MD5 or SHA?
Lifetime: how long is the IKE phase 2 tunnel valid? When the tunnel is about to expire, we will refresh the keying material.
(Optional) DH exchange: used for PFS (Perfect Forward Secrecy).

This negotiation happens within the protection of our IKE phase 1 tunnel so we can’t see anything. Just for the sake of completeness, here’s what it looks like in Wireshark:

- Message 1

- Message 2

- Message 3

Once IKE phase 2 has been completed, we are finally ready to protect some user data.

Conclusion

As we conclude our exploration of IKE Phase 1 & 2 messages, we've laid the foundation for a secure and authenticated connection. The intricacies of Main Mode and the efficiency of Aggressive Mode have paved the way for the next chapter in our journey. Join us in the upcoming blog where we delve into the fascinating realm of IPsec Protocols, unlocking the layers of authentication, encryption, and secure communication. Stay tuned for a comprehensive guide that demystifies the protocols ensuring the robustness of our networks. Secure your seat as we unravel the intricacies of IPsec in our next installment!

Connect with Me

LinkedIn: Pavankumar Hegde
GitHub: Pavankumar Hegde

Feel free to reach out for collaborations, questions, or just to say hello!

References

Thanks for reading this far. That's my basic understanding of IPSec and VPN.

Thanks again!! 😊

Recent Blog Posts

What is TCP 3 Way Handshake?

Pavankumar Hegde — Sat, 11 Nov 2023 15:06:55 +0000

Unlocking the Secrets: A Guide to TCP 3-Way Handshake

Introduction
Section 1: Understanding TCP Basics
Section 2: The Need for Handshakes
Section 3: Decoding the 3-Way Handshake
Section 4: Common Issues and Solutions
Section 5: Best Practices for Developers
Conclusion
References

Introduction

🔥 🔥 ALL ABOUT TCP Handshake !!

Welcome to the fascinating world of TCP, where connections are established through a mysterious dance known as the 3-Way Handshake. In this comprehensive guide, we'll demystify the intricacies of TCP communication and unveil the secrets behind this pivotal handshake process.

Section 1: Understanding TCP Basics

TCP (Transmission Control Protocol) serves as the backbone of internet communication, ensuring reliable and ordered data transfer. Before we delve into the 3-Way Handshake, let's quickly review the fundamentals of TCP.

TCP operates at the transport layer of the OSI model, providing a reliable, connection-oriented communication service. It ensures that data is delivered in the correct order and without errors.

Section 2: The Need for Handshakes

But why do devices need to shake hands before exchanging data? This section explores the necessity of establishing a reliable connection and how the 3-Way Handshake plays a pivotal role in this process.

In a world where data integrity is crucial, the 3-Way Handshake acts as a protocol to negotiate and synchronize the sequence numbers for reliable communication. It sets the stage for a smooth exchange of data between devices.

Section 3: Decoding the 3-Way Handshake

Now, let's dissect the 3-Way Handshake step by step.

SYN - Synchronization: Initiating the connection, the client sends a SYN packet to the server.
SYN-ACK - Acknowledgment: The server responds with a SYN-ACK packet, acknowledging the request.
ACK - Final Acknowledgment: The client sends an ACK packet, confirming receipt of the server's response.

This synchronized dance ensures that both ends are ready for a reliable data transfer, creating a foundation for communication.

Section 4: Common Issues and Solutions

No system is without its quirks. This section addresses common problems that may arise during the 3-Way Handshake and provides practical solutions to ensure a smooth connection establishment.

Issue 1: Timeout during Handshake
Solution: Adjust the timeout settings to accommodate network latency.

Issue 2: Dropped Packets
Solution: Implement packet retransmission mechanisms to handle dropped packets.

Issue 3: Misconfigured Firewalls
Solution: Ensure that firewalls are properly configured to allow the necessary handshake packets.

Section 5: Best Practices for Developers

As developers, how can we optimize the 3-way Handshake for our applications? This section offers valuable insights into best practices that enhance the efficiency and reliability of your TCP connections.

Practice 1: Use Persistent Connections
Maintain long-lived connections to reduce the overhead of repeated handshakes for multiple requests.

Practice 2: Implement Connection Pooling
Reuse existing connections to minimize the overhead of establishing new ones.

Practice 3: Optimize Timeout Settings
Adjust timeout settings based on network conditions to prevent premature connection termination.

Conclusion

Congratulations! You've successfully unlocked the secrets of the TCP 3-Way Handshake. Armed with this newfound knowledge, you're better equipped to navigate the intricate world of Internet communication. Keep coding, and may your connections be forever stable!

Connect with Me

LinkedIn: Pavankumar Hegde
GitHub: Pavankumar Hegde

Feel free to reach out for collaborations, questions, or just to say hello!

References

Thanks for reading this far. That's my basic understanding of the three-way handshake.

Thanks again!! 😊

What is OSI Model? | All 7 Layers Explained!!

Pavankumar Hegde — Fri, 10 Nov 2023 10:00:49 +0000

Introduction
Overview of the OSI Model
Layer 1: Physical Layer
Layer 2: Data Link Layer
Layer 3: Network Layer
Layer 4: Transport Layer
Layer 5: Session Layer
Layer 6: Presentation Layer
Layer 7: Application Layer
Conclusion
Additional Resources

Introduction

The OSI (Open Systems Interconnection) Model is a conceptual model that characterizes and standardizes the communication functions of a telecommunication or computing system without regard to its underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard protocols.

Let’s Understand........

Okay, that was the proper definition of the OSI model. The definition looks quite simple and to the point, but when it comes to the elucidation of the OSI model, many of us get confused and are not able to realize what it is. The first thing that comes to people’s mind when they hear the OSI model is that they will have to do a lot of memorization and cramming. This was exactly what happened when I read about OSI Layers the first time.

So, in this article, we will see about the OSI model and its seven layers. Therefore, read this article if you need to understand what the OSI model is all about.

Overview of the OSI Model

The OSI Model

OSI stands for “Open Systems Interconnection”. The exact definition of the OSI Model has been already given above. In simpler words, to be precise, the OSI model is a tool used by IT professionals to actually model or trace the actual flow of how data transfers in networks. So, basically, the OSI model is a logical model/representation of how the network systems are supposed to send data (or, communicate) to each other.

What is it composed of?

The OSI Model breaks down this data transfer/communication procedure into different components (called layers). Why layers, because those components follow a proper order of execution. For example, the Physical Layer in which the “physical” wiring and connections take place, the Data Link Layer in which switching takes place, etc. In total, seven layers together make up the OSI Model.

Why does the OSI model matter?

Although the modern Internet does not strictly follow the OSI Model (it more closely follows the simpler Internet protocol suite), the OSI Model is still very useful for troubleshooting network problems. Whether it’s one person who can’t get their laptop on the Internet, or a website being down for thousands of users, the OSI Model can help to break down the problem and isolate the source of the trouble. If the problem can be narrowed down to one specific layer of the model, a lot of unnecessary work can be avoided.

What are the 7 layers of the OSI Model?

Layer 1: Physical Layer
Layer 2: Data Link Layer
Layer 3: Network Layer
Layer 4: Transport Layer
Layer 5: Session Layer
Layer 6: Presentation Layer
Layer 7: Application Layer

The seven abstraction layers of the OSI model can be defined as follows, from top to bottom:

Layer 7: Application Layer

This is the only layer that directly interacts with data from the user.
Software applications like web browsers and email clients rely on the application layer to initiate communications.
However, it should be made clear that client software applications are not part of the application layer;
rather the application layer is responsible for the protocols and data manipulation that the software relies on to present meaningful data to the user.

Important ports and protocols include:

HTTP (Hypertext Transfer Protocol): Port 80 *(HTTP) and **443 *(HTTPS**) are crucial for web communication.
FTP (File Transfer Protocol): Port *21 *(control) and *20 *(data) are commonly used for file transfers.
SMTP (Simple Mail Transfer Protocol): Port 25 is used for email communication.
POP3 (Post Office Protocol 3): Port 110 is used for receiving emails.
IMAP (Internet Message Access Protocol): Port 143 is used for accessing and managing email on a server.

Layer 6: Presentation Layer

This layer is primarily responsible for preparing data so that it can be used by the application layer;
in other words, layer 6 makes the data presentable for applications to consume.
The presentation layer is responsible for translation, encryption, and compression of data.
Two communicating devices communicating may be using different encoding methods, so layer 6 is responsible for translating incoming data into a syntax that the application layer of the receiving device can understand.
If the devices are communicating over an encrypted connection, layer 6 is responsible for adding the encryption on the sender’s end as well as decoding the encryption on the receiver's end so that it can present the application layer with unencrypted, readable data.
Finally, the presentation layer is also responsible for compressing data it receives from the application layer before delivering it to layer 5.
This helps improve the speed and efficiency of communication by minimizing the amount of data that will be transferred.

Layer 5: Session Layer

This is the layer responsible for opening and closing communication between the two devices.
The time between when the communication is opened and closed is known as the session.
The session layer ensures that the session stays open long enough to transfer all the data being exchanged, and then promptly closes the session in order to avoid wasting resources.
The session layer also synchronizes data transfer with checkpoints.

For example, if a 100 megabyte file is being transferred, the session layer could set a checkpoint every 5 megabytes. In the case of a disconnect or a crash, after 52 megabytes have been transferred, the session could be resumed from the last checkpoint, meaning only 50 more megabytes of data need to be transferred. Without the checkpoints, the entire transfer would have to begin again from scratch.

Layer 4: Transport Layer

Layer 4 is responsible for end-to-end communication between the two devices. This includes taking data from the session layer and breaking it up into chunks called segments before sending it to layer 3.
The transport layer on the receiving device is responsible for reassembling the segments into data the session layer can consume.
The transport layer is also responsible for flow control and error control.
Flow control determines an optimal speed of transmission to ensure that a sender with a fast connection does not overwhelm a receiver with a slow connection.
The transport layer performs error control on the receiving end by ensuring that the data received is complete, and requesting a retransmission if it isn’t.

Transport layer protocols include the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).

Layer 3: Network Layer

The network layer is responsible for facilitating data transfer between two different networks.
If the two devices communicating are on the same network, then the network layer is unnecessary.
The network layer breaks up segments from the transport layer into smaller units, called packets, on the sender’s device, and reassembling these packets on the receiving device.
The network layer also finds the best physical path for the data to reach its destination; this is known as routing.

Network layer protocols include IP, the Internet Control Message Protocol (ICMP), the Internet Group Message Protocol (IGMP), and the IPsec suite.

Layer 2: Data Link Layer

The data link layer is very similar to the network layer, except the data link layer facilitates data transfer between two devices on the same network.
The data link layer takes packets from the network layer and breaks them into smaller pieces called frames.
Like the network layer, the data link layer is also responsible for flow control and error control in intra-network communication (The transport layer only does flow control and error control for inter-network communications).

Layer 1: Physical Layer

This layer includes the physical equipment involved in the data transfer, such as the cables and switches.
This is also the layer where the data gets converted into a bit stream, which is a string of 1s and 0s.
The physical layer of both devices must also agree on a signal convention so that the 1s can be distinguished from the 0s on both devices.

Conclusion

This was a short and to-the-point article explaining the OSI Model, to help out all those who are having a hard time understanding the model. Hope it will help you understand the OSI model, in case you are stuck and trying to by-heart and cram the OSI Layers.

Also, you can refer to this awesome YouTube video to get a clear picture of the OSI Model -

Video Credits: RealPars YouTube Channel

A simple mnemonic for memorizing the names of OSI layers:

[Top to Bottem]

All People Seem To Need Data Processing
A Priest Says Ten Nuns Doing Pushups

[Bottem to Top]

Please Do Not Throw Sausage Pizza Away

This is for Hindi People:

Andhra Pradesh Se Train New Delhi Pahuchi

Connect with Me

LinkedIn: Pavankumar Hegde
GitHub: Pavankumar Hegde

Feel free to reach out for collaborations, questions, or just to say hello!

DEV Community: Pavankumar Hegde

DNS Explained: Navigating the Web's Address Book!

Table of Contents

Introduction

Understanding DNS

DNS Record Types

Advanced DNS Concepts

Conclusion

Contact Me

References

SSL Handshake: A Comprehensive Guide to SSL/TLS Protocols

Overview

History

Client Hello

Server Hello

Certificate

Server Key Exchange

Server Hello Done

Client Key Exchange

Change Cipher Spec

Finished

Change Cipher Spec

Finished

Conclusion

Contact Me

References

Recent Blog Post

What is IPsec? | How IPsec VPNs Work Explained!!

Lesson Contents

Table of Contents

IKE (Internet Key Exchange)

IKE Phase 1

Main Mode

Aggressive mode

IKE Phase 2

Quick Mode

Conclusion

Connect with Me

References

Recent Blog Posts

What is TCP 3 Way Handshake?

Unlocking the Secrets: A Guide to TCP 3-Way Handshake

Table of Contents

Introduction

Section 1: Understanding TCP Basics

Section 2: The Need for Handshakes

Section 3: Decoding the 3-Way Handshake

Section 4: Common Issues and Solutions

Section 5: Best Practices for Developers

Conclusion

Connect with Me

References

What is OSI Model? | All 7 Layers Explained!!

Table of Contents

Introduction

Overview of the OSI Model

Layer 7: Application Layer

Layer 6: Presentation Layer

Layer 5: Session Layer

Layer 4: Transport Layer

Layer 3: Network Layer

Layer 2: Data Link Layer

Layer 1: Physical Layer

Conclusion

Connect with Me

Additional Resources

Recent Blog Posts