Encryption in the network: what it hides and what not

From the Caesar cipher and frequency analysis to today: what is visible on the cable and what encryption really hides, three properties (confidentiality, integrity, authenticity), symmetric and asymmetric ciphers and why they are used together, password hashing with salt and pepper, the TLS handshake step by step, what a certificate holds and why the browser complains, the chain of trust and an internal company authority, the limits of encryption (a compromised computer, firewall decryption, metadata) and the practical order of what to encrypt first.

Lesson 1: From Caesar to today

The Caesar cipher

Encryption is not an invention of the internet – people needed to write so a messenger could not read it long before the first cable existed. The best-known old example is named after a Roman commander: the Caesar cipher. It works so simply you can try it on paper. You take the alphabet and replace every letter of the message with the letter a few places further on. With a shift of three, A becomes D, B becomes E and so on; at the end of the alphabet you simply continue from the start. The number you shift by is the key. Whoever knows it reads the message easily: shift the letters back. Whoever does not sees a meaningless row of letters. This simple example already shows everything essential that holds for today’s ciphers too. First, the procedure (shift the letters) is separate from the key (by how much). Second, both sides must somehow know the key in advance – and how a key gets delivered is a problem that will accompany you through the whole course. And third: the strength of the protection depends on how many different keys come into question. With Caesar there are twenty-five, so you can try them all on paper before you finish your coffee. That is precisely why ciphers had to move much further on – and why exactly this is not enough is what the next module shows.

Step by step

We start with plaintext: an ordinary word we want to send so the messenger cannot read it.
We shift every letter three places. A becomes D, B becomes E – and past the last letter you continue from the start of the alphabet.
An outsider sees only a row of meaningless letters. Whoever knows the key shifts them back and reads the original.
The key here is a single number and there are twenty-five options. Trying them all takes moments – and that is where the problem starts.

Why hand ciphers fall

The Caesar cipher falls to brute force because there are few keys. The fix suggests itself: replace every letter with another letter from an arbitrary table, not merely by a shift. Such a substitution has an enormous number of possible tables and trying them all is genuinely out of reach. Even so, such a cipher breaks easily, with a tool called frequency analysis. The trick is that in every language letters do not occur equally often. In Czech the most common are E, A and O, in English E, T and A. When one letter appears in the ciphertext far more often than the others, there is a fair chance it is exactly the most common letter of the language – and from that one guess the rest unravels like a crossword. Substitution preserves the frequencies: it only repaints their name tags. A modern cipher does not do that. In it the same letter comes out differently every time depending on what came before, so the output looks like perfectly even noise and no statistic pulls anything out of it. And one more thing was learned from the history of hand ciphers, the hard way: security must not rest on keeping the procedure secret. A procedure always leaks sooner or later – a device is stolen, a person defects, someone simply works it out. So today ciphers are published and left to be publicly attacked; only the key should be secret. A cipher nobody has seen, whose author claims it is safe, is not trusted – it is a warning sign.

Step by step

In every language some letters are far more common than others. That is a property of the text, not of the cipher.
Substitution keeps the frequencies: the tallest bar stays tallest. Guess one letter and the rest unravels.
A modern cipher makes even noise: the same letter comes out differently every time and statistics has nothing to catch on.
The last lesson from history: only the key should be secret. The procedure is published – one nobody has seen is a warning sign.

Hide or encrypt

There is a second way to keep something from someone, and it is confused with encryption surprisingly often. It is called steganography and it means hiding a message instead of encrypting it. Encryption says: ‘here is a message, but you will not read it’. Steganography says: ‘there is no message here’. The classic form is a picture: the photo looks perfectly ordinary, but text is imperceptibly tucked into the data of individual dots. The eye sees no difference, the file size fits, the format is fine. Things can also be hidden in sound, in video, in unused space in a document, or in the pattern of someone sending seemingly dull queries. The difference matters and is worth remembering: encryption protects the content, steganography protects the fact that you are communicating at all. Neither replaces the other, and anyone serious uses both – encrypt the message first and only then hide it. For you as a defender the term has one practical consequence above all, which the incident course follows up: steganography is a favorite way to get data out of a company. An attacker does not send the database as a file but pours it piece by piece into images uploaded to an ordinary photo service or into DNS queries. Nobody finds the content odd, because there is no suspicious content. It is spotted almost solely by what the course has already discussed: metadata and volume – who suddenly sends far more data out than before, and where to.

Step by step

Encryption says ‘you will not read the message’. Steganography says ‘there is no message here’. Two different things.
The classic form is a picture: text scattered through the dot data. The eye sees no difference and format and size still fit.
An attacker pours data out piece by piece into images or queries. There is no suspicious content because there is no content.
Detection rests on metadata and volume: who suddenly sends far more out than before, and where to. Content will not help.

▶ Open in the simulator

Lesson 2: Why encrypt

What is visible on the cable

