6 min read
On this page

Network Security Applied

Network security applies cryptographic protocols and architectural principles to protect data in transit and control access to services. Modern networks combine encryption, authentication, and segmentation to defend against interception and unauthorized access.

TLS 1.3 Handshake

TLS 1.3 handshake flow

TLS 1.3 (RFC 8446) dramatically simplified the handshake compared to TLS 1.2, reducing it from two round-trips to one (or zero with 0-RTT).

Full Handshake (1-RTT)

Client                                Server
  |                                     |
  |--- ClientHello ------------------>  |   Key share, supported ciphers
  |                                     |
  |  <--- ServerHello ----------------  |   Key share, chosen cipher
  |  <--- {EncryptedExtensions} ------  |   (encrypted from here)
  |  <--- {Certificate} --------------  |
  |  <--- {CertificateVerify} --------  |
  |  <--- {Finished} -----------------  |
  |                                     |
  |--- {Finished} ------------------->  |
  |                                     |
  |  ====== Application Data ========  |

Key changes from TLS 1.2:

  • Only 5 cipher suites (all AEAD): TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, etc.
  • RSA key exchange removed — all key exchanges use ephemeral Diffie-Hellman (forward secrecy by default).
  • Server encrypts after ServerHello — certificates are never sent in plaintext.
  • 0-RTT resumption possible (but vulnerable to replay attacks).

Key Exchange

TLS 1.3 uses ephemeral (EC)DHE exclusively:

  1. Client generates ephemeral key pair, sends public key in ClientHello.
  2. Server generates ephemeral key pair, sends public key in ServerHello.
  3. Both derive the shared secret independently.
  4. Key schedule derives handshake keys, then application keys.

Forward secrecy: Compromising the server's long-term private key does not compromise past sessions, because session keys are ephemeral.

Certificate Transparency

Problem: Certificate Authorities can issue fraudulent certificates. CT provides public, append-only logs of all issued certificates.

Components:

  • CT Logs: Append-only Merkle trees of certificates. Multiple independent logs exist.
  • Signed Certificate Timestamp (SCT): Proof that a certificate has been submitted to a log.
  • Monitors: Watch logs for unauthorized certificates for their domains.

How it works: CAs submit certificates to CT logs before issuance. The log returns an SCT. Browsers require SCTs (typically from 2-3 logs) to trust a certificate.

Public Key Infrastructure (PKI)

PKI provides the trust framework for authenticating public keys.

Certificate Chain

Root CA (self-signed, embedded in OS/browser trust store)
  └── Intermediate CA (signed by Root)
        └── End-entity certificate (signed by Intermediate)

Validation: Verify each signature up the chain. Check revocation status (CRL or OCSP). Verify the domain matches the certificate's Subject Alternative Name (SAN).

Certificate revocation:

  • CRL (Certificate Revocation List): Periodically published list of revoked certificates. Can be large and stale.
  • OCSP (Online Certificate Status Protocol): Real-time revocation check. Privacy concern — CA knows which sites you visit.
  • OCSP Stapling: Server fetches its own OCSP response and staples it to the TLS handshake. Solves the privacy and availability problems.

VPN Technologies

IPsec

Operates at the network layer (Layer 3). Two modes:

Transport mode: Encrypts only the payload. Used for host-to-host communication.

Tunnel mode: Encrypts the entire IP packet and encapsulates it in a new IP header. Used for site-to-site VPNs.

Protocols:

  • IKE (Internet Key Exchange): Establishes security associations (SAs). IKEv2 is the current standard.
  • ESP (Encapsulating Security Payload): Provides confidentiality, integrity, and authentication.
  • AH (Authentication Header): Integrity and authentication only (no encryption). Rarely used.

WireGuard

A modern VPN protocol designed for simplicity and performance.

Key properties:

  • ~4,000 lines of code (vs ~400,000 for OpenVPN).
  • Fixed cryptographic suite: Curve25519 (key exchange), ChaCha20-Poly1305 (encryption), BLAKE2s (hashing), SipHash (hashtable keys).
  • Operates at Layer 3. Implemented as a kernel module (Linux) or userspace (other platforms).
  • Cryptokey Routing: Each peer has a public key and a list of allowed IP addresses. Routing is determined by which peer's key can decrypt the packet.
  • Silent to unauthenticated packets — does not respond to probes.
# WireGuard configuration
[Interface]
PrivateKey = <base64-encoded private key>
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <base64-encoded public key>
AllowedIPs = 10.0.0.2/32, 192.168.1.0/24
Endpoint = peer.example.com:51820
PersistentKeepalive = 25

SSH (Secure Shell)

