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

“When you log into your bank online and transfer money, where does it go?”

That was the question your instructor opened with. Most people shrug — it goes somewhere, the money arrives, and that is enough. But “somewhere” is actually a precisely engineered journey through cables, routers, data centres, and protocols. 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 sbi.co.in into an address a computer can use
• 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 why everyone needs to agree on the same rules

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.

Putting It Together: The Online Banking Journey

Now you can answer the opening question. When you log into your bank’s website and transfer money:

1. Your browser creates a request (using HTTPS protocol)
2. DNS resolves onlinesbi.sbi to an IP address
3. The request is broken into TCP/IP packets
4. Packets are routed hop by hop from your device through your network to the bank’s servers
5. The bank’s servers verify your identity and process the transfer instruction
6. A response travels back the same way — broken into packets, routed, reassembled
7. Your screen shows “Transfer Successful” in under two seconds

Every single step in that chain used the concepts from this session.

Hands-On: See the Internet in Action

These exercises use free tools that work on any smartphone browser. You do not need to install anything.

Exercise 1 — Find Your Public IP Address

Before You Start: Your phone has a private IP on your mobile network and a public IP that the internet sees. This exercise shows you the public one.

1. Open your phone’s browser (Chrome, Firefox, or Safari)
2. Go to toolbox.googleapps.com
3. Tap Check MX in the top menu — then look for Check Header (or search for “what is my ip” in any search engine)
4. Alternatively, go to whatismyip.com — your public IP appears at the top of the page
5. Note the IP address shown
6. 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 from your phone’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 2 — Watch DNS Work

Before You Start: DNS translates names to IP addresses. This exercise lets you see that translation happen for different domain names around the world.

1. Open your browser and go to dnschecker.org
2. In the search box, type sbi.co.in and tap the search button
3. Wait for the results to load — you will see a map and a list of IP addresses
4. Note the IP address shown for India
5. Now search for google.com — note how many different IP addresses appear (Google uses many servers worldwide)
6. Now search for irctc.co.in

What You’re Seeing

Each domain name maps to one or more IP addresses. Google shows many different IPs because they have servers in data centres all over the world — when you connect to Google, you are routed to the nearest one. IRCTC likely shows fewer IPs because their infrastructure is more centralised in India.

Discussion Prompt: If an attacker could control the DNS response for sbi.co.in, what could they do with it?

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.”

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?

Tying It Together

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

• IP addresses — every device has one (Exercise 1)
• DNS — names get translated to addresses (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 — Why Security Matters & Encryption

Rajan bhaiya clicked a link in an email. It looked like it was from his bank. It asked him to log in. Three hours later, every file on his computer — years of records, customer data, everything — was encrypted. A message appeared: pay ₹50,000 or lose it all. He paid. The files were never returned.

This is not a story from a movie. CERT-In (India’s Computer Emergency Response Team) reports thousands of ransomware incidents every year across India. Rajan bhaiya is real. This session is about why attacks like this happen and how encryption is the foundation of our defence.

What You Will Learn

• What types of attacks are most common in India — and what makes them work
• What encryption is and how it keeps data private
• The difference between symmetric and asymmetric encryption
• 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.

Character Focus This Session

Rajan bhaiya opens the session — his ransomware story shows what happens when we ignore security.

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).

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: Threats, Encryption, HTTPS

The Threat Landscape in India

Before we talk about solutions, we need to understand what we are protecting against. The three most common threats you will encounter are phishing, ransomware, and man-in-the-middle attacks.

Phishing

Phishing is when an attacker tricks you into revealing information — your password, your OTP, your bank details — by pretending to be someone trustworthy.

You have seen the messages. “Your IRCTC account has been suspended. Click here to verify your KYC.” “Your SBI account will be blocked in 24 hours. Update your details now.” “Your email storage is full — click here to verify your account.”

What makes phishing work is urgency plus familiarity. The message looks real. The logo looks real. The link almost looks real (it might say sbi-update.online instead of sbi.co.in). And you are scared of losing your account, so you act fast without checking carefully.

Rajan bhaiya’s story was phishing — an email that looked like it came from a software company, with an attachment that turned out to be ransomware.

Ransomware

Ransomware is a specific type of attack where malware encrypts your files and demands payment to decrypt them. The attacker holds your data hostage.

The irony of ransomware is that the attacker uses encryption — the same technology that protects your data — against you. They encrypt your files with a key only they know. Unless you pay, you cannot read your own files.