Before you start: this course builds on courses 1–8 (addresses and mask, gateway, ports, DNS, firewall, DPI and sensors) – if any term feels unfamiliar, check those first. We begin with an unpleasant finding: a cable hides nothing. The data running through a network is just a sequence of bytes, and whoever reaches it reads it exactly as the sender sent it. You can try this in the simulator right away: right-click a link and choose Capture traffic. You will see what travels along that cable – and with old protocols the reading is uncomfortably legible. HTTP shows the whole page address and everything you typed into a form. Telnet shows the login name, the password and every command you typed on the device. FTP behaves the same: name and password go over the wire in plain text. These protocols were not born out of malice – they were born when networks were small and everyone in them trusted each other. Anyone who needs to capture traffic today need not be a hacker with expensive gear: it is enough to be on the path the data flows through. A switch plugged into the meeting room, public Wi-Fi in a cafe, the connectivity provider, anyone between you and the server. That is exactly why encryption exists: so that whoever looks at the cable sees only an unintelligible jumble. The rest of the course is about how that is done and – no less important – what it still does not hide.

Step by step

Over HTTP everything goes in plain text: the page address and whatever you typed into a form. Whoever is on the path reads along.
Telnet and FTP are the same: name, password and every typed command go over the wire as they are.
Try it: right-click a link → Capture traffic. You will see exactly what anyone on the path would see.
With encryption the same connection travels the same cable, but a capture sees only an unintelligible jumble of bytes.

What encryption solves and what not

In everyday speech encryption is often treated as a magic cloak of invisibility: ‘it is encrypted, so it is safe’. The reality is more precise and worth knowing at the outset, so you do not lean on encryption where it will not help. Encryption reliably hides the content: what you wrote, which file you downloaded, which password you entered, what the server answered. That is genuinely strong protection and nobody breaks it by brute force in practice. What encryption does not hide is metadata – the facts about the connection itself: who talked to whom, when, for how long and how much data moved. For data to arrive at all, the sender and recipient addresses must be readable to every switch and router along the way. They cannot be encrypted, or the packet could not be delivered. And a surprising amount can be derived from metadata. That the accountant’s computer connects to a foreign address every night at three and sends hundreds of megabytes tells you almost everything, even if you read not one byte. That someone in the company regularly connects to a job-hunting site does too. And third: encryption does not protect the endpoints either. When an attacker has your computer, they see the data at the moment it is decrypted – exactly where you work with it. Encryption is protection on the path, not protection of everything.

Step by step

Encryption hides the content: what you wrote, what you downloaded, which password you entered. That is genuinely strong protection.
Addresses must stay readable – otherwise the packet could not arrive. Every switch and router on the path sees them.
Metadata remain: who talked to whom, when, for how long and how much moved. A great deal follows from that.
And encryption does not protect the endpoint: whoever has your computer sees the data the moment it is decrypted.

Three properties

When security talks about encryption, it almost always means three different properties at once. It pays to tell them apart, because each is provided by a different part of the mechanism and each can fail on its own. The first is confidentiality: no outsider reads the content. That is the property everyone pictures – data turns into a jumble from which nothing can be pulled without the key. The second is integrity: nobody changes the content on the way without it being noticed. Without it an attacker could not read your message, but could shuffle bytes in it and the recipient would receive something other than you sent. So a short check value is computed for every message; after any change it no longer matches and the recipient discards the message. The third is authenticity: you really are talking to who you think. Without it even perfect encryption is useless – a perfectly encrypted conversation with an attacker merely posing as the server helps you not at all. Authenticity is precisely what certificates address, and half this course is devoted to them. Remember it as three questions about any connection: Can anyone read this? Can anyone change it? And who am I actually talking to? Good encryption answers all three; when only the first is answered, the protection is merely apparent.

Step by step

Confidentiality: the content becomes a jumble from which nothing can be pulled without the key. That is the first of three properties.
Integrity: a check value is computed for the message. If someone shuffles bytes on the way it no longer matches and the recipient discards it.
Authenticity: are you really talking to who you think? Certificates and authorities answer that – the second half of the course.
Three questions for any connection: can anyone read it, can anyone change it, and who am I talking to? Good encryption answers all of them.

▶ Open in the simulator

Lesson 3: Unencrypted protocols and their replacements

The pairs you must know

Most network services come in two forms: an older one that sends everything in plain text, and a newer one that wraps the same thing in encryption. The simulator knows this split – when you send an unencrypted service in a path test, it warns you and suggests the replacement right away. To make that make sense, let us walk the six pairs you meet most often. HTTP (port 80) → HTTPS (443): the web. Over HTTP an attacker on the cable would see the whole page and the password you typed into a form. FTP (21) → SFTP or FTPS: file transfer. Over FTP the name, the password and the content of every transferred file are visible. Telnet (23) → SSH (22): remote device administration. Over Telnet the login and every command you type on the router are visible – the keys to the network, in other words. SMTP (25) → SMTPS, or STARTTLS: sending mail. Over bare SMTP the sender, the recipient and the whole body of the email are visible. LDAP (389) → LDAPS (636): queries into the company directory. Over LDAP the name and password of the account an application signs in with are visible, plus the answers about users. SNMP v1 and v2c (161) → SNMPv3: device monitoring. The older versions send only a ‘community’ string in the clear instead of a password, and whoever captures it can query the device themselves. One closing point, because it is confused over and over: a port encrypts nothing by itself. The number 443 is merely an agreed habit for where TLS-protected web tends to live – TLS encrypts, not the port. You can happily run an unencrypted service on 443 and it stays as legible as before.

