SSH and TLS¶

Exercise ssh-and-tls-annex.pdf · PDF

How many machines did your packets cross the last time you ran traceroute to 1.1.1.1 from home? Around ten. Each one belongs to somebody else. And each one sees every packet that goes by. So here is a nasty question: who else read your message on the way?

Until now you asked "does the message arrive?". Today you ask "who could read it?". You are going to steal a password off the wire yourself, with one command. Then you will try again, over SSH and HTTPS, and fail. That failure is the whole lesson.

The postcard problem¶

A packet on the network is a postcard: whoever carries it can read it.

That is the analogy for the whole page. A postcard is clear text: anyone on the path can read it. A sealed envelope is encrypted: carriers know it goes from A to B, but not what is inside.

The old way to type commands on a remote machine is Telnet (standardised in 1983, RFC 854, TCP port 23). It sends every key you press as readable text. The password too. It was designed when the whole network was a few universities that trusted each other.

Read a password off the wire¶

The Exercise sheet uses the office lab: pc1 is your office PC, srv (203.0.113.10, name intranet.tramuntana.internal) is a server on the other side of the router r1. The user on srv is marta, password Tramuntana2027.

You need two terminals inside pc1: terminal A captures, terminal B works.

cd ~/lab/office && containerlab deploy -t office.clab.yml
docker exec -it clab-office-pc1 bash          # twice: terminal A and terminal B

First check which doors are open on the server (port 23 is Telnet, 22 SSH, 80 HTTP, 443 HTTPS):

nc -zv 203.0.113.10 23        # then 22, 80 and 443

Now capture a Telnet login. Start the capture first, or the login will not be in it.

A$ tcpdump -i eth1 -w /tmp/telnet.pcap port 23
B$ telnet 203.0.113.10            # log in as marta, then: whoami ; exit
A$ (Ctrl+C)
A$ tshark -r /tmp/telnet.pcap -q -z follow,tcp,ascii,0

tcpdump saves the packets to a file; tshark (Wireshark without windows) rebuilds the conversation as text. The output, shortened:

srv login:
marta
Password:
Tramuntana2027
marta@srv:~$
whoami

The screen never showed your password. The network carried it, letter by letter. Anyone on the path could have made this capture: here, the router r1 could.

SSH: a sealed envelope and a known seal¶

SSH (TCP port 22) puts the postcard in a sealed envelope, and lets you check who you are talking to.

SSH makes two promises:

Your client stores the host keys it has seen in the file ~/.ssh/known_hosts. The short form of a host key is its fingerprint. The first time you connect, SSH asks:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:6WkPajxDJZLfyn2otLz6/TPrs4JT4qCUj8ptmFfopv8.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This question is the only moment SSH needs you. Almost everybody types yes without reading. The right answer: ask the administrator of the server for the fingerprint, and compare.

The same login over SSH¶

Get the true fingerprint straight from the server (a third terminal, on the PC), then capture an SSH login:

docker exec clab-office-srv ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
A$ tcpdump -i eth1 -w /tmp/ssh.pcap port 22
B$ ssh marta@203.0.113.10         # STOP at the question, compare, then: yes
A$ (Ctrl+C)
A$ tshark -r /tmp/ssh.pcap -q -z follow,tcp,ascii,0 | head -20

The two fingerprints must be the same string. In the capture, only two things are readable: a version line such as SSH-2.0-OpenSSH_10.0p2 Debian-7+deb13u4 from each side, and a list of algorithm names. After that, nothing. No user, no password, no command.

A spy on the path still learns who talked to whom, when, on port 22, and how much. Just not what was said.

"REMOTE HOST IDENTIFICATION HAS CHANGED!"¶

If the server's key changes, SSH refuses to connect:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

There are two possible explanations: the server was reinstalled (new key), or somebody stands in the middle pretending to be it — a man-in-the-middle attack. Check with the administrator first. Only then delete the old key:

ssh-keygen -R 203.0.113.10

Today you still log in with a password, inside the envelope. Logging in with a key pair instead of a password comes in Unit 6.