Man-in-the-Middle (MITM)

A man-in-the-middle attack is when an attacker positions themselves between you and the server you are trying to reach, secretly reading or altering the data flowing between you.

Imagine writing a letter to your bank. Unknown to you, the postman opens every letter, reads it, copies it, reseals it, and delivers it. You and the bank think you are communicating directly. You are not.

On the internet, this can happen on unsecured public Wi-Fi networks. We will go deep on this in Session 4.

The Answer: Encryption

Encryption is the transformation of readable data into unreadable scrambled data that can only be unscrambled by someone with the right key.

The postcard vs the sealed letter:

When you send data over HTTP (without the S), it travels like a postcard. Every router, every ISP, every network device between you and the server can read the contents. Your username. Your password. Your message.

When you send data over HTTPS, it travels like a sealed letter. Even if someone intercepts it in transit, they see only scrambled nonsense. Only the intended recipient — the server you are connecting to — has the key to unscramble it.

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.

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.

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 sbi.co.in, 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:

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 I am really sbi.co.in. 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 did not exist so that criminals could hide ransomware. 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.

Rajan bhaiya’s story is not about encryption failing. Encryption was working perfectly — the ransomware used it against him. His story is about what happens when you trust without verifying. Session 3 is about how trust works on the internet.

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 — Certificates & Digital Trust

Deepa opens her SBI banking app. In under a second, her phone has verified that it is really talking to SBI’s server, that the server has not been tampered with, and that the connection is encrypted. She taps her balance and sees ₹12,450. She never thinks about any of this. Her phone does it automatically, every single time.

But what if her phone got it wrong? What if an attacker had set up a fake SBI server? How does her phone know the difference?

The answer is certificates and the chain of trust. This session explains how the internet’s trust system works — and what happens when it fails.

What You Will Learn

• 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 digital signatures are and why they are legally binding in India
• What happens when certificate verification fails (the error pages you’ve seen)

The Big Idea

The internet’s trust system is a chain of vouching. Your browser trusts a small list of top-level authorities (built into your device). Those authorities vouch for intermediate authorities. Those vouch for individual websites. If the chain is intact, you can trust the site. If any link in the chain is broken, your browser warns you — loudly.

Character Focus This Session

Deepa walks through her banking app and starts to wonder: “Who decided that DigiCert is trustworthy? Why does my phone trust them?”

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

Warm-Up Check

Before reading on:

1. You have probably seen a browser warning saying “Your connection is not private” or “This site’s certificate has expired.” What did you do? Did you go back, or click “Advanced” and continue anyway?
2. If someone showed you an official-looking document that said they were from your bank, how would you verify it was real?
3. Who decides which Certificate Authorities your phone trusts?

These questions are exactly what this session answers.

Concepts: Certificates, PKI, Digital Signatures

What Is a Digital Certificate?

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.”

A certificate contains:

• The domain name it is issued for (e.g., sbi.co.in)
• The public key of the server
• The name of the Certificate Authority (CA) that issued it
• The validity period (start date and expiry date)
• A digital signature from the CA (more on this below)

Certificate Authorities — The Internet’s Notary System

A Certificate Authority (CA) is an organisation that verifies identities and issues certificates. When you apply for a certificate for your website, the CA checks that you actually own the domain. Once satisfied, they issue a certificate with their digital signature on it.

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).

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 and browser — 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.
• “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) or a certificate from an organisation your device has not approved.
• “Certificate has been revoked” — the CA has explicitly cancelled this certificate, usually because the private key was compromised.

Digital Signatures — Proving Authenticity

A digital signature is how a CA proves it issued a certificate. It is also how you can prove you wrote a document.

Here is how it works:

1. You have a private key (only you have it) and a public key (shared with everyone)
2. When you sign a document, your software creates a unique “fingerprint” of the document (called a hash) and encrypts that fingerprint with your private key
3. Anyone with your public key can decrypt that fingerprint and verify it matches the document

If the document had been changed after signing, the fingerprint would no longer match. The signature would fail verification. This proves two things:

• Authenticity — the document came from you (only your private key could have created that signature)
• Integrity — the document has not been modified since you signed it

Non-repudiation is the property that means you cannot deny signing something. Because only your private key could have created the signature, and only you (theoretically) have your private key, you cannot credibly claim “I didn’t sign that.” This is why digital signatures are stronger than handwritten signatures in some respects — they are mathematically tied to the signer.