Step by step

HTTP → HTTPS. Over HTTP a listener on the cable would see the whole page and the password you typed into the form.
Telnet → SSH. Over Telnet the login and every router command are visible – the keys to the whole network.
FTP → SFTP or FTPS. Over FTP the name, the password and the content of every transferred file are visible.
SMTP → SMTPS and LDAP → LDAPS. Over bare SMTP the whole email is visible, over LDAP the password of the account querying the directory.
SNMP → SNMPv3. And above all: a port encrypts nothing by itself. 443 is merely an agreed habit – TLS encrypts, not the number.

How to tell what runs in your network

Knowing which protocols have a secure variant is half the job. The other half is finding out what runs in your network right now – because an unencrypted service does not announce itself. There are two routes and you can try both right here in the app. The first is by port. Most services sit on their usual number, so when a path test or a list of open ports shows 23, that is almost certainly Telnet; 21 is FTP, 161 SNMP, 389 LDAP. It is a quick overview, but not proof: a service can be run on any port and occasionally someone does. The second route is by behavior, that is, by what the traffic actually reveals. When a legible name and password show up in a capture, the port it ran on does not matter – it is unencrypted. And here the app helps you on its own, in two places. In the path test a warning with the recommended replacement appears for an unencrypted service, so you need not recall anything. And in the capture on a link (right-click a link) legible traffic is marked, so you see at a glance which stretch of the path is open. One case deserves special mention, because the port will not reveal it: STARTTLS. The connection starts on the same, unencrypted port (typically SMTP on 25) and only then do both sides agree to switch to an encrypted form. When all is well, traffic is unreadable from that moment on. But if the other side does not offer encryption, or someone strips it on the way, the switch simply does not happen – and the mail goes on in plain text. That is why STARTTLS is configured to rather not send at all without encryption.

Step by step

By port: 23 is almost certainly Telnet, 21 FTP, 161 SNMP, 389 LDAP. A quick overview, but no proof – another port can be chosen.
In the path test an unencrypted service gets a warning with the recommended replacement. You need not memorize the pairs.
By behavior: right-click a link → Capture traffic. Legible traffic is marked, so you see which stretch is open.
STARTTLS is the special case: the same port, encryption switched on later. If it is not switched on, traffic goes on in the clear.

Migration without an outage

When you find an unencrypted service in the network, the question is what to do with it. The answer ‘we will ban it on Friday afternoon’ sounds decisive and is the fastest way to make yourself weekend work. A secure variant is rolled out in an order that cuts nobody off, and that order has four steps. First turn on the secure variant alongside the old one. SSH can be enabled on a router without turning Telnet off; https runs on a different port than http. So both will run at once for a while, and that is fine – it is a temporary state, not the target. Then verify the new path really works: sign in over it, transfer a file, try it from where the others normally connect too. This is where a missing certificate or a firewall that does not pass the new port usually shows up. Only then switch clients and applications to the new variant; this step takes longest, because there is always a script or a printer nobody thought of. And only at the very end ban the old service – turn it off on the device and add a firewall rule so the unencrypted port cannot be used even by accident. Why the reverse order hurts is easy to work out. If you turn Telnet off first and only then find SSH was never configured on that device, you have just shut yourself out of a room whose handle is on the inside. With a remote router that means a drive. So in administration you never remove the last working access before the new one is tested. Try that last step in the simulator now on the task ‘Block Telnet’: unencrypted administration should be banned so that a Telnet login to the device really does not work.

Step by step

1. Turn the secure variant on alongside. SSH can be enabled without turning Telnet off. Running both is temporary, not the target.
2. Verify the new path. Sign in, transfer a file, try it from elsewhere. A missing certificate or a closed firewall port shows up here.
3. Switch clients and applications. This step takes longest – there is always a script or a printer nobody thought of.
4. Only now ban the old service. The reverse locks you out: you turn Telnet off and find SSH was never set up. With a remote router that is a drive.

▶ Open in the simulator

Lesson 4: How it works without the math

The symmetric cipher

The simplest way to encrypt something is a symmetric cipher: there is a single key and it is used both to encrypt and to decrypt. Whoever has the key reads the data; whoever lacks it sees a jumble. The comparison holds: an ordinary lock with one key. Whoever has the key can both open and close the door. In practice the cipher used today is mainly AES, and two things about it suffice: it is considered secure and it is very fast. Modern processors handle it directly in hardware, so encrypting a large volume of data costs practically nothing – which is why it encrypts ordinary traffic, video calls and whole disks. But a symmetric cipher has one flaw, and it is fundamental: how to get the key to the other side. For a server to send you encrypted data you must both hold the same key – yet sending it over the very network you are only starting to protect is nonsense. Whoever is listening captures the key and reads everything from then on. And delivering it otherwise, say by meeting in person, is impossible with the hundreds of servers you talk to daily. This problem is called key exchange and for decades it was encryption’s hardest nut. It is solved precisely by the second kind of cipher, called asymmetric, which comes in the very next module.

