Coder Legion - Recent posts tagged securityarchitecture#networksecurity

What Is Undefined Behavior (UB) and Why Is It Dangerous?

Mon, 05 Oct 2026 14:29:24 +0000

What Is Undefined Behavior (UB) and Why Is It Dangerous?

In languages like Python or Java, a program either works or throws an error. In C and C++, things are different. Here we have UB — undefined behavior. This is a situation where the language standard does not say what the program should do. And then the compiler can do anything.

What is UB

Undefined behavior is code that is formally allowed for the compiler, but the result is unpredictable. The C standard does not describe what will happen — and the compiler is not required to warn you.

Examples of UB:

Out-of-bounds array access

Division by zero

Dereferencing a NULL pointer

Using an uninitialized variable

Signed integer overflow

Modifying a variable twice in one expression (i = i++)

Why it's dangerous

Unpredictability — the program may work today and break tomorrow

Optimizations — the compiler uses UB to speed up code and breaks logic

Security — UB is a common cause of vulnerabilities

Debugging — UB is hard to find, because the bug doesn't always show up

Example
c

int arr[3];
arr[5] = 10; // out-of-bounds — UB

This may:

work and break nothing

corrupt a neighboring variable

cause a segmentation fault

do literally anything

Why the compiler doesn't save you

The compiler optimizes code assuming that UB does not exist. If UB is present, the optimization can break the logic:
c

int x = 0;
if (x + 1 > x) { ... } // the compiler may remove this check

Because signed integer overflow is UB. So the compiler is allowed to assume it won't happen.

How to avoid UB

Read the standard — know what is allowed

Enable warnings — -Wall -Wextra in GCC

Use sanitizers — -fsanitize=undefined,address

Write carefully — check bounds, pointers, initialization

Use Rust — UB is almost impossible there

Conclusion

UB is not a bug. It's a hole in the standard.
The compiler is not required to catch it.
A program may work for years — and break at the worst possible moment.

Understanding UB is what separates a beginner from a systems programmer.
If you know where your code can become unpredictable, you write reliable code.

Rate Limiting and API Security in Next.js 15 — The Patterns I Actually Use

Wed, 26 Aug 2026 08:33:06 +0000

An API route with no rate limiting works fine right up until someone hits it a thousand times a second, either by accident (a buggy client retry loop) or on purpose. I learned this the annoying way, watching a client's database bill spike because a public form endpoint had no limit on how often it could be called.

Here is what I actually put in place now, on every project with public-facing endpoints.

1. Rate Limiting with Upstash

Upstash's Redis-backed rate limiter works well with Next.js since it is designed for serverless, no persistent connection required between requests.

npm install @upstash/ratelimit @upstash/redis

// lib/ratelimit.ts
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL as string,
  token: process.env.UPSTASH_REDIS_REST_TOKEN as string,
});

export const ratelimit = new Ratelimit({
  redis,
  limiter: Ratelimit.slidingWindow(10, '60 s'),
  analytics: true,
});

slidingWindow(10, '60 s') allows 10 requests per 60 seconds per identifier. Sliding window is generally the better default over a fixed window, since a fixed window lets someone burst right at the boundary between two windows and effectively double their allowed rate.

2. Applying It to a Route Handler

// app/api/contact/route.ts
import { ratelimit } from '@/lib/ratelimit';
import { headers } from 'next/headers';

export async function POST(request: Request) {
  const headersList = await headers();
  const ip = headersList.get('x-forwarded-for') ?? 'unknown';

  const { success, limit, remaining, reset } = await ratelimit.limit(ip);

  if (!success) {
    return Response.json(
      { error: 'Too many requests' },
      {
        status: 429,
        headers: {
          'X-RateLimit-Limit': limit.toString(),
          'X-RateLimit-Remaining': remaining.toString(),
          'X-RateLimit-Reset': reset.toString(),
        },
      }
    );
  }

  const body = await request.json();
  // handle the actual request
  return Response.json({ success: true });
}

Returning the rate limit headers even on success is good practice, it lets well-behaved clients see how close they are to the limit and back off proactively instead of finding out by hitting a 429.

3. Rate Limiting Server Actions

Server Actions do not get the same automatic IP access that route handlers do, since they are not standard HTTP endpoints in the same way. Getting the identifier takes an extra step.

// actions/contact.ts
'use server';
import { ratelimit } from '@/lib/ratelimit';
import { headers } from 'next/headers';

export async function submitContact(formData: FormData) {
  const headersList = await headers();
  const ip = headersList.get('x-forwarded-for') ?? 'unknown';

  const { success } = await ratelimit.limit(`contact_${ip}`);

  if (!success) {
    return { success: false, message: 'Too many attempts, try again shortly' };
  }

  // proceed with validation and saving
  return { success: true, message: 'Message sent' };
}

Prefixing the identifier with contact_ matters if multiple Server Actions share one rate limiter, it keeps each action's usage counted separately instead of one action's traffic eating into another's limit.

4. Rate Limiting by User, Not Just IP

IP-based limiting is the right default for unauthenticated endpoints, like a public contact form. For authenticated actions, limiting by user ID is usually more accurate, since multiple users can share an IP behind the same network, and one user can rotate IPs to dodge an IP-based limit entirely.

