Computer Security
Chapter 4
Network Security Concepts and Mechanisms
Detailed Explanation with Examples
Topics Covered: Internet Structure • TCP/IP Layers • Attacker Capabilities • IPSec • SSL/TLS • SET • Email Security
1. Introduction to Internet Structure
The Internet is composed of three broad components that work together to connect billions of devices
worldwide.
1.1 Network Edge
The network edge is where end users and their applications reside — laptops, smartphones, servers, and
desktop computers. These are called hosts or end systems because they sit at the boundaries of the network.
Example: Your laptop in Addis Ababa streaming a YouTube video is a host at the network edge.
1.2 Access Networks
Access networks connect end systems to the Internet core through wired or wireless communication links. They
form the 'last mile' between users and the backbone.
Example: Your home Wi-Fi router is an access network connecting your devices to your ISP.
1.3 Network Core
The network core is a mesh of interconnected routers forming the 'network of networks' — the Internet
backbone. Data travels as small chunks called packets, forwarded hop-by-hop through routers.
Example: When you send an email from Addis Ababa to London, packets hop across dozens of routers through
multiple ISPs before arriving.
2. Internet Protocol Stack (TCP/IP Layers)
The TCP/IP model describes how data is prepared, transmitted, and received across networks. It has 5 layers,
each with a specific responsibility.
Layer Role Example Protocols
Application Supports user applications and services HTTP, FTP, SMTP, DNS
Transport End-to-end data delivery and reliability TCP, UDP
Network Routes packets across multiple networks IP, routing protocols
Data Link Transfers data between adjacent network nodes Ethernet, ARP, PPP
Physical Transmits raw bits over physical media Cables, fiber, radio waves
Encapsulation Process
When you visit a website, data is wrapped (encapsulated) at each layer as it travels down the stack, and
unwrapped at each layer on the receiving side:
• Application Layer creates an HTTP Message
• Transport Layer wraps it into a Segment (adds source/destination port numbers)
• Network Layer wraps it into a Datagram/Packet (adds source/destination IP addresses)
• Data Link Layer wraps it into a Frame (adds MAC addresses)
• Physical Layer transmits raw Bits over the wire or air
Example: Like mailing a letter: you put the letter in an envelope (Transport), write the address (Network), place it in
a postal bag (Data Link), and physically transport it (Physical).
2.1 ISO/OSI Reference Model (7 Layers)
The OSI model adds two additional layers above the Transport layer that TCP/IP omits:
• Presentation Layer: Handles data formatting, encryption, and compression (e.g., converting character
sets)
• Session Layer: Manages communication sessions — synchronization, checkpointing, and recovery
Note: The Internet TCP/IP stack does NOT implement these layers. Any session or presentation functionality must
be handled within the application itself. OSI was never fully implemented but remains an important theoretical
reference model.
3. What Can Attackers Do on a Network?
Since data travels through shared, public infrastructure, attackers have multiple opportunities to interfere.
Understanding these threats is the foundation of network security.
3.1 Eavesdropping (Passive Attack)
Passively intercepting network messages without modifying them. The sender and receiver are unaware their
communication is being monitored.
Example: A hacker on a coffee shop Wi-Fi uses Wireshark to capture unencrypted HTTP login credentials sent by
other users.
3.2 Message Insertion / Modification (Active Attack)
Injecting new packets into an ongoing connection or altering packets already in transit between sender and
receiver.
Example: An attacker intercepts a bank transfer request and changes the recipient account number before it
reaches the bank server.
3.3 Impersonation / IP Spoofing
Forging the source IP address (or any field) in a packet to make it appear as though it came from a legitimate,
trusted sender.
Example: An attacker sends packets with the source IP forged to appear as your bank's IP address, tricking your
system into trusting the communication.
3.4 Session Hijacking
The attacker monitors an authenticated session between a client and server, then takes it over by removing the
original client and inserting themselves. Since TCP connections transmit in cleartext by default, session tokens
can be stolen and reused.
Example: After you log into your webmail, an attacker on the same local network steals your session cookie and
gains full access to your account without needing your password.
3.5 Denial of Service (DoS)
Flooding a service with so many requests that it becomes overwhelmed and unavailable to legitimate users. A
Distributed DoS (DDoS) uses thousands of compromised machines simultaneously.
Example: Sending 10 million fake connection requests to a banking website causes it to crash, preventing real
customers from accessing their accounts.
4. What is Network Security? (Core Goals)
Network security is defined by four fundamental goals that every secure system must address:
Goal Description How Achieved
Confidentiality Only the intended sender and receiver can understand
Encryption
the message
(symmetric/asymmetric)
Authentication Parties confirm each other's identity Digital certificates, digital signatures
Message Integrity Message has not been altered in transit Hash functions, MACs
Availability Services remain accessible to legitimate users Anti-DoS mechanisms, redundancy
4.1 Practical Example: Alice Sends a Secure Message to Bob
This example demonstrates how confidentiality is achieved using hybrid encryption:
• Alice generates a random symmetric key (KS)
• Alice encrypts the message: E(KS, m) — fast symmetric encryption
• Alice encrypts KS with Bob's public key: E(KB+, KS) — securely delivers the key
• Alice sends both encrypted items to Bob over the Internet
• Bob decrypts KS using his private key: D(KB-, E(KB+, KS))
• Bob uses KS to decrypt the message: D(KS, E(KS, m))
Note: This hybrid approach combines the speed of symmetric encryption with the security of asymmetric key
exchange — a pattern used in SSL/TLS, SET, and most modern security protocols.
5. Security in the TCP/IP Protocol Stack
Security mechanisms can be added at different layers of the TCP/IP stack. Each placement has different
trade-offs:
Layer Mechanism Properties
Network (IP) IPSec Transparent to all applications; protects all traffic
Transport (TCP) SSL / TLS Can be app-embedded or OS-level; protects specific connections
Application S/MIME, PGP, Kerberos, SET Application-specific; fine-grained control
6. Network Protocol Vulnerabilities
The Internet was originally designed for a trusted group of researchers — not the billions of adversarial users
it now serves. This fundamental design assumption created widespread vulnerabilities.
The original vision: 'A group of mutually trusting users attached to a transparent network' — meaning security
was not a priority.
Key consequences:
• IP has no built-in authentication — anyone can forge source addresses
• Routing protocols lack authentication — a compromised router can redirect traffic
• Most protocols transmit data in cleartext — easily intercepted
• Attackers exploit vulnerabilities at every layer of the protocol stack
Note: This is why security must be considered at all layers, not just at the application level.
7. Link Layer Attack: ARP Spoofing
7.1 How ARP Works Normally
ARP (Address Resolution Protocol) maps IP addresses to MAC (hardware) addresses on a local network:
• Computer A wants to communicate with Computer B at IP [Link]
• A broadcasts an ARP request: 'Who has IP [Link]?'
• Computer B replies with its MAC address
• A saves this mapping in its ARP cache and sends data to that MAC address
Example: Like asking 'Who lives at house number 5?' in your neighborhood and the owner shouts back their name.
7.2 The ARP Spoofing Attack
An attacker sends spoofed (fake) ARP reply messages, associating their own MAC address with a legitimate
IP address such as the default gateway. All traffic meant for that IP now flows through the attacker's machine.
Example: Attacker announces: 'I am the router ([Link]) — my MAC is AA:BB:CC:DD:EE:FF.' All your internet
traffic now passes through the attacker's computer first (Man-in-the-Middle).
7.3 Why ARP Spoofing Works (Root Cause)
ARP is stateless — three critical weaknesses make it exploitable:
• Hosts automatically cache any ARP reply received, even unsolicited ones
• ARP cache entries are overwritten when a new reply arrives, even if not expired
• No authentication exists in ARP to verify the sender of a reply
ARP spoofing is commonly used as a launching pad for DoS, Man-in-the-Middle, or session hijacking attacks.
8. Network Layer Security: IPSec
8.1 Why IP is Vulnerable
• IP packets can be intercepted at LAN broadcasts, at routers, or at switches
• Packets are not encrypted by default — anyone intercepting them can read the contents
• Packets are not authenticated — they can be modified without detection
• Even with encrypted data, traffic analysis reveals who communicates with whom and when
• Routing information between routers is not authenticated — a compromised router can corrupt routing
tables
8.2 IPSec Services
IPSec (IP Security) adds security at the IP layer, providing six key services:
Service Description
Origin Authentication Verifies the packet came from the claimed source (counters IP spoofing)
Confidentiality Encrypts packet contents to prevent eavesdropping
Message Integrity Detects any modification to the packet in transit
Replay Detection Prevents attackers from re-sending old captured packets
Key Management Secure exchange and distribution of cryptographic keys
Access Control Filters packets based on security policy (SPD)
Note: IPSec is transparent to applications — companies can secure all network traffic without modifying individual
apps or servers.
8.3 IPSec Protocols
Authentication Header (AH)
Inserts an AH header into the IP packet to provide:
• Origin authentication — verifies packet source
• Message integrity — detects tampering
• Anti-replay services — prevents packet replay attacks
• Does NOT provide encryption/confidentiality
Encapsulated Security Payload (ESP)
Inserts an ESP header to provide everything AH provides, plus confidentiality (encryption). ESP is more
complex and requires more processing time.
Internet Key Exchange (IKE)
Before ESP or AH can operate, both endpoints must share cryptographic keys. IKE handles this automatic,
secure key exchange. The use of encryption always implies the need for key management.
8.4 IPSec Modes of Operation
Mode What is Protected When Used Typical Use Case
Transport Mode Upper-layer protocols (TCP/UDP);Both
original
endpoints
IP header
support
exposed
IPSec Host-to-host security within an organization
Tunnel Mode Entire original IP packet, includingAt
IPleast
header
one endpoint is a gateway
VPN between two offices over the Internet
Example: Transport Mode: Two company laptops with IPSec connecting securely through the corporate LAN.
Tunnel Mode: Branch office in Addis Ababa connecting securely to headquarters in London through an encrypted
VPN tunnel.
8.5 Security Associations (SAs)
Before secured communication begins, two parties establish a Security Association (SA) — a logical
connection defining how security services will be applied. SAs transform the connectionless IP layer into a
connection-oriented secure channel.
SA is unidirectional — two SAs are needed for bidirectional communication (one for inbound, one for
outbound).
Each SA is uniquely identified by three parameters:
• Security Parameter Index (SPI): A 32-bit value stamped on all packets belonging to the SA
• Destination IP address: The address of the SA's endpoint (end user, firewall, or router)
• Security Protocol Identifier: Specifies whether this is an AH or ESP association
8.6 IPSec Policy: SPD and SAD
IPSec policy is managed through two key databases:
• SPD (Security Policy Database): Defines policies for all inbound and outbound traffic — discard the
packet, apply security services, or forward unchanged
• SAD (Security Association Database): Contains all active SAs and their cryptographic parameters
8.7 Four Deployment Cases
Case Description Example
Case 1: Host-to-Host Full IPSec security between two end systems Two employees connecting securely within a company
Case 2: Gateway-to-Gateway
Security only between routers/firewalls (basic VPN)
Two office networks connected via encrypted tunnel
Case 3: End-to-End + Gateway
Combines Cases 1 & 2 for layered protection Office VPN + individual device security
Case 4: Host-to-Gateway Remote user accesses corporate firewall over Internet
Work-from-home employee connecting to office network
9. Transport Layer Security
9.1 TCP SYN Flood Attack
A SYN Flood exploits the TCP three-way handshake to exhaust server resources:
Step Normal Handshake SYN Flood Attack
1 Client sends SYN to server Attacker sends thousands of SYN packets with fake source IPs
2 Server sends SYN-ACK back to client Server sends SYN-ACK to fake IPs — no one responds
3 Client sends ACK — connection established
Server waits for ACKs that never come; connection table fills up
Result Normal TCP connection Server overwhelmed; real users cannot connect
Example: Like calling a restaurant 10,000 times to make fake reservations with fake names — no real customer
can book a table.
9.2 SSL/TLS – Securing TCP Connections
SSL (Secure Sockets Layer) was created by Netscape in 1994. SSL 3.0 was standardized by IETF and
renamed TLS (Transport Layer Security). It enhances TCP with four key capabilities:
• Confidentiality: Symmetric encryption of all data
• Data Integrity: MAC (Message Authentication Code) detects tampering
• Server Authentication: Server's digital certificate proves its identity
• Client Authentication: Optional — client can also present a certificate
How SSL Establishes a Secure Session
• Server sends its public key certificate to the client
• Client verifies the certificate and uses the server's public key to securely exchange key material
• Both parties negotiate a shared session key (symmetric) for the rest of the session
• All subsequent data is encrypted with this session key
Example: When you log in to Gmail: your browser verifies Google's certificate, establishes a session key, and all
your credentials travel encrypted over HTTPS.
HTTPS = HTTP over SSL/TLS
HTTPS uses port 443 (instead of HTTP's port 80). The following elements are encrypted:
• URL of the requested document
• Page contents
• Form data (passwords, credit card numbers)
• Cookies sent between browser and server
• HTTP headers
9.3 SSL Protocol Structure
Protocol Layer Sub-Protocol Function
Upper Layer SSL Handshake Protocol Authenticates server/client; negotiates algorithms and session keys
Upper Layer SSL Change Cipher Spec Activates the negotiated security settings for use
Upper Layer SSL Alert Protocol Sends error/warning messages (e.g., 'certificate expired')
Lower Layer SSL Record Protocol Fragments data, adds MAC for integrity, encrypts, transmits
10. Web Security
10.1 Why Web Security is Challenging
• The Web is highly visible — attacks can damage corporate reputation and cause significant financial loss
• Web server software is extraordinarily complex with potential hidden security flaws
• Web servers can be exploited as launch pads to attack internal corporate systems
• Users are generally unaware of the risks involved in web browsing
10.2 Types of Web Threats
Threat Category Attack Type Countermeasure
Integrity Data/memory modification, Trojan horse browser Cryptographic checksums
Confidentiality Eavesdropping, theft of client/server data, network topology
Encryption
info
Denial of Service Flooding, DNS attacks, disk/memory exhaustion, killing
Pattern
threads
detection and automated response
Authentication Impersonation, data forgery Cryptographic techniques (certificates)
10.3 Web Security Protocols
• SSL/TLS: Provides security between TCP and applications; confidentiality + integrity
• HTTPS: HTTP over SSL/TLS — the standard for secure browser-server communication
• SSH (Secure Shell): Secure remote login and file transfer (replaces telnet and FTP)
11. Application Layer Security
11.1 DNS Spoofing
If an attacker gains access to a DNS name server, they can redirect domain names to malicious IP addresses.
DNS cache poisoning inserts false mappings into a resolver's cache.
Example: Attacker redirects [Link] to their own server IP. Users type the correct URL but land on a
fake site, unknowingly entering their credentials.
11.2 Browser and Helper Application Threats
• Browsers obtained online may contain malicious code that spies on user activities or steals passwords
• Helper applications (media players, PDF readers) used by browsers may contain Trojan horse code
• Downloaded content can exploit vulnerabilities in helpers
• Browser security (e.g., SSL key length) can be silently downgraded by malicious code
11.3 Mobile Code: Java Applets & ActiveX
Mobile code migrates from a server to run on the client's machine — powerful but risky:
• Normally runs in a sandbox that restricts access to local resources
• Security manager controls what the code can access
• However, sandbox escapes are possible through Java Virtual Machine (JVM) bugs
Example: A malicious Java applet on a compromised webpage attempts to read password files from your local hard
drive by exploiting a JVM vulnerability.
11.4 Cookies and Privacy
Cookies are set by web servers and stored in browsers. When you revisit the same server, your browser
automatically sends back its cookies.
• Cookies can track user activities across sessions — serious privacy violation risk
• Third-party advertising networks use cookies to build detailed user profiles across many websites
Example: An ad network's cookie tracks that you visited a shoe store, a sports site, and a health website — building
a profile used to target you with ads.
11.5 Server-Side Risks
• Interactive web forms and server-side scripts can be exploited by malicious client inputs
• Malicious inputs can cause buffer overflows that crash or compromise the server
• Successful exploitation can give attackers full control over the server
12. Secure Electronic Transaction (SET)
12.1 Four Essential Security Requirements for E-Payments
Requirement Description Problem Addressed
Authentication Verify the buyer is a legitimate cardholder Fake credit card numbers
Encryption Protect payment data in transit Eavesdropping on card numbers
Integrity Ensure payment data is not altered Unauthorized modification of amounts
Non-repudiation Buyer cannot deny placing the order False refund claims
12.2 Why SSL Alone is Not Enough
• SSL only protects the channel between customer and merchant
• Customer is not protected from a dishonest merchant — a fake site can collect card numbers
• Merchant is not protected from dishonest customers — fake card numbers or false chargebacks
Example: A criminal sets up a fake website pretending to be [Link]. SSL encrypts the connection, but
customers are still handing their card details to a fraudster.
12.3 SET Overview
SET (Secure Electronic Transaction) was developed by Visa and MasterCard with IBM, Microsoft, RSA, and
others. SET is not a payment system itself — it enables the existing credit card infrastructure to work securely
over the Internet using cryptography.
SET's Key Privacy Innovation: Order information is hidden from the bank; payment information is hidden from
the merchant. Yet both can verify the transaction is legitimate — achieved through dual signatures.
12.4 SET Participants
Participant Role
Cardholder The customer with an authorized payment card
Merchant The online store (web server) offering goods/services
Issuer The cardholder's bank that issued the credit card
Acquirer Verifies the card is active and purchase is within credit limit
Payment Gateway Processes merchant payment messages (operated by acquirer or third party)
Participant Role
Certificate Authority (CA) Issues X.509v3 digital certificates to all parties — the cornerstone of SET's trust
Note: All parties must register with and receive digital certificates from the CA before participating in SET
transactions.
12.5 SET Transaction Flow (9 Steps)
Step Action
1 Customer browses website and selects items to purchase
2 Customer sends one message with two parts: Purchase Order (for merchant) + Payment Information (for bank only)
3 Merchant forwards Payment Information (encrypted) to its bank
4 Merchant's bank checks with the Issuer for payment authorization
5 Issuer sends authorization back to merchant's bank
6 Merchant's bank sends authorization to the merchant
7 Merchant completes the order and sends confirmation to customer
8 Merchant captures the transaction funds from its bank
9 Issuer sends credit card statement/invoice to customer
12.6 Key Technologies Used in SET
Security Goal Technology
Confidentiality DES symmetric encryption
Data Integrity RSA digital signatures with SHA-1 hash codes
Cardholder Authentication X.509v3 digital certificates with RSA signatures
Merchant Authentication X.509v3 digital certificates with RSA signatures
Privacy (separating OI from PI) Dual Signatures (SET's key innovation)
12.7 SET Dual Signature — Key Innovation
The dual signature solves a unique challenge: the customer must link their Order Information (OI) to the
merchant and Payment Information (PI) to the bank — without either party seeing the other's data.
Construction of the Dual Signature:
• Step 1: Hash OI using SHA: H(OI) = Digest 1
• Step 2: Hash PI using SHA: H(PI) = Digest 2
• Step 3: Concatenate the two digests: H(PI) || H(OI)
• Step 4: Hash the concatenation: H(H(PI) || H(OI)) = new digest
• Step 5: Encrypt new digest with customer's private key:
Dual Signature = E(KRc, H(H(PI) || H(OI)))
How Verification Works:
• Merchant verifies: Recomputes H(PIMD || H(OI)) and decrypts DS with customer's public key — both
must match. Merchant only has H(PI), not PI itself.
• Bank verifies: Recomputes H(H(PI) || OIMD) and decrypts DS with customer's public key — both must
match. Bank only has H(OI), not OI itself.
Example: Think of it like a notary sealing two documents together — both recipients can verify the seal is authentic
without reading the other's document.
13. Email Security
13.1 Why Email is Insecure by Default
• Emails transit through multiple intermediate servers before reaching the recipient
• SMTP transmits email in plaintext — anyone with server access can read messages
• SMTP has no authentication of sender identity — easy to forge 'From' addresses
Four required security features for email:
• Confidentiality: Eve should not be able to read Alice's email to Bob
• Sender Authentication: Bob must confirm the email truly came from Alice, not Trudy
• Message Integrity: Trudy should not be able to modify Alice's email in transit
• Receiver Authentication: Alice must confirm she is sending to Bob, not to an impersonator
13.2 PGP (Pretty Good Privacy)
Created by Philip R. Zimmermann as free, open-source email security software. PGP provides:
Service Mechanism Details
Authentication Digital signatures Proves message came from the claimed sender
Confidentiality Symmetric encryption Encrypts message content
Compression ZIP algorithm Reduces message size before encryption
Email compatibility Base-64 (Radix-64) encoding Converts binary data to ASCII-safe text for SMTP
Example: You install PGP and generate a key pair. Share your public key with contacts. A friend encrypts their
email using your public key. Only you can decrypt it with your private key.
13.3 SMTP Limitations and MIME
SMTP was designed for simple text and cannot handle:
• Executable files or binary files (e.g., JPEG images, ZIP archives)
• Non-ASCII 'national language' characters (e.g., Amharic, Chinese, Arabic)
• Messages over a certain size
• Lines longer than 72–254 characters
MIME (Multipurpose Internet Mail Extension) was designed to address these limitations and is now the
universal standard for email attachments and rich content.
13.4 S/MIME (Secure MIME)
An Internet standard for email security using a formal Certificate Authority (CA) model — equivalent in
functionality to PGP but using PKI infrastructure:
• Enveloped Data: Encrypted content with encrypted session keys for recipients (confidentiality)
• Signed Data: Message digest encrypted with the signer's private key (authentication + integrity)
• Clear-Signed Data: Signed but NOT encrypted — anyone can read but signature is verifiable
• Signed and Enveloped Data: Both signed and encrypted — full security
Key Difference: PGP uses a decentralized 'web of trust' (users vouch for each other). S/MIME uses formal
CA-issued certificates (like a government-issued ID).
14. Chapter Summary: Security Mechanisms by Layer
Layer Key Threat Security Mechanism Provides
Physical/Data Link Eavesdropping, ARP Spoofing ARP inspection, VLANs Link-layer isolation
Network (IP) IP Spoofing, Packet ModificationIPSec (AH + ESP) Auth, Integrity, Confidentiality
Transport (TCP) SYN Flood, Session Hijacking SSL/TLS, TCP SYN Cookies Secure connections
Application (Web) DNS Spoofing, XSS, CSRF HTTPS, DNSSEC, Content-Security-Policy
Secure web browsing
Application (Email) Phishing, Forgery, Eavesdropping
PGP, S/MIME, DKIM Secure email
Application (E-Commerce)
Credit card fraud, Repudiation SET (Dual Signatures) Secure transactions
End of Chapter 4 — Network Security Concepts and Mechanisms