Step by step

A symmetric cipher: one key encrypts and decrypts. Like an ordinary lock – whoever has the key both opens and closes.
Mainly AES is used: considered secure and very fast – processors handle it directly in hardware.
The flaw is fundamental: how do you get the key to the other side? Sending it over the network you want to protect is nonsense.
Whoever captures the key on the way reads everything from then on. This is called key exchange – and the next module solves it.

The asymmetric cipher

An asymmetric cipher looks nonsensical at first glance and ingenious at the second: instead of one key it has a pair that belongs together. One of them is public and anyone may have it – you can post it on the web. The other is private and never leaves the device it belongs to. The relation between them is what matters: what you encrypt with the public key can be opened only by the private one. And the other way round: what the private key encrypts, anyone can verify with the public one. Two different uses follow, and they are often confused. The first is delivering a secret: to send something to a server so that only it can read it, you encrypt it with the server’s public key. Anyone on the path holds that same public key, but for decryption it is useless. The second use is a signature: the server encrypts something with its private key and you verify it with its public one. When verification succeeds, you know the holder of the private key sent it – and nobody else could have. That is exactly how certificates work, which we reach in the TLS lesson. There is one catch, a practical one: an asymmetric cipher is orders of magnitude slower than a symmetric one. Encrypting a whole file download or a video call with it would be unusable. So in practice it is not used alone – and how the two ciphers complement each other is the next module.

Step by step

There are two keys and they belong together. Anyone may hold the public one; the private one never leaves its device.
Want to send a secret only to the server? Encrypt with its public key – only its private key opens it.
The second use is a signature: the server signs with the private key and you verify with the public one. Nobody else could have done it.
The catch: an asymmetric cipher is orders of magnitude slower. Encrypting a download or a video call with it would be unusable.

Why they are used together

Now the two ciphers join and produce what protects almost the whole internet today. A symmetric cipher is fast but cannot deliver the key. An asymmetric one can deliver a secret but is slow. The solution suggests itself: use the asymmetric cipher only once, to agree a symmetric key – and encrypt everything else with the fast symmetric one. That is exactly what TLS does, the protocol behind the https prefix. At the start of a connection there is a short, computationally heavier part in which both sides agree a shared key and check who they are talking to. Then it switches to the symmetric cipher and the rest of the connection runs fast. A comparison: with the asymmetric cipher you shake hands and safely pass the safe’s key; from then on you use the safe. Two things are worth adding. First, these days the key is usually not even sent – both sides compute it from publicly exchanged values in a way that a listener cannot derive from what they saw. It sounds like magic, but it is only mathematics this course does not need. Second, a new key is created for every connection. If someone obtains one later, an old captured connection does not help them – that property is called forward secrecy and it is a main reason old TLS versions are no longer used.

Step by step

At the start of a connection a shared key is agreed asymmetrically. It is a short but computationally heavier part.
These days the key is usually not even sent – both sides compute it so a listener cannot derive it from what they saw.
Then it switches to the symmetric cipher and the rest runs fast. Shake hands, pass the safe’s key, then use the safe.
A new key is created for every connection. A later leak therefore does not reveal previously captured traffic.

▶ Open in the simulator

Lesson 5: Hashing: a fingerprint, not a cipher

A fingerprint with no way back

Until now the talk was about encryption, that is about something that can be decrypted again. Now comes a thing confused with encryption almost constantly, while being something else entirely: a hash, a fingerprint of data. A fingerprint is produced by running data through a computation that spits out a short string of fixed length. Whether you feed it one word or a two-hour film, the result is always the same length. And above all: the road runs one way only. From data you compute a fingerprint easily, but from a fingerprint you do not get the original data back – not because it is hard, but because it is simply not in there. It is like the ash of a letter: it came from the letter, but you will not reassemble the letter from it. This one-way nature is what makes fingerprints an ideal tool for passwords. A server need not know your password at all. At registration it computes its fingerprint and stores only that. When you log in, it computes the fingerprint again from what you typed and compares it with the stored one. If they match, the password was right. When someone steals such a database, they do not have passwords – they have fingerprints. The second useful property is sensitivity to change: a tiny change of input makes a completely different fingerprint. Rewrite a single letter in a file and the result is not ‘almost the same’ but unrecognizably different at first glance. Integrity checking, which the third module covers, builds on exactly this.

Step by step

A fingerprint is a short fixed-length result. Feed the computation a word or a whole film – the output is always the same length.
There is no way back: the data is simply not in the fingerprint. So it is not a cipher – nothing can be decrypted, there is nothing there.
The server stores only the fingerprint. At login it recomputes and compares. Whoever steals the database finds no passwords.
Change one letter and the fingerprint is completely different, not ‘almost the same’. Checking a file did not change rests on that.