// actions/posts.ts
'use server';
import { ratelimit } from '@/lib/ratelimit';
import { getSession } from '@/lib/auth';

export async function createPost(formData: FormData) {
  const session = await getSession();
  if (!session) throw new Error('Not authenticated');

  const { success } = await ratelimit.limit(`create_post_${session.userId}`);

  if (!success) {
    return { success: false, message: 'Slow down, try again in a minute' };
  }

  // proceed
}

5. Validating Input Before It Reaches the Database

Rate limiting controls how often someone can call an endpoint. It says nothing about what they send. Every route handler and Server Action still needs its own validation, same principle covered in the form handling setup, applied specifically at the API boundary here.

// app/api/users/route.ts
import { z } from 'zod';

const CreateUserSchema = z.object({
  name: z.string().min(2).max(50),
  email: z.string().email(),
});

export async function POST(request: Request) {
  const body = await request.json();
  const parsed = CreateUserSchema.safeParse(body);

  if (!parsed.success) {
    return Response.json({ error: 'Invalid input' }, { status: 400 });
  }

  // proceed with parsed.data, never the raw body
}

Never pass the raw request body into a database call. Even with rate limiting in place, an endpoint accepting arbitrary shaped input is still open to malformed data, oversized payloads, or fields that were never meant to be settable from outside.

6. CORS for Public API Routes

If an API route is meant to be called from your own frontend only, restricting CORS prevents other websites from calling it directly from a browser using a visitor's already-authenticated session.

// app/api/data/route.ts
export async function GET(request: Request) {
  const origin = request.headers.get('origin');
  const allowedOrigin = process.env.NEXT_PUBLIC_URL;

  const response = Response.json({ data: 'example' });

  if (origin === allowedOrigin) {
    response.headers.set('Access-Control-Allow-Origin', allowedOrigin);
  }

  return response;
}

This matters specifically for cookie-based auth. Without a CORS restriction, a malicious site could make a request that rides on a logged-in user's cookies, and without a check like this, your API would happily respond as if the request came from your own frontend.

7. Secrets Never Reach the Client

An easy mistake in Next.js specifically, any environment variable prefixed with NEXT_PUBLIC_ gets bundled into client-side JavaScript, visible to anyone who opens dev tools.

// ❌ This leaks the secret into the browser bundle
const apiKey = process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY;

// ✅ Secret keys stay server-only, no NEXT_PUBLIC_ prefix
const apiKey = process.env.STRIPE_SECRET_KEY;

Only prefix an environment variable with NEXT_PUBLIC_ when the value is genuinely meant to be public, a publishable Stripe key, an analytics ID, not an API secret, database URL, or anything meant to stay server-side only.

Summary

Pattern	Protects against
Sliding window rate limit (Upstash)	Endpoint abuse, accidental retry loops, brute force attempts
Per-user rate limiting on authenticated actions	IP rotation and shared-IP inaccuracy
Zod validation at the API boundary	Malformed or unexpected input reaching the database
CORS restriction on cookie-authenticated routes	Cross-site requests riding on a logged-in session
No `NEXT_PUBLIC_` on secrets	API keys and secrets leaking into the client bundle

Rate limiting and validation solve different problems and both matter. Rate limiting controls how often, validation controls what. An endpoint with one but not the other is still exposed, just in a different way.

I put this exact set of protections, rate limiting through Upstash, Zod validation at every boundary, on any public-facing endpoint across the SaaS projects I build.

Get the templates: https://pixelanas.gumroad.com

Have you had an endpoint get hit hard enough to actually need rate limiting in production? Drop it below 👇

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

How to evaluate a small language model on multiple choice without fooling yourself

Fri, 12 Jun 2026 07:42:26 +0000

I spent months building GhostLM, a cybersecurity language model I trained from scratch in PyTorch. The architecture was the easy part. The thing that actually cost me weeks was evaluation. Three separate times, my benchmark told me something that was not true, and each time the bug was in the eval, not the model.

This post is the protocol I wish I had started with. It is not specific to cybersecurity or to GhostLM. If you are evaluating any small model on a multiple-choice benchmark, these are the ways the number lies to you, and how to stop it.

1. Never score the letter. Score the option text.

The obvious way to grade a multiple-choice question is to ask the model for the probability of each letter and take the highest. So for a question with options A through D, you compare log P("A"), log P("B"), and so on.

This is the single most dangerous shortcut in small-model evaluation, because it does not measure reasoning. It measures which letter the model likes.

I had a model scoring 36.9% on a 2,500-question benchmark, comfortably above the 25% random baseline. Then I looked at the gold label distribution:

gold=A: 374 (15.0%)
gold=B: 813 (32.5%)
gold=C: 928 (37.1%)
gold=D: 385 (15.4%)

A model that emits "C" on every single question scores 37.1%. I checked the per-letter accuracy on my "best" checkpoint:

gold=A: 7/374   (1.9%)
gold=B: 0/813   (0.0%)
gold=C: 915/928 (98.6%)
gold=D: 0/385   (0.0%)

