Introduction

Welcome to How the Internet Stays Safe — Course 1 of the IndusForward Skills Series.

Every day you use the internet. You log into your bank and transfer money to a friend. You send an email that arrives on the other side of the world in seconds. You check your SBI balance and the bank sends you private information across a public network. How does any of this happen safely? That is what this course is about.

Who This Book Is For

This book is for students who have just completed the five classroom sessions of Course 1. It is your after-class reading — something to go back to when you want to review a concept, look up a term, or refresh your memory before Course 2.

You do not need a computer science degree to read this. If you can use a smartphone, you have everything you need.

Meet the Characters

You will meet the same people throughout this book that you met in class.

Deepa is a student like you. She asks the questions most people are afraid to ask — “Wait, but what does that actually mean?” When Deepa is confused, she says so. That is a strength, not a weakness.

Rohan is Deepa’s classmate. He likes to go deeper. When the class moves on, Rohan is still thinking about the last question. Look for Rohan Goes Deeper boxes if you want the optional extra detail.

Rajan bhaiya runs a cyber cafe near the college. He is the cautionary tale. One wrong click cost him ₹50,000 and every file on his computer. His story is why this course exists.

Sunita didi works in customer support at a bank. She uses everything in this course every single day on the job. She is the career destination — achievable, real, and well-paying.

How to Use This Book

Each session has three pages:

• Overview — the big idea and what to expect
• Concepts — the full explanation with analogies and examples
• Hands-On — step-by-step exercises you can do on your smartphone right now

Read the Overview first. Then work through Concepts at your own pace. Then do the Hands-On exercises — don’t skip them. The tools are the part that makes everything stick.

At the back, you will find a Glossary (every technical term explained in plain English) and a Further Reading list (where to go next).

What You Will Be Able to Do After This Course

By the time you finish all five sessions, you will be able to:

• Explain how data travels from your phone to a server and back
• Tell the difference between HTTP and HTTPS and why it matters
• Read a digital certificate and understand what it is telling you
• Recognise a phishing attempt and explain why it is dangerous
• Describe how online banking keeps your money safe
• Use tools like SSL Labs, VirusTotal, and ICANN WHOIS like a professional
• Have a real conversation about a career in network security

Let’s begin.

Session 1 — How Data Travels

“What happens when you type google.com and press Enter?”

That was the question your instructor opened with. Most people shrug — the page appears, it is fast, and that is enough. But what happens in the fraction of a second between pressing Enter and seeing results is one of the most precisely engineered processes in modern technology. By the end of this session, you can trace every step of that journey.

What You Will Learn

• What a network actually is, and how devices connect to share data
• What an IP address is and why every device on the internet needs one
• How DNS turns a name like google.com into an address a computer can use
• What ports are and how they direct traffic to the right service on a server
• What server processes are and what software actually answers your request
• What packets are and why data is broken into small chunks before sending
• How packets find their way across the internet (routing)
• What protocols are and the TCP/IP stack — four layers, each with one job

The Big Idea

The internet is a physical, engineered system with rules — not magic. Every transfer of data follows the same basic process: break it into packets, address each packet, route them across hops, and reassemble at the destination. Once you see this, you start understanding why some things fail and how security fits in.

Character Focus This Session

Deepa asks the question on everyone’s mind: “But if data breaks into packets and they all take different paths, how do they arrive in the right order?”

Rohan wants to know what happens at each router hop and whether packets can get lost.

Warm-Up Check

Before reading on, try to answer these without looking anything up. There are no wrong answers — this is just to see what you already know.

1. Your phone connects to the internet through your mobile network. But your laptop connects through Wi-Fi. Does your laptop have a different IP address than your phone on the same Wi-Fi?
2. When you type google.com into a browser, how does it know where to send your request?
3. If you send a 10 MB file to a friend, does it travel as one big chunk or many small pieces?

Keep your answers in mind as you read the Concepts page — you will find out if you were right.

Concepts: Networks, IP, DNS, Packets

What Is a Network?

A network is any group of devices that are connected so they can share data. Your phone, your router at home, and your ISP’s equipment are all part of a network. The internet is just a very large network of networks — millions of them, all connected and talking to each other using agreed-upon rules.

When you log into your bank’s website and transfer money, your browser is sending data to the bank’s server. That data travels through your Wi-Fi or mobile connection, through cables, through data centres, and back again — all in under two seconds.

IP Addresses — The Postal Address of the Internet

Every device that connects to the internet needs an address so data knows where to go. This is called an IP address (Internet Protocol address).

Think of it this way: your home has a postal address. Without it, no parcel can find you. Every device on the internet has an IP address. Without it, no data packet can find you.

IP addresses look like this: 142.250.192.46. Four numbers separated by dots, each between 0 and 255. That particular address belongs to Google.

Public vs. Private IP

Your router has a public IP address — this is the address the rest of the internet sees. All the devices in your home (your phone, laptop, smart TV) share this one public IP.

Inside your home network, each device gets a private IP address — something like 192.168.1.5. Your router keeps track of which private device gets which data from the outside world.

Internet ← Public IP: 103.21.58.10 → Your Router → Private IPs:
                                                      Phone: 192.168.1.2
                                                      Laptop: 192.168.1.3
                                                      Smart TV: 192.168.1.4

DNS — The Internet’s Phone Book

When you type sbi.co.in into your browser, your computer does not know where that is. It only knows addresses — numbers like 203.197.166.60. So how does it find SBI’s server?

This is where DNS (Domain Name System) comes in.

Imagine you know someone as “Priya from Haldwani.” You don’t know her phone number. But you have a phone book that can look up “Priya from Haldwani” and return her number. DNS is exactly that phone book — except it converts domain names into IP addresses, and it works in milliseconds.

How a DNS lookup works, step by step:

1. You type sbi.co.in into your browser
2. Your phone checks its own memory first — “Have I looked this up recently?” (This is called the DNS cache)
3. If not, it asks your ISP’s DNS server: “What is the IP for sbi.co.in?”
4. The ISP’s DNS server may ask other DNS servers higher up the chain
5. Eventually the answer comes back: 203.197.166.60
6. Your browser now connects to that IP address

The whole process takes milliseconds. You never see it happen.

Packets — Breaking Data into Pieces

Here is something surprising: when you send a WhatsApp photo to a friend, that photo does not travel as a single chunk. It gets broken into hundreds or thousands of small pieces called packets.

Why? Because the internet was designed for resilience. If one route is congested, individual packets can take different paths. If one packet gets lost, only that piece needs to be resent — not the whole photo. This is much more efficient than sending one giant chunk that would need to be completely re-sent if anything went wrong.

Pandey sir’s postal analogy: Imagine writing a very long letter — 20 pages. You could put it in one giant envelope and hope it arrives. Or you could number each page, put each in its own envelope addressed to the same destination, and send them separately. Some might go through Lucknow, some through Delhi. All arrive at the destination and are reassembled in order.

Each packet contains:

• A piece of the actual data (the “payload”)
• The destination IP address
• The source IP address
• A sequence number (so packets can be reassembled in order)
• Error-checking information

Routing — Finding the Path

Once data is broken into packets, each packet needs to find its way across the internet. This is done by routers — devices whose entire job is to receive packets and decide where to send them next.

Imagine a packet travelling from your phone in Bhopal to a server in Mumbai. It might pass through:

Your phone → Mobile tower → ISP network → City router →
Backbone router → Maharashtra network → Mumbai data centre

Each router along the way looks at the destination IP address and makes a decision: “Which direction should I send this next?” This is called routing, and there are sophisticated algorithms that make these decisions in microseconds, accounting for congestion and failures on the network.

Protocols — The Agreed Rules

None of this works unless every device agrees on the same rules. These rules are called protocols.

• IP (Internet Protocol) — how packets are addressed and routed
• TCP — how reliable delivery is guaranteed
• HTTP — how browsers and web servers communicate
• HTTPS — encrypted HTTP (the padlock you see in the browser)

Think of protocols like railway track gauge — all trains in India are built to the same track width. Different manufacturers, different trains, but they all run on the same tracks. Protocols are the agreed-upon “gauge” of the internet.

Ports & Server Processes — You Are Talking to Software

Here is something that surprises most people: when you connect to google.com, you are not connecting to a building. You are connecting to a specific piece of software — a server process — running on a computer inside Google’s data centre.

An IP address gets your request to the right machine. But a single machine runs many different services simultaneously. How does your request find the right one? That is what ports are for.

A port is a number — from 0 to 65535 — that identifies a specific service on a machine. Think of an IP address as the address of a large apartment building, and the port as the flat number inside it. The building address gets you to the right building; the flat number gets you to the right door.

The most important ports you will encounter:

When your browser connects to https://google.com, it automatically connects to port 443 — because HTTPS always uses port 443 by convention. You never type the port number; your browser adds it for you.

Sometimes you will see a port number explicitly in a URL, like http://192.168.1.1:8080. The :8080 means “connect to port 8080 on this address.” This is common for internal tools, routers, and test servers that run on non-standard ports.

On the other end of that port sits a server process — software like Nginx or Apache — that is permanently running, listening on port 443, and waiting to answer requests. When your browser connects, this software wakes up, reads your request, and sends back a response.

The TCP/IP Stack — Four Layers, Each with One Job

Everything we have described — your browser making a request, packets being routed, DNS resolving names — fits into a four-layer model called the TCP/IP stack. Each layer handles one part of the job, hands its output to the layer above or below, and does not care about the rest.

┌─────────────────────────────────────────────┐
│  Application Layer  (HTTP, HTTPS, DNS)       │
│  "What are we saying?"                       │
├─────────────────────────────────────────────┤
│  Transport Layer    (TCP, ports)             │
│  "How do we deliver it reliably?"            │
├─────────────────────────────────────────────┤
│  Network Layer      (IP addresses, routing)  │
│  "Which path do we take?"                   │
├─────────────────────────────────────────────┤
│  Physical Layer     (cables, Wi-Fi, 4G)      │
│  "How do we move bits from A to B?"         │
└─────────────────────────────────────────────┘

Application Layer — This is where your browser lives. It constructs an HTTP or HTTPS request: “GET the homepage of google.com.” It does not know or care how the request travels.