Salt and pepper

Storing a fingerprint instead of a password is the right idea, but on its own it is not enough – and the reason is inconspicuous. A fingerprint is always computed the same way, so two identical inputs give an identical output. When a thousand people pick the same favorite password, the database holds the same string a thousand times. An attacker who steals the database therefore sees straight away who shares a password with whom – and above all need not compute anything anew. There are rainbow tables: enormous precomputed lists of ‘this fingerprint belongs to this password’. Breaking a password then means not computing but looking up, and that takes a fraction of a second. The defense is called a salt. Before the computation a short random value is mixed into each password, different for every user, and stored next to the fingerprint in the same record. A salt is not secret – its point is not secrecy but that it breaks the sameness: two people with the same password end up with completely different fingerprints, and a precomputed table becomes useless, because it would have to be built separately for every salt. The companion is a pepper: another secret value mixed in the same way, but not stored in the database – it lives in the application configuration or a secure key store. When an attacker steals only the database and cannot reach the application, a piece of the input is missing and they compute nothing. So a salt is a duty, a pepper a welcome extra.

Step by step

A fingerprint is always computed the same, so identical passwords give identical fingerprints. A stolen database shows it at a glance.
A rainbow table is a precomputed ‘fingerprint → password’ list. Cracking turns from computing into a lookup – a matter of moments.
A salt is a random value, different for each user. It need not be secret; its point is to break the sameness of fingerprints.
A pepper is a secret outside the database – in the app configuration. Whoever steals only the database lacks part of the input.

A fingerprint as an integrity check

Fingerprints are not used only for passwords. The second big use is integrity checking, that is answering whether a file is still the one someone released. The principle follows directly from what you know: identical data gives an identical fingerprint and a tiny change gives a completely different one. So downloadable files come with a published checksum. You download the file, compute its fingerprint yourself and compare it with the one stated on the page. If they match, nobody changed the file on the way and it was not corrupted. If they do not, do not run it. You met the same reasoning with the three properties in the previous lesson – message integrity in TLS is watched by exactly such a short check value computed from the content. One important note remains: not every fingerprint is worth anything today. For the older functions MD5 and SHA-1, collisions were found – pairs of different inputs with the same fingerprint. For integrity checking that is fatal: an attacker can prepare a forged version of a file with the same checksum as the real one. Hence SHA-256 is used today. And passwords have one more quirk: there a fast computation is a disadvantage, because an attacker with a stolen database tries passwords by the billion. So deliberately slow functions are used, such as bcrypt or argon2, designed so that a single computation costs something. The practical rule: SHA-256 for integrity, bcrypt or argon2 for passwords, MD5 and SHA-1 nowhere.

Step by step

A checksum: the publisher states the fingerprint, you compute it after downloading and compare. If they match, the file is unchanged.
When the fingerprints differ, the file is not what the publisher released. Do not run it – be it corruption or a forgery.
For MD5 and SHA-1, collisions can be found: two different files with one fingerprint. So they no longer suffice for integrity.
The practical rule: SHA-256 for integrity, bcrypt or argon2 for passwords – deliberately slow ones. MD5 and SHA-1 nowhere.

▶ Open in the simulator

Lesson 6: TLS in practice

What happens when you open https

You type an address starting with https:// and before the page appears a conversation called a handshake takes place. It lasts a fraction of a second and has four steps, which we walk through without a single formula. Step one: the browser contacts the server and says which TLS versions and ciphers it supports and, importantly, which name it is asking for. The name matters because one address may host several sites. Step two: the server replies which cipher it picked from the offer and sends its certificate – a document stating its name, its public key and the signature of the authority confirming it. Step three: the browser verifies the certificate (does the name match? is it valid? was it signed by someone I trust?) and both sides agree a shared symmetric key. If verification failed you would see a warning and the next step would never come. Step four: both sides confirm they hold the same key, and from this moment the whole connection is encrypted – only now does the page request go out. It is worth noting what follows in practice: the padlock in the browser does not mean ‘this site is honest’. It only means ‘the connection is encrypted and the certificate matches the name you typed’. A fraudulent site can hold a valid certificate exactly like a bank.

Step by step

The browser speaks up: I support these versions and ciphers, and I am asking for this name. One address may host several sites.
The server replies which cipher it picked and sends its certificate: name, public key and the authority’s signature.
The browser verifies the certificate – name matches, still valid, signed by someone trusted? – and a key is agreed.
Both sides confirm the key and only now the request goes out – encrypted. But the padlock does not mean ‘an honest site’.

What a certificate holds

