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

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!