The model was not doing cybersecurity reasoning. It had collapsed onto the letter C and was scoring off the label skew. My 36.9% was a measurement of how unbalanced the benchmark was.

The fix is to score the text of each option, not its letter. Instead of comparing log P("C"), compare log P(option_text) under the prompt. Now the model has to actually prefer the correct statement, not the correct position.

2. Debias with multiple permutations.

Text scoring alone is not enough, because a model can still have a positional bias that text scoring does not fully remove. The clean test is to shuffle the option order.

Run each question N times with the options in different orders, and require the model to pick the same correct answer every time. A model that is genuinely reasoning is invariant to order. A model that is secretly emitting one position collapses to random under permutation.

I ran four permutations across all 2,500 questions on every checkpoint. The result was humbling. The checkpoint I had crowned as "canonical" at 36.9% single-order got zero questions correct under all four permutations. A different checkpoint I had dismissed as a failed run got three correct under all four. The single-order ranking was inverted from real capability.

If a number does not survive permutation, it is not a capability, it is an artifact.

3. For classification, subtract the prior (PMI scoring).

If your task is classification (pick the category, the severity, the technique), you will hit a related trap. Score by raw conditional probability and the model will assign its highest probability to the same common label for every input, regardless of the question. Every checkpoint I trained reported exactly the random baseline on my classification eval, which is the signature of a mode-collapsed metric, not a model that cannot learn.

The fix is pointwise mutual information. Instead of scoring log P(label | context), subtract the model's unconditional preference for that label:

pmi_score = log P(label | context) - log P(label)

This cancels out the model's prior bias toward common labels, so a label only wins if the context actually raises its probability. After switching to PMI, my eval could finally tell checkpoints apart instead of flatlining at random.

4. Audit your train/validation split for leakage.

Before you trust any validation number, check how you split the data. I split mine by random shuffle, which sounds fine until you remember that real corpora are repetitive. In my case CVE descriptions repeat the same patterns with slight wording changes, so a random split put near-duplicate records on both sides. The model memorized in training and "validated" on text it had effectively already seen.

My leaky split reported a validation loss of 2.74. After I fixed it the same model on the same recipe reported 3.78. The model did not get worse. The eval got honest.

The fix is deterministic content-hash bucketing, so identical or near-identical text always lands in the same split:

bucket = int(hashlib.sha256(text.encode()).hexdigest(), 16) % 100
split = "val" if bucket < val_pct else "train"

5. Audit for contamination against your training corpus.

A clean split protects you from leakage you created. Contamination is leakage you inherited, when your training corpus happens to overlap with the benchmark's sources.

I checked this with an 8-gram shingle overlap between every benchmark question and my training data. Eleven percent of my benchmark questions had at least one overlap. Interestingly, the contaminated questions scored slightly worse than the clean ones, which told me the overlap was confusing the model rather than helping it, and ruled out the "leakage inflated my score" theory. Either way, you want to know the number before you report anything.

6. Look at per-source perplexity, not just aggregate loss.

Aggregate validation loss hides what the model is actually learning. When I broke perplexity out per source, I could see that one document type (short CVE descriptions, 87% of my tokens) was dominating, and the model had learned exactly one output register and applied it to everything. A CTF prompt produced fake CVE text. A research-paper prompt produced fake CVE text.

A per-source breakdown after every run tells you whether new data is helping or quietly cannibalizing the domains you already had. When I added one large source and watched every other source get 28 to 42% worse, that was the model hitting its capacity ceiling, visible only because the metric was split by source.

7. Test free-form recall, not just multiple choice.

Multiple choice flatters a model because the answer is on the screen. To find out whether the model actually knows anything, ask it open questions and grade by substring match, with disqualifier phrases to catch lucky echoes.

I built a 50-question free-form recall set. The scores were brutal and honest: roughly one correct out of fifty, and even that one was spurious because the model echoed a term from the question. The conclusion was clear and worth more than any benchmark percentage. My models had absorbed the vocabulary and register of the domain but not the facts. They were fluent parrots. That is a useful thing to know about a small model, and multiple choice will never tell you.

The meta-lesson

At small scale, benchmark quality compounds more than model quality. Every one of my real improvements came from fixing the eval, not the model. Fixing the leaky split alone changed a perplexity number by more than 14x with zero extra training. Fixing the letter-scoring bug revealed that months of ablations had been optimizing positional bias instead of capability.

So the protocol, short version:

Score option text, never the letter.
Require the answer to survive multiple option permutations.
Use PMI scoring for classification so common labels do not win by default.
Split by content hash so the validation set is honest.
Shingle-check the benchmark against your training corpus for contamination.
Break perplexity out by source.
Test free-form recall to separate register from knowledge.

None of this is expensive. The permutation test is about twenty lines of Python. The contamination check is similar. The reason these bugs survive long enough to get into published numbers is not that they are hard to catch, it is that people rarely audit the benchmark before trusting it. Audit it first.

The full harness I built while finding these bugs is open source, including the multi-permutation text scorer, the free-form recall grader, and the contamination checker.

GitHub: https://github.com/joemunene-by/GhostLM