A certificate sounds mysterious, but it is an ordinary data file with a few fields and one signature. Inside you find four essential things. The name the certificate is valid for – a specific domain or a group of domains. The server’s public key, the half of the pair anyone may hold. The validity period, from when to when the certificate counts as good; today it tends to be short, a matter of months. And the authority’s signature, which attested all of it – without it anyone could produce such a file about themselves. The signature is exactly the use of asymmetric cryptography you saw in the second lesson: the authority signed with its private key and you verify with its public one. The word valid then means three things hold at once. First, the name matches the address you actually typed. Second, the validity period is running – it does not start tomorrow and did not end last week. Third, the signature leads to an authority your device trusts; the browser and the operating system carry a list of such authorities. If any of the three fails, the connection must not be treated as verified. And once more the most important part, because even professionals confuse it: a valid certificate attests the name, not honesty. That a site has a properly issued certificate says nothing about what it will do with your data.

Step by step

A certificate holds four essentials: the name, the public key, the validity period and the authority’s signature.
The signature is asymmetric cryptography at work: the authority signed with its private key, you verify with its public one.
Valid means three things at once: the name matches the address, the period is running and the signature leads to a trusted authority.
Careful: a valid certificate attests the name, not honesty. A fraudulent site can hold one exactly like a bank.

Why the browser complains

Everyone sees certificate warnings and most people click them away, because they do not understand what the browser is actually asking. Yet it is always one of three specific faults – and each means something different. Expired. The validity period ended. In the vast majority of cases it is an operational slip: someone forgot the renewal. The risk itself is small, but it is a warning sign about how the server is cared for – and it cannot be told apart from a certificate that expired because nobody administers the server any more. Name mismatch. The certificate is issued for a different domain than the one you asked for. This is the most serious of the three: it is exactly what an attempt to impersonate someone else’s server looks like. Sometimes it is only an administrator’s slip (a name variant is missing), but the two cannot be told apart from outside. Unknown authority. The certificate is signed by someone your device does not know – typically it is self-signed, that is signed by itself, or it comes from an internal company authority the device does not have on its list. Encryption in such a connection runs normally, but authenticity is missing: nothing guarantees the other side is who you expect. The practical rule for all three cases is the same: never click a warning away where you log in or enter sensitive data. And when the server is yours, do not teach users to click ‘proceed’ – learn to watch renewals instead.

Step by step

Expired: the period ended, usually because someone forgot the renewal. Small risk, a loud signal about the care taken.
Name mismatch: the certificate is for another domain. This is what impersonating a server looks like – the most serious of the three.
Unknown authority (often self-signed): encryption runs, but authenticity is missing – nobody vouches for the other side.
A rule for all three: do not click warnings away where you log in or enter sensitive data.

▶ Open in the simulator

Lesson 7: Certificates and authorities

Who trusts whom

One question has hung in the air since the last lesson: why do you trust the signature of an authority you have never seen? The answer is called the chain of trust and rests on a simple idea: trust is not passed directly but link by link. At the start of the chain is a root authority. Its certificate is signed by itself and nobody attests it – it is trusted because your browser and operating system carry it in a list of trusted authorities. That list is the outcome of audits and rules; you do not maintain it, but you can add your own entries, which will matter shortly. A root authority does not sign ordinary certificates directly – its private key is too precious to be used daily. Instead it signs intermediate authorities, and those issue certificates to individual servers. A chain arises: the server certificate ← the intermediate authority ← the root. The browser walks the chain upward looking for a link it knows. When it finds one and all signatures match, the connection is verified. The practical consequence people trip over most in operations: the server must also send the intermediate certificates. When an administrator forgets to configure them, the chain breaks and some devices report an error while others – which happen to remember the intermediate from before – do not. Hence the classic line ‘it works for me’.

Step by step

At the start is a root authority. Its certificate is signed by itself and is trusted because it sits in the list.
The root does not sign servers directly. It signs an intermediate authority, and that issues the certificate to the server.
The browser walks up the chain looking for a link it knows. When it finds one and the signatures match, the connection is verified.
When a server does not send the intermediates, the chain breaks. Some devices error, others do not – hence ‘it works for me’.

An internal company authority

A company runs plenty of things unreachable from the internet: a switch’s web interface, an internal system, a print server, a test environment. A public authority will not issue them a certificate, because it has no way to verify a name that does not exist on the internet. So companies often run their own certificate authority. The principle is the same as with a public one: a root certificate is created, distributed to all company devices (typically by central management) and from then on internal certificates appear trustworthy to them. The reward is decent: internal services stop raising warnings, you stop teaching users to click errors away, and you also gain a way to issue certificates to devices and people, not just servers. But the price is real and it is fair to know it in advance. First, the root’s private key is a crown jewel: whoever steals it can impersonate any internal service and every company device will believe them. It must therefore be stored away from daily operations, ideally offline. Second, it is extra work: issuing, renewal, records, revocation – without automation it quickly becomes forgotten paperwork and certificates start expiring quietly. And third, an internal root counts only at home: a visitor or a customer does not have it on their device, so an internal authority must never be used for a service people reach from outside. For those a public authority remains the right choice.

Step by step

A public authority cannot cover internal services – their names do not exist on the internet. So the company runs its own authority.
The root certificate is distributed to company devices. From then on internal certificates look trustworthy to them.
Internal interfaces stop raising warnings and you need not teach users to click errors away. That is the main reward.
The price: the root private key is a crown jewel, it is extra work – and outside it will not help you; there a public authority belongs.