PKI — Public Key Infrastructure

The whole system we have been describing — certificate authorities, trust chains, public and private keys, digital signatures — 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 log into your bank or send email — PKI is there too.

Putting It Together: Deepa’s 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 checks the chain: DigiCert → Intermediate → api.sbi.co.in
4. The app verifies DigiCert is in its trusted root list (it is — pre-installed on her Android phone by Google)
5. The app verifies the domain name matches
6. The app verifies the certificate has not expired
7. The TLS handshake completes
8. 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. Banking apps are strict about this for good reason.

Hands-On: Read a Real Certificate

These exercises take you inside the certificate system — the same one your phone checks automatically every time you open a banking app.

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 a “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.

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?
3. Look for the “Advanced” option and tap it — read the technical explanation your browser provides
4. Do not proceed to the site for the next step
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:

Discussion Prompt: If you were an attacker trying to steal someone’s banking credentials, which of these three errors would you most likely trigger accidentally? Why?

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 — a unique identifier for this specific certificate
   • Pin SHA256 — used for certificate pinning (an advanced security feature)
   • 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 whether the site supports TLS 1.3

What You’re Seeing

The certificate fingerprint is a hash — a unique digital fingerprint of the certificate. If the certificate changes (even by one character), the fingerprint changes completely. This is how certificate pinning works: an app stores the expected fingerprint and refuses to connect if it does not match, even if a technically valid certificate is presented. Banking apps use this to prevent attackers from using fake certificates.

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 how to read the certificate system that underpins all HTTPS security:

• Reading the chain — from site certificate to Intermediate CA to Root CA
• Understanding errors — expired, self-signed, wrong domain, revoked
• Using SSL Labs — the professional tool for certificate analysis

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 see what happens when attackers try to circumvent this system — and how online banking is designed to resist those attacks at every layer.

Session 4 — Attacks, Online Banking Security & Troubleshooting

Sunita didi works in customer support at a bank. Every single day, she answers calls from people who clicked a link that looked real, entered their details on a page that looked real, and discovered too late that it was not real at all. “The OTP is gone, the money is gone,” she says. “And there is almost nothing I can do at that point.”

This is the most applied session of the course. We look at how real attacks work — not in theory, but step by step, the way an attacker thinks. Then we look at how online banking is designed to resist those attacks. Then we look at how to troubleshoot when something goes wrong on a network.

What You Will Learn

• How phishing attacks are constructed and why they work
• How MITM (man-in-the-middle) attacks work on unsecured networks
• What DNS spoofing is and how to spot it
• How online banking login works end-to-end and where security is applied
• How to investigate a suspicious link or email before clicking it
• A basic mental model for troubleshooting network problems

The Big Idea

Attackers do not break encryption — they bypass it. The most successful attacks do not crack TLS or steal private keys. They trick people into handing over credentials willingly. Understanding how attacks are constructed is the best defence against falling for them.

Character Focus This Session

Sunita didi opens the session — her daily work makes every concept concrete and urgent.

Rohan goes deep on how banks layer security into the login process — not just encryption, but session management and 2FA.

Deepa asks the hard question: “If phishing is so obvious, why do so many people fall for it?”

Warm-Up Check

Before reading on:

1. You receive an email: “Dear customer, your SBI net banking has been suspended. Click here to update your KYC: sbi-kyc-update.in.” What are the red flags?
2. You are at a café and see two Wi-Fi networks: “CafeWiFi_Official” and “Free_CafeWiFi”. The second one does not ask for a password. Which one is safer? Why?
3. Have you ever received a call or message claiming to be from your bank asking for your OTP? What is the right response?

Concepts: Phishing, MITM, Online Banking Security

How Phishing Works — Dissecting a Real Attack

Phishing is not as simple as “a fake email.” Modern phishing is carefully engineered to exploit how humans think and behave. Let us dissect a real example.

Here is an email that has circulated widely in India:

From: support@sbi-netbanking.in Subject: Urgent: Your SBI Net Banking Access Has Been Suspended

Dear Customer, Your SBI Net Banking account has been locked due to multiple failed login attempts. To unlock immediately, click the link below and verify your details within 24 hours or your account will be permanently disabled. [Verify Now] → sbi-netbanking-unlock.com

Let us go through it element by element:

