HTTP, HTTPS and Ports

Your browser now knows the address of a server. But a server runs many programs at once: a website, a mail service, a remote administration tool. How does a request reach the right one? And what exactly does the browser say once connected? This lesson covers ports, the HTTP protocol that carries the web, and what HTTPS adds. Web security, the subject of the next course in this track, is built entirely on these notions.

Last lesson ended with a resolved name. We now move one layer up and look at the conversation itself.

Ports: the apartments in the building

An IP address is like the address of a building. Inside, there are many apartments, and each program listens at one of them. The apartment number is the port, a number between 0 and 65535. A connection is therefore identified by four values: source address, source port, destination address and destination port.

Ports are split into three families:

• Well-known ports (0 to 1023): reserved by convention for standard services.
• Registered ports (1024 to 49151): used by many applications.
• Dynamic or ephemeral ports (49152 and above, though systems vary): picked automatically by your computer for the client side of a connection.

When your browser connects to a website, the server side uses a fixed port (443 for HTTPS), while your computer picks a random high port for itself, so replies can be matched to the right program.

Port	Protocol	Service
22	TCP	SSH (secure remote shell)
25	TCP	SMTP (mail delivery between servers)
53	UDP/TCP	DNS
80	TCP	HTTP
443	TCP	HTTPS
445	TCP	SMB (Windows file sharing)
3389	TCP	RDP (Windows remote desktop)

A port is said to be open when a program is listening on it, closed when nothing listens and the system answers "no one here", and filtered when a firewall silently drops the packets. Every open port is a door, so a core principle of hardening is: keep open only the ports you need. You can list the ports your own computer listens on with ss -tuln (Linux), netstat -an (Windows and macOS) or lsof -i -P -n | grep LISTEN (macOS).

HTTP: a conversation in plain text

HTTP (HyperText Transfer Protocol) is the language of the web. It is a simple request-and-response protocol: the client asks, the server answers, and the connection can then be reused or closed. A request has a method, a path, headers and sometimes a body. Here is a minimal example, written for illustration:

GET /products?category=books HTTP/1.1
Host: shop.example.com
User-Agent: ExampleBrowser
Accept: text/html
Cookie: session=abc123

The server replies with a status line, headers and a body:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session=abc123; Secure; HttpOnly
Content-Length: 5120

<html> ... </html>

Methods

GET asks for a resource and should not change anything. POST sends data to be processed, such as a form. PUT and DELETE create, replace or remove a resource. HEAD asks only for the headers. OPTIONS asks what is allowed. When you test web applications later, you will care about which methods a server accepts.

Status codes

• 2xx success: 200 OK, 201 Created.
• 3xx redirection: 301 permanent, 302 temporary.
• 4xx client error: 400 Bad Request, 401 Unauthorized (not authenticated), 403 Forbidden (authenticated but not allowed), 404 Not Found.
• 5xx server error: 500 Internal Server Error, 503 Service Unavailable.

Headers and cookies

HTTP itself is stateless: each request is independent. To remember that you are logged in, the server gives you a cookie in a Set-Cookie header, and your browser sends it back with every later request. That cookie is effectively your temporary key, which is why protecting it matters so much. Attributes such as Secure (send only over HTTPS) and HttpOnly (hide from page scripts) reduce the risk of theft. The Mozilla developer documentation at developer.mozilla.org is an excellent, neutral reference for all of these headers.

HTTPS: HTTP inside an encrypted tunnel

Plain HTTP travels in clear text. Anyone on the path, such as a person on the same public Wi-Fi, can read it or alter it. HTTPS is simply HTTP carried inside a TLS connection. Before any HTTP is exchanged, client and server perform a TLS handshake: the server proves its identity with a certificate, and both sides agree on keys used to encrypt everything that follows. We explain the mechanics in chapter 6; for now, keep the practical consequences in mind.

• HTTPS protects the content in transit: URL path, headers, cookies and body are encrypted.
• It does not hide who you are talking to. The destination address and, usually, the server name remain visible to the network.
• It does not make a website trustworthy. A fraudulent site can also have a valid certificate. The padlock means "the connection is encrypted to the site whose name is in the address bar", not "this site is honest".

This is why a well-configured site redirects port 80 to port 443 and tells browsers to always use HTTPS.

Seeing HTTP with your own eyes

The curl command lets you speak HTTP from a terminal. The -I option asks only for headers and -v shows the whole conversation. Use it on example.com or on a site you own:

curl -I https://example.com
curl -v http://example.com

Notice how the verbose output shows the connection step, the request line you sent and the response headers. Your browser does exactly the same, with many more headers. You can also open the developer tools of your browser (the "Network" tab) to watch real requests, their methods, status codes and cookies.

Your turn: map a web conversation

Run curl -I against http://example.com and against https://example.com. In your lab notebook, note the status code and the first three response headers for each. Then run the listening-ports command for your system and write down three open ports on your own machine, with the program that uses each one if you can find it. Finally, answer: if a web server in your lab listens on port 8080 instead of 80, what must you write in a URL to reach it?

See a solution

You will usually see 200 OK (or a redirect code such as 301 or 308 if the site forces HTTPS), together with headers such as Content-Type, Content-Length or Date. The listening ports depend on your machine: a typical personal computer may listen on a few local-only ports (addresses such as 127.0.0.1) for development tools or system services. A port bound to 127.0.0.1 is reachable only from the machine itself, while one bound to 0.0.0.0 accepts connections from the network, which is much more exposed. For the web server on 8080, the URL is http://address:8080/: when a service uses a non-default port, it must be written after a colon.