When a certificate fails

A certificate is not something you set and forget. It fails, in three ways that differ in practice both in severity and in what can be done about them. The first and most common is expiry. A certificate has a limited validity and today it is deliberately being shortened – a shorter validity means smaller damage when something goes wrong. But an expired certificate means a broken service: users see a warning and applications that cannot click warnings away simply stop connecting. The defense is boring and effective: automatic renewal and watching the dates in monitoring, not in your head. The second failure is a private key leak. When an attacker obtains a server’s private key, they can impersonate that server and nobody notices – the certificate is valid, after all. This is the most serious case, because the encryption itself keeps working and what is missing is exactly what trust rests on. The third thing is revocation, declaring a certificate invalid before its period ends. It is used precisely after a key leak or when a service is retired. The problem with revocation is practical: the browser must somehow learn the certificate no longer counts, either by downloading a list of revoked certificates or by asking the authority. Both are slow and unreliable, so in practice much is left to the certificate expiring by itself. That is also why validity periods are short today: a short validity beats a fast revocation.

Step by step

Expiry is the most common: users see a warning and applications that cannot click it away stop connecting.
A private key leak is the most serious: an attacker can impersonate the server while the certificate stays valid.
Revocation invalidates a certificate early. But the browser must learn of it – and that is slow and unreliable.
Hence today’s short validity and automatic renewal: a short validity beats a fast revocation.

▶ Open in the simulator

Lesson 8: Where encryption is not enough

An attacker on the endpoint

This lesson is about the limits of encryption and we begin with the harshest: encryption does not protect a compromised computer. The reason is logical, not technical. Data is encrypted so that nobody reads it on the path. At both ends it must be readable, or it could not be used – the browser has to render the page, you have to see the message text. So whoever sits on the end device sees the same as you, and how perfect the cipher protecting the connection was makes no difference to them. The practical consequence is unpleasant. A compromised computer can log into internet banking, read the page content, record what the user types on the keyboard and send it away – inside a perfectly correct encrypted connection. Neither an IDS sensor nor a firewall on the path will see anything unusual, because from their view it is ordinary encrypted traffic on an ordinary port. Quite the opposite: encryption helps the attacker, because it hides what they are sending. That is exactly why the incident response course talked so much about metadata and flows – when you cannot see content, what is left is watching who talks to whom and when. Do not conclude from this that encryption is pointless, though. The conclusion is different and it is one of the main takeaways of the whole course: encryption is one layer of defense, not the whole defense. It protects data on the path perfectly and leaves everything else to endpoint protection, access control and monitoring.

Step by step

The path is protected perfectly: nobody reads the content on the cable. But at both ends it must be readable.
Whoever sits on a compromised computer sees the same as the user: the page content and the keystrokes.
And sends it out in a correctly encrypted connection. Neither sensor nor firewall on the path sees anything unusual.
The conclusion: encryption is one layer of defense, not the whole defense. The rest is devices, access control and monitoring.

Decryption on the firewall

In the advanced security course you saw that DPI looks into packet contents and searches them for attacks. But when traffic is encrypted, DPI sees nothing but a jumble – and that is a problem for defense, because today almost everything is encrypted, including malware downloads and communication with an attacker’s control server. So companies reach for something called TLS inspection: the firewall terminates the connection at itself, decrypts the content, examines it, re-encrypts it and sends it on. For this to work, the firewall must produce its own certificate for every site visited – and for browsers to accept it, company devices must be set to trust the internal authority from the previous lesson. Yes, this is precisely what textbooks call a man-in-the-middle attack, only operated by your own company and with the device owner’s consent. The price is high and it is fair to list it. Privacy: the firewall sees the content of all employee communication, including banking and health data; sensitive categories are therefore commonly excluded from inspection. Risk: the firewall becomes the place where the company’s whole traffic exists in the clear – and its compromise is a catastrophe. Operations: some applications refuse inspection because they check which certificate they received. And performance: decrypting and re-encrypting everything costs a lot. A sensible deployment therefore turns inspection on selectively, not across the board.

Step by step

With TLS inspection the connection does not end at the site but at the firewall. It decrypts and looks inside.
The firewall then opens a second connection outward and passes the data on. The browser gets a certificate made by the firewall.
Only now does DPI see the content and can find a malicious file or communication with the attacker’s control server.
The price is high: privacy, performance, refusing applications – and a firewall holding all traffic in the clear. Hence selectively.

Metadata and traffic analysis