I thought my LLM hit 36.9% on a cybersecurity benchmark. It was picking C every time.

Mon, 11 May 2026 08:17:18 +0000

I've been building GhostLM — a decoder-only transformer trained from scratch in PyTorch on cybersecurity data. No pretrained weights, every component hand-written. A few weeks ago I published a post about fixing a leaky train/val split that made my model look 14x better than it was.
I just found a second bug. This one made the benchmark itself look meaningful.
The 36.9% that wasn't
After months of training, I had a chat-tuned model hitting 36.9% on CTIBench MCQ — a 2,500-question cybersecurity multiple-choice benchmark. That's above random (25%) and I was running ablations trying to reproduce and beat it.
Then I checked the gold label distribution.
gold=A: 374 (15.0%)
gold=B: 813 (32.5%)
gold=C: 928 (37.1%) ← skewed
gold=D: 385 (15.4%)
A model that always picks C scores 37.1%. Higher than my "best" result.
I ran a quick diagnostic on the canonical checkpoint. Per-letter accuracy:
gold=A: 7/374 (1.9%)
gold=B: 0/813 (0.0%)
gold=C: 915/928 (98.6%)
gold=D: 0/385 (0.0%)
The model wasn't doing cybersecurity reasoning. It was emitting C on every question and scoring off the label distribution.
The permutation test
The correct eval is multi-permutation text scoring. Instead of scoring log P("C" | prompt), score log P(option_text | prompt) under N different option orderings. A pure C-emitter collapses to 25% random under this metric regardless of label distribution.
I ran 4 option permutations × 2,500 questions across every checkpoint:
Modelsingle-orderdebiasedall-perm correctchat-v3 "canonical"36.9%30.5%0/2500chat-v3 repro231.2%31.7%3/2500chat-v0629.8%31.2%0/2500
The model I'd dismissed as a "failed reproduction" (31.2% single-order) answered 3 questions correctly under all permutations. The "canonical" answered zero. The single-order ranking is inverted from real capability.
I also found that the bias letter depends on the base checkpoint, not the SFT recipe. v0.4 base learned to emit C. v0.6 base learned to emit B. v0.6 hybrid learned to emit A and scored 37.1% under a different permutation — same trick, different letter.
What the models actually know
After switching to text scoring, every checkpoint clustered at 27-29% on the full 2,500-question bench — roughly 4 points above random. I also built a 50-question free-form fact recall set with substring grading:

v0.4 chat: 0/50
v0.7 chat: 1/50 (spurious — "Injection" appeared in tangent prose)
v0.9 chat: 1/50 (spurious — echoed "SHA-256" from the question)

The models have absorbed the register and vocabulary of cybersecurity writing. They do not know the facts. EternalBlue gets a wrong CVE. MITRE technique IDs get conflated. The model is a cybersec parrot.
Contamination audit
After discovering v0.9 was trained on PRIMUS corpus that overlaps with CTIBench sources, I ran an 8-gram shingle overlap check. 11% of CTIBench questions have at least one overlap with the training corpus. The contaminated questions score 2.2pp lower than clean ones — contamination is confusing the model, not helping it. This rules out the leakage-helps hypothesis and points to register-shift as the explanation.
What I built while diagnosing this
The diagnosis forced me to build better infrastructure:

eval_text_scoring.py — multi-permutation text scoring, works on any MCQ JSONL
eval_fact_recall_v2.py — free-form fact recall with boundary matching and disqualifier phrases
audit_ctibench_contamination.py — shingle overlap checker
GhostBench — a packaged eval suite with Wilson 95% CIs, McNemar's tests, forest plots, scaling-law projections. Can evaluate any small open LM, not just GhostLM.

I also published the fact-recall benchmark as a HuggingFace dataset: Ghostgim/cybersec-fact-recall.
The actual bottleneck
The RAG diagnostic told the story clearly:
MetricScoreRetrieval@4 (no LM)41/100v0.9 bare1/100v0.9 + RAG0/100
The retriever surfaces the right passage 41% of the time. The 81M model extracts the fact 1% of the time. Adding retrieved context destabilizes the model into repetition loops. The bottleneck is generation capacity, not retrieval. Parameter scaling is the answer.
SmolLM2-360M and Phi-3.5-mini both show factual recall emerging around 300-400M params. Ghost-base (~360M) is the next rung, gated on GPU compute.
What I actually learned
Benchmark quality compounds more than model quality at small scale. Fixing the eval methodology revealed I'd been chasing a number that was measuring positional bias, not capability. Months of ablations were optimizing the wrong objective.
The correct eval protocol for MCQ at small scale: text scoring + multi-permutation debiasing. Single-order letter scoring is uninterpretable on any benchmark with skewed gold label distribution.
The 30% real ceiling across every architecture, BPE, SFT objective, and corpus density I tried is the clearest result I have. It's reproducible, it's controlled, and it tells me exactly what the next experiment needs to be.
GitHub: https://github.com/joemunene-by/GhostLM
Eval harness: scripts/eval_text_scoring.py
Fact-recall dataset: huggingface.co/datasets/Ghostgim/cybersec-fact-recall