SSH provides encrypted remote access, file transfer, and tunneling.

Authentication Methods

  1. Password: Encrypted by the SSH tunnel but vulnerable to brute force.
  2. Public key: Client proves possession of private key. Most secure common method.
  3. Certificate-based: SSH certificates signed by a CA. Scales to large organizations.
  4. GSSAPI/Kerberos: Single sign-on in enterprise environments.

SSH Tunneling

Local port forwarding: Access a remote service through the SSH tunnel.

ssh -L 8080:internal-db:5432 bastion-host
# Connects local:8080 → bastion → internal-db:5432

Remote port forwarding: Expose a local service to the remote network.

ssh -R 9090:localhost:3000 remote-host
# Connects remote:9090 → tunnel → localhost:3000

Dynamic port forwarding (SOCKS proxy): Route arbitrary traffic through the tunnel.

ssh -D 1080 bastion-host
# Creates SOCKS5 proxy on localhost:1080

SSH Hardening

  • Disable password authentication: PasswordAuthentication no
  • Use Ed25519 keys: ssh-keygen -t ed25519
  • Limit users: AllowUsers deploy admin
  • Use fail2ban or sshguard to block brute force attempts.

Network Segmentation

Dividing a network into isolated segments limits lateral movement after a breach.

Techniques:

  • VLANs: Layer 2 isolation. Not a security boundary on their own (VLAN hopping attacks exist).
  • Firewalls: Stateful packet inspection between segments. Define allow-rules between zones.
  • Microsegmentation: Per-workload firewall rules, often implemented in software (SDN). Each service can only communicate with explicitly allowed peers.
  • DMZ (Demilitarized Zone): Public-facing servers isolated from the internal network. Two firewalls: external (internet ↔ DMZ) and internal (DMZ ↔ LAN).
Internet ──[FW]── DMZ (web, mail) ──[FW]── Internal LAN
                                              ├── Workstations
                                              ├── Database segment
                                              └── Management segment

Zero-Trust Architecture

Principle: "Never trust, always verify." No implicit trust based on network location.

Core Tenets

  1. Verify explicitly: Authenticate and authorize every request based on all available data (identity, device health, location, service).
  2. Least-privilege access: Just-in-time and just-enough access. Time-bounded permissions.
  3. Assume breach: Minimize blast radius. Segment access. Encrypt all traffic (even internal). Monitor continuously.

Implementation Components

  • Identity provider (IdP): Centralized authentication with MFA (e.g., Okta, Azure AD).
  • Policy engine: Evaluates access requests against policies considering user, device, resource, and context.
  • Policy enforcement point: Proxy or gateway that enforces the policy engine's decisions.
  • Device trust: Managed devices with health attestation (patched, encrypted, compliant).
  • Microsegmentation: Network controls that enforce per-service access policies.

Zero-Trust vs Perimeter Security

| Aspect | Perimeter Model | Zero Trust | |--------|----------------|------------| | Trust boundary | Network edge | None (per-request) | | Internal traffic | Trusted | Encrypted and authenticated | | Access control | VPN + network ACLs | Identity-aware proxy | | Lateral movement | Easy after breach | Contained per segment |

Intrusion Detection and Prevention

IDS Types

Network IDS (NIDS): Monitors network traffic at strategic points. Examples: Snort, Suricata, Zeek (Bro).

Host IDS (HIDS): Monitors activity on individual hosts — file integrity, log analysis, system calls. Examples: OSSEC, Wazuh, osquery.

Detection Methods

Signature-based: Matches known attack patterns. Fast and low false-positive rate but cannot detect novel attacks.

Anomaly-based: Establishes a baseline of "normal" behavior and flags deviations. Can detect unknown attacks but has higher false-positive rates.

Stateful protocol analysis: Understands protocol state machines and detects violations (e.g., unexpected commands in an FTP session).

IDS vs IPS

An IDS passively monitors and alerts. An IPS sits inline and can actively block malicious traffic.

Deployment: IDS typically uses a network tap or SPAN port (passive). IPS is deployed inline between network segments. False positives in an IPS cause availability issues, so tuning is critical.

Suricata Rule Example

alert http $EXTERNAL_NET any -> $HOME_NET any (
    msg:"Possible SQL Injection in URI";
    flow:established,to_server;
    http.uri;
    content:"UNION"; nocase;
    content:"SELECT"; nocase;
    sid:1000001; rev:1;
)

Network security is most effective when deployed in layers: encryption in transit (TLS, VPN), authentication at every boundary (zero trust), segmentation to limit blast radius, and continuous monitoring (IDS/IPS) to detect what defenses miss.