DEV Community: VickkyKruz NetSec

TLS and Certificates: How Two Strangers Agree on a Secret, and Why Your Browser Trusts Anyone

VickkyKruz NetSec — Fri, 14 Aug 2026 15:50:29 +0000

Last post ended with a promise. We had explained that HTTPS is ordinary HTTP running inside an encrypted tunnel called TLS, Transport Layer Security, and that this tunnel provides confidentiality, integrity, and authentication. But we deliberately left the hardest question unanswered: how does any of that actually work?

It is worth pausing on just how impossible the core problem sounds. Two computers that have never communicated before want to exchange secret information. The only path between them is the open internet, where, as we have seen throughout this series, anyone along the route can read what passes by. And yet, somehow, they need to agree on a secret key that only the two of them know, while an eavesdropper watches every single message they exchange. It sounds like a paradox. If the attacker sees everything, how can the two ends share a secret the attacker does not learn?

And there is a second problem, just as hard. Even if they can agree on a secret, how does your browser know it is talking to the real bank, and not an attacker who has inserted themselves in the middle? Agreeing on a secret with an impostor is worse than useless.

TLS solves both. The first through a beautiful piece of mathematics called public-key cryptography. The second through a system of certificates and authorities that, when you follow it to its root, rests on a surprisingly human foundation of trust. Let us take them in turn.

The Two Problems, Named Clearly

Everything in this post serves two goals. It helps to hold them separate in your mind, because they are genuinely different, and TLS uses different tools for each.

Confidentiality: agree on a secret key over a channel where everything is visible, so that all further communication can be encrypted with it. This is the key-exchange problem.

Authentication: prove that the server is genuinely who it claims to be, so you are not establishing that secret with an impostor. This is the certificate problem.

A connection that has confidentiality but not authentication is encrypted, but you might be talking privately to a criminal. A connection with authentication but not confidentiality proves who you are talking to, but everyone can hear it. You need both, and TLS delivers both in a single handshake. First, the mathematics that makes confidentiality possible.

The Impossible-Sounding Trick: Public-Key Cryptography

For most of history, encryption worked one way: the same secret key both locked and unlocked a message. This is called symmetric encryption, and it is fast and effective, but it has a fatal flaw for our problem. Both parties need the same key, and if they have never met, how do they agree on that key without sending it across the open network where an eavesdropper would simply catch it in transit? You cannot secure the channel by sending the key over the unsecured channel.

The breakthrough that solves this is asymmetric, or public-key, cryptography, and it is one of the most important ideas in all of computing. Instead of one shared key, each party has a pair of keys that are mathematically linked: a public key and a private key. The public key can be shared with the entire world. The private key is kept absolutely secret, never shared with anyone.

The magic is in how they relate. Anything locked with the public key can only be unlocked with the matching private key, and nothing else, not even the public key that locked it. Picture a padlock that anyone can snap shut, but that only one unique key can open. You can hand out open padlocks to the whole world, invite anyone to lock a message and send it to you, and rest assured that only you, holding the single private key, can open any of them. The eavesdropper can watch a locked message travel past and is powerless to open it, even though they watched it being locked, and even though they have a copy of the very padlock that locked it.

This is what makes the impossible possible. Two strangers can now establish a shared secret in full view of an eavesdropper. There are a couple of ways to use this, and modern TLS uses an elegant one, but the essential point is this: public-key cryptography lets you bootstrap a secret over an open channel, because the piece that unlocks is never transmitted at all. It stays on the private side the whole time.

There is one catch, and it shapes everything that follows. Public-key cryptography is mathematically expensive and slow. It would be far too costly to encrypt an entire web session, every request and response, this way. So TLS uses it for exactly one job: the delicate task of agreeing on a secret at the start. Once both sides share that secret, they switch to fast symmetric encryption for the actual data. Public-key crypto is the armoured van that delivers the key. Symmetric encryption is the fast, efficient lock used for everything afterwards. You get the security of public-key infrastructure and the speed of symmetric encryption, together.

The TLS Handshake, Step by Step

Now we can watch the whole thing happen. When your browser connects to an HTTPS site, before any web page data flows, the two sides perform the TLS handshake. I will describe it as modern TLS, version 1.3, does it, because that is the current standard and the cleanest version of the story.

Step 1, Client Hello. Your browser opens by saying hello. It sends the TLS version it wants to use, a list of encryption methods (cipher suites) it supports, and a random number. Crucially, in modern TLS it also immediately generates a temporary key pair for this connection and sends its share of the key-exchange material right away, to save a round trip.

Step 2, Server Hello, and the Certificate. The server responds. It picks the encryption method both sides will use, sends its own random number and its own share of the key-exchange material, and, critically, sends its certificate. That certificate contains the server's public key and its claimed identity, the domain it says it is. We will scrutinise this certificate in a moment, because it is the entire basis of authentication.

Step 3, the shared secret is derived. Here is the elegant part. Using the key-exchange material both sides have now exchanged, each end independently performs a calculation that produces the same shared secret, without that secret ever being sent across the wire. Both sides arrive at the same key by combining their own private piece with the other side's public piece. An eavesdropper who saw both public pieces cannot reproduce the result, because they never had either private piece. This is the modern Diffie-Hellman key exchange, and it has a valuable property called forward secrecy: because the key pair for this connection is temporary and thrown away afterwards, even if the server's long-term private key is stolen in the future, past recorded conversations still cannot be decrypted. The keys that protected them no longer exist anywhere.

Step 4, proving identity. Deriving a shared secret is not enough, because you might have derived it with an impostor. So the server now proves it genuinely owns the certificate it sent. It does this by signing a hash of the handshake so far with its private key. Your browser uses the public key from the certificate to verify that signature. Only the true owner of the certificate's private key could have produced a signature that verifies against its public key, so this step proves the server on the other end is the legitimate holder of the certificate, not someone merely replaying a copy of it.

Step 5, encrypted communication begins. Both sides confirm the handshake is intact with a finished message, and from this point on, everything, every HTTP request and response from the last post, is encrypted with the fast symmetric key derived from the shared secret. The tunnel is open.

All of this happens in a few milliseconds, before the first byte of the actual page is sent. Every single time you visit an HTTPS site, this exchange plays out invisibly.

But notice that the entire authentication step rests on one assumption we have not yet justified: that the certificate can be trusted. Your browser verified that the server owns the certificate. But what makes the certificate itself believable? Anyone can generate a key pair and claim to be your bank. This is the second great problem, and it is where certificates and authorities come in.

The Certificate: A Public Key With an Identity Attached

Let us be precise about what a certificate actually is, because it is the linchpin of the entire system.

On its own, a public key is anonymous. It is just a number. If a server hands your browser a public key and says "I am your-bank.com," nothing about the key itself proves that claim. An attacker could generate their own key pair and make the identical claim. A public key proves you can talk to whoever holds the matching private key. It says nothing about who that holder actually is.

A certificate solves this by binding a public key to an identity, and having that binding vouched for by a trusted third party. A certificate essentially says: "This public key belongs to this domain, and I, a certificate authority, have verified that and put my name to it." It contains the public key, the identity (the domain name), an expiry date, and, crucially, a digital signature from the authority that issued it.

That signature is the key to everything. It is created using the same public-key mathematics, in reverse. The certificate authority signs the certificate with its own private key. Anyone can then verify that signature using the authority's public key, and a valid signature proves that this authority really did issue and vouch for this certificate, and that it has not been tampered with since. So the question of "can I trust this public key belongs to this domain" becomes "do I trust the authority that signed this certificate." Which raises the obvious next question: why would you trust that authority?

The Chain of Trust: Why Your Browser Trusts Anyone at All

This is the deepest question in the whole system, and answering it reveals the surprisingly human foundation underneath all of internet security.

Certificates are not signed in a flat, single layer. They form a chain of trust, a hierarchy with three levels.

At the bottom is the end-entity certificate, the one for the actual website, your-bank.com. It was issued and signed by an intermediate authority.

In the middle sits one or more intermediate certificate authorities. These do the day-to-day work of issuing certificates to websites. Each intermediate's own certificate is, in turn, signed by an authority above it.

At the top sits a root certificate authority. The root is the ultimate anchor. Its certificate is special in two ways: it is self-signed, meaning it vouches for itself, and, most importantly, it is pre-installed in a trust store that ships with your operating system and browser. When you installed your OS or browser, it came with a built-in list of a few hundred root authorities that its makers have decided to trust.

Now the chain makes sense. When your browser receives the website's certificate, it checks the signature and sees it was signed by an intermediate. It checks the intermediate's certificate and sees it was signed by a root. It checks whether that root is in its pre-installed trust store. If the chain leads, link by verified link, up to a root the browser already trusts, the certificate is accepted. If it leads nowhere, or to an unknown root, the browser shows the security warning you have occasionally seen.

So the honest answer to "why does your browser trust anyone" is this: it trusts a website's certificate because it chains up to a root authority that was placed in your device's trust store by the company that made your browser or operating system. The entire edifice of web encryption rests, at its foundation, on a curated list of a few hundred organisations that browser and OS makers have vetted and chosen to trust on your behalf. Trust on the internet is not magic. It is a pre-agreed list, shipped to you inside your software.

Why the layered structure, rather than roots signing website certificates directly? Because it isolates the most precious keys. The root's private key is so catastrophically important that it is kept offline, in physical vaults, used as rarely as possible. The intermediates do the daily work and absorb the daily risk. If an intermediate is compromised, it can be revoked without destroying the root and every certificate beneath it. The hierarchy exists to protect the anchor and to contain damage. Which brings us, inevitably, to what happens when this system fails.

When Trust Breaks: The Structural Weakness at the Heart of HTTPS

Everything above describes the system working. But the series' commitment to honesty demands we look at how it breaks, because the trust model has a genuine structural weakness, and it has failed in the real world with serious consequences.

Here is the weakness, stated plainly. Your browser trusts several hundred root authorities equally. For any given website, it will accept a valid certificate signed by any one of them. This means that every single certificate authority in that trust store is a potential single point of failure for the entire web. If any one of those hundreds of authorities is compromised or misbehaves, an attacker can obtain a fraudulent-but-valid certificate for any domain they like, your bank, your email, anything, and your browser will accept it without complaint. The security of HTTPS is, in a real sense, only as strong as the weakest authority in the list.

This is not theoretical. In 2011, a Dutch certificate authority called DigiNotar was compromised by an attacker. Because DigiNotar was a trusted root, the attacker was able to issue fraudulent but fully valid certificates for high-value domains, including Google. Those forged certificates were then used to intercept the encrypted Gmail traffic of an estimated hundreds of thousands of users in Iran, reading communications that the victims believed were completely secure. The padlock was there. The encryption worked perfectly. And it was all being delivered, sealed and trusted, straight to an attacker, because the authority underpinning the trust had been breached.

The response was swift and brutal, and it shows how the system defends itself. Once the compromise was understood, browser and operating system makers removed DigiNotar from their trust stores entirely, within days. Every certificate DigiNotar had ever issued instantly became untrusted worldwide. The company, its authority gone, went bankrupt within weeks. This is the ultimate enforcement mechanism: an authority that fails badly enough is simply deleted from the lists, and ceases to exist.

DigiNotar was not unique. There have been other cases, authorities that mistakenly issued powerful intermediate certificates, or were tricked into issuing certificates for domains the requester did not own. Each incident exposed the same underlying truth: the convenience of trusting many authorities is also the fragility of trusting many authorities.

The system has been hardened in response, and it is worth knowing how, because it connects to the theme of layered defence this series keeps returning to. A major improvement is Certificate Transparency: certificate authorities are now required to publish every certificate they issue to public, append-only logs. This means that if an authority issues a certificate for your-bank.com, the real owners of that domain can see it appear in the logs and raise the alarm, even if they never requested it. It does not prevent mis-issuance, but it makes it visible and detectable, turning a silent betrayal into a public record. Combined with certificate revocation mechanisms and the ever-present threat of removal from trust stores, it keeps the authorities honest through accountability rather than through perfect prevention.

And so we arrive, as the series so often does, at the honest conclusion. The trust that secures the entire web is not absolute or mathematical at its foundation. It is institutional. It rests on a curated list of organisations, kept honest by transparency, revocation, and the credible threat of instant excommunication. It works remarkably well. But it is a human system with human failure modes, and understanding that is far more valuable than believing the padlock represents some unbreakable mathematical guarantee. It does not. It represents a well-designed, well-defended, but ultimately human chain of trust.

This also completes the honest point from the last post. The padlock proves your connection is encrypted and that the server holds a certificate for the domain, vouched for by a trusted authority. That is a real and valuable guarantee. But it is a statement about domain control and a chain of institutional trust, not a statement that the site is honest, and not an unbreakable one. Now you know exactly what stands behind it, and exactly where it can bend.

Commands to See It Yourself

The entire certificate system is open to inspection, and looking at a real certificate makes all of this concrete.

See a website's full certificate and chain:

openssl s_client -connect example.com:443 -showcerts

This connects and prints the certificates the server presents, the end-entity certificate and the intermediates, the actual chain we discussed, as raw data.

See a certificate's details in readable form:

openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text

This decodes the certificate into human-readable fields. Look for the Issuer (the authority that signed it), the Subject (the domain it is for), the Validity dates, and the Public Key. You are reading the exact binding of key to identity that this whole post described.

See just the issuer and validity, quickly:

openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates

In your browser: click the padlock icon in the address bar and select the certificate or connection details. Your browser will show you the full chain, from the site's certificate up through the intermediate to the trusted root, exactly the links your browser verified to decide the connection was safe. You can see, for any site, precisely which authority vouched for it and which root anchors the trust.

What You Now Understand

You came in with two questions that sounded impossible, and you can now answer both.

How do two strangers agree on a secret over an open channel? Through public-key cryptography: a mathematically linked pair of keys where the public one locks and only the private one unlocks, so a shared secret can be established in full view of an eavesdropper who never sees the piece that unlocks. Because that mathematics is slow, TLS uses it only to bootstrap a fast symmetric key, and modern TLS does so with forward secrecy, so that stealing a key tomorrow cannot unlock the conversations of today. You can trace the whole handshake: hello, certificate, key exchange, identity proof by signature, and then the encrypted tunnel.

And how does your browser know the server is genuine? Through certificates, which bind a public key to an identity and carry the signature of a certificate authority. That authority's certificate is signed by another above it, forming a chain that leads up to a root authority pre-installed in your device's trust store. Your browser trusts a site because the chain climbs, link by verified link, to a root it was told to trust when you installed your software.

Most importantly, you understand the honest truth at the foundation. That trust is institutional, not magical. It rests on a few hundred authorities, any one of which is a potential single point of failure, as the DigiNotar breach showed when forged certificates were used to spy on real people behind a perfect padlock. The system defends itself not through perfect prevention but through transparency, revocation, and the credible threat of instant removal from the trust stores. It is a human chain of trust, well-designed and well-defended, and now you can see every link in it.

In the next post, we step back from the web and look at how traffic actually crosses the entire internet, from one network to another, all the way around the world. We will meet the routers and the routing protocols that stitch tens of thousands of independent networks into one, and we will see why the system that decides how your data traverses the globe was also, like so much of the internet, built on trust, with consequences we have already glimpsed. That is Post 9, on routing and BGP.

This is Post 8 of the Networking Foundations series. If TLS and certificates finally make sense, and you can see both the beauty of the cryptography and the humanity of the trust beneath it, share it with someone who thinks the padlock is pure mathematics. New here? Start with Post 1, and Post 7 on HTTP and HTTPS leads directly into this one. Subscribe to our newsletter to get each new post as it publishes.

HTTP and HTTPS: The Language of the Web, and the S That Protects It

VickkyKruz NetSec — Sat, 08 Aug 2026 13:28:11 +0000

We have climbed a long way up the stack. We gave data a network to travel on, a way to travel in packets, an address to aim for, a name that resolves to that address, and in the last post, a reliable connection to carry it, courtesy of TCP. Every one of those layers exists to support the thing that finally sits on top: the actual conversation between your browser and a website.

That conversation has a language, and its name is HTTP, the Hypertext Transfer Protocol. Every time you load a page, submit a form, watch a video, or use an app that talks to a server, HTTP is the language being spoken underneath. It rides on top of the TCP connection you now understand, and it is the foundation of the entire web.

This post is about that language, in real depth. How a request is actually structured, how a response answers it, the methods and status codes and headers that make it work, and the surprising fact that HTTP remembers nothing about you between requests, which shaped the entire modern web. Then we turn to the single most important upgrade in the web's history: the S in HTTPS. We will see clearly what it protects, why it became universal, and, just as importantly, what it does not protect, because the padlock promises less than most people think.

One note before we begin. This post introduces HTTPS and what it achieves. The deep cryptographic machinery underneath it, the TLS handshake, certificates, and how trust is actually established, is the entire subject of the next post. Here, we cover what the S does. Post 8 covers how.

What HTTP Actually Is

At its heart, HTTP is beautifully simple. It is a request-response protocol. A client, usually your browser, sends a request to a server. The server sends back a response. That is the entire model. Every interaction on the web is some version of this single exchange: ask, and receive an answer.

When you loaded this page, your browser sent an HTTP request to the server asking for the page's content. The server sent back an HTTP response containing the HTML. As your browser read that HTML and found it needed more things, images, stylesheets, fonts, scripts, it sent more requests, one for each resource, and received more responses. A single web page you view is very often the result of dozens of these request-response pairs happening in quick succession.

HTTP is also, by design, human-readable in its classic form. The messages are structured text, which is part of why it became so universal: it was easy to understand, easy to implement, and easy to debug. Let us look at what those messages actually contain, because the structure is the substance.

The Anatomy of a Request

Every HTTP request has three parts: a request line, headers, and an optional body.

The request line states what you want. It contains three things: a method, a path, and the protocol version. It might look like this:

GET /products/42 HTTP/1.1

Here, GET is the method (the action), /products/42 is the path (which resource), and HTTP/1.1 is the version. This one line captures the essence of the request: what action, on what resource.

The method is the verb, and it tells the server what action to perform. There are several, and the main ones are worth knowing:

GET retrieves a resource. It asks the server to send something back, and it should not change anything on the server. Viewing a page or fetching data from an API is a GET. It is the default, and the most common method by far.

POST sends data to the server to create something or trigger an action. Submitting a form, adding an item to a cart, or creating an account is typically a POST.

PUT updates a resource, replacing it with the data you send.

DELETE removes a resource.

HEAD asks only for the headers of a response, not the body, useful for checking something without downloading it.

OPTIONS asks what methods a resource supports.

These methods are classified by two useful properties. Some are safe, meaning they do not modify server state, GET, HEAD, and OPTIONS are safe, because they only read. And some are idempotent, meaning that repeating the request produces the same result as making it once. All safe methods are idempotent, and so are PUT and DELETE, deleting something twice leaves it just as deleted as doing it once. POST is neither safe nor idempotent, which is why submitting a payment form twice can genuinely charge you twice, and why browsers warn you before re-sending a POST.

The headers come next, a set of key-value lines carrying extra information about the request. They are where a huge amount of the web's real work happens. A few important ones: Host names the domain being requested, essential because one server can host many sites. User-Agent identifies the client, whether a browser, a mobile app, or a tool like curl. Accept tells the server what content formats the client can handle. Accept-Language states the user's preferred language. Authorization carries credentials to authenticate the request. And Cookie, which we will come back to shortly, carries stored data back to the server.

The body is optional. For a GET request, there is usually no body, you are only asking for something. For a POST or PUT, the body carries the data being sent, the form contents, the JSON payload, the file being uploaded. The Content-Type header tells the server how to interpret that body, whether it is JSON, form data, or something else.

The Anatomy of a Response

The server's response mirrors the request's structure: a status line, headers, and a body.

The status line reports what happened. It contains the protocol version, a three-digit status code, and a short reason phrase:

HTTP/1.1 200 OK

The 200 is the status code, the machine-readable outcome. The OK is the reason phrase, a human label with no technical significance, which newer versions of HTTP omit entirely.

The status code is one of the most useful things to understand about the web, because it tells you, in three digits, exactly how your request was handled. Codes are grouped into five classes by their first digit:

The 1xx codes are informational, rarely seen directly.

The 2xx codes mean success. 200 OK is the classic, the request worked and here is your content.

The 3xx codes mean redirection, the resource is elsewhere. 301 is a permanent redirect, 304 means "not modified, use your cached copy."

The 4xx codes mean the client made an error. 404 Not Found is the famous one, the server cannot find what you asked for. 403 Forbidden means you are not allowed. And 402 Payment Required, which we met in the web-centralisation interlude, is the status code that sat reserved and unused for three decades because the web never got a native payment layer.

The 5xx codes mean the server failed. 500 Internal Server Error is the general "something broke on our end."

Once you know the five classes, you can read any status code's meaning at a glance: 2 is success, 3 is go elsewhere, 4 is your fault, 5 is my fault.

The headers in the response carry information about what is being sent back. Content-Type states the format of the body, such as text/html or application/json, so the browser knows how to handle it. Content-Length gives its size. Cache-Control tells the browser how long it may reuse this response without asking again. And Set-Cookie, which we are about to discuss, hands the browser a piece of data to store.

The body is the actual content: the HTML of the page, the JSON from the API, the bytes of the image. It is what you came for. Everything else, the status line and headers, is the envelope and the label around it.

The Great Quirk: HTTP Remembers Nothing

Here is a fact about HTTP that shaped the entire web, and it connects directly to the story we told in the web-centralisation interlude.

HTTP is stateless. Each request is completely self-contained and independent. The server, by default, retains no memory whatsoever of any previous request from the same client. Every request arrives as if it were the very first the server had ever seen from you. When you load one page and then click to the next, HTTP itself has no idea those two requests came from the same person.

This statelessness was a deliberate design choice, and a good one. It keeps the protocol simple and lets servers handle enormous numbers of requests without tracking the history of each visitor. But it creates an obvious problem: if the server forgets you between every click, how does a shopping cart remember its contents? How does a site keep you logged in? How does anything that depends on continuity work at all?