support@sbi-netbanking.in — The sender address looks official but is not. SBI’s real domain is sbi.co.in. Anyone can register sbi-netbanking.in for a few hundred rupees.

“Dear Customer” — No personalisation. Your bank knows your name and would use it.

“locked due to multiple failed login attempts” — This creates alarm. Your instinct is to fix it immediately.

“within 24 hours” — Urgency removes your thinking time. Attackers rely on this.

sbi-netbanking-unlock.com — Not onlinesbi.sbi. Not sbi.co.in. A domain registered by the attacker. If you check WHOIS, it was registered days ago.

“permanently disabled” — A threat. Designed to prevent you from stopping to think.

The Anatomy of a Phishing Site

Once you click the link, the phishing site is waiting:

• It looks exactly like SBI’s real site — the attacker used a web scraper to copy the HTML, CSS, and images
• The URL in the address bar reads sbi-yono-unlock.com — but on mobile, only the first part is visible
• It has an HTTPS padlock — the attacker got a free certificate from Let’s Encrypt in five minutes
• It asks for your account number, password, and OTP
• When you submit, your credentials go to the attacker’s server
• The site shows a “Thank you, your account is now unlocked” message
• You think the problem is solved. Your account has just been emptied.

How to Spot Phishing

Man-in-the-Middle (MITM) Attacks

Rohan is at the airport. He sees a Wi-Fi network called “Free_Airport_WiFi”. He connects. What he does not know is that a person sitting nearby set up that hotspot using their phone. Every packet Rohan sends goes through the attacker’s device first.

For HTTP sites, the attacker can read everything. For HTTPS sites, the story is more complicated.

Does HTTPS protect against MITM?

Yes — with a caveat. If you are connected to a legitimate HTTPS site and an attacker intercepts your traffic, they see only encrypted data. They cannot read it. They cannot modify it without breaking the certificate verification.

But — and this is the caveat — if the attacker can also get your device to trust a certificate they control (for example, by tricking you into installing a rogue Certificate Authority), they can decrypt and re-encrypt your traffic in real time. This is why:

• You should never install custom certificates unless you know exactly what you are doing
• Corporate devices often have corporate CAs installed for IT monitoring — your employer can technically see your HTTPS traffic on a work device

SSL Strip

An older but important attack: when you type sbi.co.in without https://, your browser first connects via HTTP and then gets redirected to HTTPS. An attacker on your network can intercept that first HTTP connection and serve you a fake HTTP page, stripping the HTTPS before it starts. The protection against this is HSTS — if you have visited a site before with HSTS, your browser remembers to always use HTTPS and never makes that initial HTTP request.

DNS Spoofing

In Session 1, you learned that DNS converts domain names to IP addresses. What if an attacker could give you a false answer?

DNS spoofing (also called DNS cache poisoning) is when an attacker inserts a false DNS record so that your device looks up sbi.co.in and gets the IP address of the attacker’s server instead of SBI’s real server.

On a controlled network (like a compromised home router or a malicious public Wi-Fi), this is achievable. HTTPS and certificate verification are your protection: even if DNS sends you to the wrong IP, the server at that IP cannot present a valid certificate for sbi.co.in (because only SBI’s server has the corresponding private key). Your browser would show a certificate error.

This is another reason why certificate verification matters so much: it is the last line of defence when DNS cannot be trusted.

How Online Banking Login Works — and Why It Is Well Designed

Every day, millions of people log into their bank accounts online in India. Very few experience fraud through the banking system itself — because banks have layered security into every step of the login and transfer process.

Here is the full flow of an online banking login and transfer:

You
    ↓ Enter username + password on the bank's HTTPS site
Bank's Web Server
    ↓ Verifies credentials against its database (password is hashed, never stored in plaintext)
    ↓ Generates a one-time OTP and sends it to your registered mobile number
You
    ↓ Enter the OTP within its validity window (usually 3–5 minutes)
Bank's Server
    ↓ Verifies OTP, creates an encrypted session token for your browser
    ↓ Logs the login: your IP address, device fingerprint, timestamp
You (now logged in)
    ↓ Initiate a transfer — bank may ask for OTP again for high-value transactions
Bank's Server
    ↓ Processes transfer, sends SMS confirmation to your registered number
    ↓ Session expires after inactivity (typically 5–10 minutes)

Where security is applied:

