DEV Community: Diksha Sharma

How HTTPS Authenticates Websites Using SSL/TLS 🔐

Diksha Sharma — Fri, 29 May 2026 08:05:41 +0000

How HTTPS Authenticates Websites Using SSL/TLS 🔐

Every time you open a website like Google, Amazon, or your banking portal, your browser shows a small lock icon beside the URL.

But have you ever wondered:

How does the browser actually know the website is genuine?

How does it verify that nobody is impersonating the server or intercepting your data?

This is where HTTPS and the SSL/TLS protocol come in.

In this blog, we’ll break down:

How HTTPS works
How SSL/TLS authenticates websites
What certificates actually do
How browsers establish secure communication

Let’s dive in.

What is HTTPS(port-443)?

HTTPS stands for:

HyperText Transfer Protocol Secure

It is the secure version of HTTP(port-80).

HTTPS uses SSL/TLS to provide:

Authentication
Encryption
Data Integrity

Without HTTPS, attackers could perform:

Data Tampering
Session Hijacking
MITM: Man-in-the-middle Attack
SSL Stripping Attack

The Main Goal: Authentication

Before your browser sends any sensitive information, it first needs to answer:

“Am I really talking to the actual website?”

For example:

Is this really amazon.com?
Or is it an attacker pretending to be Amazon?

TLS solves this using digital certificates.

The HTTPS Authentication Flow

Let’s understand the process step by step.

Suppose you open:

https://amazon.com

Here’s what happens behind the scenes.

Step 1: Browser Sends "Client Hello"

Your browser initiates communication by sending:

Client Hello

This message contains:

Supported TLS versions
Supported cipher suites
Encryption algorithms
A random value

The browser is basically saying:

Hey server,
here are the security methods I support.

Step 2: Server Responds with Certificate

The server replies with:

Server Hello

Along with:

Chosen encryption method
TLS certificate
Public key
Another random number

The most important thing here is the:

TLS Certificate

Think of it like a digital identity card for the website.

It contains:

Domain name
Public key
Expiry date
Certificate Authority (CA)
Digital signature

Example:

Domain: amazon.com
Issued By: DigiCert

Step 3: Browser Verifies the Certificate

This is the actual authentication phase.

The browser performs several checks.

1. Domain Verification

The browser checks:

Does the certificate belong to the website I requested?

If you visit:

amazon.com

But the certificate says:

google.com

The browser blocks the connection immediately.

2. Certificate Expiry Check

Certificates have validity periods.

If the certificate is expired, browsers show warnings like:

Your connection is not private

3. Certificate Authority Verification

Browsers already trust certain organizations called:

Certificate Authorities (CAs)

Examples include:

DigiCert
Let’s Encrypt
GlobalSign

These authorities verify website ownership before issuing certificates.

The browser verifies:

whether the CA is trusted
whether the CA’s digital signature is valid

If valid:

The website identity is trusted.

How Digital Signatures Work

Certificate Authorities use asymmetric cryptography.

The CA:

Creates a hash of the certificate
Encrypts the hash using its private key

Your browser:

Decrypts the signature using the CA’s public key
Compares the hashes

If the hashes match:

the certificate is authentic
the certificate was not modified

This proves the website is genuine.

Step 4: Secure Key Exchange

Once the website is authenticated, the browser and server establish a shared secret key.

Modern TLS commonly uses:

Diffie-Hellman
ECDHE (Elliptic Curve Diffie-Hellman)

This generates a temporary session key.

Why TLS Uses Symmetric Encryption Afterwards

Asymmetric encryption is secure but computationally expensive.

So TLS uses:

Purpose	Encryption Type
Authentication	Asymmetric Encryption
Data Transfer	Symmetric Encryption

This makes HTTPS secure and efficient.

Step 5: Encrypted Communication Begins

Now both sides share the same session key.

All communication becomes encrypted:

Passwords
API requests
Cookies
Payment data
User sessions

Even if attackers capture the traffic, they only see encrypted gibberish.

How HTTPS Prevents MITM Attacks

Suppose an attacker tries to intercept traffic and impersonate Amazon.

To succeed, they would need:

Amazon’s valid certificate
A trusted CA signature
Amazon’s private key

Since they don’t possess these:

browsers detect fake certificates
the connection gets blocked

This prevents:

