Day 8: TLS/SSL & Network Security
What You'll Learn Today
- The difference between symmetric and asymmetric encryption
- How TLS versions evolved from SSL to TLS 1.3
- The TLS handshake flow step by step
- How certificates and Certificate Authorities (CAs) establish trust
- Common network attacks (MITM, DDoS, ARP/DNS spoofing) and how to defend against them
- Firewall types and their role in network security
Why Network Security Matters
Every piece of data you send over the internet passes through multiple networks, routers, and switches. Without encryption, anyone along the path can read, modify, or impersonate the traffic.
flowchart LR
subgraph NoTLS["Without Encryption"]
C1["Client"] -->|"Plaintext\nPassword: secret123"| A["Attacker\n(can read everything)"]
A -->|"Plaintext"| S1["Server"]
end
subgraph WithTLS["With TLS"]
C2["Client"] -->|"Encrypted\nx7f2a9b..."| S2["Server"]
end
style NoTLS fill:#ef4444,color:#fff
style WithTLS fill:#22c55e,color:#fff
Encryption Fundamentals
Symmetric Encryption
Both parties share a single secret key used for both encryption and decryption.
flowchart LR
subgraph Symmetric["Symmetric Encryption"]
P1["Plaintext"] -->|"Encrypt with\nshared key"| CT["Ciphertext"]
CT -->|"Decrypt with\nsame key"| P2["Plaintext"]
end
style Symmetric fill:#3b82f6,color:#fff
| Algorithm | Key Size | Speed | Use Case |
|---|---|---|---|
| AES-128 | 128 bits | Very fast | General purpose encryption |
| AES-256 | 256 bits | Fast | High-security applications |
| ChaCha20 | 256 bits | Very fast (software) | Mobile devices, TLS 1.3 |
Strength: Very fast, suitable for encrypting large amounts of data. Weakness: How do you securely share the key with the other party?
Asymmetric Encryption
Uses a key pair: a public key (shared openly) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the private key, and vice versa.
flowchart LR
subgraph Asymmetric["Asymmetric Encryption"]
P1["Plaintext"] -->|"Encrypt with\nreceiver's public key"| CT["Ciphertext"]
CT -->|"Decrypt with\nreceiver's private key"| P2["Plaintext"]
end
style Asymmetric fill:#8b5cf6,color:#fff
| Algorithm | Key Size | Speed | Use Case |
|---|---|---|---|
| RSA | 2048-4096 bits | Slow | Key exchange, digital signatures |
| ECDSA | 256-384 bits | Moderate | Digital signatures (TLS certificates) |
| ECDHE | 256-384 bits | Moderate | Key exchange (TLS handshake) |
Strength: No need to share a secret key in advance. Weakness: Much slower than symmetric encryption.
How TLS Combines Both
TLS uses asymmetric encryption to exchange a symmetric key, then uses the symmetric key for the actual data transfer. This gives you the best of both worlds.
flowchart TB
subgraph Hybrid["TLS Hybrid Approach"]
ASYM["Asymmetric Encryption\n(Key Exchange)"]
SYM["Symmetric Encryption\n(Data Transfer)"]
KEY["Shared Session Key"]
end
ASYM -->|"Securely establishes"| KEY
KEY -->|"Used for fast"| SYM
style ASYM fill:#8b5cf6,color:#fff
style KEY fill:#f59e0b,color:#fff
style SYM fill:#22c55e,color:#fff
TLS Version History
| Version | Year | Status | Notes |
|---|---|---|---|
| SSL 2.0 | 1995 | Deprecated | Fundamentally broken |
| SSL 3.0 | 1996 | Deprecated | Vulnerable to POODLE attack |
| TLS 1.0 | 1999 | Deprecated | Based on SSL 3.0, various vulnerabilities |
| TLS 1.1 | 2006 | Deprecated | Minor improvements over 1.0 |
| TLS 1.2 | 2008 | Active | Widely deployed, secure with correct configuration |
| TLS 1.3 | 2018 | Active (recommended) | Faster handshake, removed insecure algorithms |
Current recommendation: Use TLS 1.3 where possible, with TLS 1.2 as a fallback. All SSL versions and TLS 1.0/1.1 should be disabled.
The TLS 1.2 Handshake
The TLS 1.2 handshake requires two round trips before encrypted data can flow.
sequenceDiagram
participant Client
participant Server
Note over Client,Server: Round Trip 1
Client->>Server: ClientHello (supported ciphers, random)
Server->>Client: ServerHello (chosen cipher, random)
Server->>Client: Certificate (server's public key)
Server->>Client: ServerKeyExchange (DH parameters)
Server->>Client: ServerHelloDone
Note over Client,Server: Round Trip 2
Client->>Server: ClientKeyExchange (DH public value)
Client->>Server: ChangeCipherSpec
Client->>Server: Finished (encrypted)
Server->>Client: ChangeCipherSpec
Server->>Client: Finished (encrypted)
Note over Client,Server: Encrypted Application Data
Client->>Server: Application Data (encrypted)
Server->>Client: Application Data (encrypted)
The TLS 1.3 Handshake
TLS 1.3 reduces the handshake to one round trip and supports 0-RTT resumption for returning clients.
sequenceDiagram
participant Client
participant Server
Note over Client,Server: Single Round Trip
Client->>Server: ClientHello + KeyShare
Server->>Client: ServerHello + KeyShare + Certificate + Finished
Client->>Server: Finished
Note over Client,Server: Encrypted Application Data
Client->>Server: Application Data (encrypted)
Server->>Client: Application Data (encrypted)
| Feature | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake round trips | 2 RTT | 1 RTT (0-RTT for resumption) |
| Key exchange | RSA or DHE | Only (EC)DHE |
| Cipher suites | Many (some insecure) | 5 strong suites only |
| Forward secrecy | Optional | Mandatory |
| Removed features | - | RSA key exchange, RC4, SHA-1, CBC mode |
Forward Secrecy
Forward secrecy (also called perfect forward secrecy) means that even if the server's private key is compromised in the future, past recorded sessions cannot be decrypted. This is achieved by using ephemeral keys (ECDHE) that are generated fresh for each session.
Certificates and Certificate Authorities
What Is a Certificate?
A digital certificate (X.509) binds a public key to an identity (domain name). It is signed by a trusted Certificate Authority (CA).
flowchart TB
subgraph Chain["Certificate Chain of Trust"]
ROOT["Root CA\n(pre-installed in OS/browser)"]
INT["Intermediate CA\n(signed by Root CA)"]
LEAF["Server Certificate\n(signed by Intermediate CA)"]
end
ROOT -->|"Signs"| INT
INT -->|"Signs"| LEAF
style ROOT fill:#ef4444,color:#fff
style INT fill:#f59e0b,color:#fff
style LEAF fill:#22c55e,color:#fff
Certificate Contents
| Field | Description | Example |
|---|---|---|
| Subject | Domain the certificate is for | CN=www.example.com |
| Issuer | CA that signed the certificate | CN=Let's Encrypt Authority X3 |
| Validity | Not Before / Not After dates | 2024-01-01 to 2024-04-01 |
| Public Key | Server's public key | RSA 2048-bit or ECDSA P-256 |
| Signature | CA's digital signature | Proves the CA vouches for this certificate |
| SAN | Subject Alternative Names | example.com, www.example.com, *.example.com |
Certificate Types
| Type | Validation Level | What CA Verifies | Issuance Time |
|---|---|---|---|
| DV (Domain Validation) | Domain ownership only | DNS or HTTP challenge | Minutes |
| OV (Organization Validation) | Domain + organization identity | Business registration | Days |
| EV (Extended Validation) | Extensive organization check | Legal identity, physical address | Weeks |
Let's Encrypt
Let's Encrypt is a free, automated CA that issues DV certificates. It uses the ACME protocol to verify domain ownership.
# Issue a certificate with certbot
sudo certbot --nginx -d example.com -d www.example.com
# Check certificate details
openssl s_client -connect example.com:443 -servername example.com
openssl x509 -in cert.pem -text -noout
HTTPS
HTTPS is simply HTTP over TLS. The browser establishes a TLS connection first, then sends HTTP requests through the encrypted tunnel.
| Aspect | HTTP | HTTPS |
|---|---|---|
| Port | 80 | 443 |
| Encryption | None | TLS |
| URL scheme | http:// |
https:// |
| SEO impact | Neutral | Positive ranking signal |
| Browser indicator | "Not secure" warning | Padlock icon |
HSTS (HTTP Strict Transport Security)
HSTS tells browsers to always use HTTPS for a domain, even if the user types http://.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Common Network Attacks
Man-in-the-Middle (MITM)
An attacker positions themselves between the client and server, intercepting or modifying traffic.
flowchart LR
subgraph MITM["Man-in-the-Middle Attack"]
C["Client"]
A["Attacker\n(intercepts traffic)"]
S["Server"]
end
C -->|"Thinks it's talking\nto the server"| A
A -->|"Forwards to\nreal server"| S
style A fill:#ef4444,color:#fff
style C fill:#3b82f6,color:#fff
style S fill:#22c55e,color:#fff
Defense: TLS with proper certificate validation. The attacker cannot forge a valid certificate for the target domain.
DDoS (Distributed Denial of Service)
An attacker overwhelms a server with traffic from many sources, making it unavailable to legitimate users.
| DDoS Type | Layer | Method | Example |
|---|---|---|---|
| Volumetric | L3/L4 | Flood bandwidth | UDP flood, DNS amplification |
| Protocol | L3/L4 | Exploit protocol weaknesses | SYN flood, Ping of Death |
| Application | L7 | Exhaust server resources | HTTP flood, Slowloris |
Defense: Rate limiting, CDN/DDoS protection services (Cloudflare, AWS Shield), SYN cookies, traffic analysis.
ARP Spoofing
On a local network, the attacker sends fake ARP replies to associate their MAC address with another host's IP (typically the gateway). This redirects local traffic through the attacker.
Defense: Static ARP entries, Dynamic ARP Inspection (DAI) on managed switches, network monitoring.
DNS Spoofing / Cache Poisoning
The attacker injects false DNS records into a resolver's cache, redirecting users to malicious servers.
Defense: DNSSEC (validates DNS responses), DNS over HTTPS/TLS, randomized source ports and query IDs.
flowchart TB
subgraph Attacks["Common Attack Vectors"]
MITM_A["MITM\nIntercept traffic"]
DDOS_A["DDoS\nOverwhelm with traffic"]
ARP_A["ARP Spoofing\nRedirect local traffic"]
DNS_A["DNS Spoofing\nPoison DNS cache"]
end
subgraph Defenses["Defenses"]
TLS_D["TLS / HTTPS"]
RATE_D["Rate Limiting / CDN"]
DAI_D["DAI / Static ARP"]
DNSSEC_D["DNSSEC / DoH"]
end
MITM_A --> TLS_D
DDOS_A --> RATE_D
ARP_A --> DAI_D
DNS_A --> DNSSEC_D
style Attacks fill:#ef4444,color:#fff
style Defenses fill:#22c55e,color:#fff
Firewalls
A firewall controls network traffic based on predefined rules. It is the first line of defense for any network.
Firewall Types
| Type | Layer | Description |
|---|---|---|
| Packet Filter | L3/L4 | Inspects source/destination IP and port; simple, fast |
| Stateful Inspection | L3/L4 | Tracks connection state; allows return traffic automatically |
| Application Layer (WAF) | L7 | Inspects HTTP content; blocks SQL injection, XSS |
| Next-Gen (NGFW) | L3-L7 | Deep packet inspection, IDS/IPS, application awareness |
Firewall Rule Example
# iptables example: Allow SSH, HTTP, HTTPS; deny everything else
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -j DROP
flowchart LR
subgraph FW["Firewall"]
RULE1["Rule 1: Allow SSH (22)"]
RULE2["Rule 2: Allow HTTP (80)"]
RULE3["Rule 3: Allow HTTPS (443)"]
DEFAULT["Default: DENY"]
end
IN["Incoming Traffic"] --> RULE1
RULE1 --> RULE2 --> RULE3 --> DEFAULT
style FW fill:#f59e0b,color:#fff
Security Best Practices
| Practice | Description |
|---|---|
| Default deny | Block all traffic by default; explicitly allow only what is needed |
| Least privilege | Grant minimal network access required for each service |
| Defense in depth | Multiple layers of security (firewall + TLS + WAF + monitoring) |
| Regular updates | Patch operating systems, applications, and firmware promptly |
| Logging and monitoring | Record and review network activity for anomalies |
Summary
| Concept | Description |
|---|---|
| Symmetric Encryption | Single shared key (AES, ChaCha20); fast for bulk data |
| Asymmetric Encryption | Public/private key pair (RSA, ECDSA); used for key exchange |
| TLS Hybrid | Asymmetric for key exchange, symmetric for data transfer |
| TLS 1.3 | 1-RTT handshake, mandatory forward secrecy, fewer cipher suites |
| Certificate | X.509 document binding a public key to a domain identity |
| Certificate Authority | Trusted third party that signs certificates |
| HTTPS | HTTP over TLS; standard for secure web communication |
| MITM Attack | Attacker intercepts communication between two parties |
| DDoS Attack | Overwhelms a server with traffic from distributed sources |
| ARP / DNS Spoofing | Redirects traffic by poisoning local ARP or DNS caches |
| Firewall | Controls traffic based on rules (packet filter, stateful, WAF) |
Key Takeaways
- TLS combines asymmetric and symmetric encryption for security and performance
- TLS 1.3 is significantly faster (1-RTT) and more secure than TLS 1.2
- Certificate chains establish trust from root CAs down to server certificates
- Every public-facing service should use HTTPS with HSTS
- Security requires defense in depth: encryption, firewalls, monitoring, and patching
Practice Problems
Beginner
Use openssl s_client -connect www.google.com:443 to inspect the TLS connection. Identify the TLS version, cipher suite, and certificate issuer. Explain what each piece of information tells you about the security of the connection.
Intermediate
A company operates a web application that handles credit card payments. Design a security architecture that includes: which TLS version and cipher suites to support, certificate type and renewal strategy, firewall rules, and HSTS configuration. Justify each choice.
Advanced
You capture the following attack scenario: an attacker on the same Wi-Fi network is performing ARP spoofing to become a man-in-the-middle, then uses a self-signed certificate to intercept HTTPS traffic. Explain step by step: (1) how the ARP spoofing redirects traffic, (2) why the HTTPS interception would trigger a browser warning, (3) what happens if the user ignores the warning, and (4) three countermeasures that would prevent this attack from succeeding.
References
- RFC 8446 - TLS 1.3
- RFC 5246 - TLS 1.2
- Let's Encrypt Documentation
- OWASP - Transport Layer Security Cheat Sheet
- Cloudflare - What Is a DDoS Attack?
- Mozilla SSL Configuration Generator
Next up: In Day 9, we'll explore "Wireless Networking & VPN." You'll learn about Wi-Fi standards and security protocols, how VPNs create encrypted tunnels, and the differences between IPsec, OpenVPN, and WireGuard!