Building & Staying Secure as a Solo Developer (Text Seminar)

Sun, 11 Jan 2026 13:44:59 +0000

This post is written in a seminar-style format.

You can read it quietly, pause, reflect, and come back.
No rush. No performance.

Welcome

Hi, I’m Prasoon Jadon, a solo builder working on tools, open-source projects, and security awareness under Vyoma.

This article is part of VSAP — Vyoma Security Awareness Program.

The goal is simple:

Help developers stay secure while building publicly.

Why This Matters

As developers, we:

Push code publicly
Share progress online
Build in open communities

This is powerful — but it also creates attack surfaces we often ignore.

Security is not paranoia.
Security is awareness.

1️⃣ Public Repositories Are Not Safe by Default

One of the most common mistakes I see:

Treating public repositories as harmless.

Never commit:

API keys
Tokens
.env files
Internal URLs

Even if you delete them later, history remains.

Habit to build:
Always assume your code will be read by strangers.

2️⃣ OSINT Works Both Ways

OSINT (Open-Source Intelligence) means:

Collecting information from publicly available sources.

Developers unknowingly leak:

Email addresses
GitHub activity patterns
Tech stack details
Location hints

If you can research companies using OSINT,
someone can research you the same way.

Question to reflect on:
What can someone learn about me in 10 minutes online?

3️⃣ Security Is a Habit, Not a Tool

Many developers ask:

“Which security tool should I use?”

The honest answer:
Tools help, but habits protect.

Core habits:

Unique passwords
Password managers
Regular updates
Minimal permissions
Thinking before sharing

Most breaches happen due to human habits, not missing tools.

4️⃣ Building in Public ≠ Oversharing

Building in public is great.
Oversharing is risky.

You don’t need to share:

Exact infrastructure details
Internal logic
Sensitive architecture diagrams

Rule of thumb:
Share learnings, not weaknesses.

5️⃣ Calm Security > Fear-Based Security

Security content often relies on fear.

VSAP focuses on:

Awareness over panic
Habits over hacks
Calm learning

Security should empower you, not scare you.

Open Reflection

If this were a live text seminar, I’d ask:

What security mistake taught you the most?
What’s one habit you want to improve?
What topic should the next session cover?

You can reflect privately or share in comments.

Closing Thoughts

This article is not about being perfect.
It’s about being a little more aware than yesterday.

I’m experimenting with:

Text-based seminars
Calm developer communities
Community-first growth under Vyoma

If this style resonates, more sessions will follow.

Thanks for reading quietly
— Prasoon Jadon
Founder, Vyoma

How We Solved “Unable to Get Certificate CRL” in Rails: A Debugging Story

Thu, 13 Nov 2025 11:53:55 +0000

If you’ve been around Rails long enough, you’ve probably battled your fair share of SSL demons. But this one? This one had personality.

It was a Seahorse::Client::NetworkingError that failed only on macOS — yet worked perfectly inside Docker. The kind of “it works on my container” bug that makes you question every life choice leading up to this point.

So here’s the story of how we chased down a ghostly SSL error, only to discover that the real culprit was… OpenSSL itself.

⚠️ The Error

Seahorse::Client::NetworkingError
SSL_connect returned=1 errno=0 peeraddr=[...]
state=error: certificate verify failed (unable to get certificate CRL)

This popped up whenever our Rails app tried connecting to AWS S3 using the aws-sdk-ruby gem.

The Contradiction That Made No Sense

From the get-go, the bug refused to play by any rules of logic.

❌ It failed locally but
✅ Worked flawlessly in Docker

That told us one thing: the problem wasn’t our code. It was the environment. macOS and Docker’s Linux setup were behaving differently.

The “Wait, What?” Moment

We decided to test the SSL connection manually, expecting it to fail the same way:

openssl s_client -connect 52.219.66.109:443 -servername s3.ap-south-1.amazonaws.com < /dev/null

Result?

Verify return code: 0 (ok)

So, macOS’s OpenSSL tool had no problem verifying the certificate. But Rails (and the AWS SDK) still choked on it.

At this point, confusion levels were high. Coffee consumption was higher.

The Real Test — Inside the Rails Console

To rule out any system-level differences, we went straight into rails c:

require 'aws-sdk-s3'
s3 = Aws::S3::Client.new(region: 'ap-south-1')
s3.list_buckets

Result:

certificate verify failed (unable to get certificate CRL)

Boom. So the system OpenSSL was fine, but Ruby’s built-in OpenSSL (via Net::HTTP) was throwing a tantrum.

The Root Cause — A Policy Change in OpenSSL

That cryptic message — “unable to get certificate CRL” — turned out to be the key.

A CRL (Certificate Revocation List) is basically a “blacklist” for certificates that have been revoked. The problem? The AWS certificate didn’t actually have a CRL defined.

We checked with:

openssl s_client ... | openssl x509 -noout -text | grep "CRL Distribution Points"

Result:

X509v3 CRL Distribution Points:
# (empty)

Comparing environments made things click:

Environment	OpenSSL Version	Result
macOS (failing)	3.4.0 (new)	❌ Fails
Docker (working)	3.0.11 (stable)	✅ Works

