HTTP and HTTPS Traffic

• Read an HTTP request and response start line, headers and body
• Explain what HTTPS actually protects and what it doesn't
• Spot suspicious web behavior in logs and captures

• Web attacks — injection, XSS, brute force, scraping — are all visible as HTTP patterns in logs.
• Status-code distributions (a flood of 401s = password attacks) are instant intrusion signals.
• Knowing HTTPS' limits prevents the classic error: assuming 'encrypted' means 'safe'.
• Every proxy, WAF and SIEM field you triage is a piece of HTTP anatomy.

HTTP is a postcard: anyone handling it can read the message. HTTPS is a sealed letter — but the envelope (sender, recipient, size, timing) is still visible to anyone who handles the mail.

• The client opens a TCP connection (often TLS-first) to the server's address and port (443 for HTTPS).
• A request line: `GET /account HTTP/1.1` plus Host and other headers.
• The server maps the path/verb through its routing and returns a status line: `HTTP/1.1 200 OK` with headers and a body.
• Status classes: 2xx success, 3xx redirect, 4xx client error, 5xx server error.
• HTTPS wraps the request/response in the TLS record layer, so the payload is encrypted mid-path (but endpoints and proxies may decrypt).
• Cookies, auth headers and parameters travel either in headers or bodies and are the usual targets of attacks.

• A WAF logs `403` bursts on `/wp-login.php` — the SOC correlates them into a credential-stuffing alert.
• A proxy captures `POST /api/orders` bodies for audit, so the incident team can prove what an API client really submitted.
• A defender filters on `HTTP/2.0` and `Set-Cookie: HttpOnly` to validate that headers were configured correctly across the fleet.

• Serve everything over HTTPS with HSTS and redirect any HTTP; an unencrypted listener leaks session data.
• Log method, URI, status and latency to a central store — HTTP logs are your cheapest intrusion sensor.
• Put sensitive data in the body over TLS, never in URLs (which leak into proxy and referrer logs).

• Believing HTTPS encrypts the hostname — the SNI field still reveals it in the handshake.
• Logging full request URIs that contain tokens then shipping those logs to a third-party SIEM.
• Treating a 200 as 'success': an attacker returning 200 with a poll page is also 'successful'.

• curl -I shows headers only — fast way to verify redirects, caching headers and TLS config.
• When HTTPS fails, split the problem: TCP (nc -zv host 443), TLS (openssl s_client -connect), HTTP (curl -k).
• In captures, filter http.request.method to see which verbs dominate on your perimeter.

• Man-in-the-middle: TLS authenticity rests on certificates and trust; on your own traffic you may install a lab CA to inspect it (authorized traffic only).
• TLS doesn't stop injection: an attacker who reaches your app speaks encrypted SQLi/XSS perfectly — that's why app-layer defenses still matter.