The answer is that statefulness had to be built on top of stateless HTTP, and the primary tool for it is the cookie. The mechanism is elegant. When the server wants to remember something about you, it includes a Set-Cookie header in its response, handing your browser a small piece of data. Your browser stores it, and then automatically includes that data in a Cookie header on every subsequent request to that same site. Suddenly the server can recognise you: the cookie you send back carries, for example, a session identifier that lets the server look up who you are and what is in your cart.

This is exactly the point made in the interlude. HTTP left a gap, no memory, no state, and that gap had to be filled. Cookies filled it, and in filling it, they became not just the mechanism for logins and carts but the foundation of the entire tracking and advertising economy, because a thing that can recognise you across requests can also follow you across the web. The modern concepts of sessions and authentication tokens are all refinements of this same idea: carrying state across a protocol that was built to have none.

Understanding this one quirk explains an enormous amount about how the web actually works, and why so much of its infrastructure, and so many of its privacy problems, exist.

HTTP's Fatal Flaw: It Travels in the Open

Now we arrive at the problem that the S was invented to solve, and it is a serious one.

Classic HTTP sends everything as plaintext. The request line, the headers, the body, all of it travels across the network as readable text, exactly as written. This includes everything you type into a site over HTTP: your username, your password, your credit card number, the contents of every form. None of it is protected. It is the postcard problem from Post 2, now at the very top of the stack, carrying the most sensitive data of all.

Think about what that means in practice. Between your device and the server, your data passes through many hands: your local router, your internet provider, and every network in between. On plain HTTP, anyone positioned along that path can do three dangerous things. They can read everything you send and receive, capturing passwords and personal data in transit. They can modify it, altering the page you receive or the data you send, injecting content you never asked for. And they can impersonate, pretending to be the site you meant to reach. This is the classic man-in-the-middle attack: someone sitting invisibly between you and the server, reading and altering the conversation.

This was not a theoretical risk. In the era of plain HTTP, using public Wi-Fi at a cafe or airport was genuinely dangerous, because anyone else on that same network could position themselves in the middle and harvest the credentials of everyone around them. The web was, for its first decades, fundamentally insecure by default. Every login and every purchase travelled in the clear unless a site made a special effort otherwise.

The web needed to seal the envelope. That seal is HTTPS.

HTTPS: What the S Actually Adds

HTTPS stands for HTTP Secure, and the crucial thing to understand is what it actually is: it is ordinary HTTP, exactly as we have described it, running inside an encrypted tunnel. The requests and responses, the methods, the headers, the status codes, all of it is identical. HTTPS simply wraps that entire conversation in a layer of encryption called TLS, Transport Layer Security, so that no one along the path can read or tamper with it.

That encryption provides three distinct protections, and it is worth naming them separately because they are different guarantees.

Confidentiality. The conversation is encrypted, so anyone intercepting it sees only scrambled, unreadable data. Your password, typed over HTTPS, is meaningless to anyone watching the wire. This is the protection people usually think of.

Integrity. The encryption also ensures that if anyone tampers with the data in transit, the change is detected and the connection rejects it. An attacker cannot silently alter the page you receive or the form you submit, because the tampering breaks the cryptographic seal.

Authentication. HTTPS also lets your browser verify that the server it is talking to genuinely controls the domain in the address bar. This is what stops a man-in-the-middle from simply impersonating the site. How this verification actually works, through certificates and certificate authorities, is the subject of the next post, but the guarantee it provides is that you are really connected to the server for the domain shown, and not to an impostor sitting in the middle.

Together, these three, confidentiality, integrity, and authentication, close the man-in-the-middle attack. A listener on public Wi-Fi now sees only encrypted noise. This is why HTTPS went from a rarity, once reserved mainly for login and payment pages, to the default for essentially the entire web. Browsers now actively warn users away from plain HTTP sites, marking them "Not Secure," and the padlock icon appears when a connection is protected by HTTPS. The web sealed its envelopes, at last.

The Honest Part: What the Padlock Does Not Mean

Here is where I want to be carefully honest, because this is one of the most widely misunderstood things in all of web security, and the series' commitment to the real picture demands it.

The padlock in your browser means one specific thing: your connection to that server is encrypted, and the server controls the domain shown in the address bar. That is all it means. It does not mean the website is safe, honest, or trustworthy.

This distinction matters enormously, and attackers exploit the confusion deliberately. A phishing site, a scam shop, a page built purely to steal your login, can have a perfectly valid padlock. HTTPS will faithfully encrypt your data and deliver it securely, in a sealed envelope, straight to the criminal who set up the trap. The encryption works perfectly. It is just protecting a conversation with a thief.

This became a real problem for a specific, almost ironic reason. In the early web, certificates cost money and required some validation, so the padlock loosely correlated with legitimate operators who had spent effort to get one. Then, from 2015, free certificate authorities made certificates instant and free for anyone, which was a genuine and important win for privacy, since it let the whole web encrypt. But it also meant a scammer could get a valid certificate for a fraudulent domain in minutes. The result is that the overwhelming majority of phishing sites today use HTTPS, precisely because users were taught to look for the padlock and trust it. The padlock stopped being a signal of trustworthiness the moment trustworthiness stopped being required to obtain one.

So the accurate mental model is the one this series keeps returning to: HTTPS is a sealed, tamper-proof envelope. It guarantees that what you send arrives unread and unaltered, and that it went to the domain shown. It says nothing whatsoever about whether the person receiving it is honest. Addressing a sealed envelope to a scammer still delivers your secrets to a scammer. Encryption secures the channel. It does not vouch for the destination.

Understanding that line, what the padlock proves and what it does not, is one of the most practically valuable things you can take from this entire series, because it is misunderstood by almost everyone.

Commands to See It Yourself

HTTP's text-based design makes it wonderfully easy to inspect directly.

See a full HTTP request and response, headers and all:

curl -v http://example.com

The -v (verbose) flag shows the entire exchange: the request line and headers your machine sends, marked with >, and the status line and headers the server returns, marked with <. You are reading the raw language of the web, exactly as it goes over the wire.

See just the response headers:

curl -I https://example.com

The -I flag requests only the headers, using a HEAD request. You will see the status line, the Content-Type, Cache-Control, and often Set-Cookie and other headers, without the page body cluttering the view.

Compare HTTP and HTTPS directly:

curl -v https://example.com

Run this against an HTTPS site and, in the verbose output, you will see the TLS negotiation happen before any HTTP is exchanged, the encrypted tunnel being established first, then the ordinary HTTP conversation flowing inside it. That negotiation is the subject of the next post.

Watch your browser do it: open your browser's developer tools and select the Network tab, then load any page. You will see every single HTTP request the page makes, each with its method, status code, and full headers. It is the entire content of this post, visible live on any site you visit.

What You Now Understand

You started at the top of the stack, with the language everything else exists to carry, and you now understand it properly.

You know that HTTP is a request-response protocol: a client asks, a server answers, and a single page is dozens of these exchanges. You can read the anatomy of a request, its method, path, headers, and body, and of a response, its status line, status code, headers, and body. You know the main methods and the difference between safe and idempotent ones, and you can decode any status code from its first digit, 2 success, 3 redirect, 4 your error, 5 server error.

You understand the great quirk that HTTP is stateless, remembering nothing between requests, and how cookies were invented to carry state on top of it, becoming both the foundation of logins and the engine of web tracking, exactly the gap-filling story the interlude described.

And you understand the single most important upgrade in the web's history. Plain HTTP travels as readable plaintext, exposed to reading, tampering, and impersonation by anyone on the path, the man-in-the-middle threat that made the early web insecure by default. HTTPS wraps HTTP in TLS encryption to provide confidentiality, integrity, and authentication, sealing the envelope and closing that attack. But, crucially, you know what the padlock does not promise: it secures the channel, not the site, and a phishing page can wear the padlock as comfortably as a bank can. Encryption protects the conversation. It does not vouch for who you are talking to.

In the next post, we open up that encrypted tunnel and look inside. How does TLS actually work? How do two machines that have never met agree on a secret no eavesdropper can learn? What is a certificate, who issues it, and why does your browser trust them? That is the deep machinery of trust on the internet, and it is Post 8.

This is Post 7 of the Networking Foundations series. If HTTP and HTTPS finally make sense as more than an address-bar detail, share it with someone who has always wondered what the padlock really means. New here? Start with Post 1, and Post 6 on TCP and UDP leads into this one. Subscribe to our newsletter to get each new post as it publishes.

TCP vs UDP: Reliability or Speed, the Choice Every Connection Makes

VickkyKruz NetSec — Sun, 02 Aug 2026 17:27:43 +0000

We have spent this series following data on its journey. We gave it a network to travel on, a way to travel in packets, layers to pass through, an address to aim for, and a name that resolves to that address. By now, a connection can find its destination anywhere in the world.

But finding the destination is not the whole story. Once two machines are ready to exchange data, they face a decision, and it is one of the most consequential decisions in all of networking. Do they want the exchange to be reliable, where every piece is guaranteed to arrive, in order, no matter what, or do they want it to be fast, where data flies with the least possible delay, even if the occasional piece goes missing?

This is the reliability-versus-speed tradeoff, and it lives at Layer 4, the transport layer from our OSI post. Almost everything that travels the internet is carried by one of two transport protocols that answer this question in opposite ways. TCP chooses reliability. UDP chooses speed. Neither is better. They are two different tools for two different jobs, and knowing which does what, and why, explains an enormous amount about the behaviour of everything you use online.

Let us meet them properly.

The Whole Idea, in One Picture

Before any mechanics, hold this comparison in your head, because everything else is just detail hanging off it.

Imagine you need to send an important series of documents to someone.

TCP is the recorded-delivery courier. It establishes contact with the recipient first, confirms they are ready, and only then begins. It numbers every package, waits for a signed confirmation that each one arrived, and if any package is lost or damaged, it notices and sends another copy. It guarantees that everything arrives, complete and in the right order. That reliability is wonderful, but it has a cost: all that confirming, waiting, and re-sending takes time, and adds overhead.

UDP is the person who writes messages on postcards and drops them in the postbox as fast as they can. No prior contact, no confirmation, no record of what was sent. Most postcards arrive, usually quickly. But if one gets lost in the post, nobody notices and nobody re-sends it. What you lose in guarantees, you gain in raw speed and simplicity.

That is the entire tradeoff. TCP trades speed for reliability. UDP trades reliability for speed. Every other fact in this post is a consequence of that one difference.

TCP: The Reliable One, in Depth

TCP stands for Transmission Control Protocol, and it is described as connection-oriented. That single word is the key to everything it does. Before TCP sends any real data, it establishes a formal connection between the two machines, a shared agreement that both are present, ready, and synchronised. Nothing meaningful is sent until that connection exists.

Building that connection is the job of one of the most famous exchanges in all of networking.

The Three-Way Handshake

When a TCP connection opens, the two machines perform a three-step exchange called the three-way handshake. It is worth understanding step by step, because it appears everywhere, including in the security section later.

Step 1, SYN. The client that wants to connect sends a SYN packet (SYN is short for "synchronise"). This is the opening knock. In it, the client proposes a connection and includes an initial sequence number, a starting count that will be used to keep all the following data in order.

Step 2, SYN-ACK. The server receives the knock and responds with a SYN-ACK packet. This does two things at once: it acknowledges the client's request (the ACK, "acknowledge") and it sends the server's own initial sequence number (its own SYN). The server is saying, in effect, "I heard you, I am ready, and here is my starting count too."

Step 3, ACK. The client sends a final ACK packet, acknowledging the server's response. Now both sides have confirmed they can send and receive, both have exchanged sequence numbers, and both move into the ESTABLISHED state.

Only after these three messages does a single byte of actual application data flow. Notice why three steps and not two: two messages would only confirm that the server can hear the client, not that the client can hear the server. The third message closes that loop, confirming two-way communication and letting both sides agree on where their numbering begins. It also helps prevent old, duplicate connection requests from being mistaken for new ones.

Acknowledgements and Retransmission

Once the connection is established, TCP's reliability machinery goes to work on every piece of data.

TCP breaks your data into numbered segments and sends them. The receiver acknowledges what it has received, but in a clever way: it acknowledges by naming the next byte it expects, not the last one it got. So if the receiver has successfully taken in everything up to byte 1000, it sends an acknowledgement saying "I am now expecting byte 1001."

Here is where the reliability becomes concrete. Suppose the segment carrying bytes 1001 to 1500 goes missing in transit. The receiver never gets it, so it keeps acknowledging "I am expecting 1001," over and over, even as later segments arrive. Those repeated acknowledgements are a signal: a gap has opened. The sender detects the loss in one of two ways, either it receives several duplicate acknowledgements for the same byte, or its own timer for that segment expires with no fresh acknowledgement at all. Either way, it re-sends the missing segment. Nothing is lost, because TCP simply refuses to move on until the gap is filled.

Ordering

Data can take different paths across the internet, so segments sometimes arrive out of order. Because every segment is numbered, TCP can reassemble them into the correct sequence before handing them to the application. And crucially, if a segment is missing, TCP holds back everything that arrived after the gap until the missing piece is retransmitted and slotted into place. The application never sees jumbled or incomplete data. It only ever receives a clean, ordered stream, exactly as it was sent.

Flow Control

There is one more piece of the machinery worth knowing. What happens if the sender is a powerful server and the receiver is a slow device that cannot keep up? Without some control, the fast sender would overwhelm the slow receiver, and data would be dropped simply because the receiver had no room for it.

TCP prevents this with flow control. The receiver constantly tells the sender how much data it is currently able to accept, a value called the window. The sender respects this limit, slowing down or speeding up so it never sends more than the receiver can handle at that moment. It is a continuous negotiation that keeps a fast sender from drowning a slow receiver, and it is another reason TCP is described as reliable: it manages not just loss, but pace.

The Cost

All of this machinery, the handshake, the acknowledgements, the retransmissions, the ordering, the flow control, is what makes TCP dependable. But it is not free. Every connection begins with a full round trip before any data moves. Every segment carries a header that starts at 20 bytes. Every piece of data waits for confirmation. This adds overhead and latency. For most uses that cost is completely worth it, and invisible. But for some uses, as we will see, it is exactly the wrong trade, and that is where UDP comes in.

As a historical note, TCP is one of the oldest protocols on the internet, originally defined in 1981. It has been refined for over four decades, and the current standard, published in 2022, consolidates all those years of fixes into a single modern specification.

UDP: The Fast One, in Depth

UDP stands for User Datagram Protocol, and where TCP is connection-oriented, UDP is connectionless. This is the heart of the difference. UDP performs no handshake, establishes no connection, and keeps no shared state. The sender simply packages data into units called datagrams and fires them at the destination address and port, with no setup and no expectation of a reply.

Everything TCP carefully does, UDP deliberately does not. There is no acknowledgement that a datagram arrived. There is no retransmission if one is lost, a dropped datagram is simply gone, and any recovery is left entirely to the application to handle if it wants to. There is no guarantee of ordering, datagrams may arrive in a different order than they were sent. And there is no flow control.

This might sound like a broken version of TCP. It is not. It is a deliberately minimal design, and its minimalism is the entire point. Because it skips the handshake, the acknowledgements, and the retransmissions, UDP avoids the round trips and the waiting that those mechanisms require. Its header is only 8 bytes, compared to TCP's 20 or more. The result is dramatically lower latency and overhead. UDP nearly always wins on speed, because it is doing so much less.

The key insight is this: for some applications, a lost piece of data is not worth the delay it would take to recover it. Think about a live voice call. If a tiny fragment of audio is lost, you do not want the protocol to stop everything, go back, and re-send that fragment, because by the time it arrived, the conversation would have moved on and you would hear a stutter or a delay. You would much rather it simply skip the lost fragment and keep the call flowing in real time. For live, real-time data, a late packet is often worse than a lost one. That is precisely the situation UDP is built for.

Who Uses Which, and Why

The tradeoff makes the choice almost obvious once you see it. The question is always: for this application, what matters more, that every byte arrives, or that data arrives with minimal delay?

TCP is used where completeness is non-negotiable. Web pages ride on TCP, because a page with missing bytes is broken. Email uses TCP, because a message must arrive whole. File transfers use TCP, because a downloaded file with a missing chunk is corrupt and useless. Anything where the loss of even a single byte would ruin the result uses the courier who guarantees delivery. When you loaded this page, that was TCP doing its careful work, and you never noticed, which is exactly the point.

UDP is used where speed matters more than perfection. Live video streaming and video calls use UDP, because a dropped frame is better than a frozen picture. Voice over IP, the technology behind internet calls, uses UDP for the same reason. Online gaming uses UDP, because the current position of a player is what matters, and a delayed update about where they were a moment ago is useless. And DNS, the phone-book system from our last full post, uses UDP for its quick lookups, because a query and its answer usually fit in a single small packet and speed is essential, though it switches to TCP for larger responses.

Once you internalise the tradeoff, you can often guess correctly which protocol any given application uses, just by asking whether it would rather be complete or fast.

The Security Dimension: When the Design Becomes the Weakness

Here is the thread that runs through this entire series, appearing once again. The very design choices that make these protocols work are also what make certain attacks possible. Understanding TCP and UDP is not just useful for building things. It is essential for understanding a whole category of attacks, because the attacks target the protocols' fundamental mechanics.

The SYN Flood: Weaponising the Handshake

Remember the three-way handshake, and specifically what the server does at step two. When a server receives a SYN, it responds with a SYN-ACK and then waits for the final ACK to complete the connection. While it waits, it holds that connection half-open, setting aside a small amount of memory and a slot in its connection queue for it. This is completely normal, and the half-open connection times out and clears after a short period, roughly a minute, if the final ACK never comes.

An attacker can weaponise this. In a SYN flood attack, the attacker sends a rapid stream of SYN packets, thousands per second, but never sends the final ACK for any of them. Each one forces the server to open another half-open connection and reserve resources for it. If they arrive fast enough, the server's connection queue fills entirely with these incomplete handshakes, and there is no room left for legitimate connections. Real users are turned away, not because the server was flooded with overwhelming traffic, but because its handshake mechanism was turned against it. It is an elegant and nasty attack precisely because it abuses TCP working exactly as designed.

The primary defence is a clever technique called SYN cookies. Instead of reserving memory the moment a SYN arrives, the server encodes the connection information into the sequence number it sends back in the SYN-ACK, and allocates no resources yet. Only when a legitimate final ACK returns, carrying that encoded information back, does the server actually set up the connection. This means a flood of SYNs that never complete costs the server almost nothing, because it was never holding state for them in the first place. Other mitigations include rate-limiting incoming SYNs, enlarging the connection queue, and recycling the oldest half-open connections to make room.

UDP Amplification: Weaponising Connectionlessness

UDP's defining feature, that it is connectionless and requires no handshake, creates a different and equally serious weakness. Because there is no handshake to prove who you are, it is trivial to lie about your own address. An attacker can send a UDP request while forging the source address, so the reply is sent not to the attacker but to whoever they named. This is called spoofing, and connectionless protocols make it easy, because nothing ever verifies that the sender is who they claim to be.

Now combine that with a second idea. Some UDP-based services reply to a small request with a much larger response. An attacker exploits this by sending many small requests to these services, each one forged to appear to come from the victim's address. The services dutifully send their large responses to the victim, who is buried under a flood of traffic they never asked for. This is a reflection and amplification attack, and the numbers are staggering. A DNS-based amplification can multiply the attacker's traffic by roughly 28 to 54 times. Using misconfigured time servers, the NTP protocol, the amplification can reach over 500 times. And exploiting exposed memcached servers, the factor can exceed fifty thousand times, meaning a trickle of attacker traffic becomes a torrent aimed at the victim.

A famous real-world demonstration of this class of attack came from the Mirai botnet, which harnessed vast numbers of insecure internet-of-things devices, the cheap cameras and routers we discussed segmenting away in the subnetting post, to launch some of the largest denial-of-service attacks ever recorded. It is a direct illustration of how these transport-layer weaknesses, combined with poorly secured devices, translate into real and massive disruption.

Defences against amplification focus on the root causes: network operators filtering traffic with forged source addresses so spoofing becomes harder, operators securing or closing the exposed services that do the amplifying, and dedicated mitigation services absorbing and scrubbing the flood before it reaches the target. As always in this series, no single fix is complete, and defence is layered.

The lesson is consistent with everything we have seen. These are not bugs in TCP or UDP. They are the direct consequences of the exact design choices, the handshake and the connectionless simplicity, that make the protocols useful. To defend a system, you have to understand the mechanics of what it is built on.

Commands to See It Yourself

Both protocols are visible on your own machine with the right tools.

See active TCP connections and listening ports:

netstat -ant      (shows all TCP connections and their state)
ss -t             (a modern Linux equivalent)

Look at the state column. You will see connections in the ESTABLISHED state, the same word from the handshake. You may also see states like TIME_WAIT, part of the connection teardown that mirrors the setup handshake.

Watch a three-way handshake happen live:

sudo tcpdump -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' -c 10

With this running, open a website in your browser, and you will see the SYN, SYN-ACK, and ACK packets fly past in real time, the handshake we described, captured on your own connection. Few things make the concept as concrete as watching it occur.

See UDP traffic, including DNS:

sudo tcpdump -i any udp port 53 -c 5

Then trigger a DNS lookup, for example by visiting a new site, and watch the UDP DNS queries and responses appear, connectionless and quick, with no handshake preceding them. You are seeing the contrast from this post directly: TCP's careful setup versus UDP's fire-and-forget.

What You Now Understand

You began with a single question that every connection must answer, reliability or speed, and you now understand the two protocols that answer it in opposite ways.

You understand TCP in real depth. It is connection-oriented, opening with the three-way handshake of SYN, SYN-ACK, and ACK to synchronise both sides before any data flows. It numbers its segments, uses acknowledgements that name the next expected byte, and retransmits anything lost, detected either by duplicate acknowledgements or by a timeout. It reorders segments so the application sees a clean, ordered stream, and it uses flow control so a fast sender never overwhelms a slow receiver. All of this guarantees delivery, at the cost of overhead and latency.

You understand UDP just as clearly. It is connectionless, with no handshake, no acknowledgements, no retransmission, no ordering, and no flow control. That is not a flaw, it is a deliberate design for situations where speed matters more than completeness, and where a late packet is worse than a lost one, like live calls, video, gaming, and quick DNS lookups.