Turns out, OpenSSL 3.4.0 introduced stricter validation rules. It now treats missing CRL entries as fatal errors — whereas the 3.0.x series simply shrugged and moved on.

So no, your Mac isn’t broken — it’s just being too helpful.

The Fixes — Two Paths to Sanity

After a lot of trial (and some error), we landed on two solid fixes.

Fix 1: The Local-Only (Insecure but Practical) Workaround

Since this issue only showed up in development, one quick way to move on is to tell AWS SDK to skip SSL verification locally.

Create: config/initializers/aws_ssl_workaround.rb

# WARNING: LOCAL DEVELOPMENT ONLY
# OpenSSL 3.4.0 enforces stricter CRL policies, so skip verification here.
if Rails.env.development?
  Aws.config.update(ssl_verify_peer: false)
end

✅ Pros:

Works instantly
Doesn’t affect production

⚠️ Cons:

Insecure (but fine for local development)

Fix 2: Match Environments (I tried this one!)

The better long-term solution is to make your local OpenSSL match Docker’s version.

Install an older OpenSSL (3.0.x):
```
brew install openssl@3.0
```

Reinstall Ruby:

rbenv uninstall 3.2.2
RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl@3.0)" rbenv install 3.2.2

Reinstall gems:
```
gem install bundler
bundle install
```

Now your local Ruby is linked against OpenSSL 3.0 — just like Docker and peace is restored.

Confirmation & References

Turns out, we weren’t the only ones haunted by this ghost:

openssl/openssl#28758 — CRL verification failures in OpenSSL 3.6.0
ruby/openssl#949 — Net::HTTP failing due to stricter CRL rules

Takeaway

SSL errors can feel like black magic, but more often than not, they’re version mismatches in disguise.

So next time something works in Docker but not on your laptop, remember: sometimes it’s not your code, it’s just your OpenSSL being extra.

Thanks for reading! If you found this helpful, share it with a fellow developer who’s currently staring at an SSL error and losing their mind.

How a VPN Works: A Technical Mind Map

Tue, 14 Oct 2025 11:08:24 +0000

TLDR; client -> server -> internet -> server -> client

A while ago a classmate told me he had built a VPN in Java for his final project and I found it very interesting. Too interesting in fact to leave the idea alone.

I found that I really didn't know what a VPN really was even though I had used it so many times. So this article is a technical mind map of what I found. I will be exposing my approach to thinking about the technology itself and the questions I asked myself. Right now, there are two layers of understanding to this for me. I will update these layers when I found out more things. The first layer is the conceptual overview of how a VPN works. The second layer is more architectural, so if you wanted to build one yourself how would you do it? That's the question the second layer answers. So let's dive right in.

The Conceptual Overview: What is a VPN?

A VPN stands for Virtual Private Network. Taking each word apart from the rear, we can easily tell there's network engineering involved, then some cybersecurity, and finally, it's virtualized as in a logical rather than physical thing. In software engineering, 'virtualized' generally means it's replicating some hardware function on software. So what does it do really?

Simply put, it allows you to access a network (whether LAN or WAN) securely over the internet. Access and Securely being the two most important words there. The typical example you'd find is of an office. Let's assume this office runs an intranet, so things like the official communication channel, files, etc., are hosted on a physical server that is within the office premises. Whenever you're in the office, you can access these services just by typing the IP address (or domain name) in your browser or looking through the networks tab of your file explorer. This is because you are connected to the very same network as the servers that host these things and you probably have network discovery turned on on your work device.

Now whenever you are outside the office, you cannot access these services and documents because you are no longer within the same local network. But if your office connects these servers to the internet, and you are also connected to the internet where you are, then by design you should be able to make a request across the internet to your office servers and they should be able to respond. So what's the problem here? Well, if it's over the public internet that you make these requests, then technically it's open for everyone to see, and your work information flying over the airways can be sniffed and potentially stolen. By extension, the data could have easily been your banking information, passwords, personal identification details, and other very important and very personal data. A solution to this is a VPN. This brings us to the question the first layer answers, which is, aside from the acronym, what is a VPN?

If you google this question, you'd most likely see something along the lines of a VPN is a secure encrypted tunnel that protects your internet traffic, masks your IP address, and some other amazing things. So following from the scenario above, when you turn on your VPN on your work device, your internet traffic is suddenly no more open, visible, or accessible to the public internet. It encrypts your traffic from your device, and when it gets to the VPN server, it is decrypted and then forwarded to the internet or the services you want to access.

This VPN tunnel would have two parts: the VPN client on your device and the VPN server at the other end. The server waits for connections from the client so that it can make requests to the internet on behalf of the client and then send the results back. As a side effect, your IP address is also changed, which makes it look like you're in another country. If your requests/internet traffic is not encrypted (and tunnelled) then this is merely a proxy server. You request is just bouncing off of another server before it goes to the internet. But when you have a proxy plus encryption (and tunnelling) then congrats, you have a VPN.

The Architectural Layer: Building Your Own VPN