We reached metadata in the very first lesson; now it is time to show how strong it is. When the content is encrypted, what remains is observing the traffic pattern: who connects to whom, how often, at what time, how long a connection lasts and how much data flows in each direction. A surprising amount follows. Short regular connections every few minutes to the same address look like communication with an attacker’s control server, even though you cannot read a single letter of them. A long connection with a large volume outward in the middle of the night looks like data being sent away. A new pair, ‘this computer talks to that server’, never seen in the network before, looks like an attacker moving. And third: which name the client asked for is often visible at the start of a connection, and DNS queries are visible almost always. The key insight is that this view is available to you exactly as it is to an attacker: the connections overview in the simulator shows precisely what anyone on the path sees. It cuts both ways. For defense it is good news – even in a fully encrypted network a great deal can be detected without decrypting anything, and it is far cheaper and less invasive than TLS inspection. For privacy it is bad news: encrypting content is not anonymity. Whoever sees your traffic knows who you talk to and when – and that is often half the story.

Step by step

Short regular connections every few minutes to the same address look like an attacker’s control channel – without reading content.
A new pair – ‘this computer talks to that server’ – looks like an attacker moving. The connections overview shows it.
Volume and timing reveal a lot: a long connection sending a lot outward in the middle of the night looks like a data leak.
Good news for defense, bad for privacy: encrypting content is not anonymity. The map of connections stays readable.

▶ Open in the simulator

Lesson 9: Practice and summary

What to encrypt first

Encrypting absolutely everything at once is not feasible – or rather it is, but in a real company it means months of work and a series of broken things along the way. So you start where the ratio of benefit to effort is best. First comes device administration. Logging into switches, routers, firewalls and servers is among the most valuable things in a network: whoever captures it gains administrator access outright. Telnet is therefore replaced by SSH, web interfaces switch to https, and the old administration is turned off, not merely ‘not used’. Second are passwords and logins in general. Every form where a user enters a name and password must run over https – including inside the company network, because an attacker inside is still the most common scenario. Third are backups and data transfers. A backup is a copy of everything valuable in one place; when it travels the network in the clear or lies unencrypted on a disk, it is the cheapest possible target. And fourth is anything crossing someone else’s network: branches, working from home, public Wi-Fi. VPN belongs there, or at least consistent https. A useful shortcut for deciding: rank services by what capturing them would give an attacker and start at the top. Not by what is easiest to encrypt – that is the road to a beautifully secured print server and Telnet on the main switch.

Step by step

Device administration comes first: whoever captures it gains administrator access. Telnet out, SSH and https in.
Passwords and logins belong on https inside the company too: an attacker inside the network is still the most common case.
Backups are a copy of everything valuable in one place. An unencrypted backup is the cheapest possible target.
And anything crossing someone else’s network: branches, home office, public Wi-Fi. VPN belongs there, or consistent https.

Common mistakes

Mistakes in encryption share one property: they look like everything is done. The address starts with https, the padlock is on, nobody complains – and yet the protection does not work the way everyone assumes. Four of the most common deserve naming. A self-signed certificate in production. It usually appears during a test and nobody ever replaces it. Encryption runs, but users learn to click warnings away – and with that, protection against server impersonation is practically abolished, because nobody would recognize the fraud any more. A forgotten renewal. The certificate expires quietly over the weekend and on Monday morning an application nobody thought of stops working. The fix is automatic renewal and watching the dates in monitoring, not in one person’s calendar. Encryption only from outside. A classic: the site has beautiful https from the internet, but behind the firewall traffic to the application server goes in the clear, administration runs over Telnet and the database talks unencrypted. An attacker inside suddenly has everything – exactly why the Zero Trust course insists the internal network is not a safe zone. And old versions and weak ciphers: a server with obsolete protocols enabled for years offers an attacker a way to push the connection down to something weaker. The check is boring but quick: go through what the server offers and turn off what does not belong.

Step by step

Self-signed in production: encryption runs, but users learn to click warnings away – and then miss a fraud.
A forgotten renewal: the certificate expires over the weekend and on Monday an app nobody thought of is down.
Encryption only from outside: https from the internet, but Telnet and an unencrypted database inside. An attacker inside has it all.
Old versions and weak ciphers offer a way to push a connection down. Go through what the server offers and turn off the rest.

A checklist

To close the course, let us sum encryption into a list you can walk in a few minutes and that tells you where you stand today. Does device administration run encrypted only? Check that Telnet is off, not merely unused, and that web interfaces go over https. This is the one item you must not postpone. Is https everywhere a password is entered? Including internal applications – an attacker inside the network is the most common scenario. Do you know when your certificates expire? If the answer is ‘someone watches it’, then nobody watches it; it belongs in monitoring together with automatic renewal. Are the certificates from an authority the devices really trust? Self-signed in production teaches users to click warnings away and thereby cancels the protection against fraud. Are passwords stored as a salted fingerprint? Nowhere should they lie in the clear, nor as a bare unsalted fingerprint; passwords belong in bcrypt or argon2, not MD5 and SHA-1. Do you encrypt inside as well? Walk the path from the user to the database and look for a stretch where data is in the clear. Do you know what your metadata reveals? Open the connections overview and look at the ‘who talks to whom’ pairs – you see exactly what an attacker sees. And a last question people do not ask: what would you see if someone were listening on your cable right now? Try capturing on a link and walk the traffic. If you find a legible password there, you have the first item of the plan – and you know where to start.

▶ Open in the simulator