You can now reason about which protocol an application should use, just by asking whether it needs every byte or needs minimal delay. And you understand how this all connects to security: the SYN flood that weaponises the handshake, defended by SYN cookies, and the spoofing and amplification attacks that exploit UDP's connectionless trust, capable of multiplying an attacker's traffic thousands of times over. These attacks are not flaws in the protocols. They are the shadow side of the very features that make the protocols work, which is the lesson this series returns to again and again.

In the next post, we climb one layer higher, to where these transport protocols are actually put to use by the applications you interact with directly. We will look at HTTP and HTTPS, the protocols of the web itself, how a request for a web page actually works on top of the TCP connection you now understand, and what that crucial S in HTTPS is really doing to keep you safe. That is Post 7.

This is Post 6 of the Networking Foundations series. If the TCP and UDP distinction finally makes sense, and you can see the tradeoff behind it, share it with someone who has only ever memorised the two as a list of differences. New here? Start with Post 1, and Post 5 on DNS leads into this one. Subscribe to our newsletter to get each new post as it publishes.

Why the Web Centralised: The Protocol Gaps That Platforms Filled

VickkyKruz NetSec — Sat, 18 Jul 2026 15:37:29 +0000

Five posts in, this series has been circling one idea from five different angles.

ARPANET connected four trusted institutions and needed no security, because everyone on it was known. Packets travel with their addresses exposed, like postcards, because routing demands it. The OSI layers each trust the layer beneath them to have done its job honestly. IP addresses locate a machine but say nothing about who is operating it. And DNS, the internet's phone book, cannot verify that its own answers are genuine.

Every post lands in the same place: the foundational protocols were built for connection, not control. They answered "how do we make these machines talk to each other" brilliantly, and left almost everything else to someone else.

This interlude is about that "someone else."

Because here is the thing I want to argue, and I think the evidence for it is strong: the web did not centralise despite its open, decentralised design. It centralised because of it. Every gap the original protocols left open was eventually filled by a company. And every company that filled a gap became a chokepoint.

That is not a betrayal of the web's architecture. It is the market completing an unfinished protocol.

The Gaps Were Real, and They Were Deliberate

Let us be precise about what the early web actually shipped, because the story only works if we are honest about the technical facts.

Tim Berners-Lee's web gave us three things: a way to name resources (URLs), a way to request them (HTTP), and a way to structure them (HTML). That combination was extraordinarily powerful and extraordinarily minimal. It let any machine serve a document and any machine request one, with no permission needed from anybody. That openness is why it won.

But look at what it did not include.

It did not include a way to know who you were talking to. As we established in Post 4, IP addressing tells you the address of a machine, not the identity of the person, organisation, or thing responsible for that machine. The protocol stack was built to locate endpoints, not to authenticate the humans behind them. The internet was built without any native way of knowing who and what we are connecting to, and because of that, everyone offering a service has had to cobble together their own workaround. That patchwork is why the average business user today juggles something like 191 passwords. Every site had to invent its own identity system, because the web never provided one.

It did not include a way to pay for anything. This one is my favourite, because the evidence is sitting in the specification itself, in plain sight, and has been for over thirty years. HTTP status code 402 is called "Payment Required." It has been in the HTTP specification since the early 1990s. And its official definition has always been, essentially, reserved for future use. The people who designed the web knew a payment layer would be needed. They left a placeholder for it. And then it sat dormant for three decades, because the web was never given a native payment primitive, and the core architecture of the internet has no way to send money the way it transmits information.

Think about what that means. There is a status code in every HTTP implementation on earth, waiting for a payment system that the protocol never delivered.

It did not include a way to establish trust. HTTP will faithfully fetch you a document from a stranger's server. It has no opinion whatsoever about whether that stranger is honest, whether the goods they are selling exist, or whether they will take your money and vanish. Trust was simply not in scope.

It did not include a way to find anything. The web gave us links, but no directory, no index, no search. If you did not already know a URL, or know someone who did, the resource was effectively invisible to you.

And it did not include a way to store state. HTTP is stateless by design. Each request stands alone, knowing nothing of the last. Elegant, scalable, and completely incapable of remembering that you are logged in, what is in your basket, or who you are.

None of these were oversights by careless engineers. They were the deliberate minimalism that made the web deployable. A protocol that had tried to standardise identity, payment, trust, discovery, and state in 1991 would have been so complex, so contentious, and so slow to agree that it would very likely never have shipped at all. The web won because it was small enough to adopt without asking anyone's permission.

But an unfinished protocol does not stay unfinished. The gaps get filled. The only question is by whom.

Every Gap Became a Company

Here is the pattern, and once you see it, the entire shape of the modern web snaps into focus.

The identity gap became login providers. Because there was no protocol-level way to prove who you are, every website built its own account system. That was miserable for users and miserable for developers, so a solution emerged: let one big platform handle identity for everyone. "Sign in with Google." "Log in with Facebook." Facebook's identity system was explicitly marketed to app developers as a generalised web identity system, and it genuinely improved usability, but at the cost of ceding developer and consumer control to the platform. A missing protocol layer became a product, and the company that provided it now sits between you and thousands of services, watching you arrive at each one.

The payment gap became payment processors. HTTP 402 stayed dormant, so commerce needed rails the protocol did not offer. Card networks, then PayPal, then Stripe stepped into that void. They did it well. But it means that value on the web does not flow peer to peer the way information does. It flows through gateways, each of which can charge a fee, set terms, and decide who is allowed to transact at all. The web transmits data without asking permission and money only with it.

The trust gap became platforms. This is the subtlest and most powerful one. Because HTTP could not tell you whether a stranger was trustworthy, buying from a random website was genuinely risky. The solution that emerged was to not trust the stranger at all, and trust an intermediary instead. You do not trust the seller on Amazon; you trust Amazon. You do not trust the driver; you trust Uber. You do not trust the host; you trust Airbnb. Each of these companies is, at its core, a trust layer that the protocol never provided, monetised. And notice what happens once a company becomes the trust layer for a market: it can set the rules of that market, take a cut of every transaction, and remove any participant it chooses. That is not a business model bolted onto the web. It is a missing protocol layer, privatised.

The discovery gap became search. With no directory in the protocol, finding anything required an index, and building a good index was hard and expensive. Google built the best one, and in doing so became the front door to the web. A gap in the protocol turned into the most valuable position on the internet: the entity that decides what is findable.

The state gap became cookies, then tracking. HTTP's statelessness had to be worked around for anything interactive to function, so we got cookies. Cookies solved a genuine engineering problem, and then, because they let a party recognise you across visits, they became the foundation of the entire surveillance advertising economy. A patch for a protocol limitation became the infrastructure of tracking.

Look at the pattern in aggregate. Identity, payment, trust, discovery, state. Five gaps. Five industries. And in every single case, the entity that filled the gap acquired enormous power, not by conquering the web, but by supplying something the web needed and had never provided.

This is why I think the standard story of centralisation is wrong. It is usually told as a moral tale: the open web was hijacked by greedy corporations. But the mechanism was simpler and more structural than that. The protocols left holes. Holes in essential infrastructure get filled. Whoever fills a hole that everyone depends on becomes a chokepoint, and chokepoints accumulate power automatically, regardless of anyone's intentions.

If this argument sounds familiar, it should. It is the same one I made in my post on AI infrastructure: control concentrates in the layers underneath, and it cascades upward. The web is that argument told over thirty years.

Web3: The Right Diagnosis, and What Actually Happened

This is where Web3 enters, and I want to handle it carefully, because it is a topic where most writing is either evangelism or contempt, and neither is useful.

Give Web3 its due: the diagnosis was correct. Its central claim was that the web's centralisation was caused by missing protocol layers, particularly trust and identity and payment, and that if you could provide those at the protocol level instead of the platform level, you would remove the need for the intermediaries entirely. That is a genuinely serious argument, and it is the same argument I have just spent this post making. Web3 read the problem correctly.

The bet was that cryptography and distributed consensus could supply the missing layers. A blockchain could provide trust without a trusted intermediary. A wallet could provide identity without an identity provider. A token could provide payment without a payment processor. Fill the protocol gaps, and the platforms that grew inside them become unnecessary.

So what happened? The honest answer is that it has largely not worked at the scale it promised, and the infrastructure lens explains why better than either the hype or the mockery does.

It re-centralised at the layer below. This is the most instructive failure, and it is exactly what this series would predict. In November 2020, an Infura outage disrupted Ethereum wallets, DeFi platforms, and exchanges. MetaMask users could not access their funds. But the blockchain itself was fine, still processing blocks normally. The problem was the access layer: too many applications depended on a single infrastructure provider to reach the chain. The lesson the ecosystem drew was blunt, and it is the thesis of this entire post: even a decentralised blockchain can rely heavily on centralised gateways.

It happened again, larger. When a major AWS outage hit in October 2025, it exposed how heavily Web3 depends on centralised infrastructure. Coinbase went down. Its Base layer-2 network went down. Infura was degraded. MetaMask front-ends faltered. An ecosystem built explicitly to eliminate central points of failure was taken offline by a central point of failure, because someone still has to run the servers, and it turned out to be the same handful of companies as everyone else.

That is the pattern this series keeps finding. You can decentralise a protocol, but the protocol runs on infrastructure, and infrastructure has economics. Whoever pays for the servers, the bandwidth, and the reliability tends to end up in control, no matter what the protocol above them says.

It fought network effects and lost. The centralised incumbents were not just holding a technical position. They were holding a network effect. A decentralised alternative that is technically superior but has a tenth of the users is not, for most people, superior at all. This is the same wall I discussed in a recent comment about DNS: you cannot flag-day the internet. IPv6 is technically better than IPv4 and, decades in, still runs alongside it rather than replacing it. Better does not win. Better-plus-deployable wins.

And the incentives pulled it off course. Much of the energy that could have gone into building the missing layers went into speculation instead. Serious critical scholarship has questioned whether Web3 genuinely distributes power or merely shifts influence to a new tech-savvy elite, and a fair reading of the last few years makes that question hard to dismiss. Meanwhile the practical gateways people actually used, the exchanges, the wallet providers, the RPC endpoints, consolidated into exactly the kind of intermediaries the movement set out to abolish.

So the fair summary is this: Web3 identified the right problem and demonstrated, at real expense, that fixing a protocol gap with cryptography alone does not fix the centralisation, because centralisation is not only a protocol phenomenon. It is an infrastructure and economics phenomenon. That is a genuinely valuable finding, even though it is not the one anyone wanted.

And it is worth noting the quieter, more interesting sequel. HTTP 402 is finally being activated, thirty years on, through efforts to build a real payment primitive into HTTP, driven largely by the needs of AI agents that cannot click through a checkout page. Whether that succeeds is genuinely unsettled, and I would not bet either way. But it is the clearest possible demonstration of the thesis: the gap was real, it was left in the specification on purpose, and the pressure to fill it never went away.

What This Means for Anything Being Built Now

The reason this matters beyond history is that the pattern is not finished. It is running right now, on the next layer.

Every emerging technology arrives with its own set of protocol gaps, and the same race to fill them. AI systems have no native identity layer, no native payment layer, no native trust layer. Right now, those gaps are being filled, and the entities filling them are becoming the chokepoints of the next era, exactly as Google, Facebook, Amazon, and Stripe did for the web. The specific technologies change. The structure does not.

So the useful question, whenever you look at any new system, is not "is this decentralised?" It is: what does this protocol not provide, and who is going to provide it instead? That question tells you where the power will accumulate, usually years before it becomes obvious.

If you want to feel this rather than just read it, a few small projects make the gaps tangible, and I would suggest them as things to try rather than tutorials to follow:

Run your own service end to end, on your own VPS with your own domain, as I covered in a recent standalone guide. Doing it once teaches you exactly how much the platforms are actually doing for you, and where you are still dependent no matter how self-hosted you feel.

Build a small site that handles its own authentication instead of using "Sign in with Google," and notice how much work the identity gap really represents, and why almost everyone hands it to a platform.

Try to accept a payment without a processor, and watch how quickly you discover that the web has no native way to move money.

Serve something over a peer-to-peer protocol like IPFS and then ask yourself, honestly, who is pinning the data and who is running the gateway you are reaching it through.

Each of these is small. Each one teaches the same lesson from a different side: the gaps are real, filling them is hard, and that difficulty is precisely why the companies that filled them became so powerful.

What You Now Understand

We took a detour from the plumbing, but it was not really a detour.

You now know that the web's foundational protocols were deliberately minimal: they specified naming, requesting, and structuring documents, and left out identity, payment, trust, discovery, and state. That minimalism is why the web was deployable at all, so it is not a design flaw. It is the reason the web exists.

You know that those gaps did not stay empty. Each one was filled by a company, and each company that filled one became a chokepoint: login providers for identity, processors for payment, platforms for trust, search for discovery, cookies and tracking for state. Centralisation was not a hijacking. It was the market finishing an unfinished protocol, and collecting rent on the parts it completed.

You know that Web3 diagnosed this correctly and still largely failed to fix it, and you know why: it re-centralised at the infrastructure layer beneath the protocol, it fought network effects without a deployment path, and its incentives pulled it toward speculation. That is not a moral judgement, it is a structural one, and it is the same lesson the whole series teaches. Control lives in the layers underneath.

And most usefully, you have a question you can now apply to anything: what does this system not provide, and who will provide it instead? That is where the power goes.

In the next post we return to the plumbing, and to a question this interlude has quietly raised. We have talked a lot about how data finds its destination. Post 6 is about the choice every application makes once it gets there: reliability or speed. TCP and UDP, the three-way handshake, and the tradeoff that shapes everything from your bank transfer to your video call.

This was an interlude in the Networking Foundations series, sitting between Post 5 on DNS and Post 6 on TCP and UDP. If it gave you a new way to read the web's history, share it with someone who thinks centralisation was just greed. New here? The series starts with Post 1, on what a network actually is, and this interlude leans on everything from Posts 1 to 5. Subscribe to our newsletter to get each new post as it publishes.

Connecting a Domain to a VPS From a Different Company: The Guide Nobody Gives You

VickkyKruz NetSec — Sun, 12 Jul 2026 13:32:47 +0000

Almost everyone who has ever deployed something hits this exact wall.

You rent a VPS from one provider, maybe Hetzner, DigitalOcean, Contabo, or a Namecheap VPS. It gives you a public IP address, a string like 203.0.113.45. Separately, you bought a domain name from somewhere else entirely, maybe GoDaddy, Namecheap, or Cloudflare, because that is where it was cheapest or where you already had an account. So now you have two things bought from two different companies that have no relationship with each other: a server with an IP address, and a domain with a name.

And between them sits a gap that nobody explains. The VPS provider assumes you will sort out the domain. The domain registrar assumes you know where you want to point it. Neither walks you through the bit in the middle. You are left with a working server that nobody can reach by name, and a domain that leads nowhere.

This guide closes that gap. First the concept, because the reason people get stuck is almost never the clicking, it is not understanding what the clicks are actually doing. Then the walkthrough, covering both of the main methods, so you know not just how but which one to choose. And finally the part most guides skip entirely: getting HTTPS working, because a site reachable only over plain HTTP in 2026 is a site browsers actively warn people away from.

The Concept: Two Separate Decisions People Wrongly Merge Into One

Here is the single most important idea in this entire guide, and the thing that, once understood, makes everything else obvious.

Connecting a domain to a server involves two completely separate decisions, and almost everyone who gets stuck is stuck because they have merged them into one confused blob in their head. Separate them, and the confusion evaporates.

