Routelearn.net
Course menu

Unit 7: TCP, UDP and PortsLesson 7.3.2 (14 of 20 in this unit)47 of 84 in the Network Fundamentals course

HTTPS and TLS

How TLS encrypts web traffic and how certificates prove a site is who it claims to be.

Beginner · 7 min read

HTTPS (HTTP Secure) is HTTP carried inside a TLS (Transport Layer Security) connection, which encrypts the traffic, detects tampering and lets the client verify the server’s identity through its certificate. It uses TCP port 443 by default.

In simple terms: HTTPS is the web inside a locked envelope. Nobody in between can read or change what you send without being detected, and your browser checks that the site really is who it claims to be.

A situation

You log in to your bank on a café's free Wi-Fi. Anyone else on that Wi-Fi could capture your packets. With plain HTTP, they would see your password. With HTTPS, they see only encrypted data, and your browser checks that it is talking to the real bank, not a fake site.

What it is

HTTPS is normal HTTP sent inside a TLS connection. TLS (Transport Layer Security) sits between TCP and HTTP and provides three things:

  • Encryption: the data is encrypted so that only the two ends can read it.
  • Integrity: any change to the data in transit is detected.
  • Authentication: the server proves who it is with a certificate.

HTTPS uses TCP port 443. TLS replaced an older protocol called SSL (Secure Sockets Layer), which is why people still say “SSL certificate”.

The TLS handshake

After the TCP handshake, the browser and the server run a TLS handshake. They agree on how to encrypt, exchange the values needed to build a shared secret key, and the server presents its certificate. TLS 1.3, the current version, needs only one round trip:

Step 1 of 4 · ClientHello
Browser
192.168.1.20:51600
Internet
Web server
203.0.113.10:443
Secure session
Protocol:
TLS 1.3
Cipher:
TLS_AES_256_GCM_SHA384
Server identity:
example.com (verified)

The key share lets each side work out the same secret key without ever sending the key itself over the network.

Why it works: certificates

Encryption alone is not enough, because you could set up an encrypted connection with an attacker. A certificate is a digital ID card that links a website name to a public key. It is signed by a certificate authority (CA), an organisation that checks that the site owner really controls the name.

Your browser and operating system ship with a list of trusted root CAs. A site's certificate is usually signed by an intermediate CA, which is in turn signed by a root CA. The browser follows this chain of trust up to a root it already trusts.

Browsertrusted root listexample.comsite certificateIntermediate CARoot CAbuilt into the browser
  1. 1. 1. Send the certificates. The server sends its own certificate plus the intermediate certificate.
  2. 2. 2. Check the signature. The site certificate is signed by the intermediate CA. Is the name correct, and is the certificate still valid?
  3. 3. 3. Climb the chain. The intermediate certificate is signed by a root CA that the browser already trusts, so the chain is valid.
Browser checkIf it fails
The name on the certificate matches the site“Certificate name mismatch” warning
Today is between the start and end dates“Certificate expired” warning
The chain ends at a trusted root CA“Not trusted” warning (common with self-signed certificates)

HTTPS on a Cisco router

Many routers and switches have a web interface for management. If you use it, turn off plain HTTP and use only HTTPS. These commands are based on Cisco documentation, not run on a lab device:

no ip http server

Turn off the clear-text web server on TCP 80.

ip http secure-server

Turn on the HTTPS server on TCP 443. Many IOS versions create a self-signed certificate if none is configured.

show ip http server secure status

Check that the secure server is enabled and see its port and ciphers.

A self-signed certificate is not signed by any CA, so the browser warns you. That is fine for a lab. In production, many companies sign device certificates with their own internal CA.

How to verify it from a computer

curl -v https://example.com -o /dev/null

Show the TLS details of a connection and discard the page itself.

Example output, shortened and written for this lesson:

* Connected to example.com (203.0.113.10) port 443
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=example.com
*  expire date: Dec 30 23:59:59 2026 GMT
*  issuer: C=US; O=Example Trust; CN=Example Intermediate CA
*  SSL certificate verify ok.

What to look for: the SSL connection using line shows the TLS version (TLSv1.3) and the cipher. subject is who the certificate belongs to, issuer is the CA that signed it and expire date is when it stops being valid. SSL certificate verify ok means the chain of trust and the name both checked out. The SSL Checker tool shows the same details for any public site.

Check yourself

Predict · scenario 1

You connect to https://example.com. Which part of the connection proves that the server really is example.com?

Predict · scenario 2

You browse to a router's HTTPS page and get a "not trusted" warning. What is the most likely reason?

Predict · scenario 3

With HTTPS, can someone on the same Wi-Fi read the path you request, such as /account/settings?