• Your password is never stored in plaintext. The bank stores only a secure hash. Even bank employees cannot see your password.
• All communication uses TLS encryption with certificate verification — your browser verified the bank’s certificate before you typed a single character.
• The OTP is tied to your registered SIM. Even if an attacker knows your password, they cannot log in without your phone.
• Session tokens expire. Even if someone steals your session cookie, it becomes useless after you log out or after inactivity.
• Login attempts from new devices or unusual locations trigger additional verification.

Why most online banking fraud is social engineering, not system hacking:

Attackers do not break bank encryption or crack passwords. Instead, they:

• Send phishing emails that redirect to fake login pages to harvest credentials
• Call victims posing as bank support and talk them into sharing their OTP
• Use screen-sharing apps to watch victims type their credentials and OTP in real time

The common thread: the attacker needs the victim to take an action. The bank’s systems are sound. Human behaviour is the attack surface.

Network Troubleshooting — Thinking in Layers

When something is not working on a network, Sunita didi has a mental script she runs through on support calls. It mirrors the internet’s layered architecture:

1. Is the device connected? Can you ping an IP address? → If yes, the physical/network layer works
2. Is DNS working? Can you resolve domain names? → If ping-by-name fails but ping-by-IP works, it is a DNS problem
3. Is the server reachable? Can you reach the server’s port? → If DNS works but the page does not load, it is an application or firewall issue
4. Is the application working? Does the right content load? → If the server responds but the page looks wrong, it is an application issue

Thinking in layers prevents you from jumping to conclusions. “The internet is broken” is almost never true. Something specific at a specific layer is broken.

Hands-On: Investigate a Suspicious Link

These exercises teach you to investigate URLs and domains the way a security professional does — before clicking anything.

Exercise 1 — Scan a URL with VirusTotal

Before You Start: VirusTotal is a free service that checks URLs and files against dozens of antivirus and security engines simultaneously. It is the standard first tool when you receive a suspicious link.

1. Open your browser and go to virustotal.com
2. Tap the URL tab at the top
3. In the search box, paste this test URL (it is a known phishing test domain, safe to check): http://phishing.test.eicar.org
4. Tap the search icon and wait for results
5. Read the results — how many security engines flagged it? What categories do they label it?
6. Now check a legitimate site: search for https://sbi.co.in
7. Compare the results

What You’re Seeing

VirusTotal queries dozens of security engines (Kaspersky, Avast, Google Safe Browsing, ESET, and many more) and shows you their collective verdict. A phishing URL will typically be flagged by many engines. A legitimate site will show clean results across the board.

Discussion Prompt: VirusTotal shows results from many different engines. If 60 engines say “clean” and 3 say “malicious,” what would you do? Is majority vote the right metric here?

Exercise 2 — Check a Domain’s WHOIS Record

Before You Start: Every domain on the internet is registered with a creation date, registrant information, and an expiry date. WHOIS lets you look up this information. A domain registered yesterday claiming to be a major bank is a major red flag.

1. Open your browser and go to lookup.icann.org
2. In the search box, type sbi.co.in and tap Lookup
3. Note the following:
   • Creation Date — when was the domain first registered?
   • Updated Date — when was it last modified?
   • Registrar — who manages the domain registration?
   • Name Servers — which DNS servers are authoritative for this domain?
4. Now search for a suspicious-looking domain. Try sbi-kyc-update.com or make up a domain that sounds like a phishing site. If it exists, check when it was registered
5. Compare the creation date of the real sbi.co.in with any suspicious variations you find

What You’re Seeing

sbi.co.in was registered many years ago. A phishing domain impersonating SBI would typically be registered days or weeks before use — attackers do not need the domain for long, because it gets blacklisted quickly. A domain registered recently that claims to be a major bank is almost certainly fraudulent.

Discussion Prompt: WHOIS records often show “Registrant information redacted for privacy.” Why would a legitimate business hide their registrant information, and why would a fraudster hide it?

Exercise 3 — DNS Lookup and Domain Investigation

Before You Start: The Google Admin Toolbox has a DNS lookup tool that lets you query DNS records for any domain. This is useful for understanding who controls a domain and verifying that the IP it resolves to is correct.

1. Open your browser and go to toolbox.googleapps.com/apps/dig
2. In the domain field, type sbi.co.in and select record type A (which gives you IPv4 addresses)
3. Tap the Run button and note the IP address(es) returned
4. Now go to who.is and paste that IP address — this shows you who owns the IP block
5. Verify the organisation matches what you expect (SBI or a known Indian hosting provider)
6. Now do the same for npci.org.in — check the IP and verify the owner

