3.2 HTTP, TLS, VPN, Web Browsing, and Email Transmission

Once the handshake is up, the SOC ticket is usually about what the application said. This independent study section covers the rest of the Network Essentials cluster named in SAL1 training content: HTTP, Secure Sockets Layer (SSL)/TLS, virtual private network (VPN) scenarios, and the workflows of web browsing and email transmission. OpenExamPrep is teaching those protocol facts for learners preparing for SAL1 topics. It is not an official TryHackMe course and does not invent a SAL1 score weight for HTTP or mail.

HTTP methods and why they appear in logs

HTTP is a request/response protocol. A request starts with a method, a target, and a version (GET /login HTTP/1.1), then headers, then an optional body. HTTP/2 and HTTP/3 change framing on the wire but keep the same method and status vocabulary in server logs.

Status codes: classes and SOC-relevant numbers

HTTP status codes are three-digit numbers. The first digit is the class.

Memorize these eight because they dominate web and WAF tickets:

• 200 OK. Successful GET or POST. In a WAF or web log, 200 on /wp-login.php from one IP after hundreds of failures is brute force with a hit—not “the page worked, close the ticket.”
• 301 Moved Permanently and 302 Found. 301 should update bookmarks and caches; 302 should not be treated as permanent. If Location points off-domain, investigate the redirect. Do not dismiss it as “just HTTP.”
• 401 Unauthorized. Authentication is missing or failed. For HTTP authentication the response should include WWW-Authenticate. Users often say “unauthorized” when they mean 403.
• 403 Forbidden. The server understood the request and refuses. The user may already be authenticated (authorization failure), or a WAF may emit 403 for a blocked signature.
• 404 Not Found. No resource. A directory-busting tool produces long runs of 404 with occasional 200.
• 500 Internal Server Error. Unhandled exception. SQL injection and template injection often first appear as 500s during probing.
• 502 Bad Gateway. A proxy, load balancer, or WAF could not get a valid response from upstream. Correlate with the reverse-proxy error log, not only the app container.

Other 5xx codes you will meet: 503 Service Unavailable (overload or maintenance) and 504 Gateway Timeout (upstream too slow). They are siblings of 502, not substitutes for 401.

Cookies versus headers

Every HTTP header is a name/value pair on the request or response (Host, User-Agent, Authorization, Content-Type, Referer, Origin). A cookie is not a separate protocol. The server sends Set-Cookie; the browser stores the cookie and returns it on later requests as Cookie: name=value.

Flags that change incident impact:

• HttpOnly: JavaScript on the page cannot read the cookie (reduces some cross-site scripting token theft).
• Secure: the cookie is sent only on HTTPS.
• SameSite: controls cross-site sending (Strict, Lax, None).

Authorization: Bearer … is a header, not a cookie. Session tokens can travel in either place. When a proxy strips Cookie but leaves Authorization, API clients still authenticate.

Worked header pair: the response includes Set-Cookie: sid=8f3a; HttpOnly; Secure; SameSite=Lax. The next request includes Cookie: sid=8f3a plus Host: shop.example.com. The session identifier is the cookie value; the Host header chooses the virtual site on a shared IP.

TLS handshake at analyst resolution

TLS is the current name. SSL 3.0 is obsolete and should not be offered. HTTPS is HTTP over TLS and typically listens on TCP/443. After the TCP three-way handshake:

1. ClientHello. Advertises TLS versions, cipher suites, Application-Layer Protocol Negotiation (ALPN) such as h2 or http/1.1, and Server Name Indication (SNI)—the hostname the client wants (for example shop.example.com). On TLS 1.2, SNI is visible in cleartext. TLS 1.3 encrypts more of the handshake; SNI is still often visible unless Encrypted Client Hello (ECH) is in use.
2. ServerHello. Chooses version and cipher.
3. Certificate. The server proves identity. On TLS 1.2 you can often read the certificate from the capture. On TLS 1.3 the certificate is encrypted. Check Common Name (CN) and Subject Alternative Name (SAN) against the hostname, walk the issuer chain, and read not-before / not-after dates.
4. Key exchange and Finished messages. After this, Application Data records carry HTTP.