Decision one: who hosts your DNS? Remember from the DNS post (DNS: The Internet's Phone Book, and Its Biggest Weakness) that somewhere out there, a set of authoritative nameservers holds the records for your domain and answers the world's questions about it. The question here is: whose nameservers will those be? You have a choice. It can be your registrar's own nameservers, the default, since they run DNS for every domain they sell. Or it can be a third party like Cloudflare, whom you delegate the job to. This decision is about where your domain's DNS records live and who serves them.

Decision two: what do those records say? Wherever your DNS is hosted, it holds records. The one that matters here is the A record, which maps your domain name to an IPv4 address. This decision is about what address your domain actually points to, namely, your VPS's IP.

People get stuck because they conflate these. They think "pointing my domain at my server" is one action, when it is really two: choosing who runs your DNS, and then setting the record that names your server's IP. Once you see them as separate, the two methods below stop being competing mysteries and become simply two answers to decision one, with decision two working the same way in both.

Hold one more idea from the DNS post in mind as we go: propagation. DNS answers are cached all over the world according to their TTL, so when you change where your domain points, the change is not instant. It rolls out as old cached records expire. This is why nothing in this guide takes effect the very second you click save, and why patience is part of the process, not a sign something is broken.

Method One: Keep Your Registrar's DNS, Just Add an A Record

This is the simplest method, and for a great many people it is the right one. You leave your DNS where it already is, at your registrar, and you simply edit one record to point at your VPS.

Here is the whole idea: your registrar is already hosting your domain's DNS by default. You do not need to move anything. You just log in and add or edit the A record so it points at your VPS's IP address.

The steps, in principle, are the same wherever your domain lives, even though every registrar's panel looks slightly different:

Get your VPS's public IP address from your hosting provider's dashboard. It will look like 203.0.113.45.
Log in to your domain registrar and open the DNS management page for your domain.
Find the existing A records. Delete or edit any old A, AAAA, or CNAME records for the root (often shown as @) and for www, so they do not conflict with what you are about to add.
Add an A record for the root domain: host @, value your VPS IP. This makes example.com point at your server.
Add a second record for www. You can make this another A record pointing at the same IP, or a CNAME pointing at your root domain. Either makes www.example.com work.
Save, and wait for propagation, up to around 24 hours, though often much faster. That is it. Your domain now resolves to your server.

When to choose this method: if your VPS has a static IP that will not change, and you do not need extra features like a CDN or DDoS protection, this is the clean, correct choice. There is one honest caveat worth knowing: with the A record method, if your VPS IP ever changes, you must come back and update this record by hand. For a stable server that is a non-issue, but it is the tradeoff to be aware of.

Method Two: Delegate Your DNS to Cloudflare (or Another Provider)

The second method answers decision one differently. Instead of leaving your DNS at your registrar, you hand the job of hosting it to a third party, most commonly Cloudflare, and manage your records there instead.

Why would you do the extra work? Because moving your domain's nameservers to Cloudflare unlocks a set of things the registrar's basic DNS panel simply cannot do: putting your site behind Cloudflare's network for CDN caching and speed, hiding your server's real IP address, DDoS protection, a web application firewall, free SSL termination, easy DNSSEC, and a proper API. For anything you are self-hosting seriously, this is often worth it.

Crucially, and this surprises people, you do not move your domain away from your registrar to do this. Your domain stays registered exactly where it is. The only thing you change at the registrar is which nameservers it points to. Ownership does not move; only the DNS-hosting job does.

The steps:

Create a Cloudflare account and choose "Add a site" (or "Onboard a domain"), then enter your domain.
Cloudflare automatically scans your existing DNS records and imports what it finds. Review this list. In particular, make sure there is an A record pointing your domain at your VPS's IP; add or correct it if needed.
Cloudflare gives you two nameservers to use, something like ada.ns.cloudflare.com and bob.ns.cloudflare.com. Copy them.
Log in to your registrar, find the nameserver setting for your domain, and replace the registrar's default nameservers with the two from Cloudflare.
Wait for the delegation to take effect, up to 24 to 48 hours, though usually faster. Cloudflare emails you and shows the domain as "Active" once it sees the change.
From now on, you manage all your DNS records inside Cloudflare, not at your registrar. One important gotcha, learned the hard way by many. If your domain currently has DNSSEC enabled at your registrar, you must turn DNSSEC off at the registrar before changing the nameservers. Changing nameservers while DNSSEC is still active can make your domain unreachable, because the old cryptographic signatures no longer match the new DNS host. You can re-enable DNSSEC later, from within Cloudflare, once the domain is active. This single step trips up a lot of people, so do not skip it.

The orange cloud versus the grey cloud. Once you are managing records in Cloudflare, each record has a proxy toggle shown as a cloud icon, and understanding it prevents a lot of confusion. An orange cloud (proxied) means traffic goes through Cloudflare's network first: your real server IP is hidden, and you get the CDN, caching, and protection. A grey cloud (DNS only) means Cloudflare just answers the DNS question and the visitor connects straight to your server's real IP, with none of the proxying. For a normal website you want the orange cloud. But one rule to remember: mail records, and any non-web service like SSH, should always be grey cloud, because proxying only works properly for web traffic on the standard HTTP and HTTPS ports. Proxying your mail records will break your email.

When to choose this method: if you want a CDN, DDoS protection, to hide your origin IP, or if your VPS has a changing IP that you would rather manage through an API than by hand, this is the stronger choice. It is a few more steps up front for considerably more capability afterwards.

Which Method Should You Actually Use?

To make the choice concrete rather than abstract:

Choose the registrar A record method if you have a single VPS with a static IP, you want the simplest possible setup, and you do not need a CDN or the extra protection. It is direct and there is nothing wrong with it. Many perfectly good production sites run exactly this way.

Choose the Cloudflare nameserver method if you want performance and protection features, you want to hide your server's real IP from the public, you are running anything that might attract attention or attack, or you simply want a more powerful DNS control panel and API for the future. Given that Cloudflare's basic tier is free, many developers pick this route by default now, even for small projects, because it costs nothing and leaves room to grow.

Neither is wrong. They are answers to the same question at different levels of ambition.

The Step People Forget: Pointing Is Not Serving

Here is a mistake so common it deserves its own section, because it causes hours of confused debugging.

Getting your domain to point at your server is only half the job. It gets a visitor's browser to arrive at your server's front door. But it does nothing to make your server actually answer for that domain once they knock. Those are two separate things, and people constantly do the first and forget the second.

"DNS points to the server" and "the server is configured to serve the site for that domain" are different steps. Your DNS records send the visitor to the right IP. But your web server software on the VPS, whether that is Nginx, Apache, Caddy, or something else, also has to be told to respond to requests for your domain name and serve the right content. If you point your domain correctly but never configure the web server to recognise it, you will get a connection that lands but shows a default page, an error, or nothing useful, and you will wrongly assume the DNS is broken when it is fine.

So the real sequence is: point the domain (DNS), and configure the web server to serve that domain (server config). Only when both are done does typing your domain into a browser actually show your site.

Verifying It Worked, and the Waiting Game

Once you have set your records, you will want to check whether they have taken effect, especially since propagation is not instant. Two commands do almost all the work, both of which the DNS post introduced.

Check what your domain currently resolves to:

dig example.com +short

This should eventually print your VPS's IP address. If it prints nothing, or an old address, propagation has not finished, or a record is wrong. Run it again after a while.

Check that your server actually responds over the domain:

curl -I http://example.com

This makes a request and shows you the response headers. A sensible response here means your domain is not only pointing at the server, but the server is answering for it, both halves of the job done.

If these do not work immediately, resist the urge to change everything in a panic. Propagation genuinely can take up to 24 hours, occasionally a little more, because DNS resolvers around the world are still serving cached older records until their TTL expires. A tool like whatsmydns.net lets you watch propagation happen across different locations globally, which is reassuring when you are wondering whether you broke something or simply need to wait.

The Final Step: Turn On HTTPS

Your domain points at your server, and your server answers for it. But right now it does so over plain, unencrypted HTTP. In 2026, browsers show a visible "Not Secure" warning on HTTP sites, which quietly scares away visitors and undermines trust. And as the DNS and firewall posts in the series argued, unencrypted traffic is a genuine security exposure, not a cosmetic issue. So the last step of any real deployment is enabling HTTPS.

The standard, free way to do this is Let's Encrypt, a free and automated certificate authority, using a tool called Certbot. On a typical Ubuntu server running Nginx, the process is short.

Install Certbot and its Nginx plugin:

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

Then request and install a certificate for your domain:

sudo certbot --nginx -d example.com -d www.example.com

Certbot verifies that you control the domain, obtains a certificate, and automatically edits your Nginx configuration to serve HTTPS. It will offer to redirect all HTTP traffic to HTTPS, which you should accept. The certificate is valid for 90 days and renews itself automatically, so this is genuinely a set-and-forget step.

The crucial ordering gotcha, and why this section comes last. Certbot's standard verification method works by having Let's Encrypt connect to your domain over the public internet, on port 80, to confirm you really control it. This means your domain must already be resolving to your server and reachable before you run Certbot. If DNS has not propagated yet, or your server is not answering on port 80, certificate issuance will fail. This is exactly why HTTPS is the last step: it depends on every previous step already being complete and live. Get the domain pointing and serving first, confirm it with the commands above, and only then run Certbot.

Once done, verify:

curl -I https://example.com

Seeing a secure response here is the finish line. Your domain, bought from one company, now points at your server, bought from another, and serves your site securely over HTTPS. The gap is closed.

The Whole Thing, in Order

Stepping back, here is the complete mental model, which is worth more than any single set of click-by-click steps because panels change but the logic does not:

You have a server with an IP, and a domain with a name, bought from two unrelated companies. To connect them, you first decide who hosts your DNS: your registrar, the simplest option, or a third party like Cloudflare, the more powerful one. Then, wherever that DNS lives, you set an A record pointing your domain at your VPS's IP. You separately configure your web server to actually answer for that domain, because pointing is not serving. You wait for propagation, verify with dig and curl, and finally enable HTTPS with Certbot once the domain is live and reachable.

Every developer hits this gap once. The reason it feels so confusing the first time is that no single company owns the whole journey, your VPS provider, your registrar, and your DNS host are potentially three different parties, and none of them explains the parts owned by the others. But once you hold the concept, that this is two decisions and a couple of verification steps rather than one mysterious action, it stops being intimidating and becomes something you can do confidently in a few minutes, for any domain and any server, for the rest of your career.

This was a standalone practical guide. If you want the theory underneath it, why a name resolves to an address at all, how the lookup actually travels the internet, and why propagation works the way it does, it is covered in Post 5 of my Networking Foundations series, on DNS. And if this saved you the confusion it saves most people, share it with someone about to deploy their first server. Subscribe to my newsletter for more practical, foundations-first guides like this one.

DNS: The Internet's Phone Book, and Its Biggest Weakness

VickkyKruz NetSec — Sat, 11 Jul 2026 13:45:53 +0000

This is Post 5 of my Networking Foundations series, originally published on my blog. Start from Post 1 there if you want the full series in order.

At the end of the last post, you understood how a device is found on a network: by its IP address, the logical location that routing depends on. But then I pointed out something you have probably never stopped to notice. In your entire life online, you have never once typed an IP address to reach a website. You do not open your browser and type 142.250.72.14. You type google.com.

So something, somewhere, is quietly translating the human name you type into the machine address the network needs. That something is DNS, the Domain Name System, and it is one of the largest, oldest, and most essential systems on the entire internet. Every website you visit, every email you send, every app that connects to a server, begins with a DNS lookup. It happens so fast and so invisibly that most people never know it is there.

This post pulls it into the light. What DNS is and why it exists, the surprisingly involved journey that happens in the fraction of a second between typing a name and the page appearing, the different kinds of records DNS holds, and then the part this series always comes back to: how a system built for a trusting world became one of the most abused surfaces on the internet, and what defends it.

What DNS Actually Is

Let us start with the problem DNS solves, because it is a genuinely human one.

Computers locate each other using IP addresses, numbers like 142.250.72.14, or the far longer strings of an IPv6 address. Machines are perfectly happy with these. Humans are not. Nobody wants to memorise a string of digits for every website they visit, and even if you did, those numbers change. A company can move its website to a new server with a new IP address, and if you had memorised the old number, you would be stuck.

DNS is the system that lets humans use names while machines use numbers. The classic description, and it is a good one, is that DNS is the phone book of the internet. In an old telephone directory, you looked up a person's name to find their number, because you remember names, not numbers. DNS does exactly this. You provide a name, google.com, and DNS returns the current number, the IP address, that the network actually needs to route your request.

This layer of translation is quietly one of the most important ideas on the internet, because it decouples the name from the location. The name google.com can stay the same forever, building trust and recognition, while the actual servers behind it can move, multiply, and change addresses freely. DNS is the flexible link between the stable human-facing name and the shifting machine-facing address. Without it, the web as we know it, built on memorable names and links, could not exist.

The Resolution Journey: What Actually Happens

Here is where it gets genuinely interesting. When you type a name and hit enter, the translation is not a single lookup in one big table somewhere. It is a small relay race across a globally distributed hierarchy of servers, each one knowing just enough to point you to the next. This process is called DNS resolution, and understanding its steps is the heart of understanding DNS.

There are four kinds of players in this race. Let us meet them, then watch them run.

The stub resolver is the simple piece of software built into your operating system. It does not do the hard work itself. It just asks a question and waits for an answer. When your browser needs an address, it hands the request to the stub resolver.

The recursive resolver, often called just the resolver or the recursor, is the workhorse. It is usually run by your internet provider, or a public service like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. Its job is to take your question and do whatever it takes to find the answer, then hand it back. It is the middleman that manages the entire search on your behalf.

The root nameservers sit at the very top of the hierarchy. There are 13 of them, known to every recursive resolver on earth. They do not know the address of google.com, but they know where to send you to get closer: to the right top-level domain servers.

The TLD nameservers are responsible for a specific top-level domain, the last part of a name, like .com, .org, or .uk. The .com TLD servers do not know google.com's address either, but they know which servers do: the authoritative nameservers for that specific domain.

The authoritative nameservers are the final source of truth. They hold the actual DNS records for a domain. When the query reaches them, they give the definitive answer.

Now watch the race for www.example.com, assuming nothing is cached yet:

Your browser asks the stub resolver in your OS for the address of www.example.com.
The stub resolver forwards the question to the recursive resolver (say, your ISP's, or 1.1.1.1).
The recursive resolver asks a root nameserver: "where do I find .com addresses?" The root server replies with a referral: "go ask the .com TLD servers, here they are."
The recursive resolver asks a .com TLD nameserver: "where do I find example.com?" The TLD server replies with another referral: "go ask example.com's authoritative servers, here they are."
The recursive resolver asks the authoritative nameserver for example.com: "what is the address of www.example.com?" This server holds the real record and replies with the actual IP address.
The recursive resolver hands that IP address back to your stub resolver, which hands it to your browser.
Your browser, finally holding the IP address, opens a connection to that server and requests the page.

Every one of those steps happened in the time it took the page to start loading, often well under a tenth of a second. A distributed, hierarchical, worldwide system of servers coordinated to answer one question, and you never saw a thing.

Notice the elegant design. No single server holds the whole internet's address book. The knowledge is delegated down a hierarchy: the root knows the TLDs, the TLDs know the domains, the domains know their own records. This is what makes DNS able to scale to billions of names without any one machine being a bottleneck or a single point of total failure.

Caching: Why It Is Not Slow

If DNS did that full seven-step journey every single time, it would be slower and would hammer the root and TLD servers with unimaginable traffic. It does not, because of caching.

At nearly every layer, the answer to a DNS query gets temporarily stored, so it can be reused without repeating the journey. Your browser caches. Your operating system caches. Above all, the recursive resolver caches. When the recursive resolver has recently looked up example.com for someone else, it simply returns the stored answer from its cache, skipping the root, TLD, and authoritative servers entirely. Given how many people share a resolver, most common lookups are answered instantly from cache.

But cached answers cannot live forever, or they would go stale when a domain genuinely changes its address. This is controlled by a value you met back in Post 2: the TTL, or Time to Live. Every DNS record carries a TTL, a number of seconds that says how long this answer may be cached before it must be looked up fresh. A short TTL means changes propagate quickly but caching is less effective. A long TTL means excellent caching but slower propagation when something changes. Every DNS administrator balances these two, and it is why, when you change a website's address, you are often told to wait for the change to propagate. You are waiting for old cached records around the world to hit their TTL and expire.

Keep the security implication of caching in the back of your mind as we move on, because that shared, trusted cache is about to become the target of one of the most important attacks in DNS.

The Records DNS Holds

DNS does not only translate names to IPv4 addresses. A domain's authoritative servers hold several types of records, each serving a different purpose. You do not need to memorise them, but knowing the main ones makes DNS concrete rather than abstract.

The A record is the most fundamental. It maps a name to an IPv4 address. This is the classic phone-book entry: example.com points to 93.184.216.34.

The AAAA record (pronounced "quad-A") does the same job for an IPv6 address. As IPv6 adoption grows, most major domains publish both an A and a AAAA record.

The CNAME record, or Canonical Name, is an alias. It points one name at another name rather than at an address. For example, www.example.com might be a CNAME pointing to example.com, so both resolve to the same place and you only have to maintain the address in one spot.

The MX record, or Mail Exchange, tells the internet where to deliver email for a domain. When you email someone at example.com, the sending mail server does a DNS lookup for example.com's MX record to find the mail server that should receive it.

The NS record, or Nameserver, states which authoritative nameservers are responsible for the domain. It is part of the delegation chain we walked through earlier.

The TXT record holds arbitrary text. It has become the internet's general-purpose noticeboard, used for verifying domain ownership and, importantly, for email security records like SPF, DKIM, and DMARC that help prove an email genuinely came from the domain it claims to.

That last point is worth pausing on. Several of the most important defences against email spoofing and phishing live entirely in DNS TXT records. DNS is not only how you find things, it is increasingly how the internet proves that things are who they say they are, which makes its own trustworthiness all the more critical.

The Security Truth: A System Built to Trust

Here is the thread this whole series keeps pulling, and DNS may be its clearest example yet.

DNS was designed in the early 1980s, for the same small, trusting, academic internet that shaped every other early protocol we have discussed. Its single purpose was to make name resolution work reliably and at scale, and at that it succeeded magnificently. But like the rest of that early internet, it was not built to be secure. The original protocol has no built-in way to verify that a DNS answer is genuine. When a resolver receives a response saying "google.com is at this address," standard DNS has no mechanism to check whether that answer really came from the legitimate authoritative server, or from an attacker who slipped a forged reply in first.

That single missing feature, the inability to verify authenticity, is the root of nearly every DNS attack. Let us look at the main ones.

DNS Spoofing and Cache Poisoning

This is the signature DNS attack, and the caching we just discussed is exactly what makes it so dangerous. In DNS cache poisoning, an attacker tricks a recursive resolver into storing a false record, so that the resolver returns a fraudulent IP address to everyone who asks. Users trying to reach a legitimate site are silently redirected to an attacker-controlled destination, often a convincing fake built to steal credentials, while their browser still shows the correct address in the bar and nothing appears wrong.

The classic technique exploits the trust gap directly: the attacker floods the resolver with forged responses, each guessing at the identifying number that ties a DNS answer to its question, hoping to land a forged reply before the real one arrives. The reason this is so serious is scale. A single poisoned resolver can misdirect thousands or millions of users at once, without touching the target domain's own servers at all. The legitimate site is untouched; the poison is in the directory that points to it.

DNS Hijacking

DNS hijacking is a broader term for any attack that redirects users by corrupting the resolution process itself, rather than poisoning a cache. This can happen several ways. An attacker might compromise the domain's account at its registrar and change its records at the source. They might take over a home or office router and change which resolver it uses, pointing every device on that network at a malicious server. Or malware on a device might alter its local settings so that specific domains resolve to attacker-controlled addresses. In every case, the result is the same: you type a legitimate name, and you are sent somewhere hostile.

DNS as a Smuggling Tunnel

There is a subtler abuse worth knowing about. Because DNS traffic is so essential and so trusted, it is very often allowed straight through firewalls that would block other traffic. Attackers exploit this by using DNS itself as a covert channel, a technique called DNS tunnelling. Data, such as stolen information or commands to malware already inside a network, is smuggled hidden inside DNS queries and responses, slipping past defences that never thought to inspect the humble name lookup. It is a striking example of how a trusted, overlooked protocol becomes an attacker's favourite hiding place.

A Real Incident: The MyEtherWallet Redirect

To make this concrete, consider what happened to users of MyEtherWallet, a popular cryptocurrency wallet service, in 2018. Attackers manipulated internet routing to hijack the traffic headed for the service's DNS infrastructure, so that people typing the correct, legitimate web address were quietly redirected to a malicious copy of the site. The fake site looked right. Users logged in as normal. And in doing so, they handed their credentials straight to the attackers, who drained cryptocurrency from the real accounts. No victim did anything obviously wrong. They typed the correct address. The directory that was supposed to send them to the right place sent them into a trap. That is the essence of why DNS security matters: when the phone book itself is lying, doing everything else right does not save you.

The Defences: Adding Trust to a Trusting System

If the root problem is that DNS cannot verify authenticity, then the defences are all, in one way or another, about adding that missing verification and privacy back on top. There are two main families, and they solve two different problems.

DNSSEC: Proving the Answer Is Genuine

DNSSEC (DNS Security Extensions) addresses the authenticity problem directly. It uses public-key cryptography to digitally sign DNS records, so that a resolver can verify that an answer genuinely came from the legitimate authoritative source and was not forged or tampered with in transit. If a poisoned or spoofed record arrives, its signature will not validate, and a DNSSEC-aware resolver will reject it. This is the primary cryptographic defence against cache poisoning and spoofing.

DNSSEC is powerful, but it is worth being honest about its limits, because this is where many explanations oversell it. First, DNSSEC provides authentication and integrity, proof that the answer is genuine and unaltered, but it does not provide encryption. DNSSEC responses are signed, not secret. Second, its real-world protection is limited by inconsistent deployment. Major top-level domains sign their zones, but signing at the level of individual domains remains patchy, and a signature only helps if both the domain publishes one and the resolver checks it. And third, DNSSEC does not defend against every DNS attack. It does nothing against registrar account compromise, router hijacking, or a malicious entry placed directly in a device's local settings, because in those cases the attacker is not forging a signed record, they are changing the process elsewhere.

DoH and DoT: Encrypting the Conversation

The second family solves a different problem: privacy and tampering in transit. Standard DNS queries travel in plain text, which means anyone positioned along the path, on the same public Wi-Fi, for instance, can see every domain you look up and potentially tamper with the response. This is the postcard problem from Post 2, applied to DNS.

DNS over HTTPS (DoH) and DNS over TLS (DoT) solve this by encrypting the DNS conversation between your device and the resolver. An on-path eavesdropper can no longer read which sites you are looking up, and can no longer secretly modify the answers, because the channel is encrypted and the resolver's identity can be verified. This makes the kind of on-path tampering that public Wi-Fi enables far harder to pull off.

The crucial point, and the honest one, is that these two families are complementary, not interchangeable. DNSSEC proves the answer is genuine but does not hide it. DoH and DoT hide the conversation but do not, by themselves, prove the authoritative answer was genuine. Strong DNS security uses both: encryption to protect the conversation in transit, and signing to prove the answer's authenticity. And because even both together do not cover registrar compromise or router hijacking, real defence also means securing the accounts and devices around DNS, not just the protocol. No single technology closes every path, which is exactly why layered defence is the theme it always comes back to.

Commands to See DNS For Yourself

DNS is one of the most satisfying systems to inspect directly, because every step is visible with the right tool.

The simple lookup, on any system:

nslookup google.com

This asks your configured resolver for the address of google.com and shows you the answer, along with which resolver gave it. Simple and available everywhere.

The detailed lookup, on macOS and Linux:

dig google.com

dig is the tool of choice for anyone serious about DNS. It shows the answer, the record type, and, importantly, the TTL counting down, the caching lifetime we discussed. Run it twice in quick succession and watch the TTL drop, that is the cache at work.

Watch the entire resolution journey happen:

dig +trace google.com

This is the one to try. The +trace option makes dig perform the full walk we described, starting at the root servers, following the referral to the TLD servers, then to the authoritative servers, printing each step. You are watching the relay race in real time, seeing the root hand off to .com, and .com hand off to google.com's own nameservers. Few commands make an abstract concept this tangible.

Look up specific record types:

dig example.com MX      (find the mail servers)
dig example.com TXT     (see the text records, including email security)
dig example.com NS      (see the authoritative nameservers)

Try the MX and TXT lookups on a domain you know. Seeing a real domain's mail configuration and its SPF or DMARC records makes the record types stop being a list and start being real infrastructure you can read.

What You Now Understand

You began with a small mystery, that you navigate the entire internet by name yet the network runs on numbers, and you now understand the system that bridges the two. DNS is the phone book of the internet, the translation layer that lets stable human names point at shifting machine addresses, decoupling the two so each can do its job.

You can trace the resolution journey yourself: the stub resolver in your OS, the recursive resolver doing the legwork, and the hierarchy of root, TLD, and authoritative servers, each knowing just enough to delegate to the next. You understand why this delegated design lets DNS scale to the whole internet, and how caching, governed by TTL, makes it fast. You know the main record types, and the striking fact that DNS is now used not just to find things but to prove identity, through the email-security records living in TXT.

Most importantly, you understand the security truth at the centre of it. DNS was built for a trusting world and cannot, on its own, verify that an answer is genuine. That single gap is the root of spoofing, cache poisoning, and hijacking, made vivid by real incidents where typing the correct address still led users into a trap. And you know the two complementary families of defence: DNSSEC to prove authenticity, DoH and DoT to protect the conversation, with the honest caveat that neither is complete and layered defence is the only real answer.

This is the same lesson the series keeps arriving at from every direction. The foundational systems of the internet were built for connection, not protection, and security has been carefully added on top ever after.

In the next post, we go deeper into how data is actually carried once a name has been resolved and a connection is being made. We will look closely at the two great transport protocols, TCP and UDP, the reliability-versus-speed tradeoff that every application on the internet has to make, and the three-way handshake that quietly opens nearly every connection you use. That is Post 6.

This is Post 5 of the Networking Foundations series. If DNS finally makes sense as more than a vague acronym, share it with someone who has wondered what actually happens when they type a web address. New here? Start with Post 1, and Post 4 on IP addressing leads directly into this one. Subscribe to our newsletter to get each new post as it publishes.

IP Addressing and Subnetting: Every Device Needs an Address

VickkyKruz NetSec — Mon, 06 Jul 2026 21:50:38 +0000

This is Post 4 of my Networking Foundations series, originally published on my blog. Start from Post 1 there if you want the full series in order.

At the end of the last post, we zoomed out to see the whole OSI model, seven layers, each with one job. Then we promised to come back and zoom all the way into one of them: Layer 3, the network layer, the home of the thing that makes global communication possible in the first place.

That thing is the IP address.

Every device that speaks to another device across a network needs one. Your phone has one right now. So does the server hosting this page, the router in your home, and the laptop you might be reading this on. Without addresses, there is no way to say "send this here rather than there," and the entire idea of a network collapses. The IP address is the network layer's answer to a single question: on a planet with billions of connected devices, how does data find the one specific machine it is meant for?

This post answers that question completely. What an address actually is, why we nearly ran out of them, how your home network quietly shares a single public one, how the newer system fixes the shortage, and finally, subnetting: the skill that trips up more networking learners than any other, taught here in the order that actually makes it stick.

What an IP Address Actually Is

Let us start with the concept, before any notation.

An IP address is a numerical label assigned to every device on a network that uses the Internet Protocol. It does two jobs at once: it identifies the device, and it locates that device within the network. Those are subtly different things, and both matter. Identification says "this is who you are." Location says "this is where you are, so traffic can be routed to you."

Here is the important word: an IP address is a logical address, not a physical one. Remember from Post 3 that every device also has a MAC address, burned into its hardware at the data link layer. That MAC address is like a person's fingerprint. It never changes and it is tied to the physical device forever. An IP address is different. It is like a mailing address. It describes where you currently are on the network, and it can change when you move. Connect your laptop to a different network and it gets a different IP address, just as you would have a different postal address if you moved house. The laptop is the same laptop, its fingerprint is unchanged, but its location, its logical address, is now different.

This is the postal analogy we have been building since Post 2, and it holds all the way up. The MAC address is who you are. The IP address is where you live. Routing, the job of getting data across the world, depends entirely on the second one.

IPv4: The Original System, and Why We Ran Out

The version of IP addressing that built the internet is called IPv4, and it has been in use since 1983.

An IPv4 address is a 32-bit number. In practice you never see it as 32 raw bits, because that would be unreadable. Instead it is split into four groups of 8 bits, each group written as a decimal number from 0 to 255, joined by dots. That is why IP addresses look the way they do:

192.168.1.75

Each of those four numbers is called an octet, because it represents 8 bits. Eight bits can hold 2 to the power of 8, which is 256 values, giving the range 0 to 255 that you see in every octet. The same address in binary looks like this:

11000000.10101000.00000001.01001011

That is the exact same address, just shown as the bits the machine actually works with. We will need this binary view later for subnetting, so keep in the back of your mind that every dotted-decimal address is really just 32 ones and zeros wearing a friendlier costume.

Now the problem. If an IPv4 address is 32 bits, then the total number of possible addresses is 2 to the power of 32, which is about 4.3 billion. In 1983, when there were a few hundred computers on the entire network, 4.3 billion seemed limitless. But the internet grew into a world of billions of phones, laptops, servers, cameras, thermostats, cars, and sensors, and 4.3 billion stopped being nearly enough. This is called IPv4 address exhaustion, and it played out over the 2010s exactly as engineers had feared decades earlier.

The industry responded in three ways. Two were stopgaps to stretch IPv4 further: private addressing and NAT, which we will cover next. The third was the real long-term fix: a brand-new addressing system with a vastly larger space, called IPv6. Almost every strange or clever thing about modern addressing traces back to this one root cause, the slow exhaustion of a 4.3 billion address ceiling that was set in 1983.

Public vs Private Addressing, and the Trick That Saved IPv4

Here is a question that reveals how the stopgap works. You might have five, ten, or twenty devices connected to your home network right now. Each one has an IP address. Yet your entire home shows up to the outside internet as a single address. How?

The answer is the split between public and private addressing, joined by a translation trick called NAT.

Three ranges of IPv4 addresses are reserved for private use, meaning they are never routed on the public internet. They are defined in a standard called RFC 1918, and they are:

10.0.0.0        to  10.255.255.255
172.16.0.0      to  172.31.255.255
192.168.0.0     to  192.168.255.255

Anyone can use these ranges inside their own network without asking permission, because they are not globally unique. Millions of home networks around the world use 192.168.0.x at the same time, and that causes no conflict, precisely because these addresses never appear on the public internet. This is why, if you check your laptop's address at home, it very likely starts with 192.168 or 10. That is a private address, visible only inside your own network.

So how does your privately-addressed laptop reach a public website? Through Network Address Translation, or NAT. Your router holds one public address, the one your internet provider assigns you, and it sits at the boundary between your private network and the public internet. When your laptop sends a request out, the router rewrites the packet so that it appears to come from the router's single public address. When the reply comes back, the router remembers which internal device asked, and forwards it to the right place. Every device in your home shares that one public address, taking turns through the router's translation table.

NAT was one of the two great stopgaps that kept IPv4 alive far longer than its address count should have allowed. It also has a quiet security side effect worth naming: because your internal devices are not directly addressable from the public internet, they are somewhat shielded from direct inbound connection. NAT was never designed as a security control, and it should never be relied on as one, but the isolation it creates is a real and useful side effect. We will come back to that idea, deliberate isolation, when we reach the security section, because it is the heart of why subnetting matters.

IPv6: The Real Fix

Stopgaps buy time. IPv6 was built to end the shortage permanently.

Where an IPv4 address is 32 bits, an IPv6 address is 128 bits. That change sounds modest, four times the bits, but because each added bit doubles the space, the result is staggering. IPv4 offers about 4.3 billion addresses. IPv6 offers 2 to the power of 128, which is roughly 340 undecillion, a number so large it is effectively beyond exhaustion. To put it in perspective, the smallest standard IPv6 subnet allocation contains more addresses than the square of the entire IPv4 internet. We are not going to run out of IPv6 addresses.

Because 128 bits would be absurd to write in dotted decimal, IPv6 uses a different notation: eight groups of four hexadecimal digits, separated by colons. A full IPv6 address looks like this:

2001:0db8:0000:0000:0000:8a2e:0370:7334

There are shorthand rules to compress the long runs of zeros, so in practice you often see something much shorter, like 2001:db8::8a2e:370:7334. The double colon stands in for a run of zero groups.

Two honest points about IPv6. First, it is not a distant future thing, it is here and running now, and it has been deploying since the mid-2000s. Second, and just as honestly, IPv4 has not gone away. Both systems run side by side across the internet today, and they will for years to come. This is why a working engineer has to be fluent in both, not one or the other. IPv6 is the destination, IPv4 is the enormous installed base we still live with, and the reality on the ground is both at once.

Subnetting: The Part Everyone Dreads, Done in the Right Order

Now for the section that makes people give up on networking. We are going to make it stick by building the idea first and doing the maths second.

Why divide a network at all?

Imagine a single flat network with thousands of devices on it. Every device can talk directly to every other device. This sounds convenient, but it is a problem for two reasons.

The first is noise and performance. Some network traffic is a broadcast, a message sent to every device at once. On a huge flat network, broadcasts reach thousands of machines, and all that unnecessary chatter clogs the network. The second reason is the one this series cares about most: security. On a flat network, anything that gets in can reach everything. There are no internal walls. An attacker or a piece of malware that compromises one machine can move sideways to every other machine, because they are all on the same undivided space.

Subnetting is the solution to both problems. It is the practice of dividing one large network into smaller, self-contained sub-networks, called subnets. Each subnet is its own contained space. Broadcasts stay inside their own subnet instead of flooding everything, which fixes the performance problem. And traffic between subnets has to pass through a router, where it can be filtered and controlled, which fixes the security problem by creating exactly the kind of internal walls a flat network lacks.

That is the whole idea. Everything below is just how we express it precisely.

The network part and the host part

Every IP address is secretly divided into two sections. The first section identifies the network (or subnet) the device is on. The second section identifies the specific device, called the host, within that network.

Think of the postal analogy one more time. A full address like "12 Baker Street, London" has a part that identifies the area (London, the street) and a part that identifies the specific building (number 12). The network part of an IP address is the area. The host part is the specific building. Devices in the same area, on the same subnet, share the same network part and differ only in their host part.

The question is: where is the dividing line between the two parts? That line is set by something called the subnet mask.

The subnet mask and CIDR notation

A subnet mask is a 32-bit value that marks which bits of an address belong to the network part and which belong to the host part. Every bit set to 1 in the mask means "this bit is network." Every bit set to 0 means "this bit is host." The ones always come first, all together, followed by the zeros.

The most common subnet mask is:

255.255.255.0

In binary that is twenty-four 1s followed by eight 0s. It says the first 24 bits of the address are the network, and the last 8 bits are the host.

Writing out full subnet masks is tedious, so modern networking uses a shorthand called CIDR notation. You simply write the address, a slash, and the number of network bits. So instead of saying "192.168.1.0 with a mask of 255.255.255.0," you write:

192.168.1.0/24

The /24 means "the first 24 bits are the network part." This single number, the prefix length, tells you everything about how the address is divided. A larger number after the slash means more bits given to the network and fewer left for hosts, which means a smaller subnet with fewer devices. A smaller number means a bigger subnet. That inverse relationship trips people up at first, so hold onto it: bigger slash number, smaller network.

The maths, worked step by step

Now we do the actual calculation, and because you understand what you are calculating, it will make sense rather than feel like magic.

For any subnet, there are a few things you want to work out: how many devices it can hold, the network address, and the broadcast address. Here are the rules, then a full worked example.

Counting the hosts. If a subnet has some number of host bits, call it h, then the number of usable device addresses is 2 to the power of h, minus 2. The formula is:

usable hosts = 2^(32 - prefix) - 2

Why minus 2? Because two addresses in every subnet are reserved and cannot be given to a device. The very first address, where all host bits are 0, is the network address, which names the subnet itself. The very last address, where all host bits are 1, is the broadcast address, used to send to every device in the subnet at once. Neither can be assigned to a real device, so we subtract them.

A full worked example: 192.168.1.0/24

The prefix is /24, so 24 bits are network and 32 minus 24, which is 8, are host.

Usable hosts = 2^8 - 2 = 256 - 2 = 254
Network address   = 192.168.1.0     (all 8 host bits = 0)
First usable host = 192.168.1.1
Last usable host  = 192.168.1.254
Broadcast address = 192.168.1.255   (all 8 host bits = 1)

So a /24 gives you 254 usable addresses, from .1 to .254, with .0 and .255 reserved. This is the classic home and small office network.

Now let us actually subnet: splitting that /24 into four smaller networks

Suppose you have that one /24 and you want to divide it into four separate subnets, perhaps one each for staff, guests, servers, and IoT devices, so you can wall them off from one another. This is subnetting in action.

To make four subnets, you need to borrow bits from the host part and give them to the network part. Four subnets is 2 to the power of 2, so you borrow 2 bits. Your prefix grows from /24 to /26.

A /26 means 26 network bits and 6 host bits. Let us work out one subnet fully:

Prefix /26  ->  host bits = 32 - 26 = 6
Addresses per subnet = 2^6 = 64
Usable hosts = 64 - 2 = 62

And the four subnets carve up the original range like this:

192.168.1.0/26    hosts .1   to .62     (broadcast .63)
192.168.1.64/26   hosts .65  to .126    (broadcast .127)
192.168.1.128/26  hosts .129 to .190    (broadcast .191)
192.168.1.192/26  hosts .193 to .254    (broadcast .255)

Look at what happened. The one network that held 254 devices is now four separate networks holding 62 devices each. Each is its own broadcast domain, and traffic moving between them must cross a router, where it can be controlled. You did not add any hardware. You simply moved the dividing line two bits to the right, and in doing so you created internal walls where there were none.

The binary underneath

Here is the binary view that shows why the boundaries land where they do. Take the address 192.168.1.75 and the mask for /24. To find the network address, the router performs a bitwise AND: wherever the mask has a 1, it keeps the address bit; wherever the mask has a 0, it forces the bit to 0.

  11000000.10101000.00000001.01001011   (192.168.1.75, the address)
AND
  11111111.11111111.11111111.00000000   (255.255.255.0, the /24 mask)
= 11000000.10101000.00000001.00000000   (192.168.1.0, the network)

The mask's 1s preserve the network part exactly, and its 0s wipe the host part to zero, leaving the network address. This single operation, done in hardware billions of times a second, is how every router on earth decides which subnet an address belongs to. Every subnetting question you will ever face is, underneath, just this: line up the bits, apply the mask, read off the boundaries.

A note on IPv6 subnetting

IPv6 uses the exact same CIDR slash notation, so everything you just learned about prefixes transfers directly. The main practical difference is that IPv6 subnets are, by strong convention, a /64. That leaves 64 bits for hosts, which is 2 to the power of 64 addresses in a single subnet, about 18 quintillion. Because address space is no longer scarce, IPv6 subnetting is less about squeezing every address out of a tight block and more about clean, consistent structure. The maths is identical. The scarcity mindset is gone.

The Security Payoff: Subnetting Is a Security Control

Everything above was leading here, because subnetting is not only an addressing and performance tool. It is one of the most fundamental security controls in all of networking, and it connects directly to the earlier posts in this series.

Recall the firewall post Behind the Wall: What Firewalls Really See, Block, and Miss, where the real danger was not the attacker getting in, but the attacker moving sideways once inside, from a low-value machine to the crown jewels, across a flat internal network. Subnetting is the structural defence against exactly that. By dividing a network into segments, you limit the attack surface and obstruct lateral movement. If an attacker compromises one machine, they cannot automatically reach the rest, because the other subnets sit behind a router boundary where traffic can be filtered and blocked. A malware infection in one subnet does not spread to another. The internal walls contain it.

This practice, dividing a network into isolated segments to control traffic and contain breaches, is called network segmentation, and subnetting is its foundation. It is why you put IoT devices, those cheap cameras and thermostats with weak security, on their own separate subnet, so that if one is compromised, the attacker is trapped in a segment with nothing valuable, unable to reach your servers or workstations.

There is a second security angle worth understanding, from the attacker's side. When a penetration tester or a real attacker gains a foothold in a network, one of the very first things they do is reconnaissance: mapping the network to find out what else is reachable. They use tools like Nmap to scan address ranges and discover live hosts and open services. The subnet structure is one of the first things this reconnaissance reveals, because the subnet mask tells an attacker how many other devices share the segment and where the boundaries are. A tester can only test what they can reach, and an attacker can only attack what they can reach. Good segmentation directly shrinks the internal attack surface by shrinking what any single compromised position can see. This is the network layer's version of the same lesson the whole series keeps returning to: control, and the lack of it, is structural. It lives in how the system is divided.

Commands to See Your Own Addressing

Everything here is visible on your own machine right now.

See your own IP address, subnet mask, and gateway:

ipconfig            (Windows, look for IPv4 Address and Subnet Mask)
ip a                (modern Linux)
ifconfig            (macOS and older Linux)

Look at the address. If it begins with 192.168 or 10, you are looking at a private RFC 1918 address, and NAT is translating for you every time you reach the internet. Note the subnet mask too, very often 255.255.255.0, your /24.

See the difference between your private and public address:

Your machine knows only its private address. To see the single public address your whole network shares, you can search "what is my IP address" in a browser. Compare the two. The private one is what your laptop calls itself. The public one is what the entire internet sees. The gap between them is NAT at work.

See your route to a destination, and the addresses along the way:

traceroute google.com     (tracert on Windows)

As in Post 2, every hop is a real router with its own address. Now you can read those addresses with understanding, spotting private ranges near your end and public ranges further out.

What You Now Understand

You started this post with a simple truth, that every device needs an address, and you now understand what that address actually is: a logical, changeable location marker at Layer 3, distinct from the fixed physical MAC address, exactly the mailing-address-versus-fingerprint split.

You know why the original IPv4 system, with its 4.3 billion address ceiling set in 1983, ran short, and the three responses that followed: private addressing, NAT, and ultimately IPv6 with its effectively limitless 128-bit space. You understand why your home network shares one public address, and you can now read your own private address and know what it means.

Most importantly, you did the thing most people give up on. You subnetted, in the right order. You understand why we divide networks before you memorised how, and then you did the how anyway: the network and host split, the subnet mask, CIDR notation, the host-counting formula, a full worked division of a /24 into four /26 subnets, and the bitwise AND underneath it all. And you saw that IPv6 uses the very same notation, just without the scarcity.

And you connected it back to the thread of the series: subnetting is not just plumbing, it is a security control. It is the structural foundation of network segmentation, the thing that contains breaches and obstructs the lateral movement that the firewall post warned about. Control lives in how a network is divided.

In the next post, we follow the address one step further. You now know how a device is located by its IP address, but you have never once typed an IP address to visit a website. You type a name, like google.com. The system that translates that human name into a machine address is DNS, the internet's phone book, and it is one of the oldest, most essential, and most quietly abused systems on the network. That is Post 5.

networking #security #beginners #tutorial

The Infrastructure Lens: Why Control of AI Lives in the Layers Underneath

VickkyKruz NetSec — Mon, 22 Jun 2026 23:07:39 +0000

If you have followed this series, you already know the core instinct of an infrastructure engineer. We do not start with the application a user sees. We start at the bottom of the stack and work up, because that is where the real constraints live. A website is only as available as the server beneath it. A server is only as reachable as the network beneath that. Control, capability, and failure all originate in the layers underneath, and they cascade upward.

I want to take that same instinct, the one we have been applying to packets and protocols all series, and point it at artificial intelligence. Because when you look at AI through an infrastructure lens rather than a software one, something becomes clear that the louder conversations tend to miss.

AI is not really a software story. It is an infrastructure story. And like any infrastructure story, the interesting question is not what happens at the top, where the applications and the headlines are. It is what happens at the bottom, where the chips, the data centres, and the electricity are. That is the layer I find most revealing, because infrastructure does not lie. You cannot argue with a power grid that has no spare capacity, or with a chip that only a handful of companies on earth can manufacture. Let us look at what AI actually runs on, why those foundational layers concentrate so much control, and what the long history of critical infrastructure tells us tends to happen next.

The Part Nobody Sees: AI Is a Physical Thing

When you send a prompt to an AI system, the interaction feels weightless. You type a question, wait a moment, and an answer appears. It feels like pure software, like something happening in an abstract cloud somewhere.

It is not. Every AI prompt depends on a physical stack: chips, data centres, electricity, cooling, water, land, and grid capacity. That weightless little interaction on your screen is the visible tip of an enormous, power-hungry, physical supply chain. AI is no longer only a software story. It is an infrastructure story, and increasingly, it is an energy story.

The scale is hard to overstate. The United States alone hosts more than 5,400 AI data centres, over ten times the count of any other country. Global data-centre electricity demand rose by 17 percent in 2025, and the electricity consumption of AI-focused data centres specifically surged by around 50 percent in a single year. A single fully-populated AI server rack, with eight high-performance GPUs, can draw 12 to 15 kilowatts of continuous power. Multiply that across hundreds or thousands of racks in a single facility, and one data centre can consume tens or hundreds of megawatts, the output of a small power station.

" width="800" height="568">

To understand why this matters for the question of control, you have to understand that this physical stack has layers, and each layer has a chokepoint. A chokepoint is a place where a small number of actors control something that everyone else absolutely depends on. Chokepoints are where power concentrates. And AI infrastructure is full of them.

The Five Layers of the Machine

Let us walk up the stack, from the ground to the application, because each layer is a potential lever of control.

Layer 1: Energy

At the very bottom sits electricity. Everything above it is downstream of power. And power, it turns out, is now the single hardest constraint in the entire AI buildout.

The single biggest chokepoint in the AI buildout is not silicon, not software, and not capital. It is electricity. In the major data-centre hubs, the waiting times to connect a new facility to the electrical grid have become extraordinary. In Loudoun County, Virginia, the largest data-centre hub on earth, the local utility has warned that some new projects could wait up to seven years for a full power connection. Grid interconnection timelines in places like Northern Virginia and Dublin now stretch to 2028 and beyond.

This has changed the nature of the industry. "Speed to power" has become the single most important factor in whether a data-centre project is even viable. By early 2026, analysts were describing the moment AI infrastructure became fundamentally energy-constrained: the binding limit was no longer demand, and no longer even capital, but control over electrons. Whoever controls power generation and grid access controls the pace at which AI can grow. That is an enormous lever, and it sits largely in the hands of utilities and the governments that regulate them.

Layer 2: The Chips

Above energy sits silicon. This is the layer most people have at least heard about, because of the prominence of companies like NVIDIA. But the chokepoint here is tighter and stranger than most people realise.

The most advanced AI chips in the world are designed by a tiny handful of companies, and they are manufactured by an even tinier handful of fabrication plants, using machines that essentially one company on earth knows how to build. The chips inside AI servers run so hot that ordinary air conditioning cannot cool them. Without specialised liquid cooling delivered through precision-engineered piping, the chips overheat in minutes and destroy themselves. That cooling hardware has its own waitlist, currently running into 2027.

This is a chokepoint stacked on a chokepoint. A few chip designers, depending on a few fabricators, depending on a few makers of fabrication equipment, depending on a few suppliers of cooling and memory. Each link in that chain is a place where control can be exercised, whether by a company hoarding supply or a government restricting exports. This is exactly why chip export controls have become one of the most significant instruments of state power in the last few years. When you can decide who is allowed to buy the machines that make intelligence possible, you hold real leverage.

Layer 3: Compute and Data Centres

Above the chips sits the compute layer: the physical data centres that house the chips, wire them together, cool them, and feed them power. This is where the raw computational capacity available to developers and researchers is actually determined.

Building these facilities has become one of the largest capital undertakings of our time. By early 2026, global commitments to AI and data-centre infrastructure had crossed hundreds of billions of dollars in a single quarter, with gigawatt-scale campuses, facilities measured by the power of a major power plant, becoming normal across the United States, Europe, and Asia. Private capital giants have committed over 100 billion dollars to building AI-ready data centres. This is no longer a software industry funded by venture capital. It is a heavy-industrial buildout on the scale of national infrastructure projects.

Layer 4: The Models

Above the data centres sit the models themselves, the trained systems that most people think of as "the AI." This is the layer that gets the headlines and the public attention. But notice that it sits near the top of the stack, dependent on everything beneath it. A model is only as available as the compute it runs on, which is only as available as the chips and the power underneath that.

Layer 5: The Applications

At the very top sits the application layer, the chatbots, assistants, and tools that ordinary people actually touch. This is the only layer most of the public ever sees, and it is the layer furthest from the physical reality that makes it possible.

The crucial insight is this: control does not live at the top, where the attention is. It lives at the bottom, where the power and the silicon are. Anyone who wants to control AI, whether a corporation or a state, does not need to control the apps. They need to control the layers underneath.

And here is why that is so powerful: the layers are stacked, so control of a lower layer cascades upward. Restrict who can buy advanced chips, and you have indirectly decided who can build data centres, which decides who can train frontier models, which decides who can offer applications. A single lever at the bottom moves everything above it. This is what makes infrastructure such an efficient instrument of power. You do not need to regulate a thousand applications if you control the one resource all of them depend on. Ask yourself: if you wanted to shape the entire AI industry with a single decision, where in the stack would you place your hand?

Why Infrastructure Attracts the State

Here is the pattern that history teaches us, and it is remarkably consistent. When a technology becomes critical enough that a society cannot function without it, governments stop treating it as an ordinary business and start treating it as strategic infrastructure. And once something is strategic infrastructure, the state gets involved, every single time. The only question is how.

This is not new, and it is not unique to AI. Consider the precedents.

The railroads, in their day, were the defining infrastructure of the industrial economy. At their peak they employed around two million American workers and made up roughly a twelfth of the entire economy. When they were considered critical to the war effort, the US government took direct control of them during the First World War, and again briefly during the Second. The principle was simple: infrastructure this essential could not be left entirely to private hands during a crisis.

Steel was nationalised, briefly, by President Truman in 1952 to prevent a strike from crippling production during the Korean War. The logic was identical: when the nation depends on it, the state asserts control.

Nuclear technology is perhaps the clearest case of all. It was developed under direct government control from its very inception, through a wartime government program, and private nuclear capability has only ever been permitted since then under stringent regulatory frameworks. No private actor has ever been allowed to develop nuclear weapons. The state claimed the commanding heights from day one and never let go.

And then there is the most striking parallel of all: the internet itself. The internet emerged from government-funded research before commercial actors built the public network on top of it. And even today, the government operates entirely separate classified networks, physically and logically walled off from the commercial internet, for its own critical functions. The state funded the foundation, let private industry build the public layer, and kept a sovereign capability of its own.

Across every one of these cases, railroads, steel, nuclear, the internet, the same arc appears. A technology becomes essential. The state recognises it as strategic. And control, in some form, follows. The mechanism varies, from outright nationalisation to regulation to direct ownership stakes, but the direction is the same.

There is no reason to expect AI to be the exception. If anything, the case for state involvement is stronger, because AI infrastructure combines several things governments already treat as strategic: advanced computing, energy, and critical supply chains, all in one.

The Pattern Playing Out Right Now

Here is where recent events fit in, and I want to handle them the way an engineer handles any data: as evidence of a pattern, not as a verdict on anyone. The point is not who is doing this or whether it is good or bad. The point is that it matches the structural logic exactly.

Over the course of 2025 and into 2026, the US government shifted from being a grantmaker, handing out subsidies, to being a direct capital provider, taking actual ownership stakes in strategically important companies. Legal analysts described this as the "visible hand" of government becoming a defining feature of the financing landscape.

The examples are concrete and verifiable. The government took a stake of nearly 10 percent in a major chipmaker, converting earlier subsidy commitments into actual equity, with a warrant to acquire more. In the rare-earths sector, the Department of Defense paid 400 million dollars for an effective 15 percent stake in a mining company, becoming its largest shareholder, and paired that with a guarantee to protect it against foreign price manipulation. Across the quantum-computing sector, the government committed more than 2 billion dollars in 2026 across nine companies, taking a minority, non-controlling equity stake in each as a condition of the funding. By that point the state's investment portfolio openly spanned semiconductors, steel, nuclear energy, rare earths, and quantum computing. The pattern moved methodically across exactly the sectors a national-security planner would prioritise.

This is the moment to pause and ask the obvious question: what do all of those sectors have in common? None of them is a consumer product. Every one is foundational infrastructure or strategic input, the layers other industries are built on top of. The state was not buying into the visible economy. It was buying into the floor beneath it.

The open question, the one being debated right now, is whether this approach extends to the largest AI companies themselves. If it does, it would mark the moment the experiment moved from strategic minerals and chipmakers to what one analysis called the crown jewels of the equity market.

I want to be careful here, because this is where verified fact ends and speculation begins, and the honest thing is to mark that line clearly. Whether any specific AI company ends up with government ownership, and on what terms, is genuinely unsettled, and it is not my place or my interest to predict it. The legal mechanism by which a company would voluntarily hand over stock is itself unclear. What the structural lens can say with confidence is narrower and more durable: foundational infrastructure attracts this kind of attention, and AI infrastructure is now foundational. The direction of travel follows from the structure, regardless of who is in office or what they decide.

The Real Tension: Regulator, Customer, Investor, Owner

Here is where the infrastructure lens reveals something the surface debate misses.

When any government takes an ownership stake in a company whose product it also regulates, buys, and depends on for national security, the roles begin to blur in a way that is structurally difficult to manage. This is not a comment on any particular administration. It is a feature of the arrangement itself, and it would be true whoever held office and whichever company was involved. The same entity can end up being the regulator, the customer, the investor, and the owner, all at once. Each of those roles has different and sometimes opposing incentives. A regulator wants to constrain. An owner wants the value to grow. A customer wants low prices. A national-security stakeholder wants control and secrecy. Putting all four in the same hands creates tensions that are hard to resolve cleanly.

Consider how one chief executive described his own company's deal after the government became its largest shareholder. He insisted plainly that it was not a nationalisation, that the company still controlled its own destiny, that it remained shareholder-driven. He may well be right. But notice what the very need to say it reveals: when the state becomes your largest shareholder, the question of who is really in control stops being obvious enough to leave unspoken. The reassurance is itself the evidence that the line has blurred.

This is the structural problem at the heart of the entire question, and it is far more interesting than the simple "companies versus governments" framing. The issue is not who wins. The issue is that as AI becomes critical infrastructure, the neat separation between the state and the industry, the separation that much of the modern economy quietly assumes, starts to dissolve. And once it dissolves, you have to answer hard questions about accountability, competition, and power that the old categories were designed to keep separate.

Why This Matters Even If You Never Touch the Infrastructure

You might reasonably ask why any of this matters to an ordinary person, a developer, or a small business, none of whom will ever own a data centre or a chip fabrication plant.

It matters because infrastructure is destiny. The entity that controls the foundational layers of AI, the compute, the chips, the energy, gets to set the terms for everyone building on top. They decide who gets access to compute and at what price. They decide which uses are permitted. They decide, ultimately, what can and cannot be built. If you are a developer building on top of someone else's AI infrastructure, your freedom to operate is defined by decisions made several layers below you, in places you have no visibility into and no vote over.

I have felt this personally, and I wrote about it once already. In an earlier post, Are AI Companies Monetising Our Desperation?, I described hitting usage limits on an AI tool I was paying for, upgrading, and hitting them again, and asking whether the pricing was quietly exploiting how dependent I had become at exactly the wrong moment. At the time I framed it as a pricing question. The infrastructure lens is the structural answer to that personal frustration. The wall I kept running into was real compute, real electricity, and real cost at the bottom of the stack, but where exactly that wall was placed was a decision made several layers below me, in a room I would never see. The lived experience of being throttled as a user and the structural reality of who controls the foundational layers are the same story, told from opposite ends of the stack.

This is the same lesson that runs through the networking series this post is a brief detour from. Whoever controls the lower layers of any system controls what is possible at the higher layers. In networking, that is about packets and protocols and who can see your traffic. In AI, it is about compute and chips and energy and who can decide what gets computed. The principle is identical. Power concentrates at the bottom of the stack, and it flows upward.

The people watching only the top layer, the apps, the models, the corporate dramas, are watching the shadow. The substance is underneath, in the unglamorous world of power contracts, fabrication capacity, grid connections, and now, government equity stakes. That is where the future is actually being decided.

The Question Worth Sitting With

So what does the infrastructure lens actually tell us, once we strip away the noise at the top of the stack?

It tells us that the most consequential decisions about AI are probably not the ones being announced about models and capabilities. They are the quieter ones being made about the foundational layers: who gets compute and at what price, who can access advanced chips, who controls the power that everything else depends on. Those decisions sit several layers below the applications most people are watching, and yet they set the boundaries for everything built above.

This is the same lesson that runs through the entire networking series this post is a brief detour from. In networking, control concentrates in the lower layers and flows upward, which is why understanding those layers matters so much for security. In AI, the principle is identical, just scaled up from packets and routers to chips and power grids. Whoever holds the bottom of the stack shapes what is possible at the top. That is not a political claim. It is an engineering one, and it has been true of every critical system humans have ever built.

So the questions worth sitting with are the structural ones, the kind an engineer asks about any system. If controlling the bottom of a stack means controlling what runs at the top, where in the AI stack does real leverage actually sit? If the foundational layers, compute, chips, and energy, become concentrated, what does that mean for everyone building on top of them? And if infrastructure shapes what is possible, then which layer should you be watching to understand where AI is really heading: the visible applications, or the physical foundations beneath them?

That is the story worth following. Not the fireworks at the top of the stack, but the quiet, decisive contest at the bottom. Watch the infrastructure. It will tell you where the power is going long before the headlines do.

This was a standalone analysis, a brief detour from our Networking Foundations series, which continues in the next post with IP addressing and subnetting. If this gave you a new way to see AI, as an infrastructure story rather than only a software one, share it with someone still watching only the top of the stack. And subscribe to our newsletter for more analysis that looks underneath the surface.

The OSI Model: Demystified, Not Memorised

VickkyKruz NetSec — Mon, 22 Jun 2026 22:35:19 +0000

If you have ever opened a networking textbook, you have met the OSI model. And there is a good chance you met it like this: a list of seven layers, top to bottom, with a mnemonic to help you remember the order. "Please Do Not Throw Sausage Pizza Away." You memorised it the night before an exam, answered the question, and forgot it within a week.

That is the wrong way to learn the OSI model, and it is the reason so many people who have technically "learned" it still cannot explain what it actually does.

Here is the good news. If you read Post 2 of this series, you already understand the hard part. You have already met packets, headers, encapsulation, IP addresses, and MAC addresses. You watched data get wrapped in nested envelopes, each one added by a different part of the system for a different purpose. The OSI model is simply the formal name for that structure. It is not new information to memorise. It is a label for something you already understand.

So let us not memorise it. Let us recognise it.

The One Diagram That Makes It Click

Before we go layer by layer, hold onto one idea from Post 2: encapsulation.

When you send data, it travels down the layers on your device. Each layer wraps the data in its own header (and sometimes a trailer), then hands it to the layer below. By the time it leaves your device as raw signal, it has been wrapped seven times over.

When it arrives at the destination, it travels up the layers. Each layer reads and removes its own wrapper, then hands what is left to the layer above, until the original data emerges at the top, clean and complete.

Data moves down the stack on the sender's side, across the physical network, and back up the stack on the receiver's side. That single motion, down, across, up, is the OSI model in action. Everything else is detail.

The Seven Layers, As Jobs Not Names

We will go from Layer 1 at the bottom (closest to the physical wire) up to Layer 7 at the top (closest to you, the user). For each layer, here is its job, what lives there in the real world, and the security threats that specifically target it.

Layer 1: The Physical Layer

The job: Move raw bits, the literal 1s and 0s, across a physical medium. This layer is concerned with turning data into electrical signals, pulses of light, or radio waves, and transmitting them from one device to the next.

The physical layer handles all network communication at the bit level. It is responsible for the physical connection between devices, and it defines the hardware elements involved: cables, the electrical or optical or radio characteristics of the signal, and the timing that keeps sender and receiver in sync. When you are troubleshooting a network and someone says "check the cable," they are telling you to check Layer 1.

Data unit: bits.

What lives here: Ethernet cables, fibre optic cables, Wi-Fi radio signals, hubs, repeaters, modems, and network interface cards at the electrical level.

Security at this layer: Physical layer attacks involve hardware tampering and physical access. The classic example is wiretapping: physically tapping into a cable to intercept the signal travelling through it. Other threats include cable cutting (a denial of service through brute physical destruction) and the installation of rogue physical devices. The defences are equally physical: locked server rooms, secured cabling, surveillance, and physical access controls. No amount of clever software protects you if an attacker can walk up and splice your cable.

Layer 2: The Data Link Layer

The job: Take the raw bit-transmission ability of Layer 1 and turn it into reliable communication between two directly connected devices on the same local network. This layer packages bits into frames and uses physical hardware addresses, called MAC addresses, to make sure data reaches the correct device on the local segment.

This is the layer where MAC addresses live, the ones you met in Post 2. The data link layer breaks data into frames for transmission and includes mechanisms for detecting errors that may have occurred at the physical layer.

Data unit: frames.

What lives here: switches, the Ethernet protocol, MAC addresses, and Wi-Fi at the data-framing level.

Security at this layer: This is one of the most actively attacked layers on a local network, and the attacks are worth knowing by name. In MAC spoofing, a device changes its MAC address to impersonate a legitimate device on the network. In ARP spoofing (also called ARP poisoning), an attacker sends forged ARP messages to link their own MAC address with the IP address of a legitimate device, quietly redirecting that device's traffic to the attacker's machine. This is the foundation of most man-in-the-middle attacks on a local network. In MAC flooding, an attacker overwhelms a switch's address table with fake MAC addresses, forcing the switch to fail open and broadcast all traffic to every port, which lets the attacker capture traffic that was never meant for them. Defences include port security on switches, dynamic ARP inspection, and VLAN segmentation.

Layer 3: The Network Layer

The job: Get data from one network to another, anywhere in the world. While Layer 2 handles communication on the local segment, Layer 3 handles the global journey: logical addressing with IP addresses, and routing the data across multiple interconnected networks to reach a destination that may be thousands of miles away.

This is the layer of IP addresses and routers, and it is where the packet (the term you met in Post 2) officially lives. Within Layer 3, the protocol data unit is the packet. The IPv4 header at this layer contains the source address, the destination address, the protocol, and the Time to Live (TTL) value, exactly the TTL countdown we used to explain traceroute in the last post.

Data unit: packets.

What lives here: routers, the IP protocol (both IPv4 and IPv6), and ICMP (the protocol behind ping and traceroute).

Security at this layer: The signature attack here is IP spoofing, where an attacker forges the source IP address in a packet to masquerade as a trusted device or to hide their identity. Layer 3 is also where many Distributed Denial of Service (DDoS) attacks operate, overwhelming a target with a flood of traffic, and where route manipulation attacks alter routing tables to redirect or intercept traffic. Defences at this layer include firewalls, router access control lists (ACLs), and packet filtering, the very mechanisms we explored in the firewall post earlier in this blog.

Layer 4: The Transport Layer

The job: Manage the end-to-end delivery of data between two applications, including reliability, ordering, and the splitting of data into manageable segments. This is the layer that decides how data gets delivered: reliably and in order, or quickly and without guarantees.

The transport layer sits at the boundary between the lower hardware-oriented layers and the upper software-oriented layers. It is the home of the two protocols you will meet in depth in Post 6: TCP, which provides reliable, ordered, acknowledged delivery (the sequence numbers and retransmissions from Post 2 live here), and UDP, which provides fast, lightweight delivery without those guarantees. This layer uses port numbers to make sure data reaches the correct application on the destination device, not just the correct device.

Data unit: segments (for TCP) or datagrams (for UDP).

What lives here: TCP, UDP, and port numbers.

Security at this layer: The classic transport-layer attack is the TCP SYN flood. Recall that TCP opens a connection with a three-way handshake: SYN, then SYN-ACK, then ACK. In a SYN flood, the attacker sends a massive volume of SYN packets, often with spoofed source IPs, but never completes the handshake. The server sets aside memory for each half-open connection and waits. With enough of these, the server's resources are exhausted and it begins refusing legitimate connections. This is a common way to initiate a denial of service. Port scanning also operates here, as attackers probe which ports are open to map out the attack surface. Defences include SYN cookies, rate limiting, and the encryption protocols TLS and IPsec.

Layer 5: The Session Layer

The job: Establish, manage, and cleanly terminate the ongoing conversations (sessions) between two applications. If two systems need to hold a sustained dialogue rather than exchange a single message, this layer sets up that session, keeps it organised, and tears it down when finished.

Think of the session layer as the part of the system that remembers a conversation is ongoing: that you are logged in, that this exchange is part of a larger whole, and where to resume if something is interrupted.

Data unit: data.

What lives here: session management protocols, and aspects of technologies like NetBIOS and RPC. Authentication and reconnection logic often operate at this conceptual level.

Security at this layer: The signature threat is session hijacking, where an attacker takes over a legitimate, authenticated session, often by stealing or forging the session token that proves who you are. Session fixation, where an attacker forces a victim to use a known session ID, is a related attack. Because sessions are how systems remember that you are authenticated, stealing a session can be as good as stealing a password. Defences include strong, random session tokens, binding sessions to other attributes, and timely session expiry.

Layer 6: The Presentation Layer

The job: Translate, format, encrypt, and compress data so that the application layer above can understand it regardless of how it was sent. This layer is the translator: it makes sure that data sent by one system is presented in a form the receiving system can actually use.

This is the layer most associated with encryption and decryption, character encoding (such as how text is represented), and data compression. When data is encrypted for transit, that transformation conceptually happens here.

Data unit: data.

What lives here: encryption standards, TLS/SSL (which spans this area conceptually), character encodings like ASCII and Unicode, and compression and file formats like JPEG and PNG.

Security at this layer: Because this is the encryption layer, it is the target of attacks aimed at undermining encryption. SSL/TLS stripping is the key example: an attacker downgrades a secure HTTPS connection to plain, readable HTTP, turning the sealed envelope from Post 2 back into a postcard. Attacks that exploit weak or outdated encryption algorithms also belong here. The defence is to enforce strong, current encryption and to use mechanisms (like HSTS) that refuse to allow a secure connection to be downgraded.

Layer 7: The Application Layer

The job: Provide the interface between the network and the actual applications and users. This is the layer closest to you. It is not the application itself (your browser, your email client), but the protocols those applications use to interact with the network.

The application layer is the human-to-computer interaction layer, where applications access network services. When you load a web page, send an email, or resolve a domain name, you are using application-layer protocols.

Data unit: data (often called messages).

What lives here: HTTP and HTTPS (web), SMTP (email), FTP (file transfer), DNS (domain name resolution), and many more. These are the protocols we will spend Post 8 exploring in detail.

Security at this layer: This is the layer closest to users, and therefore the layer where human-facing and software-facing attacks concentrate. Phishing manipulates user behaviour at this layer. SQL injection inserts malicious database commands through application input fields. Cross-site scripting (XSS) injects malicious scripts into web applications to run in victims' browsers. Application-layer DDoS attacks overwhelm a service with seemingly legitimate requests. Because Layer 7 is where the most complex, human-facing logic lives, it has the largest and most varied attack surface of any layer. Defences include web application firewalls, input validation, secure coding practices, and user awareness training.

The Honest Part: OSI vs TCP/IP

Here is something many tutorials gloss over, and it matters: the seven-layer OSI model is not actually what the internet runs on.

The OSI model is primarily a teaching and reference model. It is theoretical in nature and is best used as a general guide, because few real network products keep their functions neatly separated into seven distinct layers. The model that the internet actually runs on is older and simpler: the TCP/IP model, developed by the US Department of Defense before OSI existed.

The key difference is that TCP/IP collapses several OSI layers together into a simpler, more practical structure. Here is how the two line up:

OSI Model (7 layers)	TCP/IP Model (4 layers)
7. Application	Application
6. Presentation	Application
5. Session	Application
4. Transport	Transport
3. Network	Internet
2. Data Link	Network Access (Link)
1. Physical	Network Access (Link)

In TCP/IP, the top three OSI layers (application, presentation, session) are combined into a single Application layer. The transport layer stays as its own layer. The OSI network layer becomes the Internet layer. And the bottom two OSI layers (data link and physical) are combined into a single Network Access layer.

So why learn OSI at all, if TCP/IP is what actually runs? Because OSI is the better teaching tool. Its seven layers separate concerns more finely, which makes it far easier to reason about where a problem or an attack sits. When a security professional says an attack is "a Layer 7 attack" or "a Layer 3 attack," they are using OSI numbering, because it is more precise. You think in OSI; the machines run TCP/IP. Both statements are true at once, and a real practitioner is comfortable moving between them.

Even TCP/IP, the most widely used network protocol suite, does not map perfectly onto OSI. The mapping above is a useful approximation, not a law of physics. Hold it loosely.

The Security Payoff: Knowing Which Layer You Are Defending

Here is why all of this matters beyond passing an exam.

When you understand the layers, you understand where in the stack any given attack operates, and therefore what kind of defence can possibly stop it. This is one of the most useful mental tools in all of security.

A SYN flood is a Layer 4 attack. No amount of physical security (Layer 1) or web application firewall rules (Layer 7) will stop it, because it operates at the transport layer. You need a transport-layer defence: SYN cookies, rate limiting.

ARP poisoning is a Layer 2 attack. It happens on your local network segment, below the level a traditional IP firewall even looks. You need a Layer 2 defence: dynamic ARP inspection, port security.

SQL injection is a Layer 7 attack. Your firewall will happily pass it, because to the network it looks like perfectly legitimate web traffic. Only a Layer 7 defence, input validation, a web application firewall, secure code, can catch it.

This is also why the firewall post earlier in this blog matters here. Different firewalls operate at different layers. A traditional packet-filtering firewall works at Layers 3 and 4. A next-generation firewall with deep packet inspection reaches up to Layer 7. Knowing the layers tells you exactly what a given firewall can and cannot see, which is the difference between thinking you are protected and actually being protected.

When you can place an attack on a layer, you stop guessing and start reasoning. That single skill is worth more than any mnemonic.

Commands to See the Layers in Action

You can observe different layers directly from your own machine.

Layer 2 (Data Link), view your MAC address and local ARP table:

arp -a

This shows the ARP table: the mapping of IP addresses to MAC addresses your device currently knows about on the local network. This is exactly the table that ARP spoofing attacks poison. Look at it and you are looking at Layer 2 and Layer 3 meeting.

Layer 3 (Network), see your IP configuration and test routing:

ping google.com
traceroute google.com

(tracert on Windows.) Ping uses ICMP, a Layer 3 protocol. Traceroute, as we covered in Post 2, exploits the Layer 3 TTL field to map your route hop by hop.

Layer 4 (Transport), see active connections and their ports:

netstat -an

or on modern Linux:

ss -tuln

This shows active network connections and the ports they are using. Every line is a Layer 4 conversation, with its TCP or UDP port numbers visible. You are seeing the transport layer at work.

Layer 7 (Application), watch a protocol resolve a name:

nslookup google.com

This uses DNS, a Layer 7 protocol, to translate a domain name into an IP address, the exact subject of the next post in this series.

What You Now Understand

You did not memorise seven words in order. You understand seven jobs.

You know that the OSI model exists because the early networking world was a chaos of incompatible systems, and the industry needed a shared reference so that any vendor's equipment could work with any other's. You know that the model divides communication into seven layers, each with one job, each serving the layer above and below, and that this separation of concerns is the entire point.

You can now place the concepts from Post 2 onto specific layers: bits at Layer 1, frames and MAC addresses at Layer 2, packets and IP addresses and TTL at Layer 3, segments and ports and TCP's reliability at Layer 4. And you know the security threat that targets each layer, from physical wiretapping at the bottom to phishing and SQL injection at the top.

You know the honest truth that the internet actually runs on the simpler four-layer TCP/IP model, that OSI is the superior teaching and reasoning tool, and that a real practitioner moves comfortably between the two.

Most importantly, you have gained the single most useful security habit the OSI model offers: the ability to ask "which layer does this attack operate on?" and, from the answer, to know what kind of defence can actually stop it.

In the next post, we zoom all the way into Layer 3 and the thing that makes global routing possible in the first place: the IP address. We will cover IPv4 and IPv6, public versus private addressing, and subnetting, explained without the maths-first approach that makes most people give up. Once you understand addressing, the network layer stops being abstract and starts being something you can read at a glance.

This is Post 3 of the Networking Foundations series. If this finally made the OSI model make sense, share it with someone still trying to memorise "Please Do Not Throw Sausage Pizza Away." New to the series? Start with Post 1 (what a network actually is) and Post 2 (how data travels) so the concepts build in order. And subscribe to our newsletter to get each new post as it publishes.

How Data Actually Travels: Packets, Protocols, and the Postal Service Analogy

VickkyKruz NetSec — Wed, 17 Jun 2026 10:53:51 +0000

You hit send on an email. A second later, it is in your colleague's inbox three hundred miles away.

From your perspective, it felt instant and whole. One message, sent, received. But that is not what actually happened. What you experienced as a single, seamless transfer was, underneath, something closer to controlled chaos. Your email was shredded into dozens or hundreds of small chunks. Each chunk was stamped with an address and sent out individually, sometimes by completely different routes, then reassembled at the other end into something that, by the time it reached the screen, looked exactly like what you wrote.

This is not a workaround or an edge case. This is how all data moves across every network on the planet, all the time, for everything. Understanding this single mechanism, the packet, is the key that unlocks almost everything else in networking.

And the best way to understand it is not through diagrams of computers. It is through something you already understand intuitively: the postal service.

The Postal Service That Never Sleeps

Imagine you need to send a 500-page manuscript to a publisher across the country. You cannot fit 500 pages into one envelope. It would be too thick, too heavy, and if it got lost or damaged in transit, you would lose the entire manuscript at once.

So instead, you do something clever. You split the manuscript into 500 individual pages. You put each page in its own envelope. On each envelope, you write the destination address, your return address, and, most importantly, a page number, so the publisher knows the order to put them back in. Then you post all 500 envelopes.

Here is where it gets interesting. Those 500 envelopes do not all travel together. Some might go via one sorting office, others via a different route, depending on which trucks have space, which roads are open, and which sorting centre is less busy that day. They might arrive at the publisher's office across several hours, in a jumbled, non-sequential order. Page 347 might arrive before page 12.

But because every envelope is numbered, the publisher can simply sort them back into order on arrival. The manuscript is reassembled, complete and correct, even though it never travelled as a single unit, and even though every individual piece took its own independent path.

This is precisely how data travels across a network. The "manuscript" is your email, your webpage, or your video call. The "envelopes" are called packets. And the postal service's sorting offices are the routers that make up the internet.

What Is Actually in a Packet

Let us open one of those envelopes and look closely at what is inside, because the structure matters enormously.

A packet has three parts, and the postal analogy maps onto them almost perfectly.

The first part is the header. This is the envelope's outside, the address information. It contains the source address (where this packet came from), the destination address (where it is going), and additional metadata that helps the network handle it correctly along the way.

The second part is the payload. This is the letter inside the envelope, the actual content. This is the piece of your email, webpage, or video that this particular packet is responsible for carrying.

The third part is the trailer. Not every packet has one, but many do. The trailer is like a seal on the envelope, a small piece of data used to check that the contents were not corrupted or damaged in transit. If the trailer's checksum does not match what is expected, the receiving device knows something went wrong and can discard the packet or request it again.

A network packet, sometimes called a frame at certain layers, is the basic unit of data transfer across networks, containing both the header and the actual data being transmitted. The header is placed at the front of the packet, and it enables the receiving router or switch to know where the packet comes from, what to do with it, and where to send it next.

That is it. That is a packet. A small amount of data, wrapped in addressing information, with an optional integrity check. Everything else in networking, every protocol, every device, every security mechanism, exists to manage how these small wrapped units move, multiply, and get handled correctly at scale.

Encapsulation: The Russian Doll of Data

Here is where the postal analogy needs an upgrade, because in real networking, your data does not get put into just one envelope. It gets put into an envelope, which then gets put into another envelope, which then gets put into yet another envelope.

This is called encapsulation, and it happens because different "postal services" are involved at different stages of the journey. Each one needs its own addressing information for its own part of the job. Think of it like sending an international parcel. You put your letter in an envelope addressed to the recipient. That is one layer. Your local post office then puts that envelope into a larger shipping pouch, addressed to the destination country's sorting hub. That is a second layer. The airline then loads that pouch into a cargo container, labelled for a specific flight. That is a third layer.

Each layer exists to serve a different part of the journey. The innermost envelope still has the final destination address, but the outer layers exist to get it through the next leg of the trip.

In real networking, this happens through several layers, and each one has a name worth knowing:

The transport layer (commonly TCP or UDP) takes your data and breaks it into segments. It attaches a header containing port numbers, which is information about which specific application on the destination device should receive this data.

The network layer then takes each segment and wraps it in another header. This one contains the source and destination IP addresses. Once this header is attached, the resulting unit is officially called a packet.

The data link layer wraps that packet in yet another header, and often a trailer too. This one contains MAC addresses, which identify specific physical devices on the local network. At this point, the unit is called a frame.

Each device that handles your data along the way reads only the layer relevant to its job. A switch reads the MAC address layer to forward traffic on the local network. A router reads the IP address layer to forward traffic between networks. Neither of them needs to read the contents of your actual message, and normally, neither of them can. They are reading the outer envelopes, not opening the letter inside. When the data finally arrives at its destination, this entire process runs in reverse. Each layer's header is removed in turn, like peeling back the envelopes one by one, until what is left is the original payload: your email, your webpage, your file.

We will cover the formal model behind these layers, the OSI model, in the next post in this series. For now, the important thing to understand is this. Every piece of data you have ever sent across a network was wrapped in multiple nested envelopes, each one added and removed by a different part of the system, each one serving a different purpose.

How Packets Find Their Way

Let us go back to our 500-page manuscript. How does each individual envelope actually know which route to take? The sender does not choose the route. Neither does the recipient. The routing happens at every sorting office along the way, based on the address on the envelope and the sorting office's own knowledge of the best next step.

This is exactly how routers work. A router does not know the entire path a packet will take from source to destination. It only knows one thing: given this destination address, which of my connections should I send this packet down next? It makes that decision, forwards the packet, and its job for that packet is done. The next router makes its own decision, and so on, until the packet arrives.

This is why two packets that are part of the same email, sent moments apart, can genuinely travel through different cities, different countries, and different physical cables, and still both arrive at the same destination within milliseconds of each other.

There is one more crucial piece of information in every packet's header that is worth understanding: the Time to Live, or TTL.

Imagine if an envelope got stuck in an endless loop between two sorting offices. Office A sends it to Office B because B handles that postcode, but B's records say A handles it, so B sends it back to A, forever. Without something to stop this, that envelope would circulate indefinitely, wasting resources forever.

The TTL field solves this. Every packet starts with a TTL value, commonly somewhere around 64 or 128. Every time a router forwards the packet, it decreases the TTL by one. If the TTL ever reaches zero, the packet is discarded, even if it has not reached its destination yet. This is a critical safeguard: routers decrement the TTL field in IP headers specifically to prevent routing loops from consuming network resources indefinitely.

This small detail, a number ticking down inside every packet's header, is also the basis for one of the most useful diagnostic tools in networking, which we will come back to at the end of this post.

When Packets Get Lost

Now for the part of the postal analogy that everyone has experienced personally. Sometimes, mail gets lost.

Maybe a sorting office mishandles an envelope. Maybe it falls behind a conveyor belt and gets found three weeks later. Maybe it is simply destroyed in transit. Whatever the cause, sometimes envelopes just do not arrive.

The same is true for packets. Across long journeys through congested networks, packets get dropped. They are discarded by overloaded routers, corrupted beyond recovery, or lost to faulty hardware along the way. This is called packet loss, and it is a completely normal, expected part of how networks operate. The question is not whether it happens. The question is what happens next.

This is where one of the cleverest ideas in all of networking comes in: sequence numbers and acknowledgements.

Let us return to our manuscript analogy. Imagine if, alongside numbering every page, the publisher's office sent a postcard back to you for every page they received, saying, "Got page 47, thanks." If you, the sender, kept track of which postcards you had received back, you would know exactly which pages had arrived safely, and which ones had not. If three days passed and you had not received a "got it" postcard for page 112, you would simply put page 112 in a new envelope and send it again.

This is essentially what TCP, the Transmission Control Protocol, does. TCP assigns sequence numbers to outgoing segments, and the receiving device sends back acknowledgements (ACKs) confirming what it has received. TCP uses these acknowledgement mechanisms to inform the sender about the receipt of packets and to request retransmissions of missing ones. Crucially, if the sender does not receive an acknowledgement within an expected timeframe, it assumes the packet was lost and sends it again. Under TCP, a packet is retransmitted by the sender if no acknowledgement has been received during a timeout period, which is typically set as roughly twice the round-trip time between sender and receiver.

This is also how out-of-order delivery gets resolved. Just like page 347 of the manuscript might physically arrive before page 12, packets belonging to the same conversation can arrive at the destination in a different order than they were sent. This happens because they took different routes, encountered different delays, or some were retransmitted after being lost. TCP is designed to handle out-of-order packets. It uses sequence numbers to track the order of incoming packets, buffers them temporarily, and reassembles them in the correct order before handing the completed, ordered data up to the application.

All of this happens completely invisibly to you. You never see "page 347 arrived before page 12, please wait while we reorder." You just see your email arrive, complete and correctly formed, a fraction of a second after you hit send, with an enormous amount of postal-service-style choreography having happened underneath, entirely without your awareness.

The Security Truth: Postcards, Not Sealed Letters

Here is where this post connects to the thread that runs through this entire series.

Go back to our envelope analogy one more time, but this time, imagine that most of the envelopes traveling through the postal system are not actually sealed envelopes at all. They are postcards.

Anyone who works at any sorting office that handles your postcard, anyone along the entire route, can simply turn it over and read what is written on the back. The address information has to be visible for routing to work. But on a postcard, the message is visible too.

This is the uncomfortable reality of a huge amount of network traffic, even today. Many protocols send their payload, the actual content, completely unencrypted, in plain text, readable by anyone who can see the packet as it passes by.

This is what makes packet sniffing possible. A packet sniffer is software that captures and inspects network traffic as it passes across a network. Tools like Wireshark and tcpdump are the most well-known examples. When traffic is unencrypted, packet sniffers can intercept and read raw data packets, including login credentials and personal messages. Even on networks that feel private, such as your home Wi-Fi, a coffee shop hotspot, or an office network, anyone with access to that network segment and the right software (which is freely available) can potentially see everything traveling across it in plain text.

This is not a theoretical attack requiring exceptional skill. The barrier to entry is remarkably low. An attacker with network access and a laptop can run a sniffer passively without generating any alerts at all, because packet sniffing requires no exploitation of the target system itself. It simply requires visibility of the traffic.

This is precisely why the difference between HTTP and HTTPS matters so much, and it is a difference you can demonstrate to yourself. If you capture traffic to a plain HTTP website with a tool like Wireshark, login form data can appear in the capture as readable plain text. Capture traffic to an HTTPS website performing the exact same login, and the payload is unreadable ciphertext. The TLS encryption that HTTPS provides means a packet sniffer can still see that a conversation is happening, and who it is between, but not what is being said.

This is the difference between a postcard and a sealed, tamper-proof envelope. The address on the front is always visible. That is unavoidable, because routing depends on it. But what is inside does not have to be.

So here is the practical takeaway. Every time you see "https://" rather than "http://" in your browser's address bar, you are looking at the difference between a postcard and a sealed envelope. On public Wi-Fi especially, this distinction is not academic. It is the difference between your data being private and your data being readable by anyone nearby with a free tool and five minutes.

Seeing It For Yourself

Everything in this post is invisible by default, which is exactly why it feels abstract. Here is how to make it visible.

Revisiting traceroute, now with TTL in mind

In Post 1, we ran traceroute (or tracert on Windows) and saw a list of network hops between your device and a destination. Now you know why that tool works the way it does.

traceroute google.com

Traceroute works by sending packets with a deliberately low TTL, starting at 1. That first packet will be discarded by the very first router it reaches, because its TTL hits zero immediately. But that router sends back a small message saying "TTL expired," and that message reveals the router's address. Traceroute then sends another packet with TTL 2, which gets one hop further before expiring, revealing the second router. And so on.

Every line of output from traceroute is, quite literally, a packet that was deliberately sent to die at a specific point in its journey, and the dying packet's last words reveal who stopped it. That is how the tool maps your entire route to a destination, one hop at a time.

Watching packets in real time

If you want to see actual packets, with actual headers and actual payloads, the standard tool is Wireshark, a free and widely-used packet capture and analysis tool. Installing it and capturing even thirty seconds of your own network traffic is genuinely eye-opening. You will see the sheer volume of packets flowing in and out of your device every second, just from background processes, app updates, and idle connections you did not know were active.

If you do try this, do it only on your own network and with appropriate care. Capturing traffic you do not have permission to capture is illegal in most jurisdictions. Look for the protocol column. You will see TCP, UDP, DNS, TLS, and more flying past, each one a small envelope, each one part of a larger conversation, each one finding its own way.

What You Now Understand

You now know that nothing you send across a network travels as a single, whole unit. It travels as a swarm of small, independently-addressed packets. Each one is wrapped in multiple layers of header information, each one potentially takes a different route, and each one is capable of being lost, delayed, or arriving out of order. All of it gets silently and invisibly reassembled into the experience you actually have: instant, whole, and seamless.

You know what is inside a packet, which is the header, the payload, and often a trailer. And you understand encapsulation, the nested-envelope structure that lets different devices handle different parts of the journey without needing to understand the whole thing.

You know how TTL prevents packets from looping forever, and how that same mechanism powers the traceroute tool you ran in the last post.

You know how TCP's sequence numbers and acknowledgements turn an unreliable, lossy, out-of-order delivery system into something that feels perfectly reliable from the outside. And you know that this reliability is a layer of cleverness built on top of an underlying reality that is messy and imperfect by nature.

Most importantly for this series, you know that much of this traffic travels as postcards, not sealed letters. The header has to be visible for routing to work, but the payload does not have to be, and whether it is or is not depends entirely on whether encryption is in use.

In the next post, we formalise all of this. The OSI model is the framework that organises everything we have discussed, including headers, encapsulation, routing, and addressing, into seven distinct layers, each with its own job. Once you understand packets, the OSI model stops being something to memorise and starts being something that simply describes what you already know.

This is Post 2 of the Networking Foundations series. If the postal analogy made packets click for you, share this with someone who still pictures the internet as a single pipe that data flows through. And subscribe to our newsletter to get each new post in the series as it is published.

What Is a Network? The Why Before the How

VickkyKruz NetSec — Tue, 12 May 2026 20:05:39 +0000

Right now, without thinking about it, you are connected.

Your phone knows what time it is in Tokyo. Your laptop can retrieve a document stored on a server in Frankfurt in under a second. A security camera outside a shop in Birmingham sends footage to a storage system in a data centre miles away. A hospital in Manchester shares a patient's scan with a specialist in Edinburgh without either party having to move. None of this feels remarkable anymore. It has become the background noise of modern life.

However, before moving on, think about what is really going on. A huge number of devices, including phones, laptops, servers, cameras, sensors, smart speakers, hospital equipment, traffic lights, and aircraft, are continuously exchanging information at distances ranging from a few centimetres to several thousands of miles. Instantaneously. In a very dependable way. Almost secretly.

That is a network. And understanding what it really is, why it was built, and what it does is the foundation that everything else in this series builds on.

Before Networks: Computers in Isolation

To understand why networks exist, you need to understand what the world looked like before them.

In the 1950s and early 1960s, computers were not the devices you carry in your pocket today. These computers were large, expensive, and typically stored in specialized environments like universities, laboratories, or government institutions. They had limited connectivity and centralized control, meaning computer resources were controlled by a single machine. Users would typically interact with the computer using punch cards.

One such computer could very well occupy a whole room. Possibly, a university would have one. Perhaps a government department would be the owner of several. Some big companies might allow themselves such a luxury. These computers were really powerful instruments for performing calculations and handling data; however, they were totally isolated from each other. If, for instance, you wished to distribute your calculation results to a collaborator located in another research place, you would first have to print the results and then send them by post. Alternatively, you could have gone over to their computer in person.

Before ARPANET, computers worked in isolation. Communication with other machines wasn't possible.

This isolation had consequences beyond inconvenience. Researchers at different universities doing related work could not easily build on each other's results in real time. Expensive computing resources sat idle when one institution needed them, and another had spare capacity. And for the United States government, there was a much more alarming problem: its military and research infrastructure depended on centralised systems. If a Soviet strike destroyed a central node, entire communication chains could collapse.

The problem wasn't just efficiency. It was fragility.

The Question That Started Everything

Back in 1966, Robert Taylor, who was an employee at the United States Advanced Research Projects Agency (ARPA), was sitting in his office. The walls of that room were lined with the screens of three computer terminals. Each of these was connected to a different mainframe computer at a separate research institution.

Taylor got hold of the notion that it was senseless to demand three teletype machines just for mere communication with three incompatible computer systems. One single terminal could be connected to each of the other terminals through a single computer language protocol if the three were merged. This way, it would be far more efficient.

It was a deceptively simple observation. Why should communicating with a computer require a dedicated, incompatible physical machine for each one? Why couldn't one terminal speak to any computer? Why couldn't computers speak to each other at all?

Bob Taylor initiated the ARPANET project in 1966 to enable resource sharing between remote computers. The answer to Taylor's question would eventually become the internet. But it started as something far more modest: a small experimental network called ARPANET.

ARPANET: The First Network (1969)

The Advanced Research Projects Agency Network (ARPANET) was the first wide-area packet-switched network with distributed control and one of the first computer networks to implement the TCP/IP protocol suite. Both technologies became the technical foundation of the Internet.

The people who designed ARPANET had to deal with a major problem: how to move data effectively through the network? The already available model, which was carried out through telephone systems, was named circuit switching. If you placed a call, then a special, physical circuit was set up exclusively between you and the person you were calling, and that was valid for the entire call time. It ensured reliability; however, it was inflexible. If the slightest portion of that circuit got damaged, the call got terminated.

A key issue was maintaining communications, because if the ARPANET behaved like a traditional circuit-based telephone system, failure of a single node could take down the entire network. What was needed was a means to get messages to their destination in a way that did not depend on any single node. This is the challenge that spawned the concept of packet switching.

Packet switching represented a fundamentally different idea. The traditional approach was to have one dedicated circuit for data transmission; here, the data was divided into small pieces, packets, which were each marked with their source and destination. These packets could individually navigate through the network and might even follow different routes. Finally, the receiver would put them back together in the correct sequence. If one route was inaccessible, the packets could be diverted through alternative routes.

The network did not rely on a single point of failure. It was, by design, a resilient system.

The First Message: Two Letters and a System Crash

In its earliest form, the ARPANET began with four computer nodes, and the first computer-to-computer signal on this nascent network was sent between UCLA and the Stanford Research Institute on Oct. 29, 1969.

The message was simple: the word "LOGIN". A researcher at UCLA typed the L. Stanford received it. He typed the O. Stanford received it. He pressed the G, and the system at Stanford crashed. The first time that a computer network message was sent, it was "LO". The two letters 'L' and 'O' of the "login" were actually received before the system crashed, but this meant that the two systems could be connected over long distances.

It was, depending on how one looked at it, an incredible failure or a great success. Technically, the crash was just a minor issue. The principle had been proved. Two computers that were hundreds of miles apart had communicated. Barely a few months later, the connection was stable. In the coming years, the network was joined by more universities and research institutions. By the fifteen-year mark, it had changed into something that even the original guys could hardly comprehend. By January 1983, enough individual networks had been connected to each other cto such an extent that the ARPANET had become the Internet.

So What Is a Network?

Now that you understand where networks came from, a formal definition lands differently. A computer network is two or more devices connected in a way that allows them to communicate and share resources.

That is the entire definition by itself. Two devices and a connection. All other things, such as routers, switches, protocols, firewalls, cloud infrastructures, and the internet, are just extensions of that simple idea. The resources being shared can be anything: files, processing power, storage, internet access, printers, databases, and applications. The connection can be physical (a cable) or wireless (radio waves). The devices can be in the same room or on opposite sides of the planet.

Networks are networks not because of their size or complexity, but through the act of connecting and the binding mutual understanding embedded in that connection about how devices will communicate with each other. That agreement is called a protocol. We'll go deep on protocols in later posts. For now, understand that without agreed protocols, two connected devices are just two devices plugged into the same wire. The protocol is what gives the connection meaning.

Types of Networks: The Scale of Connection

Networks come in different scales, each with its own name, purpose, and set of security considerations.

PAN: Personal Area Network

The smallest kind of a network. It links devices located in a user's personal space, generally within a distance of about 10 meters. Your Bluetooth headphones are connecting to your phone. Your phone is syncing with your smartwatch. Your laptop connects wirelessly to a portable speaker. All of these are PANs.

Security note: Bluetooth has a long history of vulnerabilities. Because PANs operate at close range and often use wireless protocols that users rarely think about securing, they are frequently overlooked in personal and corporate security policies. Attacks like BlueSnarfing (unauthorised access to Bluetooth devices) and BlueBugging (taking remote control) exploit exactly this blind spot.

LAN: Local Area Network

The most common one that we know. A LAN is a network of devices within one building or campus, a house, an office, a school, or a hospital floor. Your home Wi-Fi network is a LAN. The office network at a company headquarters is a LAN. The network in a university computer lab is a LAN.

A local area network (LAN) is a network confined to a small, localized area. Home WiFi networks and small business networks are common examples of LANs. LANs usually provide very fast data speeds and almost no delay in data transfer, as the data has to travel only a short distance. In addition, they are usually the property and in the control of the users, e.g., a household, a company's IT department, or a school's network team.

Security note: LANs are often implicitly trusted users on the same LAN are frequently given access to shared resources by default. This is exactly the trust model that attackers exploit through lateral movement, which we explored in the Firewall post. Being on the same LAN as someone doesn't mean you should trust their machine.

MAN: Metropolitan Area Network

A MAN establishes connections in a city or a metropolitan area throughout the networks that are bigger than LAN but smaller than WAN. A MAN usually extends 5-50 km, thereby covering a larger area than a LAN but a smaller one than a WAN. It links computer systems across a city or even between nearby cities. A city government connecting its municipal buildings. A university with multiple campuses across a city. A local internet service provider's infrastructure. These are all MANs.

Security note: MANs often rely on infrastructure shared across multiple organisations or routed through public carrier networks, increasing the attack surface significantly compared to a privately managed LAN.

WAN: Wide Area Network

A wide area network or WAN can be used to connect networks that are geographically apart. For instance, cities, countries, or even continents. The Internet itself is considered a WAN. But WANs also exist at smaller scales: a multinational company connecting its London, New York, and Singapore offices is operating a private WAN.

LANs are considered more secure than WANs. WANs are more susceptible to security threats due to their large scope and connection to the internet, which is a major source of security threats. To protect WANs from threats, encryption and other security protocols, such as VPNs and firewalls, must be implemented.

Security note: WAN traffic travels across infrastructure that organisations do not own or control, cables under oceans, routers in countries with different legal jurisdictions, and exchange points shared with thousands of other networks. Data in transit across a WAN is far more exposed than data on a private LAN, which is why encryption and VPNs exist.

The Security Truth Built Into the Foundation

Here is something that most introductions to networking gloss over, and it matters enormously for everything that follows in this series.

ARPANET — the origin of the internet — was designed for trust, not security.

Its users were researchers and academics at a small number of institutions. Everyone on the network was known. Everyone had legitimate access. The idea that a bad actor might connect to the network and attempt to cause harm was not a design consideration, because the network was not designed for strangers. One of ARPANET's original goals was to allow secure communications and the sharing of information between research facilities located in different parts of the world. However, "secure" in 1969 was understood as "available and reliable" rather than "protected from an attack". The security model was physical; you could only access the network if you were at an authorized terminal.

Then the network grew. And grew. And kept growing. Until the intimate, trusted community of a few dozen research institutions became the global public internet open to billions of people, including those with harmful intent. Most of the protocols that run the internet are, fundamentally, the offspring of systems created for a network where everyone was trusted. TCP/IP, the base protocol for the Internet, was made to transfer data in a reliable way, not for secrecy or security. HTTP, the protocol that runs the web, by default sends data in plaintext. DNS, the protocol for resolving domain names to IP addresses, was made with ease of use in mind rather than verification.

This is not a criticism of the people who built these systems. They were solving a different problem in a different world. But it is the single most important context for understanding why cybersecurity exists as a discipline at all. The internet was not designed to be secure. It was designed to be connected. Security has been retrofitted on top of a foundation that was never built for it. Every firewall, every encryption standard, every authentication protocol, every security framework you will ever encounter exists because of this foundational reality. Understanding networking means understanding this first.

What Happens When You Type a URL

Let's make all of this concrete. Right now, in the real world, what actually happens when you open a browser and type a web address?

Your device makes DNS inquiry: it queries "which IP address corresponds to this domain name?", a DNS server on your network receives the query.
A TCP connection is created: your device and the web server conduct a three-way handshake to reach an agreement for communication.
Your request moves as packets: fragmented into small chunks, labelled, sent via your LAN, through your router, across your ISP's network, maybe through multiple intermediate networks, till the destination server.
The server replies: the requested content is sent back as packets, which might be received in a mixed order and need to be reassembled by your device.
Your browser shows the page: the collected data is checked, decoded, and displayed.

All this takes place in just a few milliseconds. Your home LAN, your ISP's WAN facilities, DNS servers, routing equipment, and the server itself all work in a synchronized manner according to the mutually agreed protocols. And every single one of those steps is a potential target for an attacker who knows what they're doing.

We'll thoroughly explain each of those steps. That's what the rest of this series is about, anyway. But the fact that they all happen, and the reason they happen, is what this introduction is about.

Commands to Try Right Now

Understanding networking doesn't stop at the conceptual level. Here are three commands you can run right now on your own machine to see your network in action.

On Windows:

ipconfig

Shows your device's IP address, subnet mask, and default gateway, the basic addressing information that places your device on the network.

On macOS / Linux:

ifconfig

or on newer Linux systems:

ip a

Same information as above, formatted differently.

Everywhere: the most fundamental networking command:

ping google.com

Sends a small packet to Google's servers and measures how long it takes to get a response. This is the simplest possible test to see if your device can reach another device across the network. The time shown (in milliseconds) is your latency how long data takes to travel between two points.

traceroute google.com

(On Windows: tracert google.com)

This shows every network hop between your device and Google, every router your data passes through on its journey. Run this and look at the list. Those are real network nodes, each one a step in the path your data takes across the internet.

The Foundation You Now Have

You have an understanding of a network and its purpose. You also realized that it came out of frustration, ingenuity, and Cold War era-specific pressures. Besides that, you realize that the very first message sent through a network was essentially a system error alert, and yet, it still worked.

You are familiar with the four main types of networks in terms of scale, PAN, LAN, MAN, WAN, and have an idea about the typical use of each one. Besides that, you know that the most fundamental fact: the internet was created for communication, not security. Safeguards were merely a secondary afterthought that was added on top of a trust-based system. Everything is influenced by that frame of reference.

In the following article, we unlock one more layer: a network-level view of data transmission. A packet, its contents, its heading, its travel, and the destination it finds, and the cases when it doesn't, are covered.

You are reading Post 1 of the Networking Foundations series. If you found this post helpful in making networking seem more tangible and less theoretical, please share it with someone who has been delaying learning this stuff. Also, subscribe to our newsletter to receive each new post of the series directly in your inbox.

Behind the Wall: What Firewalls Really See, Block, and Miss

VickkyKruz NetSec — Fri, 01 May 2026 21:24:35 +0000

Imagine a nightclub security guard who is large, commanding and stationed at the entrance with a guest list. If your name appears on the list, you are admitted. If it's not there, you will be refused entry. The security guard doesn't accompany you inside. He doesn't observe what you do when you get inside. He also doesn't find out if you have exchanged clothes with someone on the list. His work is complete at the door.

That is a firewall, basically. For a while, that was sufficient. It has ceased being so.

WHAT A FIREWALL ACTUALLY IS?

Really, in its simplest form, a firewall is a security mechanism that watches and controls the network traffic based on the rules set beforehand. One may say it is a check point separating two networks, more often than not, a private internal network (your home, your company, your server) and the public internet.

Every time data is transferred via a network, it is done in small bits called packets. Besides the data itself, each packet has a header, a label that indicates where it came from, where it's going, what protocol it's using, and what port it's targeting. A firewall inspects those labels and determines: allow or deny.

Such a straightforward matter becomes very complicated when done at a large scale. A large enterprise network can handle millions of packets in one second. The firewall must make the correct decision each time, immediately, without disrupting the flow of genuine business traffic.

That is the core challenge firewalls were built to solve. But the way they solve it has changed dramatically over the past four decades.

THE HISTORY: FROM A UNIVERSITY LAB iN 1988 TO NATION-STATE DEFENCE

Firewalls weren't simply invented on a corporate whiteboard. In fact, they were first created at universities.

Back in 1988, a University of California, Davis graduate student named Conrad Kwok was co-supervised when he developed what many would consider the very first filtering firewall prototype a "cut-through bridge, " as he named it. The bridge acted as a gatekeeper between two networks and its software-controlled the flow of traffic. The device cost about £1,600 in today's money. However, the idea was, well, priceless.

It was a very good time to be working on this kind of technology because, guess what? In November 1988, the Morris Worm, a piece of malware that was capable of self-replicating and spreading all over the internet, infected thousands of Unix computers, paralyzing approximately 10% of all computers connected to the internet. This was a wake-up call and that there was a need for the protection of the rapidly expanding internet.

The word "firewall" came from a physical analogy: a fire-resistant barrier built into walls to stop fire spreading from one room to another. And the analogy was perfect. In a network, a firewall is a tool that stops the spread of harmful and unsafe traffic.

Firewall technology development didn't stop there. Each one was a result of the previous one failing.

THE FIVE GENERATIONS OF FIREWALL TECHNOLOGY

GENERATION 1: PACKET FILTERING (LATE 1980s)

The first generation of firewalls, or packet filtering firewalls as they're also called, first appeared back in the late 1980s. Working at the network layer level, they scrutinized individual packets against a set of pre-established rules, like source and destination IP addresses, ports, and protocols, to decide on allowing or blocking the traffic.

They were very fast and inexpensive. However, they lacked awareness of the whole situation. A packet filtering firewall would behave like it had no memory. Every packet was checked entirely independently, the firewall had no knowledge of what packets might have preceded or succeeded it. Someone out to exploit the system, knowing which ports were open, could send in packets that appeared to be legitimate. The filter would let them pass as if it were nothing.

Such firewalls are described as stateless, and it was discovered that statelessness was a huge security flaw.

GENERATION 2: STATEFUL INSPECTION (EARLY 1990s)

Then memory was given to firewalls as the next step.

Stateful inspection firewalls not only tracked the states of new network connections but also maintained a table of ongoing conversations so that based on the sequence number, the window size, the acknowledgment number, the source and destination ports and addresses, etc., they could distinguish between a legitimate reply to a request and an intrusion attempt.

It was a breakthrough, for sure. However, stateful firewalls had a major limitation. They were aware of connections but not of content. They were capable of telling which port was used for a conversation, but what was exchanged during that conversation was a mystery to them.

GENERATION 3: APPLICATION LAYER & PROXY FIREWALLS (MID-1990s)

As the internet grew rapidly in the mid-1990s, the bad guys figured out how to be sneakier. They started to create malware that looks like normal web paths like sending bad stuff hidden in a(n) (plain) web communication, because they knew that most firewalls wouldn't check into.

Application layer firewalls changed the game. These are also called proxy firewalls. They did a great job as a mediator they first caught the traffic, then they looked at what was really inside, and finally they decided if they should let it go through or not. A firewall could, for the first time, understand the message, not just who was talking to whom.

The price was the speed. Thorough checking took it causes time, and those days of the early internet, that delay was felt.

GENERATION 4: UNIFIED THREAT MANAGEMENT (EARLY 2000s)

Since the early 2000s, Unified Threat Management (UTM) systems have started to appear, bringing together several security functions in one single appliance, mixing the usual firewall features with intrusion detection and prevention, antivirus, and content filtering.

UTM really made a difference for small and medium businesses. Instead of controlling five different security tools, a company could simply gather them all in one box. It was a logical progression motivated by the increasing complexity of the real world.

GENERATION 5: NEXT-GENERATION FIREWALLS (2008–PRESENT)

The advent of NGFWs in 2008 marked a major departure of network devices that were only passive before. With NGFWs as standard, network security systems could carry out deeper inspections and take security decisions in real time on the basis of thorough data analysis.

Next-Generation Firewalls (NGFWs) combined all the features of the previous generation and added capabilities that would have been considered a work of fiction in 1988 such as deep packet inspection, application awareness, identity-based controls, integrated intrusion prevention, and the latest machine learning.

There has been a major change in the firewall landscape in the early 2020s in the form of ML-Powered NGFWs. These firewalls incorporate machine learning to predict threats and provide better protection for the network transforming firewalls from reactionary tools into systems that can detect even the modern threats and their variants before a signature is created.

WHAT A FIREWALL SEES: THE TECHNICAL REALITY

Traditional firewalls simply look at basic information on packets, such as source and destination addresses. However, modern firewalls or Next-Generation Firewalls (NGFWs) are much more sophisticated in that they analyze communication across the layers of the OSI model from the lowest Layer 1 that involves physical transmission of data to the highest Layer 7 where applications do their work.

So, whenever a packet or memory packet passes through a modern NGFW, the firewall is capable of doing the following:

Packet header analysis: Reading source/destination IPs, ports, and protocols. The baseline that all firewalls have always performed.
Stateful connection tracking: Maintaining a table of active sessions to understand the context of each packet in relation to the conversation it belongs to.
Deep Packet Inspection (DPI): Opening the packet and reading its payload. Identifying the actual application in use, regardless of what port it claims to be using. This is how a firewall can spot a VPN tunnel disguised as web traffic, or peer-to-peer software pretending to be HTTP.
Application awareness: Identifying not just which port is being used, but which actual application is responsible, distinguishing between, say, a WhatsApp call and a browser session, even if both travel on the same port.
Identity integration: In enterprise environments, NGFWs can link traffic to specific user identities rather than just IP addresses. This means a policy can say "this department cannot access this application", not just "this IP address cannot reach this port."

- Threat intelligence feeds: Cross-referencing traffic against continuously updated databases of known malicious IP addresses, domains, and file signatures.

WHAT A FIREWALL BLOCKS: THE WINS

When configured correctly, a modern firewall is genuinely powerful. It stops:

Unauthorised access attempts from external IP addresses
Port scanning by reconnaissance tools looking for open doors
Known malware signatures in inbound and outbound traffic
Traffic to known malicious domains, commands, and control servers
Data exfiltration attempts through unusual outbound connections
Network-layer DDoS attacks by rate-limiting or blocking flood traffic from identified sources
Lateral movement between network segments when micro-segmentation is in place

In fact, a firewall that has been properly set up is a very effective and absolutely necessary defence against the majority of opportunistic, automated attacks that simply spray the internet looking for vulnerable targets. It makes the cost of attack high enough for most automated threats to decide to move on to softer targets.

WHAT A FIREWALL MISSES: THE TRUTHS NOBODY TELLS YOU

This is the firewalls story that nearly never gets included in the beginner's guide. And it is actually the most important part.

1. IT CANNOT SEE INSIDE ENCRYPTED TRAFFIC, AND MOST TRAFFIC IS NOW ENCRYPTED

About 90% of the web traffic that we use daily is encrypted these days. However, firewalls manage to decrypt just a very small part of this traffic because of limitations related to performance and also due to privacy issues. Hackers take advantage of this situation by hiding their malicious code in HTTPS or QUIC traffic.

Encryption means a firewall can only see the outside of a sealed envelope. It can only check the envelope's origin and destination, it has no idea what is inside unless it opens the envelope first by decryption. Some NGFWs do SSL/TLS inspection by positioning themselves as a "man-in-the-middle" who decrypts, inspects, and re-encrypts the traffic. However, this is really demanding in terms of computing power, in some locations, legally a bit of a minefield, and quite far from being universally done.

Threats that come via files like Gootloader and QakBot often use popular cloud apps like Microsoft 365 or Slack as a channel to spread the malware that passes through encrypted channels without firewalls ever detecting it.

Simply put: if through an encrypted connection to a trusted service an attacker conceals a harmful payload, most firewalls will just let it go.

2. IT HAS NO DEFENCE AGAINST INSIDER THREATS

Addressing insider threats remains a major blind spot for enterprise firewalls. Lateral movements or suspicious user activities, including those from authenticated users, are beyond the scope of firewalls which mostly depend on specifying external-internal traffic rules. The design of a firewall is based on one key assumption: dangers come from outside. If someone gets inside the network be it a legitimate employee, a contractor, or an attacker who has compromised the credentials of a valid user the firewall will hardly be able to control what happens next.

When users are given too many privileges, they can even bypass the perimeter defences without any help from the firewall. Once inside the internal network, they could either steal data or wreak havoc on the digital infrastructure. This is not a mistake but a very fact of the architecture. Firewalls serve to monitor the perimeter as that was their main function. Making sure the inside is orderly is a whole different story!

3. MISCONFIGURATION IS ACTUALLY THE REAL THREAT AND IT'S LITERALLY EVERYWHERE.

That should be one statistic that really makes every security professional squirm: according to Gartner's report, it's misconfiguration that is responsible for 95% of all firewall breaches, not defects.

Not sophisticated zero-day exploits. Not hackers from nation-states armed with unlimited budgets. Misconfiguration. A rule set incorrectly. A port opened when it shouldn't be. An "any-any" rule, that is allow all traffic from any source to any destination, tucked away in a policy from six years ago that nobody thought to review since.

One out of five firewalls have at least one configuration problem. The 2019 Capital One breach, that was the result of a single misconfigured firewall rule made public the personal information of over 100 million people. It was not a highly sophisticated attack on the firewall itself. Just one wrong rule.

4. IT CANNOT STOP ATTACKS THAT USE ALLOWED PROTOCOLS

Think of a firewall as a gate that only lets through people that have a pass. If the rule says that people are allowed to use the gate at 443 port, then the firewall will let those people through. What it doesn't know and usually cannot figure out even after several configurations is if the ones who use that channel of web traffic are the ones with the legitimate browser or the attackers, the latter using that permitted channel to take out your data or give commands to the malware that is already inside your network.

That's what C2 (Command and Control) attacks are all about. The malware that has been put on a computer inside the organization tries pulling a fast one by making a home call through ordinary-looking HTTPS requests. For the firewall, it's as if an employee is simply browsing the web. For the attacker, it's a wide-open channel.

5. IT DETECTS INBOUND AND OUTBOUND TRAFFIC BUT NOT EAST-WEST TRAFFIC

Traditional firewall architecture is primarily designed around controlling north-south traffic, that is, the traffic that enters or leaves the network. The protection provided for east-west traffic, the communication between the systems that are located within the same network, is much weaker.

Since a flat network can be easily traversed by a single infected malware or even a rogue device, direct access to essential assets can be gained. Once inside, attackers can move laterally, locate credentials, and increase their privileges silently and without much resistance.

This is known as lateral movement, and it's the method of operation behind nearly every significant ransomware attack. The first point of entry is hardly ever the target system, it's usually a less-secured machine in the vicinity. The attacker continues to move stealthily from one machine to another, residing inside the network for days or weeks, until finally reaching their main target. No perimeter firewall will be capable of preventing this. It was simply not geared for that purpose.

THE CAPITAL ONE LESSON: THE HUMAN FACTOR

Back in 2019, a hacker enormously capitalized on a misconfigured Web Application Firewall to carry out a Server-Side Request Forgery (SSRF) attack without physically breaking the firewall at all to gain entry into Capital One's cloud infrastructure. Very simply, the firewall had been wrongly set up by a human. That human mistake literally opened the door. As a result, 106 million customer records were leaked.

The take-home message here is not that firewalls don't work. The truth is a firewall can only be as robust as the rules that someone made for it and those rules are made by humans, under the pressure of time, with limited knowledge, in constantly changing environments. Actually, the firewall did the job as per the configuration. The problem was with the configuration itself.

THE BIGGER PICTURE: THE PERIMETER IS NO LONGER ENOUGH

Network security for years was designed like a castle. The firewall was the fence. Everything inside was trusted. Everything outside was not trusted. The model was simple, clear, and efficient, if all the work was done in the same building, on the same network, and all the data was stored on-site. Unfortunately, that is not the case anymore. Cloud apps are everywhere, employees can work anywhere, partners are connected as first-class citizens, and criminals do not even wait at the drawbridge for a polite invitation.

Today's cybercriminals do not necessarily have to break into the company's systems by carrying out an attack on a firewall. What they usually do is log in using stolen credentials. According to the Verizon 2024 Data Breach Investigations Report, approximately 68% of breaches involved a non-malicious human element, including the use of stolen credentials, phishing, and social engineering.

The castle is wall-less now. The moat is dry. And the firewall, standing at a perimeter that does not exist anymore, is guarding a boundary that attackers simply do not need to go around. This situation caused a totally new security philosophy to emerge: Zero Trust.

The idea is simple, although the deliveries may be complex: be cautious at every step, verify every time, and never trust without verification. A Zero Trust model requires that every individual, device, and network connection be verified and authenticated, whether they are inside or outside the traditional network perimeter. Access is not granted based on geography but on identity, device health, and context, and it is constantly re-assessed, not just recline at the door. Firewalls continue to have an important role in the modern world. But firewalls continue to be a part of the security ecosystem, it's just that they are not the focus anymore. They are one of several control elements, not the only gatekeeper of trust.

WHAT THIS MEANS FOR YOU

If you run a small business, a home network, or a big company, these practical tips apply to you:

Don't rely on your firewall as your only defence. A firewall is like a gatekeeper, not a full security plan. Support it with endpoint protection, intrusion detection, email security, and most importantly, user training.
Keep checking your firewall rules. Unused, unnecessary, or too loose rules will pile up, and that will be where attackers get in. If you have rules that no one understands, get rid of them.
Turn on SSL/TLS inspection if possible. Encrypted traffic is nowadays the top choice of malware to hide in. Give your firewall the green light for decrypting and inspecting if it has that function.
Set up network segmentation. Avoid a flat internal network where all devices can communicate with each other. Limit the access to sensitive systems, so that an attacker won't be able to compromise the entire network just by moving from one compromised device to another.

- Go beyond the perimeter. It's not only about asking "who's trying to get in?" but also "what if someone is already in?" Organisations that ask the second question and build their defences accordingly are the ones that breach survivors rather than being breached victims.

THE FIREWALL IS NOT THE ENEMY OF NUANCE

The firewall is a truly remarkable bit of technology. What started as a university campus prototype in 1988 has developed to a security engine that uses machine learning in 2025. It halts millions of automated attacks every single day without anyone even noticing. It is a fundamental the element of every serious network security stack.

Yet it is not a promise. It is not a fortification that excludes all evil from entering. It is a very capable guard at a certain point, one that can be tricked by the right credentials, circumvented by the right protocols, and weakened by the wrong configuration.

Knowing what your firewall truly detects, what it blocks, and, most importantly, what it fails to detect is not a reason to fear it. It is a reason to develop a security strategy that goes beyond it. The wall is there. It is important. But the actual security tale has always been about the events behind it.

Did‍‌‍‍‌ you find it useful? Share it with those who think that firewall is basically security, this might start a very necessary discussion. Also, subscribe to our newsletter for more fascinating info on cybersecurity that even experts may not ‍‌‍‍‌know.