Man-in-the-Middle (MITM) attacks

SSL vs TLS

You often hear both SSL and TLS.

Here’s the difference:

SSL	TLS
Older	Modern
Insecure	Secure
Deprecated	Currently used

Today, HTTPS mainly uses:

TLS 1.2
TLS 1.3

People still casually say “SSL certificate,” even though modern systems use TLS.

What Does the Lock Icon Actually Mean?

That small lock icon means:

The connection is encrypted
The certificate is valid
The website identity is verified

It does not guarantee the website itself is safe or trustworthy.

It only means:

You are securely connected to the real server.

Final Thoughts

Whenever you open a secure website, your browser performs an entire chain of trust verification within milliseconds.

HTTPS authentication relies on:

Digital certificates
Certificate Authorities
Public key cryptography
Digital signatures
TLS handshakes

That tiny lock icon represents a massive amount of security happening silently in the background.

Quick Summary

HTTPS authenticates websites by:

Sending a TLS certificate
Verifying the certificate
Validating CA signatures
Establishing secure session keys
Encrypting all communication

This ensures:

Authentication
Confidentiality
Integrity

And that’s how HTTPS secures communication on the internet 🔐

Ever Wondered What Actually Happens When You Click “Send” on an Email?

Diksha Sharma — Wed, 27 May 2026 09:28:39 +0000

We send emails every single day.

A quick message to a friend.
An internship application.
A password reset request.
A late-night “Please find attached” email.

And honestly, for most of us, sending an email feels incredibly simple:

Open Gmail
Write the message
Add the recipient
Click Send

Done.

But have you ever stopped and wondered:

“What actually happens after I click that Send button?”

How does your email travel across the world in just a few seconds?
How does Gmail know you’re the real sender?
How does Yahoo trust that the email genuinely came from Gmail and not from a hacker pretending to be you?

Behind that tiny Send button is an entire backend ecosystem quietly working in milliseconds.

And trust me — it’s way more interesting than it looks.

Let’s Take a Real Example

Suppose I send an email from:

diksha@gmail.com

to:

tom@yahoo.com

From my perspective, I just typed a message and clicked Send.

But in reality, multiple systems, protocols, security checks, DNS servers, and mail servers immediately start working behind the scenes.

Let’s break down the complete journey of that email.

Step 1 — Gmail First Verifies Me

Before Gmail even sends my email, Google already knows who I am because I logged into my Gmail account earlier.

When I signed in, Google verified:

my username and password
session tokens
authentication status

So when I hit Send, Gmail already knows:

Yes, this is actually Diksha.

This is important because otherwise anyone could pretend to be me and send emails from my address.

Step 2 — Gmail’s SMTP Server Takes Over

The moment I press Send, Gmail hands my email to its SMTP server:

smtp.gmail.com

SMTP stands for:

Simple Mail Transfer Protocol

Think of SMTP as the internet’s digital post office.

Its job is to:

send emails
route emails
relay emails between mail servers

At this point, Gmail starts preparing my email for delivery.

Step 3 — Hidden Email Headers Are Added

Now Gmail secretly adds metadata to the email.

Things like:

sender address
receiver address
timestamps
routing information
message identifiers

For example:

From: diksha@gmail.com
To: tom@yahoo.com

These headers help email servers understand:

where the email came from
where it should go
how it should be processed

Step 4 — Gmail Digitally Signs the Email

Now comes one of the coolest parts.

Gmail adds something called a:

DKIM Signature

This is basically a digital signature added using cryptography.

Imagine Google placing an official tamper-proof stamp on the email saying:

“Yes, this email genuinely came from us.”

This signature helps prove:

the email is authentic
the message wasn’t modified during transit

If even one word changes while traveling across the internet, the signature breaks.

Step 5 — Gmail Needs to Find Yahoo’s Mail Server

Now Gmail asks:

“Where should I deliver this email?”

It looks at the recipient address:

tom@yahoo.com

and extracts:

yahoo.com

But computers don’t understand names like humans do.

They need server information.

So Gmail performs a DNS lookup.

Step 6 — DNS and MX Records Come Into Play

DNS is basically the internet’s phonebook.

Gmail asks DNS:

“Which mail server handles emails for yahoo.com?”

DNS checks something called an:

MX Record

and replies with Yahoo’s mail server details.