What You’re Seeing

The A record for a domain is its IPv4 address. The IP ownership (shown by the WHOIS on the IP itself, which is different from domain WHOIS) tells you which organisation owns that block of IP addresses. For sbi.co.in, you would expect to see an IP owned by SBI or a major Indian hosting/CDN provider. A phishing domain would resolve to an IP owned by a random hosting company, often outside India.

Discussion Prompt: You receive an email saying you have a refund from IRCTC. The link goes to irctc-refund-2024.com. Walk through what you would check using the three tools from this session before deciding whether to click.

Tying It Together

You now have a professional’s toolkit for investigating suspicious links:

1. VirusTotal — has this URL already been flagged by security engines?
2. ICANN WHOIS — how old is this domain? Who registered it?
3. DNS lookup + IP WHOIS — does this domain resolve to an IP owned by who it claims to be?

Sunita didi wishes more customers used these tools before calling. In most cases, the investigation takes 30 seconds and the answer is clear. In Session 5, we put everything together — all five sessions in one walkthrough — and look at where these skills lead professionally.

Session 5 — Putting It All Together

“Deepa gets a new phone, connects to the college Wi-Fi, opens her browser, logs into her SBI net banking, and transfers ₹200 to Rohan. Walk me through every concept we’ve covered — layer by layer.”

That is the synthesis challenge. Not a quiz. Not multiple choice. A conversation where you explain the journey of a net banking session, from the moment Deepa opens the login page to the moment the transfer confirmation appears — 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.

Sunita didi closes the course — she started it with a cautionary tale about what happens without security awareness, 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 opens her SBI app, what does her phone verify before the app loads any data?
2. If someone intercepted Deepa’s net banking session in transit, what would they see?
3. Sunita didi gets a call: “My transfer failed but money was deducted.” What is the first thing she checks?

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

Synthesis: Deepa’s Bank Login

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 her college Wi-Fi, opens Chrome, and logs into SBI net banking for the first time on this device to transfer ₹200 to Rohan.

Step 1 — Connecting to Wi-Fi

Question: When Deepa’s phone connects to the college Wi-Fi, what address does it get? Is this the address the rest of the internet will see?

Answer:

Her phone gets a private IP address from the college router — something like 192.168.10.45. This is her address on the local network.

The rest of the internet will see the college network’s public IP address — the address assigned to the college’s router by the ISP. Her phone and every other device on college Wi-Fi share this one public IP as far as the internet is concerned.

The college router uses NAT (Network Address Translation) to track which private device sent which request, and routes responses back to the correct device.

Concepts used: IP addressing, private vs public IP, NAT (Session 1)

Step 2 — The Browser Finds SBI’s Server

Question: When Deepa types onlinesbi.sbi into her browser, how does it know where to send her request?

Answer:

The browser makes a DNS lookup for onlinesbi.sbi. DNS resolves this domain name to an IP address — SBI’s actual server IP.

This lookup goes to the DNS server configured on the college Wi-Fi (probably the ISP’s resolver). The resolver asks up the DNS hierarchy until it gets an authoritative answer. The IP address comes back to Deepa’s browser.

Concepts used: DNS, name resolution, DNS hierarchy (Session 1)

Step 3 — Verifying SBI’s Identity

Question: Before the app exchanges any data with SBI’s server, it needs to verify that it is talking to the real SBI. How?

Answer:

The app initiates a TLS handshake with the server. The server presents its digital certificate — a document signed by a Certificate Authority (e.g., DigiCert) that says “this public key belongs to api.onlinesbi.sbi.”

Deepa’s phone:

1. Checks that the certificate is signed by a CA in its trusted root list (pre-installed by Google in Android)
2. Walks the chain of trust from the site certificate to the Intermediate CA to the Root CA
3. Verifies the domain name in the certificate matches the server it connected to
4. Verifies the certificate has not expired and has not been revoked

Only if all checks pass does the handshake continue.

Concepts used: TLS handshake, certificates, CA trust chain, PKI (Sessions 2 & 3)

Step 4 — Establishing Encrypted Communication

Question: After the certificate is verified, what happens next? Is the connection encrypted yet?

Answer:

The TLS handshake continues. The server sends its public key (from the certificate). Deepa’s phone uses this public key to encrypt a shared secret and sends it to the server. The server decrypts it with its private key.