Now on to the second question: if I wanted to build my own VPN, how would I do it? You might think it's difficult on the surface, and you would be right to think that, but once you get the core things figured out, the components stack nicely on top of each other to give you the desired result. At this point, you already know you would need two things: the VPN server and the VPN client. These two things are software you can write in any programming language of your choice.

A VPN has three core components and one extra component that wraps everything together:

A Virtual Network Adapter (the tunnel)
Transport
Encryption

The last thing that wraps everything together are just the headaches (essential security and management mechanisms) that keep the whole thing super secure, like auth handshakes, pre-shared keys, keep-alive requests, session management etc. These things are peripherals but they help run a tight ship in terms of a VPN service. We would start building from the perspective of the VPN client. So let's break it down.

The Virtual Network Adapter (TUN/TAP)

I'll explain it this way: growing up, I used to play Blur on LAN parties with my friends. We connected everyone with ethernet cables and could share files because we were all connected to the same network. This kind of connection is made when you plug an ethernet cable into your computer. The cable speaks to the Network Adapter hardware, your NIC (Network Interface Card).

A virtual network adapter is software that mimics the behaviour of being physically plugged in to a network. Note that when you're plugged into a network, all the requests you make go through your physical network adapter. This is the exact same concept with your virtual network adapter, but you can choose what kind of traffic passes through it. It could be all internet traffic or just some.

In a bit more detail, when you turn on the VPN service, it creates this virtual network adapter, which can be read and written to like a file descriptor. You will find it referred to as a TUN/TAP interface. If you choose for all internet traffic to go to this virtual interface then when you request for a page in your browser, the browser passes the request to the OS to pass to it's network stack but then the OS sees your virtual network adapter and then writes the users request to your virtual network adapter instead. So in your VPN program you can read this request and chose what to do with it. This has now gotten us to the transport section.

Transport, Encryption, and Encapsulation

VPNs usually send encrypted traffic over the internet and there are a number of protocols by which devices talk to one another over the internet. You need to pick one to use (heck you could write your own protocol too!). But generally speaking, TCP and UDP are common transport protocols when it comes to transport with VPNs. Both come with their own headaches so research the best one for your use case. I particularly like UDP because of its statelessness which could be a pro or a con depending on how you look at it.

The transport effectively establishes a way to communicate with the VPN server so you can send the user's request that you have read from your virtual network adapter.

Before you send the request, you need to process it. This is where the encryption and encapsulation come in. You can encrypt the entire package with pre-shared keys or whatever type of encryption you deem fit. The encapsulation typically includes slapping on some new request headers to the encrypted data.

The VPN Server

Okay, the VPN client is able to send encrypted packets over to the server, so now we shift our focus to the server.

The first thing we want to do is to setup our transport in order to receive the packets. If you used UDP on the client then you'd need to setup a UDP server on the VPN server so that the UDP client on the VPN client can connect to it and send those packets in the first place. You might decide to use TCP and the flow would be the exact same. There has to be a way for the packets to reach the server because this is your entry point.

At this point you might want to setup some of those headaches that we talked about previously so that not just anybody can connect to your server. Establishing a proper peer system would do some good here so only verified peers can send requests in the first place. Every other type of request should be ignored. Your VPN server itself should be a secure machine (you can check here to see steps on how to get to the minimum security any server should have).

After receiving the packets securely, the next step would be to decrypt them and forward them to the internet. You already know what we're about to do here. If you guessed that we would create a virtual network adapter (TUN/TAP) on the VPN server then you are 100% correct. We do this because the same way we can read from it on the client we can write to it so that the OS picks it up and sends it to its networking stack and makes the request for us.

When the OS gets the response from the internet, it writes the packets back to the virtual network adapter and we can read this response and send it back the way the request came. Finally the VPN client sees this response from the VPN server and sends it to its own virtual network adapter on the client device which then passes it to the user's OS and finally the OS passes it to the browser and the user sees the response.

Congratulations you now have a VPN, it seems like a long journey but it happens pretty fast (when implemented without unnecessary latency from bad code). Now since the real device that makes the request to the internet is the VPN server this whole concept has the effect of masking a user's real IP address. If you are thinking of implementing a VPN you should really checkout the WireGuard protocol. VPN protocols are opinionated ways of doing this whole thing, they give you a recipe to follow for the primary steps and even the headaches (sessions/auth/handshakes, etc).

This is my current mind map of how a VPN works on a technical level. I am open to comments, contributions, or questions.

Cover Photo Credit: Illustration by Slimane-Kadi on Unsplash

67% of zero trust implementations fail due to partial zero trust execution.

Fri, 15 Aug 2025 20:27:00 +0000

Zero Trust Reality Check: Why Implementation Failures Are Creating False Security

Meta Description (150 chars): 67% of zero trust implementations fail due to incomplete execution. Learn why partial zero trust creates more vulnerabilities than traditional security.

Zero Trust has become the cybersecurity equivalent of a miracle diet—everyone claims to be doing it, but most implementations fall short of delivering promised results. Research presented at Black Hat 2025 reveals that incomplete Zero Trust deployments often create more vulnerabilities than the traditional perimeter-based security they're meant to replace.

The Implementation Gap