Something like:

yahoo.com MX 10 mta5.am0.yahoodns.net

Meaning:

“Send Yahoo emails here.”

Now Gmail knows exactly where to deliver the email.

Step 7 — The Email Travels Across the Internet

Now the actual journey begins.

The email:

gets broken into packets
travels through routers
crosses ISPs and networks
moves across multiple systems

all within seconds.

Eventually, it reaches Yahoo’s mail server.

But here’s the important part:

Yahoo does NOT blindly trust the email.

And this is where cybersecurity becomes extremely important.

Step 8 — Yahoo Starts Verifying the Email

Yahoo now asks:

“Did this email really come from Gmail?”

Because attackers constantly try to:

spoof emails
send phishing emails
impersonate trusted domains

So Yahoo performs multiple security checks.

SPF Verification

First, Yahoo checks something called:

SPF

SPF stands for:

Sender Policy Framework

This tells Yahoo:

“Which servers are allowed to send emails for gmail.com?”

Yahoo checks Gmail’s DNS SPF record.

If the sending server is officially authorized:

SPF PASS

Otherwise:

SPF FAIL

This helps prevent fake mail servers from impersonating Gmail.

DKIM Verification

Next, Yahoo verifies the DKIM signature added earlier.

It:

retrieves Gmail’s public key from DNS
validates the signature
checks whether the email was modified

If valid:

DKIM PASS

If tampered:

DKIM FAIL

This ensures email integrity.

DMARC — The Final Decision Maker

Now Yahoo checks:

DMARC

DMARC basically tells receiving servers:

“What should you do if SPF or DKIM fails?”

The policy may say:

allow
quarantine
reject

For example:

v=DMARC1; p=reject

means:

Reject unauthenticated emails.

An example of sample promotional mail:

This is one of the biggest protections against phishing and spoofing today.

Step 9 — Spam and Malware Detection

Even if authentication passes, Yahoo still scans the email for:

suspicious links
malware attachments
phishing keywords
sender reputation
blacklists
spam behavior

Modern email systems even use:

AI-based spam filtering
behavioral analysis
threat intelligence

to detect malicious emails.

Step 10 — Inbox, Spam, or Rejection

Finally, Yahoo decides:

Result	Action
Trusted	Inbox
Suspicious	Spam
Dangerous	Rejected

Only after passing all these checks does the email finally appear inside Tom’s inbox.

But Wait… How Does Tom Read the Email?

Now Tom opens Yahoo Mail.

At this stage:

IMAP or
POP3

comes into the picture.

IMAP vs POP3

IMAP

IMAP keeps emails synced across devices.

So if Tom reads the email on:

laptop
phone
tablet

everything stays synchronized.

POP3

POP3 downloads emails locally to one device.

Older systems used this more often.

Today, IMAP is much more common.

The Most Interesting Part?

All of this happens in just a few seconds.

What feels like a simple “Send” button is actually:

cryptography
DNS infrastructure
server-to-server communication
authentication
threat detection
internet routing
mailbox synchronization

working together silently in the background.

And honestly, once you understand how email works, you’ll never look at your inbox the same way again.

I Finally Understood Elasticsearch After Thinking About Libraries

Diksha Sharma — Fri, 22 May 2026 07:42:15 +0000

Imagine Elasticsearch as a huge digital library system, and Apache Lucene as the high-performance search engine library working behind the scenes. Elasticsearch is built on top of Lucene to provide distributed storage and extremely fast searching capabilities.

A library contains different corners or sections based on genres like cybersecurity, history, fiction, science, etc. Similarly, Elasticsearch contains indexes, where each index stores a collection of similar types of data.

Inside those sections, shelves contain books. In Elasticsearch, indexes contain documents, which are the actual units of stored data.

Now imagine a librarian helping visitors search for books. That librarian is similar to a node in Elasticsearch.

Technically, a node is a system/server running Elasticsearch that:

stores data
processes requests
searches data
communicates with other nodes

Logically:

Library system → Elasticsearch Cluster
Genre section → Index
Book → Document
Librarian/server → Node

Now imagine the library becomes extremely large and suddenly 50 visitors arrive at the same time. If only one librarian is responsible for searching every book requested by all 50 visitors, the process becomes very slow and inefficient.