HTTPS, TLS and certificates¶

The web has the same problem. HTTP (port 80) is a postcard. HTTPS (port 443) is HTTP inside TLS (Transport Layer Security), the sealed envelope of the web. TLS also protects e-mail and most of the apps on your phone.

People still say "SSL certificate". The protocol called SSL has been dead for years; the name stayed. SSL and TLS are not two options to choose between: TLS is the new name of the same family.

The identity problem, at web scale¶

With SSH you compared a fingerprint by hand. That cannot work for the millions of websites you visit for the first time. So the web uses a certificate.

A certificate is a small file that says "this public key belongs to example.com", signed by a certificate authority (CA): a company or organisation that checked it.

Your browser and operating system come with a list of CAs they trust.

flowchart LR
    SITE["<b>Website</b><br>example.com<br>(its certificate)"] -->|"signed by"| CA["<b>Certificate authority</b><br>checked who owns the name"]
    CA -->|"trusted by"| BR["<b>Your browser</b><br>ships a list of trusted CAs"]

Before it shows the padlock, the browser makes three checks:

1. Is the name in the certificate the name I asked for?
2. Is today between its two dates (valid from, valid until)?
3. Is it signed by a CA on my list?

A certificate anybody makes for themselves is self-signed. The envelope is sealed the same, but nobody trusted vouches for who sealed it. The lab's intranet has one, on purpose.

HTTP against HTTPS in a capture¶

Back in the lab, capture both kinds of web traffic:

A$ tcpdump -i eth1 -w /tmp/web.pcap port 80 or port 443
B$ curl http://intranet.tramuntana.internal/
B$ curl https://intranet.tramuntana.internal/       # fails: read the error
B$ curl -k https://intranet.tramuntana.internal/    # -k = do not check
A$ (Ctrl+C)
A$ tshark -r /tmp/web.pcap -q -z follow,tcp,ascii,0             # HTTP
A$ tshark -r /tmp/web.pcap -q -z follow,tcp,ascii,1 | head -30  # HTTPS
B$ openssl s_client -connect intranet.tramuntana.internal:443 -brief </dev/null

What you see:

A real certificate¶

On your own PC (it needs the Internet), ask a real website:

openssl s_client -connect example.com:443 -servername example.com -brief </dev/null

This time you get Protocol version: TLSv1.3 and Verification: OK: all three checks passed. In the browser you see the same: click the padlock → connection is secure → certificate. Look at who issued it and until when. In October 2026 the certificate of example.com was valid for only three months (26 Sep – 25 Dec 2026); yours will show other dates.

Close the clear-text doors of your router¶

A fresh MikroTik answers on Telnet (23), FTP (21) and HTTP (80): all clear text. In your group, switch them off and keep only the encrypted ways in:

/ip service print
/ip service disable telnet,ftp,www,api
/ip ssh set strong-crypto=yes
/ip service print

The disabled services get the flag X; ssh and winbox (port 8291, encrypted) stay. In WinBox: IP → Services, select the line, press the red cross. Then test from a PC:

nc -zv 10.G.0.1 23        # before: succeeded; after: Connection refused
ssh admin@10.G.0.1

The first-contact question appears. Compare the fingerprint with the one a second PC of your group sees: they must match.

Key takeaways¶

• A packet is a postcard: Telnet (port 23) and HTTP (port 80) send everything, passwords included, as readable text, and a sniffer on the path can copy it.
• SSH (port 22) gives encryption plus server identity: check the host key fingerprint on first contact; a changed key may mean a man-in-the-middle.
• HTTPS (port 443) is HTTP inside TLS; TLS 1.3 (2018) is current, every SSL version is forbidden.
• A certificate binds a name to a public key, signed by a CA; the browser checks name, dates and trusted signature. A self-signed certificate encrypts but proves nobody.
• Encryption hides the content, not who talks to whom, when and how much. The padlock is not a promise of honesty.

Quick check¶

Next: the same sealed envelope, but carrying a whole network inside it — VPN with WireGuard.