Without TLS interception, a network sensor sees destination IP, destination port 443, SNI (if visible), certificate metadata (if visible), JA3/JA4-style client fingerprints, and byte counts—not the URL path. That is why DNS logs and SNI together matter for “who talked to which site.”

Self-signed or wrong-host certificates produce browser warnings; malware command-and-control and broken middleboxes produce the same class of error. An intercepting corporate proxy presents its own certificate; the client must trust the enterprise root or the handshake fails.

VPN versus proxy

A user on a VPN appears to internal systems as the VPN pool address (for example 10.255.8.40). A user on a forward proxy appears as the proxy’s egress IP on the internet. A reverse proxy sits in front of your servers and is the destination clients hit. If Zeek shows the client talking to 203.0.113.10:443 but the web server log shows an internal proxy address as the client, a forward proxy or TLS-inspecting firewall sat in the middle.

Worked workflow: browsing https://shop.example.com/cart

Walk the failure point, not the slogan “website down.”

1. The browser checks cache and HTTP Strict Transport Security (HSTS). It will not downgrade to clear HTTP if HSTS says HTTPS only.
2. DNS. The stub resolver sends a UDP/53 query (or DNS over HTTPS/TLS if the endpoint is configured that way) for shop.example.com. The recursive resolver returns 203.0.113.50. A missing, timed-out, or poisoned answer dies here—before TCP.
3. TCP. Three-way handshake to 203.0.113.50:443 from an ephemeral client port (see section 3.1).
4. TLS. ClientHello with SNI shop.example.com. The certificate SAN includes shop.example.com. Keys are agreed. ALPN may select HTTP/2.
5. HTTP. GET /cart with Host: shop.example.com (HTTP/1.1) or the HTTP/2 equivalent. A Cookie header may carry the session. The response is 200 with HTML, or 302 to /login.

If DNS fails, you will not see a ClientHello to the shop. If TCP fails, you will not see HTTP status codes. If TLS fails (untrusted cert, name mismatch), the GET never happens. Name the broken step in the ticket.

Worked workflow: sending email

Actors: Mail User Agent (MUA) (Thunderbird, Outlook, Apple Mail), Mail Submission Agent (MSA) / Mail Transfer Agent (MTA), Mail Delivery Agent (MDA).

1. Alice’s MUA submits the message to her provider’s MSA. Modern submission uses TCP/587 with STARTTLS (RFC 6409) or implicit TLS on TCP/465. Port 25 from a laptop egress is often blocked to cut spam bots.
2. The MSA authenticates Alice (password or OAuth) and may rewrite headers.
3. MTAs relay toward the recipient. Server-to-server SMTP uses TCP/25. Each hop looks up the destination Mail Exchange (MX) record in DNS (for bob@example.net, query MX of example.net).
4. The receiving MDA stores the message in Bob’s mailbox.
5. Bob’s MUA retrieves mail with Internet Message Access Protocol (IMAP) on 143 or IMAPS on 993, or Post Office Protocol version 3 (POP3) on 110 or POP3S on 995.

Each SMTP hop prepends a Received: header (newest hop at the top). Those lines carry hostnames, IP addresses, and timestamps. That is enough to start path reconstruction. A spoofed From: display name is cheap. A coherent Received chain plus later authentication results (Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), Domain-based Message Authentication, Reporting, and Conformance (DMARC)) is the real story. Those authentication checks and full phishing-header work belong in a later social-engineering chapter—do not stop at “the From line looks official.”

Ports an analyst should recognize on sight

TryHackMe does not publish an official SAL1 weight for this port list. Learn the numbers because they appear in firewall denies, Zeek, and SOC-simulator network evidence. If you see 589 in a scan dump, look up the process—do not invent an SMTP story for EyeLink.