To solve this problem, the library divides the books into smaller portions and distributes them across multiple librarians. In Elasticsearch, this concept is called sharding.

A shard is a smaller partition of an index. Instead of storing the entire index on one node:

Elasticsearch splits the data into shards
distributes those shards across multiple nodes
allows searches to happen in parallel

This improves:

performance
scalability
speed

Elasticsearch also creates replica shards, which are copies of primary shards. Replica shards help with:

fault tolerance
high availability
faster searching

So, shards can be distributed across multiple nodes, and all nodes work together as part of a cluster.

If one node contains information related to a search request, it communicates with other nodes internally to retrieve or share data. This node-to-node communication happens through the transport interface.

Elasticsearch nodes communicate using two interfaces:

1) HTTP Interface (Port 9200)

Used by:

clients
applications
Postman
curl
Kibana

to interact with Elasticsearch.

When a client sends a request:

the node receiving the request becomes the coordinating node
this node manages and routes the request internally

The coordinating node checks:

which shard contains the required data
which node contains that shard

Then, the request is sent to other nodes through the transport layer using TCP communication on port 9300.

Each node searches its own shards in parallel, and the results are returned back to the coordinating node, which merges the responses and sends the final result back to the client through the HTTP interface on port 9200.

Important:
Any node in Elasticsearch can act as a coordinating node.

2) Transport Interface (Port 9300)

Used internally by Elasticsearch nodes for:

node-to-node communication
shard coordination
replication
cluster communication
remote cluster communication

This communication happens using a high-performance binary TCP protocol.

There is also an important concept called binding address and publish address.

Binding Address

Defines where Elasticsearch listens for incoming traffic.

In simple words:

“Which IP + port should Elasticsearch accept connections on?”

When Elasticsearch starts, it tells the operating system:

“Send incoming traffic for this IP and port to me.”

Publish Address

Defines the address Elasticsearch shares with other nodes and clients.

In simple words:

“Which address should other nodes use to communicate with me?”

Now, how is Elasticsearch optimized for extremely fast searching?

Suppose you search:

"I love cybersecurity"

Elasticsearch does not scan every document one by one.

Instead, when new data is stored, Elasticsearch:

breaks text into smaller tokens/words
creates an inverted index

An inverted index stores mappings like:

Word	Documents
love	Doc1, Doc7
cybersecurity	Doc1, Doc3
elasticsearch	Doc2, Doc5

So instead of checking every document during a search, Elasticsearch directly jumps to the documents containing the required tokens.

This is one of the major reasons why Elasticsearch is extremely fast and scalable even when handling massive amounts of data.

🚨 Understanding Threat Intelligence: From Raw Data to Meaningful Insights

Diksha Sharma — Sat, 11 Apr 2026 16:29:40 +0000

Recently, I tried to understand how cybersecurity teams actually figure out if something is truly dangerous on the internet, and not just rely on one source of information.

What I Built

To explore this, I built a small system where I collected suspicious data (like IP addresses, urls,domains,etc.) from multiple platforms such as:

VirusTotal
AbuseIPDB
AlienVault OTX

Each of these platforms provides its own perspective on whether something is harmful or not.

The Reality of Data: It’s Messy

At first, it seemed simple — just collect the data.

But very quickly, I realized that the data comes in different formats and is quite messy:

Different structures
Nested JSON responses
Inconsistent field names

To handle this, I used a Python script to parse and clean the data:

Extracted relevant fields
Standardized the structure
Made the data usable for further analysis

This step turned out to be one of the most important parts of the entire process.

From Data to Insights

Once everything was structured, I stored it in a system (similar to what security teams use) and created dashboards to analyze it.

This helped me:

Compare what different platforms were saying about the same suspicious item
Identify patterns across multiple sources
Understand which indicators were more likely to be malicious

Key Insight

One source saying something is suspicious doesn’t mean much.

But when multiple trusted sources say the same thing, it becomes much more reliable.

What Changed for Me

This experience really changed how I think:

From:

Just collecting data

To:

Understanding patterns
Connecting multiple data points
Making better, informed decisions

My Thoughts

Cybersecurity is not just about tools — it’s about how you interpret and connect data.

This small practice helped me understand how raw information can be transformed into meaningful insights, which is exactly how modern SOC teams operate.

💬 If you’re exploring cybersecurity, I’d love to hear your thoughts or approaches!