Chuck Herrin, Field CTO at F5, shared during Black Hat that he has observed this pattern across hundreds of enterprise deployments: "Organizations think they're doing Zero Trust because they've implemented multifactor authentication and network segmentation. But Zero Trust is about complete verification of every transaction, not just adding more security layers."

F5's research across their customer base shows that 67% of Zero Trust initiatives fail to achieve their intended security outcomes due to incomplete implementation, creating what Herrin calls "Zero Trust theater."

The "Checkbox Zero Trust" Problem

Many organizations approach Zero Trust as a compliance exercise rather than a fundamental security transformation:

Partial MFA Deployment: Implementing multifactor authentication for some applications while leaving others unprotected
Incomplete Network Segmentation: Creating isolated network zones without proper access controls between them
Identity Washing: Rebranding existing identity management solutions as "Zero Trust" without architectural changes
Vendor Confusion: Believing that purchasing "Zero Trust" products automatically delivers Zero Trust architecture

The False Security Paradox

Incomplete Zero Trust implementations can actually increase risk by creating a false sense of security. Herrin explained: "When you implement pieces of Zero Trust without the full architecture, you often create new attack paths while believing you've eliminated old ones."

Common failure patterns include:

Trust Assumptions: Assuming that verified identities don't need continuous monitoring
Network Blind Spots: Creating secure zones that lack internal visibility
Application Gaps: Protecting modern applications while leaving legacy systems exposed
Device Inconsistency: Managing corporate devices while ignoring BYOD risks

The Continuous Verification Challenge

True Zero Trust requires continuous verification of every transaction, but most organizations struggle with the operational overhead this creates. F5's customer data shows that organizations successfully implementing Zero Trust typically see:

40% increase in initial security operations workload
60% reduction in successful breach attempts
25% improvement in incident response times after full implementation
35% reduction in overall security management complexity once mature

AI as a Zero Trust Accelerator

Artificial intelligence is emerging as a critical enabler for practical Zero Trust implementation:

Automated Policy Generation: AI can analyze traffic patterns and automatically generate appropriate access policies
Behavioral Analysis: Machine learning models can establish baselines and identify anomalous behavior requiring additional verification
Risk-Based Authentication: AI can dynamically adjust authentication requirements based on real-time risk assessment
Continuous Monitoring: AI enables the constant verification that Zero Trust requires without overwhelming security teams

The Platform Approach

Herrin advocates for platform-based Zero Trust implementation rather than point solution assembly: "Organizations that succeed with Zero Trust treat it as an architectural transformation, not a product deployment. They build platforms that enable Zero Trust principles rather than buying Zero Trust products."

F5's approach focuses on:

Application-Centric Security: Protecting applications regardless of where they're deployed
Identity-Aware Networking: Making every network decision based on verified identity
Continuous Risk Assessment: Dynamically adjusting security controls based on real-time risk
Simplified Operations: Reducing complexity through automation and integration

Real-World Success Patterns

Organizations successfully implementing Zero Trust typically follow a phased approach:

Phase 1: Identity Foundation (3-6 months)

Implement comprehensive identity management
Deploy MFA across all applications
Establish identity governance processes

Phase 2: Network Transformation (6-12 months)

Implement micro-segmentation
Deploy identity-aware network controls
Eliminate VPN dependencies

Phase 3: Application Protection (12-18 months)

Protect all applications with identity-aware proxies
Implement continuous application monitoring
Deploy adaptive access controls

Phase 4: Continuous Optimization (Ongoing)

Leverage AI for automated policy optimization
Implement advanced behavioral analytics
Continuously refine security postures

Common Implementation Mistakes

Herrin has identified recurring patterns in failed Zero Trust implementations:

Technology-First Approach: Focusing on tools rather than architecture
Incomplete Discovery: Not understanding all assets and data flows before implementation
User Experience Neglect: Implementing security that significantly impacts productivity
Vendor Lock-In: Choosing solutions that don't integrate with existing infrastructure
Training Inadequacy: Failing to prepare security teams for operational changes

The Business Case for Complete Zero Trust

Organizations with mature Zero Trust implementations report significant business benefits:

Reduced Breach Impact: Average breach costs drop by 45% compared to traditional security
Improved Compliance: Simplified audit processes and continuous compliance validation
Enhanced Productivity: Secure access to applications from any location or device
Operational Efficiency: Reduced security management overhead through automation

Strategic Recommendations

Start with Architecture: Design Zero Trust architecture before selecting technologies
Prioritize User Experience: Ensure security improvements don't hinder productivity
Leverage AI: Use artificial intelligence to manage the complexity of continuous verification
Plan for Integration: Choose solutions that work with existing infrastructure
Invest in Training: Prepare security teams for operational changes

The Future of Zero Trust

As cyber threats continue evolving, Zero Trust will become less of a strategic choice and more of a business necessity. Organizations that implement comprehensive Zero Trust architectures will be better positioned to handle sophisticated attacks, while those pursuing incomplete implementations will face increasing risks.

Herrin's conclusion resonates throughout the industry: "Zero Trust isn't a destination—it's a continuous journey of verification and improvement. Organizations that understand this will thrive. Those that treat it as a checkbox exercise will fail."