Transport Layer — TCP takes the request, breaks it into packets, assigns port numbers, and guarantees that every packet arrives and arrives in order. This is the layer that handles reliability.

Network Layer — IP takes each packet and handles routing — figuring out the path from your device’s IP address to Google’s IP address, hop by hop across the internet.

Physical Layer — At the bottom, bits become electrical signals on cables, radio waves on Wi-Fi, or light pulses through fibre optics. This layer just moves energy from one place to another.

When your response comes back, it travels up the stack in reverse: physical signals become bits, bits become packets, packets become a complete message, and your browser renders the page.

What Happens When You Type google.com

Now you can answer the session’s opening question. When you type google.com and press Enter, four things happen in sequence:

Step 1 — DNS Resolution
  Your browser asks: "What is the IP address of google.com?"
  DNS resolver answers: "142.250.192.46"

Step 2 — TCP Connection to Port 443
  Your browser connects to 142.250.192.46:443
  TCP establishes a reliable connection
  (Port 443 because you typed https://)

Step 3 — Server Process Answers
  Nginx (or a similar server) is listening on port 443
  It reads your request: "GET the homepage"
  It sends back the HTML, CSS, images

Step 4 — Browser Renders
  Your browser assembles the response
  Page appears on screen

Four steps. Less than half a second. Every time.

The same sequence happens when you open a banking app, send a WhatsApp message, or stream a video. The application changes. The four steps do not.

Hands-On: See the Internet in Action

These exercises use free tools that work on any smartphone or laptop browser. You do not need to install anything — except for Exercise 1, which uses a built-in command that every phone and laptop already has.

Exercise 1 — Run Your First DNS Lookup

Before You Start: DNS translates names to IP addresses. This exercise lets you run the lookup yourself, from your own device, the same way your browser does it every time you load a page.

On a laptop (Windows or Mac):

1. Open Terminal (Mac) or Command Prompt (Windows — press Windows key, type cmd, press Enter)
2. Type the following and press Enter:

   nslookup google.com
   

3. You will see output like:

   Server:   192.168.1.1
   Address:  192.168.1.1#53
   
   Non-authoritative answer:
   Name:    google.com
   Address: 142.250.192.46
   

4. Note the IP address returned
5. Now try with other domains — type each and press Enter:

   nslookup sbi.co.in
   nslookup gmail.com
   nslookup irctc.co.in
   

On Android:

• Download a free terminal app (like “Termux” from the Play Store) and run nslookup google.com
• Or use the dnschecker.org website from the next step as an alternative

What You’re Seeing

The “Server” line is your local DNS resolver — usually your router or ISP’s DNS server. The “Address” line is the IP address that google.com maps to. Notice that gmail.com and google.com may return the same or different IPs — Google has many servers. sbi.co.in returns a smaller set of IPs because SBI’s infrastructure is more centralised.

The key insight: If DNS fails, nothing works. Your browser cannot connect to anything by name. Every website, every app, every service starts here.

Discussion Prompt: Run nslookup google.com twice. Do you get the same IP both times? Google may return different IPs for the same domain name because they have thousands of servers worldwide and route you to the nearest one.

Exercise 2 — Find Your Public IP Address

Before You Start: Your phone or laptop has a private IP on your local network. But the internet sees a different address — the public IP of your router. This exercise shows you the public one.

1. Open your phone’s browser (Chrome, Firefox, or Safari)
2. Go to toolbox.googleapps.com
3. In the top menu, tap Check Header — or simply search “what is my ip” in any search engine
4. Note the IP address shown
5. Now switch from mobile data to Wi-Fi (or vice versa) and check again

What You’re Seeing

The two IP addresses are different because your mobile network and your home Wi-Fi connect to the internet through different routers, each with its own public IP. The internet sees your traffic coming from that router’s IP, not your device’s private IP.

Discussion Prompt: If two phones on the same Wi-Fi network both visit google.com, which IP does Google see? The router’s public IP — the same one for both phones.

Exercise 3 — Watch Packets Travel (Traceroute)

Before You Start: A traceroute shows you every router your data passes through on its way to a destination. Each router is one “hop.” This is the TCP/IP stack’s Network layer made visible.

1. Open your browser and go to ping.eu
2. In the top menu, tap Traceroute
3. In the hostname field, type google.com and tap Go
4. Watch the results load — each numbered line is one hop
5. Look at the response times in milliseconds (ms) for each hop
6. Try the same with irctc.co.in — notice where the path diverges

What You’re Seeing

The hops with low response times (5–20 ms) are nearby routers — probably within your city or state. Hops with higher response times (50–150 ms) are farther away — possibly in another city or country. If a hop shows * * *, that router is configured to not respond to traceroute probes (common on backbone networks).

Discussion Prompt: When you do a traceroute from your phone in India to google.com, do the packets ever leave India? How can you tell from the response times?

Tying It Together

You have now seen the internet’s fundamental mechanisms in action:

• DNS — names get translated to addresses (Exercise 1). If this fails, nothing works.
• IP addresses — every device and every server has one (Exercise 2)
• Routing — packets hop through multiple routers to reach their destination (Exercise 3)

Next session, we will ask the question that follows naturally from all of this: if your data is travelling through all those routers and networks — many of which you do not control — how do you keep it private and secure?

Session 2 — Encryption & TLS

Deepa opens her laptop at a college café. She types her email address and password into a login form and presses Enter. Her credentials travel from her laptop — through the café’s Wi-Fi router, through the ISP’s network, through several backbone routers — to a server, possibly in another city.

Every router along that path handles her data. None of them are run by her. None of them are her bank. What stops someone on that path from simply reading what she typed?

The answer is encryption. This session explains how encryption works, why it is necessary, and how your browser uses it automatically on every HTTPS connection.

What You Will Learn

• Why plain HTTP is a problem — what anyone on the path can see
• What encryption is and how it keeps data private
• The difference between symmetric and asymmetric encryption
• What session cookies are and why encrypting them matters
• What HTTPS is and how it protects your browser sessions
• How the TLS handshake works (in plain English, no maths)

The Big Idea

Encryption is the lock on the internet’s sealed letters. Without it, every piece of data you send travels like a postcard — anyone who handles it can read it. With encryption, data travels like a letter in a sealed envelope: the contents are private, tamper-evident, and only readable by the intended recipient.

The internet is a shared public infrastructure. Your data passes through equipment you do not own, operated by people you do not know. Encryption is the engineering solution to that reality.

Character Focus This Session

Deepa asks the question everyone has: “If encryption is so important, why doesn’t every website use it?”

Rohan wants to understand the actual maths of public-key cryptography (the Rohan Goes Deeper boxes are especially relevant this session).

Sunita didi has seen what happens in corporate networks when someone accesses sensitive data over an unencrypted connection — she uses this session’s concepts every day.

Warm-Up Check

Before reading on:

1. Have you ever seen the padlock icon in your browser’s address bar? What do you think it means?
2. If you send a WhatsApp message, can WhatsApp read it? Why or why not?
3. What is the difference between a password and encryption?

Keep these in mind as you read — the answers will become clear.

Concepts: Encryption & TLS

Why Plain HTTP Is a Problem

When Deepa logs in at the café, her request travels through several networks before reaching the server. On an unencrypted HTTP connection, every device on that path — every router, every switch, every device on the same Wi-Fi network — can read the contents of her request in plain text.

This is not a theoretical risk. It is how HTTP was designed — as an open, readable protocol. The data flowing through it looks like this to any device on the path:

POST /login HTTP/1.1
Host: example.com

username=deepa@example.com&password=mypassword123

Anyone with access to the network traffic can read that. Not just the username and password — everything:

• The exact page she is viewing
• The content of every form she fills in
• Every article she reads
• Every search she makes
• Her session cookies

The postcard analogy: sending data over HTTP is like writing a message on a postcard and dropping it in a letterbox. Every postal worker who handles it can read the front and back. The data arrives at its destination — but it was readable the entire journey.

The Answer: Encryption

Encryption is the transformation of readable data (called plaintext) into unreadable scrambled data (called ciphertext) that can only be unscrambled by someone with the correct key.

When Deepa’s browser sends data over HTTPS, the data is encrypted before it leaves her device. Every router on the path sees only ciphertext — scrambled nonsense. Only the server she is connecting to holds the key to decrypt it.

The sealed letter: HTTPS is like putting that postcard inside a locked box. The postal workers still handle it. They still deliver it. But they cannot read what is inside.

Symmetric Encryption — One Key for Everything

The simplest form of encryption uses a single key to both encrypt and decrypt data.

Think of a padlock with one key. You lock the box with the key, send it to your friend, and she uses the same key to open it. This is symmetric encryption — both sides use the same secret key.

Plaintext → [ Encrypt with Key ] → Ciphertext → [ Decrypt with Key ] → Plaintext

This is fast and efficient, which is why it is used for the bulk of encrypted data transfer. But it has a problem: how do you securely share the key in the first place? You cannot send the key over the internet unencrypted — that defeats the purpose. This is called the key distribution problem.

Asymmetric Encryption — Two Keys

Asymmetric encryption solves the key distribution problem with a clever idea: instead of one key, use two. A public key and a private key. They are mathematically linked but different.

The mailbox analogy works perfectly here:

• Your public key is like a slot in your door. Anyone can push a letter through it. You can share your public key with the whole world.
• Your private key is like the key to your door. Only you have it. Only you can open the door and read the letters inside.

Anyone  → [ Encrypt with Public Key ] → Ciphertext
                                             ↓
                              [ Decrypt with Private Key ] → Plaintext (only you)

If someone wants to send you an encrypted message, they use your public key to encrypt it. Once encrypted with your public key, it can only be decrypted with your private key — which only you have.

This solves the key distribution problem. You can share your public key openly. There is no secret to distribute.

TLS and HTTPS — Encryption in the Browser

TLS (Transport Layer Security) is the protocol that encrypts web traffic. When you see https:// at the start of a URL, or a padlock in your browser’s address bar, TLS is running underneath.

HTTPS is simply HTTP (the web protocol) running over TLS. It is the standard for all websites that handle any sensitive information — and increasingly for all websites, period.

The TLS Handshake (In Plain English)

When your browser connects to a secure site, a brief but important negotiation happens before any data is exchanged. This is the TLS handshake.

Think of it as two strangers agreeing on a secret language before having a private conversation in a public place:

Browser                                     Server
   │                                           │
   │──── "Hello, I support TLS 1.3" ─────────►│
   │                                           │
   │◄─── Certificate + Public Key ────────────│
   │                                           │
   │  (Browser verifies certificate —          │
   │   see Session 3 for how)                  │
   │                                           │
   │──── Encrypted session key ──────────────►│
   │     (using server's public key)           │
   │                                           │
   │◄══════ All data now encrypted ═══════════►│
   │         (using shared session key)        │

1. Your browser says hello — “I want a secure connection. Here are the encryption methods I support.”
2. The server says hello back — “Great. Here is my certificate, proving who I am. Here is my public key.”
3. Your browser verifies the certificate — “Let me check that this certificate is legitimate.” (We cover how in Session 3.)
4. They agree on a session key — Using asymmetric encryption, they securely exchange a temporary symmetric key that will be used for the rest of the conversation. Asymmetric encryption to share a symmetric key — this solves the key distribution problem elegantly.
5. Everything after this is encrypted — All data flows encrypted with the session key. The handshake is complete.

The whole handshake takes milliseconds. You never see it. But every time you connect to a secure site, this happens.

Putting It Together

Encryption does not exist to hide things from governments or to enable criminals. It exists because the internet is a public infrastructure — packets travel through routers you do not own, networks you do not control, and infrastructure operated by strangers. Without encryption, every sensitive thing you do online — bank transfers, messages, health queries, logins — would be readable by anyone with the right position in the network.

The café Wi-Fi story from the opening: with HTTP, every router on the path can read Deepa’s credentials. With HTTPS and TLS, they see only ciphertext. The physical path is the same. The privacy is completely different.

Hands-On: Check a Site’s Security

These exercises teach you to read security signals that your browser shows you every day — signals most people ignore.

Exercise 1 — Inspect a Bank’s HTTPS Connection

Before You Start: Every HTTPS connection uses a certificate that identifies the server. Your browser checks this certificate every time you connect. This exercise shows you how to read what your browser already knows.

1. Open Chrome or Firefox on your phone
2. Go to https://sbi.co.in
3. Look at the address bar — confirm the padlock icon is visible
4. Tap the padlock icon (in Chrome, it may appear as a small lock or a circle with an “i”)
5. In the popup, look for “Connection is secure” or similar wording
6. Tap “Certificate” or “Certificate is valid” to open the certificate details
7. Note the following:
   • Issued to: — what name appears here?
   • Issued by: — which Certificate Authority signed this?
   • Valid from / Valid until: — is the certificate currently valid?

What You’re Seeing

Your browser has verified that:

• The server presented a certificate
• The certificate was issued to sbi.co.in (the site you intended to visit)
• The certificate was signed by a trusted Certificate Authority
• The certificate has not expired

All of this happened automatically, before you loaded a single byte of the page. We will understand exactly how that verification works in Session 3.

Discussion Prompt: What would happen if someone registered the domain sbi.co.in.customer-support.xyz and got an HTTPS certificate for it? Would the padlock appear? Would the average user notice?

Exercise 2 — Find a Site Without HTTPS

Before You Start: HTTP sites (without encryption) are less common than they used to be, but they still exist. Your browser has ways of warning you about them.

1. Open your browser and try to visit http://info.cern.ch — this is the website of the first web server ever (hosted by CERN, the physics lab). It still runs on HTTP
2. Look at the address bar — Chrome shows “Not secure” or a broken padlock; Firefox shows a lock with a line through it
3. Now try visiting http://neverssl.com — a site specifically designed to always be HTTP (useful for testing)
4. In Chrome, open the address bar and type http://google.com — watch it automatically redirect to https://google.com

What You’re Seeing

info.cern.ch and neverssl.com serve content over plain HTTP. Anyone on your network can see exactly what you are reading. Google’s automatic redirect from HTTP to HTTPS is called HSTS (HTTP Strict Transport Security) — a mechanism that tells your browser “always use HTTPS for this domain, even if someone types http://”.

Discussion Prompt: If you are connected to public Wi-Fi at a café and you visit an HTTP site, what can the café owner potentially see?

Exercise 3 — Test a Site’s TLS Quality

Before You Start: Not all HTTPS connections are equally secure. The SSL Labs test tool checks exactly what encryption settings a server uses and gives it a grade.

1. Open your browser and go to ssllabs.com/ssltest
2. In the hostname field, type sbi.co.in and tap Submit
3. Wait for the test to complete (it takes about 60–90 seconds)
4. Read the grade — A, A+, B, C, etc.
5. Scroll down to see:
   • Certificate section — who issued it, expiry date
   • Protocol Support — which TLS versions are supported
   • Cipher Strength — what encryption algorithms are offered
6. Now run the test on badssl.com — it will show a failing grade to demonstrate what a poorly configured server looks like

What You’re Seeing

SSL Labs rates servers based on their TLS configuration. An A+ means the server uses only modern, strong encryption settings and has set up additional security features like HSTS. A lower grade means the server supports older, weaker encryption that an attacker could potentially exploit.

Discussion Prompt: If a bank’s site gets a B grade on SSL Labs, is that acceptable? What does it mean for users?

Tying It Together

You now know how to read the security signals your browser shows every time you connect to a website:

• The padlock = encrypted connection to this server
• The domain name = the actual site you are on (check it carefully)
• The certificate details = who vouches for this server’s identity
• SSL Labs grade = how well the server is configured

These are not abstract concepts — they are tools professionals use every day. Sunita didi checks exactly these things when a customer calls her saying a site “looks suspicious.”

In Session 3, we go deeper into the certificate system — who issues them, how they are verified, and what happens when the system is abused.

Session 3 — Hashing, Digital Signatures & Certificates

Rohan is working on a project document and wants to send it to his professor. He emails it. The professor receives it — but how does the professor know that the document arrived exactly as Rohan sent it? How does she know no one changed it in transit? And how does she know it actually came from Rohan, not someone pretending to be him?

These three questions — integrity, authenticity, non-repudiation — are what this session answers. And the answer begins with something surprisingly simple: a hash.

What You Will Learn

• What a hash function is and why it creates a unique fingerprint for any data
• The four properties of a good hash function (SHA-256 in action)
• How digital signatures work — the 3-step sign process and 3-step verify process
• What a digital certificate is and what information it contains
• What Certificate Authorities (CAs) are and why we trust them
• How the chain of trust works: Root CA → Intermediate CA → Site certificate
• How your browser verifies a certificate in milliseconds
• What happens when certificate verification fails (the error pages you’ve seen)

The Big Idea

Hashing is the foundation of digital trust. Before a CA can sign a certificate, before your browser can verify an identity, before a bank can store your password safely — there is a hash function at the core. Understand hashing and the rest of this session becomes natural.

Character Focus This Session

Deepa starts by asking: “What’s a hash? Why do we need it?” — and her question drives the whole session.

Rohan goes deep on how digital signatures work mathematically and what “non-repudiation” means legally.

Sunita didi has encountered certificates in her IT work and understands exactly which fields matter when you are investigating a suspicious site.

Warm-Up Check

Before reading on:

1. If you change one word in a 10-page document, how much of the document has changed? How would you prove to someone that the document they received is identical to the one you sent?
2. You have probably seen a browser warning saying “Your connection is not private.” What did you do?
3. Who decides which Certificate Authorities your phone trusts?

These questions are exactly what this session answers.

Concepts: Hashing, Digital Signatures & Certificates

Hashing — A Fingerprint for Data

Deepa is curious. “What exactly is a hash? Rohan keeps mentioning it.”

A hash function takes any input — a word, a document, an entire video file — and produces a fixed-length output called a hash (or digest). The output is always the same length, regardless of how long the input is.

Think of it like a fingerprint. Every person has a unique fingerprint. You can take someone’s fingerprint without knowing anything else about them. And if you compare two fingerprints, you know instantly whether they belong to the same person.

A hash function does the same for data.

SHA-256 in action:

SHA-256 (Secure Hash Algorithm 256-bit) is the hash function used in TLS certificates, digital signatures, Bitcoin, and many other systems. Let us look at what it produces:

Notice:

• Hello (capital H) and hello (lowercase h) produce completely different hashes — even though only one character changed
• All three hashes are exactly 64 characters long, regardless of input length
• There is no way to look at the hash and reconstruct the original text

This is the avalanche effect — a tiny change in the input causes a completely different output. One character different → completely different hash.

The Four Properties of a Good Hash Function

A hash function used in security must have four properties:

1. One-way — You can compute the hash from the input, but you cannot compute the input from the hash. Given 2cf24dba..., you cannot figure out that the input was hello. This is why banks store the hash of your password, not the password itself. If their database is stolen, the attacker gets hashes, not passwords.

2. Deterministic — The same input always produces the same output. hello will always hash to 2cf24dba... — on any computer, anywhere, any time. This is essential for verification: Deepa hashes a document and gets a value; her professor can hash the received document and get the same value if it is unchanged.

3. Avalanche effect — A small change in the input produces a completely different output. Change one bit and the entire hash changes. This makes it impossible to modify a document slightly and hope the hash stays the same.

4. Fixed length — SHA-256 always produces a 256-bit (64 character) output. Hash a single letter or hash a 4GB video file — the output is the same length. This makes hashes practical for comparison and storage.

Digital Signatures — Proving Who Sent It

Now that we understand hashing, digital signatures become straightforward. A digital signature answers three questions at once:

• Did this come from who it claims to come from? (Authentication)
• Has it been modified since it was signed? (Integrity)
• Can the signer deny having signed it? (Non-repudiation: they cannot)

How Signing Works (3 Steps)

Rohan wants to sign his project document before sending it to his professor.

Step 1 — Hash the document
  document.pdf → SHA-256 → "a3f82c..."  (the document's fingerprint)

Step 2 — Encrypt the hash with Rohan's private key
  "a3f82c..." + Rohan's Private Key → Digital Signature

Step 3 — Attach the signature to the document
  Send: document.pdf + Digital Signature together

The signature is just an encrypted hash. It proves two things: it came from whoever holds that private key (Rohan), and it was computed from this exact version of the document.

How Verification Works (3 Steps)

The professor receives the document and the signature. She wants to verify it is genuinely from Rohan and has not been changed.

Step 1 — Hash the received document
  received_document.pdf → SHA-256 → "a3f82c..."

Step 2 — Decrypt the signature with Rohan's public key
  Digital Signature + Rohan's Public Key → "a3f82c..."

Step 3 — Compare the two hashes
  "a3f82c..." == "a3f82c..." → Signature is VALID ✓

If the document was changed after signing, the hash in Step 1 would be different from the hash in Step 2, and the signature check would fail.

If the signature was not created with Rohan’s private key, decrypting it with Rohan’s public key would produce nonsense — and the comparison would fail.

Three Guarantees

Digital Certificates — Linking a Public Key to an Identity

Here is the problem: Rohan’s professor has his public key. But how did she get it? How does she know that key actually belongs to Rohan and not someone impersonating him?

This is exactly the problem that digital certificates solve on the internet.

A digital certificate is an electronic document that links a public key to an identity. It says, in effect: “This public key belongs to sbi.co.in, and we — DigiCert — vouch for that.”

Think of it like a government-issued ID card. Your Aadhaar card says “This photo and biometrics belong to this person, and the Government of India vouches for it.” A digital certificate says “This public key belongs to this domain, and this Certificate Authority vouches for it.”

What a Real Certificate Contains

Here is what the certificate for sbi.co.in actually contains (simplified from a real certificate):

The Thumbprint (also called Fingerprint) is the SHA-256 hash of the entire certificate. If any field in the certificate is changed — by even one character — the thumbprint changes completely. This makes tampering detectable.

Certificate Authorities — The Internet’s Notary System

A Certificate Authority (CA) is an organisation that verifies identities and issues certificates. When sbi.co.in applies for a certificate, the CA checks that they actually own the domain. Once satisfied, the CA issues a certificate with their digital signature on it — exactly like the signing process Rohan used, but now it is the CA signing the certificate.

The notary analogy: when you sign a property document, you need a notary public to stamp it. The notary checks your identity and then puts their official stamp on the document. Anyone who sees the stamp knows the notary vouched for the signer. CAs are the internet’s notaries.

Well-known CAs include DigiCert, Sectigo, and GlobalSign (commercial, paid), and Let’s Encrypt (free, automated — used by millions of websites including smaller Indian businesses and NGOs).

The Chain of Trust

No browser trusts individual website certificates directly. Instead, there is a hierarchy:

Root CA (e.g., DigiCert Global Root G2)
  └── Intermediate CA (e.g., DigiCert TLS RSA SHA256 2020 CA1)
          └── Site Certificate (e.g., sbi.co.in)

Root CAs are the top-level authorities. Their certificates come pre-installed in your device’s operating system — Apple, Google, Microsoft, and Mozilla each maintain a list of Root CAs they trust. Getting onto this list requires passing rigorous audits. There are fewer than 200 Root CAs trusted globally.

Intermediate CAs sit between Root CAs and individual websites. Root CAs issue certificates to Intermediate CAs, vouching for them. Intermediate CAs then issue the certificates that websites use. This structure protects Root CA keys — if a Root CA key were ever compromised, it would be catastrophic. Keeping Root CA keys offline and rarely used reduces that risk.

Site Certificates are what individual websites hold. sbi.co.in has a certificate issued by an Intermediate CA.

When your browser connects to sbi.co.in, it:

1. Receives the site certificate and the intermediate certificate
2. Checks that the intermediate certificate is signed by a Root CA it already trusts
3. Checks that the site certificate is signed by that intermediate CA
4. Verifies the site certificate is for the domain you are visiting (sbi.co.in)
5. Verifies the certificate has not expired
6. Verifies the certificate has not been revoked

All of this happens before the page loads.

What Happens When Verification Fails?

You have probably seen browser certificate warnings. Now you know what they mean:

• “Certificate has expired” — the validity period on the certificate is in the past. The site owner forgot to renew it. This does not necessarily mean the site is malicious, but you cannot verify its identity today.
• “Certificate is not valid for this domain” — the certificate was issued for sbi.co.in but you are connecting to sbi.co.in.update.xyz. The domain does not match.
• “Certificate authority is not trusted” — the certificate was not signed by any CA in your device’s trust list. This could be a self-signed certificate (no CA vouched for it).
• “Certificate has been revoked” — the CA has explicitly cancelled this certificate, usually because the private key was compromised.

These are not suggestions. Your browser treats them as hard blocks on banking and high-security sites.

PKI — Public Key Infrastructure

The whole system we have described — certificate authorities, trust chains, public and private keys, digital signatures, and hash functions — is called PKI (Public Key Infrastructure). It is the backbone of internet security.

PKI is not one company or one piece of software. It is a system of policies, organisations, software, and hardware that together make secure communication possible. When you use HTTPS, you are relying on PKI. When you use WhatsApp’s end-to-end encryption, you are relying on PKI. When you use a Digital Signature Certificate to sign a tax document — PKI.

Putting It Together: Deepa Opens Her Banking App

When Deepa opens her SBI app:

1. The app connects to SBI’s API server
2. The server presents its certificate: “I am api.sbi.co.in, here is my certificate signed by DigiCert”
3. The app hashes the certificate and checks the CA’s digital signature to verify the certificate has not been tampered with
4. The app walks the chain of trust: DigiCert → Intermediate → api.sbi.co.in
5. The app verifies DigiCert is in its trusted root list (pre-installed on her Android phone by Google)
6. The app verifies the domain name matches
7. The app verifies the certificate has not expired
8. The TLS handshake completes — an encrypted session begins
9. Deepa sees her balance

If any step fails — if the chain is broken, the domain does not match, or the certificate has expired — the app would refuse to connect. Not warn. Refuse.

Hands-On: Hashing & Real Certificates

These exercises take you inside the hashing and certificate system — the same foundations your phone uses automatically every time you open a banking app.

Exercise 0 — Watch the Avalanche Effect Live

Before You Start: The avalanche effect means that a tiny change in input produces a completely different hash output. This exercise makes that concrete.

1. Open your phone’s browser and go to sha256.online
2. In the text input box, type: Hello
3. Click Hash (or the equivalent button)
4. Copy or note the hash output — a 64-character string
5. Now change the H to lowercase: hello
6. Click Hash again
7. Compare the two outputs

What You’re Seeing

Two inputs that differ by a single character — the capitalisation of one letter — produce completely different 64-character hashes. There is no similarity between them. This is the avalanche effect.

Now try this:

1. Type a full sentence: The quick brown fox
2. Hash it and note the output
3. Add a single period: The quick brown fox.
4. Hash again and compare

The addition of one character — a period — produces a completely different hash. This is why hashing is used to detect any modification to a document, a file, or a certificate. Even one changed character is instantly visible.

Discussion Prompt: Banks store the SHA-256 hash of your password, not the password itself. When you log in, the bank hashes what you typed and compares it to the stored hash. If they match, you are in. Why is this safer than storing the password directly? (Hint: think about what happens if the bank’s database is stolen.)

Exercise 1 — Read a Bank’s Certificate Chain

Before You Start: Every HTTPS site has a certificate chain going from the site’s certificate up to a Root CA. This exercise shows you how to read it.

1. Open Chrome on your phone and go to https://hdfcbank.com
2. Tap the padlock icon in the address bar
3. Tap “Certificate” or “Certificate is valid”
4. You are now looking at the site’s certificate. Note:
   • Subject / Common Name — what domain is this certificate for?
   • Issuer — which Intermediate CA issued this?
   • Validity — when does it expire?
5. Look for a way to navigate up the chain. In Chrome, you may see tabs or an “Issued by” link. In Firefox on desktop, you can see the full chain in Certificate Viewer
6. If your browser shows the chain, tap through to the Intermediate CA and then the Root CA

What You’re Seeing

You have just walked the same chain your browser walks every time you visit this site. The Root CA certificate at the top is embedded in your Android or iOS device, pre-installed by Google or Apple. Everything below it depends on that pre-established trust.

Compare what you see with the certificate fields table from the Concepts page: Subject, Issuer, Valid From/To, Public Key, Signature Algorithm, Thumbprint. All of these are real values in the real certificate you are reading.

Discussion Prompt: The HDFC Bank certificate expires on a specific date. What happens to every customer who tries to use net banking if the bank’s IT team forgets to renew it?

Exercise 2 — See What a Certificate Error Looks Like

Before You Start: badssl.com is a test site maintained specifically to demonstrate different certificate error states. It is safe to visit — these errors are intentional.

1. Open your browser and go to https://expired.badssl.com
2. Read the error message carefully — what does your browser say? Note the exact error code (it usually starts with NET::ERR_CERT_)
3. Look for the “Advanced” option and tap it — read the technical explanation your browser provides
4. Do not proceed to the site — go back instead
5. Go back and visit https://self-signed.badssl.com
6. Read this error message — how is it different from the expired certificate error?
7. Now visit https://wrong.host.badssl.com — what does this error mean?

What You’re Seeing

Each error represents a different failure in the certificate verification chain:

Notice that your browser does not just warn you — for these errors, it makes you go through extra steps to proceed at all. That is intentional. These are hard blocks, not suggestions.

Discussion Prompt: Which of these three certificate errors would a site accidentally have if its IT team simply forgot to renew the certificate? Which error is the most deliberate — most likely chosen intentionally?

Exercise 3 — Analyse a Certificate with SSL Labs

Before You Start: SSL Labs runs a detailed technical analysis of a site’s certificate and TLS configuration. This is the tool that security professionals use to audit sites.

1. Go to ssllabs.com/ssltest on your phone’s browser
2. In the hostname field, type sbi.co.in and tap Submit
3. Wait for the analysis to complete (60–90 seconds)
4. Look at the overall grade (A, A+, B, etc.)
5. Scroll to the Certificate section and find:
   • Subject — the domain name
   • Fingerprint — the SHA-256 hash (thumbprint) of this specific certificate
   • Issuer — the CA that signed it
   • Signature algorithm — how the signature was created
   • Key — what type and size is the public key?
6. Scroll to Protocol Details and find the HSTS field — note whether SBI uses it (we cover HSTS in Session 4)

What You’re Seeing

The certificate fingerprint is a SHA-256 hash — the exact same hash function you used in Exercise 0. If the certificate changes (even by one character), the fingerprint changes completely. You are seeing the avalanche effect applied to a real production certificate.

Discussion Prompt: SSL Labs shows the certificate’s expiry date. Should SBI be renewing this certificate automatically or manually? What are the risks of each approach?

Tying It Together

You now know the three foundations of digital trust — and you have seen all three in action:

• Hashing — creates a unique fingerprint for any data; changing one character changes everything (Exercise 0)
• Certificate chains — trust flows from Root CA to Intermediate to site; you walked the chain yourself (Exercise 1)
• Certificate errors — each error type represents a specific failure in the verification process (Exercise 2)
• Real-world analysis — SSL Labs shows the same fields we studied in the concepts page, on a real production site (Exercise 3)

Every time you do online banking, your phone does all of this automatically. Now you understand what it is doing and why. In Session 4, we look at the browser itself — not as software that displays pages, but as a security system enforcing policies on every connection you make.

Session 4 — Browsers as Security Infrastructure

Most people think of a browser as software that displays web pages. Open a link, see a page. That is the whole story.

It is not the whole story.

Your browser is enforcing a complex set of security policies on every single request — before the page loads, while it loads, and after. It validates certificates. It remembers which sites should only be reached over HTTPS and refuses any other connection. It blocks resources that mix encrypted and unencrypted content. It maintains a list of trusted authorities that was compiled by Apple, Google, Microsoft, and Mozilla.

You do not see any of this. It happens automatically. But understanding it changes how you think about what a browser actually does.

What You Will Learn

• What browser security policies are and how they run automatically on every request
• What the Certificate Store is — and which authorities your device already trusts
• What HTTPS guarantees and what it does not guarantee
• Why HTTPS alone is not enough — what you still need for real security
• What your browser does, step by step, when you visit a banking site
• How to think through network problems in layers

The Big Idea

Your browser is the last line of verification between you and the internet. Protocols are designed. Certificates are issued. But it is your browser that actually checks the certificate, enforces HTTPS, blocks mixed content, and shows you the error page when something is wrong. Understanding what your browser does is understanding where security is actually implemented.

Character Focus This Session

Sunita didi is working in IT support at a bank. She uses the concepts from this session every day — not to defend against attacks, but to diagnose connectivity issues, explain browser warnings to users, and verify that the sites she configures are correctly secured.

Deepa is surprised: “I thought the browser just showed pages. It’s doing all this?”

Rohan goes deep on HSTS and the certificate store — the two mechanisms most people have never heard of but that silently protect every connection they make.

Warm-Up Check

Before reading on:

1. You visit a site and your browser shows a red warning: “Your connection is not private.” What is your browser actually telling you?
2. You type sbi.co.in without the https://. Does your browser use HTTP or HTTPS? How would it know which to use?
3. Who put the list of trusted Certificate Authorities on your phone?

These questions have specific, technical answers — and this session gives them to you.

Concepts: Browser Security, Certificate Store & Troubleshooting

Your Browser Is a Security System

Deepa had assumed her browser’s job was to display pages. After this session, she will see it differently.

Every time you make an HTTPS request, your browser runs four security mechanisms automatically — before you see a single pixel of the page:

You type a URL and press Enter
         ↓
1. Certificate Validation
   Does this server have a valid cert from a trusted CA?
   If no → hard block, error page shown
         ↓
2. HSTS Check
   Has this site previously said "always use HTTPS"?
   If yes → browser refuses to downgrade to HTTP
         ↓
3. Mixed Content Check
   Does an HTTPS page try to load any HTTP resources?
   If yes → those resources are blocked
         ↓
4. Security Warning UI
   If anything failed in steps 1–3 → specific error code shown
   These are not suggestions — they are hard blocks
         ↓
Page loads (or does not)

Certificate Validation — Before the TLS handshake completes, your browser walks the certificate chain (as we covered in Session 3). It checks that the chain leads to a trusted Root CA, that the certificate has not expired, that the domain matches, and that the certificate has not been revoked. This runs on every HTTPS connection, every time.

HSTS Enforcement (HTTP Strict Transport Security) — If you have ever visited a site that uses HSTS, your browser saved a note: “This site will only work over HTTPS. Never try HTTP.” When you visit that site again, your browser does not even attempt an HTTP connection. It starts with HTTPS directly. This protects against a class of attack where a network-level observer tries to downgrade your connection to unencrypted HTTP.

Mixed Content Blocking — An HTTPS page that loads one resource (an image, a script, a font) over plain HTTP has a problem: that one unencrypted resource could be intercepted and replaced by anyone on the network path. Your browser blocks it. This is why web developers sometimes see console warnings about “mixed content” — they have accidentally linked to an HTTP resource from an HTTPS page.

Security Warning UI — The error codes you see are not generic warnings. Each one means something specific:

• NET::ERR_CERT_DATE_INVALID — certificate expired
• NET::ERR_CERT_AUTHORITY_INVALID — issuer not in the trust list
• NET::ERR_CERT_COMMON_NAME_INVALID — domain name mismatch
• NET::ERR_CERT_REVOKED — certificate explicitly revoked

These are hard blocks. Your browser is not asking for your opinion. It is refusing to connect.

The Browser Certificate Store

Here is a question Deepa asked: “Who decided that DigiCert is trustworthy?”

The answer is: Apple, Google, Microsoft, and Mozilla. Each of them maintains a certificate store — a list of Root CA certificates that are pre-installed on devices and browsers that ship on their platforms.

When you buy a new Android phone, it comes with approximately 150 Root CA certificates already installed. These are the authorities that Google has audited and approved. Your phone trusts any certificate whose chain traces back to one of these pre-installed roots.

Your Android phone's certificate store (pre-installed by Google)
  ├── DigiCert Global Root G2
  ├── DigiCert Global Root CA
  ├── Let's Encrypt ISRG Root X1
  ├── Sectigo (formerly Comodo)
  ├── GlobalSign Root CA
  ├── Amazon Root CA 1
  ├── ... (~150 total)

This is why your phone trusts sbi.co.in — not because someone told it SBI is trustworthy, but because SBI’s certificate was issued by DigiCert, and DigiCert is in the pre-installed trust store that Google put on your phone.

Viewing the Certificate Store on Your Device

Android: Settings → Security → Encryption & Credentials → Trusted Credentials → System tab

You will see a long list of Root CAs. Scroll through it. Find DigiCert or Let’s Encrypt. These are the authorities whose certificates are installed on your device — the ones your phone trusts unconditionally.

Chrome/Edge on desktop: Settings → Privacy and Security → Security → Manage certificates → Trusted Root Certification Authorities

Firefox on desktop: Settings → Privacy & Security → Certificates → View Certificates → Authorities tab (Firefox maintains its own certificate store, independent of the operating system)

What Happens if a Root CA Is Removed?

If a Root CA is found to have issued certificates improperly — this has happened with several CAs over the years — it gets removed from the trust store. Once removed, every certificate it ever issued instantly stops being trusted by any browser or device that updates its store. Millions of sites could lose their certificate validity overnight. This accountability is what keeps CAs careful.

Why HTTPS Alone Is Not Enough

This is a nuance that matters. HTTPS is necessary but not sufficient. Here is why:

The middle row is the key: you can have an encrypted connection to the wrong server. Encryption protects the channel; the certificate protects the identity. You need both.

A certificate proves that you are talking to the real server — not just that the connection is encrypted. If your browser connects to sbi.co.in, validates the certificate, and the handshake succeeds, you know:

1. Your traffic is encrypted (no one on the path can read it)
2. You are connected to the actual SBI server (the certificate proves it)
3. The certificate has not been tampered with (the CA’s signature and the hash verify this)

If any one of these three things were missing, HTTPS would not be giving you what you think.

What Your Browser Does When You Visit a Banking Site

Let us trace exactly what happens, step by step, when Sunita didi opens her bank’s internal portal at work.

Step 1 — DNS Resolution
  Browser asks: "What is the IP for netbanking.example-bank.co.in?"
  DNS resolver returns: 203.x.x.x

Step 2 — TCP Connection + TLS Handshake
  Browser connects to 203.x.x.x on port 443
  Server presents its certificate

Step 3 — Certificate Validation
  Browser verifies the certificate chain
  Checks: valid CA? → expiry? → domain match? → revoked?
  All pass → TLS handshake completes

Step 4 — Session Key Established
  Symmetric session key agreed
  All data now encrypted with this key

Step 5 — HSTS Check
  Browser checks: "Has this site registered an HSTS policy?"
  If yes → browser saves: "always use HTTPS for this domain"
  Future visits skip any HTTP attempt entirely

Every step is automatic. Sunita didi does not press any button to make this happen. But she knows exactly what is happening — and when a step fails (a certificate error, a DNS failure, a connection refused), she knows which layer to look at.

Network Troubleshooting — Thinking in Layers

Sunita didi has a mental script she runs through on support calls. It mirrors the internet’s layered architecture. When something does not work, she does not guess — she eliminates layers.

Step 1 — Is the device connected to the network?
  Test: ping an IP address directly (e.g., ping 8.8.8.8)
  If this works: physical and network layers are fine
  If this fails: check Wi-Fi or cable connection

Step 2 — Is DNS working?
  Test: ping a domain name (e.g., ping sbi.co.in) or run nslookup
  If ping-by-name fails but ping-by-IP works: DNS is the problem
  Fix: check DNS server settings, try a different DNS server

Step 3 — Is port 443 reachable?
  Test: try to connect to the site on port 443
  If DNS works but HTTPS fails: firewall or port block
  Look for: corporate firewall, ISP filtering, server down

Step 4 — Is the TLS certificate valid?
  Test: visit the site and check for certificate errors
  If the connection works but shows a cert error: certificate issue
  Read the exact error code — it tells you which part of validation failed

Thinking in layers prevents the most common troubleshooting mistake: jumping to conclusions. “The internet is broken” is almost never true. Something specific at a specific layer is broken. The layers tell you where to look.

Hands-On: Inspect Your Browser’s Security

These exercises take you inside the security mechanisms your browser runs automatically. You will look at your device’s certificate store, encounter real certificate errors, and use SSL Labs to analyse a bank’s HTTPS configuration.

Exercise 1 — View Your Device’s Certificate Store

Before You Start: Your device came with approximately 150 Root CA certificates pre-installed. These are the authorities your device unconditionally trusts. This exercise shows you who they are.

On Android:

1. Open Settings
2. Go to Security (or Security & Privacy on newer Android versions)
3. Tap Encryption & Credentials
4. Tap Trusted Credentials
5. Make sure you are on the System tab (not User)
6. Scroll through the list — these are all the Root CAs pre-installed by Google on your device

What to look for:

• Find DigiCert — this is one of the CAs that issues certificates for many Indian banks
• Find ISRG Root X1 — this is Let’s Encrypt’s root CA, used by millions of websites
• Tap any entry to see its details: the CA’s own certificate, valid from/to dates, and its fingerprint

On Chrome or Edge (desktop):

1. Open Settings → Privacy and Security → Security
2. Scroll to Manage certificates
3. Go to the Trusted Root Certification Authorities tab
4. Browse the list — same categories as on Android

Discussion Prompt: You see around 150 Root CAs on your Android phone. Any one of them could technically issue a certificate for any domain. Why is this not a security problem in practice? (Hint: think about what happens to a CA that issues a fraudulent certificate.)

Exercise 2 — Certificate Errors in the Wild

Before You Start: badssl.com maintains test pages for different TLS error states. Each error demonstrates a specific failure mode. Read the exact error code your browser shows — that code tells you exactly what failed.

1. Open your browser and go to https://expired.badssl.com
2. Do not click through — read the warning page carefully
3. Note the exact error code your browser displays (look for something like NET::ERR_CERT_DATE_INVALID)
4. Go back and visit https://self-signed.badssl.com
5. Note the error code here — how is it different from the first one?
6. Go back and visit https://wrong.host.badssl.com
7. Note this error code too

What You’re Seeing

Each error code is specific. Your browser is not saying “something is wrong” — it is saying exactly which step of certificate verification failed.

Extra exploration: After reading each error, click “Advanced” to see the extended explanation your browser provides. Notice how specific it is — this is the browser telling you exactly what it found and why it is refusing to continue.

Discussion Prompt: A bank’s certificate expires overnight. What does every customer see the next morning when they try to use net banking? What should the bank’s IT team have done to prevent this? (Hint: Let’s Encrypt sends renewal reminders 30 days before expiry and supports automated renewal.)

Exercise 3 — SSL Labs Analysis of sbi.co.in

Before You Start: SSL Labs is the industry-standard tool for analysing a site’s HTTPS configuration. Security teams at banks and large organisations use it to audit their own sites. You used it in Session 3 to look at the certificate — this time focus on the HSTS and security configuration sections.

1. Go to ssllabs.com/ssltest on your browser
2. In the hostname field, type sbi.co.in and tap Submit
3. Wait 60–90 seconds for the analysis to complete
4. Note the overall grade (A, A+, B, etc.)

In the Certificate section, note:

• Subject and Issuer (does it match what you expect for a major bank?)
• Fingerprint SHA-256 (this is the SHA-256 hash of the certificate — the same hash function from Session 3 Exercise 0)
• Key type and size

In the Protocol Details section, look for:

• Strict Transport Security (HSTS) — is it enabled? What is the max-age?
  • max-age=31536000 means “remember to always use HTTPS for this domain for one year”
  • Look for whether includeSubDomains and preload are set
• TLS 1.3 — does the site support the current version?

What You’re Seeing

The HSTS status tells you whether SBI has instructed browsers to always use HTTPS. If HSTS is set with a long max-age, every browser that has visited the site will refuse to connect over HTTP for the duration of that period — even if someone on the network tries to redirect them.

Discussion Prompt: Compare the SSL Labs grade for sbi.co.in with ssllabs.com (Qualys’s own site). What differences do you notice in their HSTS and TLS configurations?

Tying It Together

You have now seen the three browser security mechanisms from the Concepts page, in action:

1. Certificate Store — you viewed the ~150 Root CAs your device trusts (Exercise 1)
2. Certificate errors — you read the exact error codes for three failure modes (Exercise 2)
3. HSTS and TLS configuration — you used SSL Labs to read a real bank’s security configuration (Exercise 3)

Every connection your browser makes runs some version of these checks automatically. You just made them visible.

In Session 5, we put all five sessions together — tracing a complete connection from DNS lookup through certificate validation and HSTS enforcement, step by step, explaining which session taught each part.

Session 5 — Putting It All Together

“Deepa gets a new phone, connects to the college Wi-Fi, and opens her browser. She types gmail.com and presses Enter. Walk me through every concept we’ve covered — from the first DNS lookup to the moment HSTS kicks in.”

That is the synthesis challenge. Not a quiz. Not multiple choice. A conversation where you trace a complete connection to gmail.com — from DNS resolution through certificate validation, encrypted session, and HSTS enforcement — using every concept from Sessions 1 through 4.

This session closes the loop and opens the door. We synthesise what you have learned, then we look at where this knowledge takes you professionally.

What You Will Learn

• How to connect all five sessions into one coherent picture
• What the synthesis exercise reveals about gaps in your understanding
• What jobs exist in network security in India
• What each job actually does day-to-day
• What certifications matter and what Course 2 covers

The Big Idea

Security is not a feature — it is a system. Every concept in this course is connected. DNS makes internet navigation possible. Encryption makes DNS and web traffic private. Certificates make encryption trustworthy. Understanding attacks shows you where and why those layers matter. Put it all together and you have a complete mental model of how the internet stays safe.

Character Focus This Session

Deepa is the hero of the synthesis exercise — the walkthrough is her journey to gmail.com.

Sunita didi closes the course — she uses the concepts from every session in her IT work every day, and she ends it as the career goal: a real job, using real skills, in a real Indian workplace.

Rohan previews Course 2 for anyone who wants to go further.

Warm-Up Check

Without looking at your notes, try to answer:

1. When Deepa types gmail.com, what is the very first network operation her browser performs?
2. How does her browser know to use HTTPS when she just typed gmail.com without https://?
3. What does her browser check before displaying the Gmail inbox — and what would happen if that check failed?

These are the kinds of questions Session 5 is designed to help you answer fluently.

Synthesis: Tracing gmail.com

This is the synthesis exercise from Session 5. Work through it yourself first — try to answer each question before reading the answer below it. The goal is to connect every concept from Sessions 1 through 4 into one coherent walkthrough.

The scenario: Deepa has a brand new phone. She connects to the college Wi-Fi, opens Chrome, and types gmail.com into the address bar. She presses Enter.

Trace everything that happens — from that keypress to the moment her inbox loads.

Step 1 — DNS Resolution

Question: Deepa typed gmail.com. Her browser does not know where gmail.com is. What is the very first thing it does?

Answer:

Her browser makes a DNS lookup for gmail.com. This query goes to the DNS resolver configured on the college Wi-Fi — usually the ISP’s resolver.

The resolver checks its cache: “Have I looked up gmail.com recently?” If not, it queries up the DNS hierarchy — the root servers, then Google’s authoritative name servers — until it gets an answer.

The answer comes back: an IP address like 142.250.192.83. Her browser now knows where to send the request.

Without this step, nothing else can happen. DNS is the foundation.

Concepts used: DNS, name resolution, DNS hierarchy, DNS cache — Session 1

Step 2 — Connecting to Port 443

Question: The browser has the IP address. It wants to connect to Gmail. Which port does it use, and why?

Answer:

The browser connects to 142.250.192.83 on port 443.

Port 443 is the standard port for HTTPS. The browser knows to use it because the URL is https://gmail.com — Chrome automatically adds https:// for well-known sites, and Gmail enforces HTTPS through HSTS (which we will cover in Step 6).

On the other end of port 443 sits a server process — Google’s web server software — that is listening for incoming HTTPS connections. The browser is not talking to a person or a building. It is talking to software running in Google’s data centre.

Concepts used: Ports, server processes, TCP/IP stack (Transport layer), HTTPS — Session 1

Step 3 — TLS Handshake and Encryption

Question: Before any Gmail data is sent, the browser and server negotiate an encrypted connection. How?

Answer:

The browser and Google’s server run the TLS handshake:

1. Browser: “I want a secure connection. I support TLS 1.3.”
2. Server: “Here is my certificate. Here is my public key.”
3. Browser: verifies the certificate (Step 4), then uses the server’s public key to agree on a shared secret
4. Both sides derive a symmetric session key from that shared secret
5. All subsequent data — Gmail’s HTML, Deepa’s login credentials, her emails — is encrypted with this session key

Asymmetric encryption (public/private key pair) was used to securely exchange the session key. Symmetric encryption (AES) is used for all the actual data. This hybrid approach gives both security and speed.

Concepts used: TLS handshake, asymmetric encryption, symmetric encryption, session key — Session 2

Step 4 — Certificate Verification

Question: How does Deepa’s browser know it is actually talking to Gmail’s server — and not an impersonator?

Answer:

The browser validates Gmail’s digital certificate:

1. It reads the certificate: Subject: mail.google.com, Issuer: Google Trust Services
2. It hashes the certificate and checks the CA’s digital signature — if the hash matches, the certificate has not been tampered with
3. It walks the chain of trust: Google Trust Services → a Root CA that is pre-installed in Android’s certificate store
4. It verifies the Root CA is trusted (pre-installed by Google on her phone)
5. It checks the domain: mail.google.com matches gmail.com (Google uses multiple domains)
6. It checks expiry: the certificate is still valid today

All six checks pass. The TLS handshake continues. The encrypted session is established.

If any check had failed, the browser would have shown a NET::ERR_CERT_* error and refused to continue.

Concepts used: Hashing, digital signatures, certificates, certificate chain, chain of trust, Root CA, certificate store — Session 3

Step 5 — Browser Certificate Store

Question: Why does Deepa’s brand new phone — which has never visited Gmail before — already trust Google Trust Services?

Answer:

Because Google pre-installed approximately 150 Root CA certificates on every Android phone before it left the factory. One of those pre-installed certificates is Google Trust Services (or the root it chains to).

Deepa did not configure this. She did not approve these CAs. They were installed by Google as part of the Android operating system. When she bought the phone, those trusted CAs were already there.

This is what makes the certificate system work at scale. No one could manually approve CAs for every site they visit. The trust comes pre-installed by the platform provider (Google for Android, Apple for iOS, Microsoft for Windows), backed by the auditing those companies do on CAs before including them.

Concepts used: Browser/device certificate store, pre-installed Root CAs, certificate trust model — Session 4

Step 6 — HSTS Enforcement

Question: Deepa only typed gmail.com — not https://gmail.com. How does her browser know to use HTTPS?

Answer:

Two mechanisms work together:

Chrome’s auto-HTTPS: Chrome automatically upgrades known domains to HTTPS. For well-known sites like Gmail, it starts with HTTPS directly.

HSTS (HTTP Strict Transport Security): When Gmail’s server responds, it includes a header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

This tells the browser: “For the next year (31,536,000 seconds), never connect to gmail.com or any of its subdomains over plain HTTP. Always use HTTPS.”

From this point forward, Deepa’s browser has saved that instruction. If she ever types just gmail.com again — or even if someone on the network tried to redirect her to an HTTP version of Gmail — her browser refuses. It goes straight to HTTPS without making any HTTP request at all.

Gmail is also on the HSTS preload list — a list compiled directly into Chrome’s source code. Even on a fresh browser that has never visited Gmail, HSTS is already in effect.

Concepts used: HSTS, browser security policies, HTTPS enforcement — Session 4

Full Picture

Deepa types gmail.com → Enter
      ↓
Step 1: DNS resolves gmail.com → 142.250.x.x          [Session 1]
      ↓
Step 2: TCP connects to port 443 (HTTPS port)          [Session 1]
        Server process answers (Google's web server)
      ↓
Step 3: TLS handshake — asymmetric key exchange        [Session 2]
        → Symmetric session key established
        → All data now encrypted with AES
      ↓
Step 4: Certificate validated — Google Trust Services  [Session 3]
        Hash verified → chain of trust walked
        Domain match ✓ | Expiry ✓ | Revocation ✓
      ↓
Step 5: Root CA trusted — pre-installed on Android     [Session 4]
        No manual approval needed
      ↓
Step 6: HSTS enforced — browser saves "always HTTPS"   [Session 4]
        Future visits go straight to HTTPS
      ↓
Gmail inbox loads — encrypted, verified, enforced

Six steps. Every session contributed one. That is the course.

Every time Deepa opens Gmail — on any device, on any network — these six steps run automatically. Understanding them means understanding how the internet actually works.

Career Paths in Network Security

Network security is one of the fastest-growing areas in India’s technology sector. NASSCOM estimates that India will need over a million cybersecurity professionals in the coming years, and the supply falls far short of demand. Every bank, every IT company, every government department, and every growing startup needs people who understand what you have learned in this course.

This page describes four roles that use Course 1 concepts every day. These are real jobs with real career paths in India.

IT Support Specialist

What they do day-to-day:

IT Support is often the entry point into technology careers. Support specialists help employees troubleshoot connectivity problems, set up devices, manage accounts and passwords, and respond to security incidents.

A typical day might include: resetting a password for a colleague who is locked out, investigating why a branch office cannot connect to the corporate server, helping a manager who received a suspicious email determine whether it is phishing, and escalating security incidents to the right team.

Course 1 concepts they use:

• Network troubleshooting (Session 4’s layered thinking: is it DNS? Is it routing? Is it the application?)
• Understanding HTTPS and certificates — explaining to users why a browser is showing an error
• Recognising phishing attempts — the first person to see a suspicious email is often IT Support
• IP addressing — setting up devices, diagnosing connection problems

Where you find this role in India:

IT companies (Infosys, TCS, Wipro, HCL), banks (SBI, HDFC, ICICI, Axis), government departments, hospitals, manufacturing companies. Almost every organisation of more than 50 people has an IT support function.

Natural first certification: CompTIA A+ — An internationally recognised entry-level certification covering hardware, networking fundamentals, and operating systems. It is the IT industry’s standard first credential and is directly applicable to the work IT Support does every day.

What comes next:

Network Administrator, Helpdesk Analyst → with experience and certifications: Systems Administrator, IT Manager.

Network Administrator

What they do day-to-day:

Network Administrators design, build, and maintain the network infrastructure that organisations depend on. They configure routers, switches, and firewalls; manage IP addressing schemes; monitor network performance; and respond when the network goes down.

A typical day might include: configuring a new branch office’s network connection, updating firewall rules to block malicious traffic identified in logs, investigating why one part of the network is slower than usual (traceroute and packet analysis), and renewing SSL certificates for internal servers before they expire.

Course 1 concepts they use:

• IP addressing and routing — the core of the job (Session 1)
• DNS — managing internal and external DNS records is a major part of network administration
• Certificates — renewing, deploying, and monitoring TLS certificates across internal and external services
• Firewall configuration and network segmentation — building the defences

Where you find this role in India:

ISPs (Jio, Airtel, BSNL), banks, large enterprises, data centres, government IT departments (NIC — National Informatics Centre is a major employer).

Natural path certification: CCNA (Cisco Certified Network Associate) — The standard certification for network administrators. Covers routing, switching, IP addressing, and network configuration in depth. Recognised by employers across India’s IT and enterprise sectors.

What comes next:

Senior Network Engineer → Network Architect → Cloud Network Engineer (as infrastructure moves to cloud providers like AWS, Azure, and GCP).

SOC Analyst (Security Operations Centre)

What they do day-to-day:

SOC Analysts monitor an organisation’s network in real time for signs of attack. They work from a Security Operations Centre — a room (or remote setup) with dashboards showing network traffic, security alerts, and threat intelligence feeds. When an alert fires, they investigate.

A typical day might include: reviewing overnight security alerts to identify which are real threats and which are false positives, investigating an alert about suspicious outbound connections from an employee’s laptop, writing a report on a phishing campaign targeting their organisation, and updating detection rules to catch a new attack pattern.

Course 1 concepts they use:

• Understanding normal network behaviour (Sessions 1–2) so they can spot abnormal behaviour
• Certificate anomalies — spotting suspicious or fraudulent certificates (Session 3)
• Phishing identification — SOC analysts review reported phishing emails and URLs (Session 4)
• Attack patterns — MITM, DNS spoofing, ransomware indicators (Session 4)

Where you find this role in India:

Large IT companies with managed security services (Tata Consultancy Services, Wipro CyberDefense, HCL Security), banks (every major bank has a SOC), insurance companies, and managed security service providers (MSSPs) that provide SOC services to smaller companies.

What comes next:

SOC Analyst Tier 1 → Tier 2 (investigates complex incidents) → Tier 3 (threat hunting, builds detection rules) → Security Engineer → Security Architect.

Cybersecurity Analyst

What they do day-to-day:

Cybersecurity Analysts assess an organisation’s security posture and identify vulnerabilities before attackers do. This role is broader than SOC — it includes security assessments, penetration testing, policy development, and security training.

A typical day might include: running an SSL Labs assessment across all public-facing servers and flagging those with weak configurations, reviewing a developer’s new application for security issues before it goes live, testing how employees respond to a simulated phishing campaign, and preparing a report for management on the current threat landscape and the organisation’s exposure.

Course 1 concepts they use:

• Every concept from this course — this role requires the complete picture
• SSL/TLS configuration assessment (exactly what you did in the Hands-On sessions)
• Certificate management and PKI (Session 3)
• Phishing simulation and awareness training (Session 4)
• Reporting and communicating risk to non-technical stakeholders

Where you find this role in India:

Consulting firms (Deloitte, PwC, KPMG, EY all have cybersecurity practices in India), IT companies with security divisions, banks and financial services, government organisations (CERT-In recruits analysts), and specialised security firms.

Certification path: OSCP (Offensive Security Certified Professional) — alongside CEH, OSCP is the technical benchmark for security professionals who assess and test systems. Where CEH covers methodology, OSCP is a hands-on exam requiring candidates to actually compromise test systems. Highly regarded for roles involving penetration testing and security assessment.

What comes next:

Cybersecurity Analyst → Senior Analyst → Security Consultant → CISO (Chief Information Security Officer) in larger organisations.

Certifications That Matter

If you want to move into any of these roles, industry certifications demonstrate that your knowledge meets a professional standard.

APITCANS — The certification associated with the IndusForward Skills Series. Information will be shared as availability is confirmed.

CompTIA Security+ — An internationally recognised entry-level certification covering network security fundamentals. Respected by employers in India and globally. A good first milestone after completing this course.

CEH (Certified Ethical Hacker) — An EC-Council certification focused on offensive security techniques used defensively. More advanced than Security+. Practical and highly regarded in India’s IT industry.

Course 2 Preview

Course 2 of the IndusForward Skills Series takes everything you have learned in this course and makes it hands-on:

• Build a network from scratch and configure routing
• Capture and read live network packets with Wireshark
• Set up your own Certificate Authority and issue certificates
• Write firewall rules and test them against simulated attacks
• Work through real-world incident scenarios

Course 1 is the foundation. Course 2 is where you start doing it yourself.

Glossary

Every technical term used in this book, in plain English first. Where you first encountered the concept is noted in brackets.

AES (Advanced Encryption Standard) The symmetric encryption algorithm used to encrypt most data on the internet today. AES-256 means the key is 256 bits long — effectively unbreakable with current technology. [Session 2]

Asymmetric Encryption An encryption system using two mathematically linked keys — a public key and a private key. Data encrypted with the public key can only be decrypted with the private key. Solves the key distribution problem. [Session 2]

CA (Certificate Authority) An organisation that verifies identities and issues digital certificates. Examples include DigiCert, Let’s Encrypt, and Sectigo. Your device pre-trusts a list of CAs. [Session 3]

Certificate An electronic document that links a public key to an identity (e.g., a domain name). Signed by a Certificate Authority to prove its authenticity. [Session 3]

Certificate Chain The sequence of certificates from a website’s certificate up through Intermediate CAs to a Root CA. Your browser walks this chain to verify trust. [Session 3]

Cipher An algorithm for encrypting and decrypting data. AES and RSA are examples of ciphers. [Session 2]

Certificate Store A pre-installed collection of trusted Root CA certificates on a device or browser. On Android, Google pre-installs approximately 150 Root CA certificates. Any HTTPS certificate whose chain traces back to one of these is automatically trusted. [Session 4]

DNS (Domain Name System) The internet’s phone book. Converts human-readable domain names (like sbi.co.in) into IP addresses that computers use to route data. [Session 1]

DNS Cache A temporary store of DNS lookup results on your device. Prevents the device from asking the DNS server for the same domain name every time. [Session 1]

Encryption The transformation of readable data (plaintext) into scrambled, unreadable data (ciphertext) that can only be read by someone with the correct key. [Session 2]

Hash / SHA-256 A hash function takes any input and produces a fixed-length output (a “fingerprint”) called a hash or digest. SHA-256 always produces a 256-bit (64-character) output. Good hash functions are one-way, deterministic, have the avalanche effect, and produce fixed-length output. Used in certificates, digital signatures, and password storage. [Session 3]

HSTS (HTTP Strict Transport Security) A browser security policy where a server instructs the browser to always use HTTPS for that domain — never plain HTTP — for a specified time period. Once a browser receives an HSTS header, it enforces HTTPS even if the user types only the domain name without https://. [Session 4]

HTTPS (HTTP Secure) HTTP (the web protocol) running over a TLS encrypted connection. Indicated by https:// in the address bar and a padlock icon. [Session 2]

IP Address (Internet Protocol Address) A unique numerical label assigned to every device connected to the internet. Like a postal address — data cannot find its destination without one. [Session 1]

ISP (Internet Service Provider) The company that provides your internet connection — for example, Jio, Airtel, or BSNL. [Session 1]

Key (cryptographic) A piece of information that controls how an encryption algorithm encrypts or decrypts data. In symmetric encryption, one key does both. In asymmetric encryption, a public key encrypts and a private key decrypts. [Session 2]

Mixed Content When an HTTPS page attempts to load a resource (image, script, font) over plain HTTP. Because that resource travels unencrypted, it could be intercepted and replaced by anyone on the network path. Browsers block mixed content automatically. [Session 4]

NAT (Network Address Translation) The mechanism by which a router maps many private IP addresses to one public IP address. Allows multiple devices to share one internet connection. [Session 1]

Non-repudiation The property of a digital signature that makes it impossible to credibly deny having signed something. Legally significant under India’s IT Act. [Session 3]

2FA (Two-Factor Authentication) A login method requiring two separate proofs of identity — typically something you know (password) and something you have (your phone, for OTP). Used by all Indian banks for net banking login. [Session 4]

Packet A small unit of data transmitted over a network. Large data (like a file or web page) is broken into many packets that travel separately and are reassembled at the destination. [Session 1]

PKI (Public Key Infrastructure) The complete system of hardware, software, policies, and organisations that enables secure digital communication through certificates and public-key cryptography. [Session 3]

Private IP Address An IP address used within a local network (home, office, college). Not routable on the public internet. Common ranges include 192.168.x.x and 10.x.x.x. [Session 1]

Private Key In asymmetric encryption, the key that is kept secret by its owner. Can decrypt data encrypted with the corresponding public key. Can also create digital signatures. [Session 2]

Port A number (0–65535) that identifies a specific service on a networked device. Port 443 is HTTPS; port 80 is HTTP; port 53 is DNS. When your browser connects to an HTTPS site, it connects to port 443 automatically. [Session 1]

Protocol A set of agreed rules for how devices communicate. TCP/IP, HTTP, HTTPS, and DNS are all protocols. [Session 1]

Public IP Address An IP address visible to the rest of the internet. Assigned by ISPs. Uniquely identifies a connection point on the public internet. [Session 1]

Public Key In asymmetric encryption, the key that can be shared freely. Anyone can use it to encrypt a message for the key owner, or to verify the key owner’s digital signature. [Session 2]

Session Cookie A small piece of data your browser sends with every request after you log in, to prove to the server that you are authenticated. If captured in transit on an unencrypted connection, a session cookie can be replayed to impersonate a logged-in user without knowing their password. HTTPS encrypts session cookies in transit. [Session 2]

Root CA A top-level Certificate Authority whose certificate is pre-installed in devices and browsers as unconditionally trusted. Fewer than 200 Root CAs are trusted globally. [Session 3]

Router A device that receives network packets and decides where to forward them next. Connects networks together. Your home Wi-Fi box is a router. [Session 1]

Routing The process of forwarding packets hop-by-hop across the internet from source to destination. Each router makes a forwarding decision based on the destination IP address. [Session 1]

SSL (Secure Sockets Layer) The predecessor to TLS. Technically obsolete but the name persists in common usage — “SSL certificate” is usually a TLS certificate. [Session 2]

Symmetric Encryption Encryption where the same key is used to both encrypt and decrypt data. Fast and efficient, but requires a secure way to share the key. AES is a symmetric cipher. [Session 2]

TCP (Transmission Control Protocol) A protocol that guarantees reliable, ordered delivery of packets. If a packet is lost, TCP ensures it is resent. Runs on top of IP. [Session 1]

TCP/IP Stack A four-layer model describing how internet communication is structured: Application layer (HTTP, DNS) → Transport layer (TCP, ports) → Network layer (IP addresses, routing) → Physical layer (cables, Wi-Fi). Each layer has one job and passes data to the layer above or below it. [Session 1]

TLS (Transport Layer Security) The protocol that encrypts internet communication. What makes HTTPS work. Involves a handshake to verify identity and establish an encrypted session. [Session 2]

TLS Handshake The negotiation between a browser and server that establishes an encrypted connection. Involves certificate verification and key exchange. Happens before any page data is sent. [Session 2]

OTP (One-Time Password) A short numeric code valid for a single login or transaction, sent to your registered phone number. Used by banks as the second factor in 2FA. Expires within minutes. Never share it — no bank will ever ask for it. [Session 4]

Session Token A temporary credential issued by a server after successful login. Stored in your browser and sent with each request to prove you are logged in. Expires after inactivity or logout. [Session 2]

Further Reading & Resources

This page is your starting point for going deeper. Everything listed here is free to access unless noted.

Tools to Bookmark

These are tools professionals use. You have already used most of them in the Hands-On sessions.

Reading by Topic

How the Internet Works (Session 1)

Cloudflare Learning Centre — DNS Clear, comprehensive explanation of how DNS works. No maths. Good diagrams. → cloudflare.com/learning/dns/what-is-dns/

Cloudflare Learning Centre — How the Internet Works → cloudflare.com/learning/network-layer/how-does-the-internet-work/

MDN — How the Web Works Mozilla’s developer documentation. Written for beginners but technically accurate. → developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/How_the_Web_works

How DNS Works (comic) A well-designed comic that walks through DNS in a visual and accessible way. Great for visual learners. → howdns.works

Encryption and HTTPS (Session 2)

Cloudflare Learning Centre — What Is Encryption → cloudflare.com/learning/ssl/what-is-encryption/

Cloudflare Learning Centre — What Is TLS → cloudflare.com/learning/ssl/transport-layer-security-tls/

Google Safety Centre Available in Hindi. Covers basic online safety in plain language. → safety.google/

Certificates and PKI (Session 3)

Let’s Encrypt — How It Works The organisation that provides free TLS certificates explains the process clearly. → letsencrypt.org/how-it-works/

Cloudflare — SSL Certificates → cloudflare.com/learning/ssl/what-is-a-ssl-certificate/

Cloudflare — What Is PKI → cloudflare.com/learning/ssl/what-is-a-pki/

Browser Security (Session 4)

Cloudflare — What Is HSTS Clear explanation of HTTP Strict Transport Security and why it matters. → cloudflare.com/learning/ssl/what-is-hsts/

Chromium Security — HSTS Preloading The official HSTS preload list submission site — explains what preloading is and which sites use it. → hstspreload.org

Mozilla — Mixed Content Mozilla’s explanation of mixed content blocking and how browsers handle it. → developer.mozilla.org/en-US/docs/Web/Security/Mixed_content

Next Steps After This Course

TryHackMe — Pre-Security Path

A free, beginner-friendly learning platform with interactive labs. The Pre-Security path covers the same topics as this course but with interactive exercises, including browser-based virtual machines where you run real security tools. Highly recommended as a complement to Course 2.

→ tryhackme.com/path/outline/presecurity

Cloudflare Learning Centre (Full)

Cloudflare publishes some of the best free educational content on networking and security on the internet. The full learning centre covers topics from DNS to DDoS to Zero Trust. Bookmark it and read whenever you are curious about a topic.

→ cloudflare.com/learning/

OWASP Top 10

The Open Web Application Security Project publishes a list of the ten most critical web application security risks. If you want to understand how web applications get attacked, this is the canonical starting point.

→ owasp.org/www-project-top-ten/

Certification Paths

APITCANS

The certification associated with the IndusForward Skills Series. Information will be shared as availability is confirmed.

CompTIA Security+

An entry-level certification that covers network security fundamentals. Internationally recognised. A good first professional milestone after completing this course and Course 2. → comptia.org/certifications/security

CEH (Certified Ethical Hacker)

An EC-Council certification focused on understanding and using offensive security techniques for defensive purposes. More advanced. Popular with India’s IT industry. → eccouncil.org/train-certify/certified-ethical-hacker-ceh/

A Note on Staying Current

Security is not a subject you learn once and know forever. New attacks appear. Old defences become obsolete. New standards replace old ones.

The best way to stay current:

• Follow CERT-In advisories for India-specific threats
• Read Cloudflare’s blog — they publish accessible write-ups on real-world security incidents
• Join the TryHackMe community and work through new challenges
• When something in the news mentions a cyberattack, look it up — understanding real incidents is the best education

The concepts in this course will not change. DNS will still work the same way in ten years. Asymmetric encryption will still use public and private keys. But the specific attacks, tools, and implementations evolve constantly. Curiosity is the most important skill.