Now both sides have the same shared secret — a symmetric session key. From this point forward, all communication is encrypted with this session key using fast symmetric encryption (typically AES-256).

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

Concepts used: asymmetric encryption, key exchange, symmetric encryption, TLS (Session 2)

Step 5 — Deepa Transfers ₹200 to Rohan

Question: Deepa logs in with her username and password, receives an OTP on her phone, and initiates a ₹200 transfer. What is happening at each step, and where does the security apply?

Answer:

Login — username and password: Deepa’s credentials travel over the encrypted TLS connection to SBI’s server. SBI does not store her password in plaintext — it stores only a secure hash. The server computes the hash of what she typed and compares it.

OTP step: Because this is a new device, SBI sends a One-Time Password to Deepa’s registered mobile number. This is 2FA — even if an attacker knew her password, they would be blocked here without her phone. The OTP is valid for only a few minutes.

Transfer: Deepa enters Rohan’s account details and the amount. SBI may send another OTP to confirm the high-value transaction. Once confirmed:

1. SBI debits Deepa’s account
2. SBI sends a transfer instruction to Rohan’s bank through the interbank network
3. Rohan’s bank credits his account
4. Both receive an SMS confirmation

The entire session is protected by the encrypted TLS connection established in Steps 3 and 4.

Concepts used: online banking login flow, 2FA, OTP, session security (Session 4)

Step 6 — A Threat That Did Not Happen

Question: Unknown to Deepa, someone on the college Wi-Fi was running a tool that intercepts network traffic. What did the attacker see from Deepa’s session?

Answer:

Almost nothing useful. Because the entire session was encrypted with TLS:

• The attacker could see that Deepa’s device connected to an IP address (SBI’s server IP)
• The attacker could see the domain name api.onlinesbi.sbi in the DNS query (DNS is not encrypted by default) — revealing that Deepa uses SBI YONO
• The attacker could see the volume and timing of data transfers (not the content)
• The attacker could not see: the credentials, the OTP, the transaction amount, or any account details

This is why HTTPS and certificate verification matter. The attacker on the network was powerless, because the encryption was correctly implemented and the certificate was verified.

If Deepa had been using an HTTP connection (no encryption), the attacker could have read everything.

Concepts used: MITM attacks, HTTPS protection, what encryption conceals (Sessions 2 & 4)

Full Picture

Deepa's phone
  → gets private IP from college Wi-Fi (Session 1)
  → DNS resolves api.onlinesbi.sbi to SBI's server IP (Session 1)
  → TLS handshake: SBI's certificate verified via chain of trust (Sessions 2 & 3)
  → Encrypted tunnel established with session key (Session 2)
  → Login with password + OTP (2FA): session token issued (Session 4)
  → Transfer: SBI debits Deepa, credits Rohan's bank over secure interbank connection (Session 4)
  → Attacker on Wi-Fi sees encrypted noise (Sessions 2 & 4)
  → Rohan receives ₹200 (everything worked as designed)

Every session contributed something to that ₹200 arriving safely. That is the point of the course.

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.

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).

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.

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]

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]

DNS Spoofing An attack where a false DNS response sends you to an attacker’s server instead of the real one. Certificate verification is the defence. [Session 4]

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]

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]

MITM (Man-in-the-Middle) An attack where the attacker secretly positions themselves between a user and a server, potentially reading or altering the communication. HTTPS with certificate verification defeats most MITM attacks. [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]

Phishing An attack that tricks users into revealing credentials or installing malware by impersonating a trusted entity — a bank, government agency, or company. [Session 4]

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]

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]

Ransomware Malware that encrypts a victim’s files and demands payment for the decryption key. [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]

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 4]

WHOIS A protocol and associated databases that store registration information for domain names — including creation date, registrant, and registrar. Used to investigate suspicious domains. [Session 4]

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/

Attacks and Defence (Session 4)

RBI Be(Aware) Campaign The Reserve Bank of India’s public awareness resources on financial fraud. Practical, India-specific. → rbi.org.in/beaware/

Cloudflare — What Is Phishing → cloudflare.com/learning/access-management/phishing-attack/

RBI — Online Banking Safety Guidelines The Reserve Bank of India’s guidelines for safe online banking. → rbi.org.in/beaware/

CERT-In India’s Computer Emergency Response Team. Publishes advisories on active threats. Useful for staying current on what is targeting India. → cert-in.org.in

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.