![\"Sequence](\"/images/mtls-handshake-diagram.svg\")
\n Mutual TLS — mTLS — is TLS with the authentication running in both directions. In ordinary TLS, the client checks the server's certificate and trusts it's talking to the real thing; the server doesn't check anything back. In mTLS, the server checks the client too: it demands a certificate, verifies the chain against a CA it trusts, and confirms the client's identity, all before the actual request gets processed. No valid client certificate, no connection — regardless of which network the call came from.
\nThat second check matters more than it sounds like it should, because of what most internal systems do without it. Without mTLS, "reachable" and "trusted" are usually the same thing: if a request can get to Service B's port at all, Service B mostly assumes it's legitimate, because reaching it means being inside the same VPC or cluster. That's a weaker guarantee than it feels like — a forgotten staging job, a compromised sidecar in an unrelated app, a contractor's laptop still sitting on the VPN months after the contract ended can all route a packet to that port just as easily as the real caller can. Service B has no way to tell any of them apart, because it never asked who was calling. It only checked that the request arrived.
\nmTLS closes exactly that gap. It turns "reachable" into "who are you, actually," and enforces the answer on every single connection.
\nPut Service A and Service B on either end of the handshake: A presents its certificate, B verifies it against a trusted CA and confirms A's identity, and only then does A's request get processed.
\n\n That's the whole pitch for running mTLS between services: you stop trusting the network and start trusting an identity you actually issued and control. It's also worth saying plainly what mTLS doesn't do — it tells Service B who's calling. It says nothing about what that caller is allowed to do once it's in the door. That's a separate job, handled by policy, not by the handshake.
\nmTLS earns its keep once a system has enough moving parts that "it's on the internal network" stops meaning anything — dozens of services, teams that don't all know each other's traffic patterns, or an actual compliance requirement to prove who talked to whom. At that scale, an explicit identity per service is worth more than an implicit one per subnet.
\nIt's premature somewhere else: a handful of services, low blast radius, and — this is the part that actually matters — no automated way to issue, rotate, and revoke certificates yet. Adopting mTLS without that automation doesn't buy you security so much as it buys you a very specific, self-inflicted outage, on a schedule you don't control. If most of your risky traffic is actually external — partners, enterprise customers hitting an API — a gateway that terminates mTLS at the edge is usually a better fit than trying to hand every third party a client certificate.
\nThree places, roughly in order of how much application code has to change:
\nFor anything beyond a handful of services, the mesh model tends to win on operational grounds, precisely because it centralizes the one thing you really don't want copy-pasted forty times: certificate handling.
\nmTLS costs more per connection than plain TLS, because there's an extra certificate to check on every handshake. Verifying it burns CPU, and the handshake itself takes longer end to end. The place this actually bites is short-lived connections — a service that opens a fresh TCP connection for every single request pays the full handshake cost every single time, and p95 latency creeps up in a way that has nothing to do with your application logic.
\nThe fix is almost entirely about not doing handshakes more often than you have to: keep connections alive with keepalive and pooling, use session resumption if your TLS stack supports it, and stop treating "one connection per request" as free. None of this is exotic — it's the same advice you'd give for plain TLS, just with a slightly less forgiving penalty for ignoring it.
\nEverything above is the mechanism. This is the operational half, and it's the one that actually determines whether mTLS works well or badly in practice: certificate lifecycle. Who issues certificates and what identity goes in them. How a workload gets its certificate in the first place. How rotation happens before expiry, without a rollout that kills connections in bulk. How you revoke fast when a key's been compromised. How you roll the trust bundle itself forward when a CA changes, without one side updating before the other and breaking every handshake between them.
\nIt's worth taking seriously because the same fail-closed design that makes mTLS work is not limited to tidy internal services — it's just as fail-closed on hardware that was never meant to be a cautionary tale. On December 6, 2018, a software certificate quietly expired inside Ericsson's SGSN-MME equipment, the gear that manages mobile data sessions for carriers worldwide. The equipment did exactly what it was built to do the moment it could no longer verify its own certificate: it stopped. Roughly 32 million O2 customers in the UK and 40 million SoftBank customers in Japan lost mobile data that day, across 11 countries in total — not from an attack or a capacity problem, but from one certificate nobody rotated in time.
\nThat wasn't a certificate bug. It was a lifecycle bug wearing a certificate's clothes. A service mesh with automatic sidecar-issued short-lived certificates — the model Istio ships with — exists specifically so that no single human has to remember an expiry date. mTLS at any real scale is a bet that you'll build that automation before you need it, not after.
\nThe failure modes repeat: an expired certificate, clock drift between nodes making a valid certificate look invalid, a trust bundle that's out of sync across clusters, a certificate's identity not matching what policy expects, or client and server simply not sharing a cipher suite. When something breaks, the fastest triage isn't clever — check whether it's failing during the handshake or after, check whether it's clustered by node or region or one specific service, and check expiry and clock sync first, because that's the boring answer most of the time.
\nSeeing that quickly requires actually watching for it: handshake success and error rates per upstream, handshake latency (which tells you if it's a network problem or a certificate problem), days-to-expiry on every identity that matters, and logs that say why a handshake failed, not just that it did. The goal, when something breaks at 2am, is answering three questions fast — where, who, why — instead of staring at a dashboard that says everything is up while nothing is actually working.
\nmTLS replaces an implicit trust (this request reached me, so it's probably fine) with an explicit one (this request proved who it is, so I'll process it). That's a real security improvement, and it's why the pattern keeps showing up in zero-trust and service-mesh architectures. It also means you're committing to run a certificate authority for your own infrastructure indefinitely — issuance, distribution, rotation, revocation, and trust bundle updates, all handled correctly, forever.
\nThat second part isn't optional overhead you can skip. Fail-closed authentication is the entire security benefit of mTLS; the tradeoff is that the same mechanism fails the same way when the certificate behind it is wrong, whether that's one service or, as Ericsson found out, a continent's worth of phones. Adopt mTLS once the lifecycle automation is solid enough to trust with that job — not before.
\n", "date_published": "2026-07-28T00:00:00.000Z", "authors": [ { "name": "The Duke Post" } ], "tags": [ "security", "mtls", "zero-trust", "service-mesh", "sre", "infrastructure" ], "image": "https://thedukepost.com/_astro/mtls-cell-tower-cover.DMl10H4L_2pvsVl.webp" }, { "id": "https://thedukepost.com/articles/pii-is-a-pattern-not-a-field", "url": "https://thedukepost.com/articles/pii-is-a-pattern-not-a-field", "title": "The Data Had No Name on It. It Still Mapped a Secret Military Base.", "summary": "A 2018 fitness-app heatmap outed military bases without a single name field attached — where PII actually hides in your stack, and which of redaction, masking, tokenization, or encryption actually stops it.", "content_html": "In November 2017, Strava — the fitness app millions of runners and cyclists use to track their routes — published something called the Global Heatmap. It took every public activity ever recorded on the app and laid them all on one glowing map of the planet: a billion activities, three trillion GPS points, ten terabytes of data. The more people moved through a place, the brighter it glowed. Marketing loved it. It looked like the whole planet was breathing.
\nTwo months later, Nathan Ruser — a 20-year-old student in Australia — was scrolling over Syria on the map, presumably procrastinating on an assignment like every other 20-year-old on the internet. Most of the desert was dark, since nobody there logs a run on Strava. But a few spots glowed in the unmistakable shape of a running loop, sitting in the middle of nowhere. The same shape showed up around U.S. bases in Afghanistan, around Australia's secret Pine Gap facility, and over a Chinese military outpost on Woody Island. Soldiers out for a run, wearing a watch that talked to satellites, had traced the outline of their own base — for free, for the whole world, in HD.
\nNone of that data had a name on it. Strava's heatmap was anonymized and aggregated — the exact status most privacy programs treat as "job done." Somewhere, someone in a windowless office had a genuinely terrible Monday.
\nMost PII programs work off a list: email, phone, full name, home address, national ID. Find those fields, redact or restrict them, ship it. It's the compliance equivalent of locking the front door and leaving every window open — technically secure, if nobody looks sideways. That list matters, but it hides an assumption, and that assumption is exactly what got Strava in trouble: identity doesn't live in one field. It lives in what several fields add up to.
\nA GPS ping isn't PII. A timestamp isn't PII. A device ID with no name behind it isn't PII. Strava's heatmap had none of the fields on anyone's checklist. What it had was the same anonymous ping, at the same hour, every day, in a spot where the only explanation was "someone stationed at this base." Privacy researchers have a word for this: a quasi-identifier — harmless by itself, but enough to identify someone once combined with a couple more. It's also why no single list of PII fields works for every system. The same city or device_id column is just noise in a dataset of a million users, and a full identification in a dataset of a hundred — it depends on what else sits next to it, a caveat that never quite makes it onto the compliance slide.
![\"Close-up](\"/images/pii-fitness-tracker.jpg\"){kind=tracking}
\n Picture a smaller version of the same mistake. A support engineer is debugging a failed checkout, pulls up the raw request log, and right next to the stack trace sits a customer's email, phone number, and shipping address. Nobody chose to log those on purpose — somebody just set log.level = debug back in 2019, and nobody's been brave enough to touch it since. It's still PII, still sitting there in plain text, and just as exposed if that log line ends up in a third-party error tracker or in front of a contractor working an unrelated ticket.
PII collects in the same handful of places, over and over:
\nuser_id, client IP, and session tokens, sometimes whole headers or payloads if capture isn't scoped.Logs and tracing are the riskiest of the five. The moment data is captured, it gets copied — to a log aggregator, a monitoring tool, a backup, a data lake — and each copy has its own list of who can see it, a list nobody checked against the others. The same quasi-identifier trap shows up here too. A trace span has no name field, just a user_id, an IP address, and a timestamp — none of which trips a rule built to catch "email." Joined across enough spans, that's enough to reconstruct one person's routine — just like the heatmap did for an army base, except this time it's Dave from accounting, and somehow that isn't any more comforting.
![\"Diagram](\"/images/pii-combination-diagram.svg\")
\n Once you know where PII sits, there are four different tools for dealing with it, and people use the names interchangeably in meetings — which is how you end up with a Jira ticket titled "encrypt the PII" that doesn't actually fix the thing it's supposed to fix:
\nLogs and tracing should default to redaction or masking, because that data exists to be read by a person in real time. Databases can lean more on encryption and access control, because reads there go through structured, permissioned queries instead of a person scrolling a raw feed at 2am, squinting.
\nPII often gets lumped in with secrets — API keys, passwords, tokens — but they need different defenses. A leaked API key hands someone a capability they can use right away; the fix is to rotate it, quickly. A leaked PII record isn't a capability, it's an exposure; the fix is collecting less of it and controlling who can see it, because you can't rotate someone's home address no matter how good your incident runbook is. Strava's leak makes the difference clear. Nothing about it was a credential leak — nobody logged in as anyone. The damage was that a pattern of someone's daily life became visible to people who were never meant to see it.
\nThe same causes show up in nearly every PII incident. Someone logs the raw request body "just for now." Debug logging stays on in production long after the reason for turning it on is forgotten. Tracing is set to capture everything instead of an approved list of fields, because scoping it felt like a problem for later. Exports go out unmasked because the pipeline was built before the policy was. Logs get kept forever because a retention policy is the kind of thing that lives on next quarter's roadmap and never quite makes it. Different failures. Same shape: a safe default that quietly went unsafe, or a control that only worked if someone remembered to use it — and someone, eventually, doesn't.
\n![\"Close-up](\"/images/pii-dashboard-data.jpg\")
\n The fixes that actually hold up are the ones that don't depend on anyone's memory:
\nAfter the story broke, Strava's actual fix was to make the opt-out easier to find — it moved the setting onto the first page of privacy settings within weeks, and the problem was declared solved. What it didn't do was change the default. The heatmap stayed opt-out, not opt-in. Years later, a 2023 study out of NC State found researchers could still identify individual users from the public heatmap, using close to the same trick Nathan Ruser spotted just by scrolling, back in 2018.
\nNone of this is really about a fitness app. A fix that depends on someone remembering to opt out, or remembering to add one more field to a redaction list, is a fix that has already failed once. The leak that actually gets you is never the field you knew to check for. It's the one that looked like nothing — right up until it lined up with two other fields that also looked like nothing.
\n", "date_published": "2026-07-27T00:00:00.000Z", "authors": [ { "name": "The Duke Post" } ], "tags": [ "security", "pii", "privacy", "observability", "devops", "data-classification" ], "image": "https://thedukepost.com/_astro/pii-heatmap-lights-cover.Mj_cKjn2_owHd6.webp" }, { "id": "https://thedukepost.com/articles/ddos-in-production", "url": "https://thedukepost.com/articles/ddos-in-production", "title": "The Front Door Won't Close: What a DDoS Attack Actually Does to Production", "summary": "DDoS isn't about traffic volume — it's about bottlenecks, capacity, and how well you can tell attackers apart from real users at 3am.", "content_html": "It's 3:14am. The pager goes off with a p95 latency alert on /search. Thirty seconds later, a second alert: 5xx rate above threshold. CPU on the search pods is pinned at 100%. The queue in front of them is growing, not shrinking.
Every health check is green. The database is fine. The deploy from six hours ago hasn't changed. Nothing is broken — and yet real users are getting timeouts, and the on-call engineer is staring at a dashboard that says the system is both up and unusable at the same time.
\nThis is what a DDoS attack looks like from the inside. Not a dramatic outage with red everywhere — a slow, specific squeeze on exactly the resource you didn't protect.
\nThe instinct is to think of DDoS as "too much traffic." That's technically true and almost useless as a mental model, because it tells you nothing about what to actually do.
\nThe more useful framing: a DDoS attack finds your cheapest bottleneck and pushes on it until legitimate users can't get through. Sometimes that bottleneck is raw bandwidth. More often, in modern infrastructure, it's something narrower and much less obvious — a connection table, an autoscaling policy, a single endpoint that happens to run an expensive database query.
\nThat distinction matters because it means DDoS resilience isn't one control, it's a property of your whole system: where you put protection, how you isolate expensive paths from cheap ones, and whether you can tell "attack" from "launch day traffic spike" before your on-call team burns an hour finding out the hard way.
\nDoS and DDoS share a goal — deny service to legitimate traffic — but they don't share a defense.
\nA DoS attack comes from one source, or a small handful. You can often block it with a firewall rule and move on with your night. A DDoS attack is deliberately distributed across thousands of sources — botnets, compromised IoT devices, open proxies — specifically so that IP blocking doesn't work. Block one range and traffic keeps arriving from ten thousand others.
\nThat's the whole reason DDoS is harder: it forces you to defend at a layer above "block the bad IP," which usually means edge infrastructure you don't fully control yourself — a CDN, an Anycast network, a scrubbing provider — working together with defenses you do control inside your own stack.
\n![\"Diagram](\"/images/ddos-botnet-diagram.png\")
\n "DDoS" gets used as a catch-all, but the three common flavors behave completely differently, and only one of them looks like an obvious attack.
\nVolumetric is the loud one — raw bandwidth, saturating the pipe into your infrastructure before packets even reach your load balancer. Easy to see on a graph, hard to fight without upstream help, because by the time it hits your servers, the damage is already done at the network link.
\nThe clearest real-world case is still GitHub's February 2018 incident: a memcached-reflection attack — abusing publicly exposed memcached servers to amplify traffic roughly 51,000x — peaked at 1.35 Tbps and 126.9 million packets per second, the largest publicly recorded volumetric attack at the time. GitHub.com was fully unavailable for about five minutes and intermittently degraded for a few more, until its network engineers withdrew their normal transit routes and re-announced their address space exclusively through Akamai's scrubbing network. Full recovery: roughly ten minutes after the attack started. Nothing about GitHub's own application code changed in that window — the fix was entirely "reroute through infrastructure built to absorb this," which is exactly why volumetric attacks are the one category edge protection has to handle before it ever reaches you.
\nProtocol attacks target state, not bandwidth — a classic SYN flood opens huge numbers of half-finished TCP connections to exhaust a connection table or a load balancer's backlog. The traffic volume can look almost modest. What's exhausted is capacity to track connections, not capacity to serve them.
\nApplication-layer is the one that should worry you most, because it's the one that looks like your own users. An HTTP flood against a normal-looking endpoint, credential-stuffing traffic dressed up as login attempts, a scraper hammering your search bar — all indistinguishable from real demand until you look at what it's actually doing to your backend. A /search endpoint with no cache and no rate limit doesn't need a botnet to fall over; a few thousand requests a second that all miss cache and hit the database will do it.
![\"The](\"/images/ddos-osi-layers-diagram.svg\")
\n That third category is why "just add more servers" stopped being an answer years ago. You can autoscale in front of an application-layer attack all night — and the attacker gets exactly what they wanted anyway: your cloud bill climbing while real users still time out, because the bottleneck was never compute in the first place.
\nIn production, the same handful of places take the hit, over and over:
\nThat last one is the sneaky part. Two teams can each believe their service is resilient, right up until an attack on Service A saturates a NAT gateway that Service B also depends on, and now B is down too, for reasons its own on-call has no visibility into.
\nThe pattern is usually recognizable, if you're looking at the right slice of data: RPS spiking on a narrow set of endpoints rather than uniformly across the site, p95 latency climbing with no corresponding deploy, 5xx and timeout rates rising, CPU and packet loss climbing together, and load balancer connection counts moving in a way that doesn't match your normal traffic shape.
\n![\"Close-up](\"/images/ddos-monitoring-dashboard.jpg\")
\n The catch is that none of this is visible if your dashboard only shows total RPS. A flood against one endpoint can hide comfortably inside an aggregate number that still looks unremarkable. The fix is cheap: break down traffic by endpoint and status code by default, and by region or ASN when you can, so an anomaly on one path doesn't get averaged away into "traffic's a little high today."
\nNone of this requires exotic tooling — mostly it requires deciding, before an incident, which of these you actually have:
\nAttacks happen to everyone with public infrastructure, eventually. Whether it becomes a five-minute blip or a multi-hour incident usually comes down to a short list of gaps: no CDN or edge layer in front of public traffic, no per-endpoint rate limiting on the requests that are actually expensive, no per-tenant quota so one noisy customer can't starve everyone else, load balancers with connection limits nobody load-tested, and — the quiet killer — no runbook, so the first thirty minutes of a real attack get spent re-discovering things a calmer version of the team already knew.
\nBack to /search at 3:14am. In the version of this story that ends badly, there's no cache, no rate limit, and the runbook is a Slack thread from the last incident that nobody bookmarked. CPU stays pinned, the queue keeps growing, and the fix is improvised live, in production, while users churn.
In the version that ends in twenty minutes: the dashboard already shows the spike is concentrated on one endpoint, a rate limit throttles the offending pattern without touching everyone else, a cache in front of the expensive query buys immediate breathing room, and the runbook says exactly who to loop in if it doesn't resolve on its own.
\nSame attack. The difference was entirely decided before it started.
\n", "date_published": "2026-07-26T00:00:00.000Z", "authors": [ { "name": "The Duke Post" } ], "tags": [ "security", "ddos", "sre", "incident-response", "infrastructure" ], "image": "https://thedukepost.com/_astro/ddos-network-cables-cover.RtbjaqAx_Z1Musu9.webp" }, { "id": "https://thedukepost.com/articles/welcome", "url": "https://thedukepost.com/articles/welcome", "title": "Welcome to The Duke Post", "summary": "What this site is, and how it works.", "content_html": "This is the first post on The Duke Post — a tech publication built on a simple idea: original writing where it matters, and an honest, fast-moving feed of what everyone else is reporting, clearly labeled as such.
\nThere are two kinds of posts on this site:
\nReplace this post with your own first article by editing or deleting this file in src/content/articles/.
The Wire section pulls from a small set of RSS feeds defined in scripts/sync-feeds.mjs. Running npm run sync-feeds fetches the latest items, trims them to a short excerpt, and writes them to src/data/wire.json, which the homepage and Wire page read from at build time.
To keep it current automatically, you can wire the sync script into a scheduled GitHub Action that runs on a cron schedule and commits the refreshed JSON, or trigger a redeploy on your host of choice.
\n", "date_published": "2026-06-19T00:00:00.000Z", "authors": [ { "name": "The Duke Post" } ], "tags": [ "general", "meta", "wire", "rss" ], "image": "https://thedukepost.com/_astro/wire-sync-cover.CBkDzkyA_1fkR7W.svg" } ] }