DEV Community: Labeeb Ahmad

Lessons from the Axios Hack

Labeeb Ahmad — Wed, 01 Apr 2026 07:52:01 +0000

Last week, the popular axios library was compromised. A maintainer’s npm account was stolen, and two malicious versions were published for a few hours. Anyone who ran npm install during that window automatically pulled in malware that stole credentials and keys.

Why did so many people get hit? Because most dependencies are written with a caret:

"axios": "^1.14.0"

That caret means “get the latest minor or patch version.” When the malicious 1.14.1 came out, every npm install grabbed it without asking.

The fix is simple: pin exact versions.

"axios": "1.14.0"

Now your project never upgrades unless you manually change the number.

What about package-lock.json? A lock file records what was installed at a specific time. If yours was created before the attack, you were safe. But if you regenerated it during the attack window, it would have locked in the bad version. So a lock file helps, but it’s not a substitute for pinning.

When you do upgrade:

Wait a few days after a new release.
Check GitHub issues and advisories.
Use npm audit before updating.

One more thing: AI assistants often suggest npm install commands without knowing about today’s security incidents. Take a second to verify the version you’re about to install.

Pin exact versions. Upgrade deliberately. It’s a small habit that stops attacks like this.

TLS Handshake Explained: How HTTPS Actually Works

Labeeb Ahmad — Mon, 30 Mar 2026 18:51:03 +0000

When you type https:// into your browser, a lot happens before you see the webpage. HTTPS is not a separate protocol. It is simply HTTP (the web protocol) running inside a TLS security tunnel that is carried over TCP (the reliable transport). This article walks through each layer, explains the TLS handshake, and shows how certificates are verified.

The Foundation: TCP

TCP (Transmission Control Protocol) is the workhorse that delivers data reliably between two machines. Before any application data can be sent, the client and server perform a three‑way handshake:

SYN client says “I want to connect.”
SYN‑ACK server agrees.
ACK client confirms.

After this, a bidirectional, ordered, error‑checked channel exists. TCP does not encrypt anything; it just moves bytes.

The Security Layer: TLS

TLS (Transport Layer Security) is a protocol that runs on top of TCP. Its job is to turn the plain TCP pipe into an encrypted, authenticated, and integrity‑protected tunnel. The process of setting up this tunnel is called the TLS handshake.

What the Handshake Achieves

Negotiation: client and server agree on a TLS version and cipher suite.
Authentication: the server proves its identity using a digital certificate.
Key exchange: both sides create a shared secret that only they know.
Verification: they confirm that the handshake wasn’t tampered with.

Simplified Handshake Steps

The following diagram shows the messages exchanged. Note that the first three messages happen over the already‑established TCP connection.

ClientHello – client sends supported TLS versions, cipher suites, and a random number.
ServerHello – server picks a version and cipher suite, sends its own random number.
Certificate – server sends its certificate (contains its long‑term public key, domain, and a CA signature).
ServerKeyExchange – server sends an ephemeral (temporary) public key, signed with its long‑term private key.
ClientKeyExchange – client sends its ephemeral public key.
ChangeCipherSpec – signals that subsequent messages will be encrypted.
Finished – both sides send an encrypted hash of the handshake to confirm it was not tampered with.

After the handshake, the actual HTTP data is sent inside encrypted TLS records.

The Purpose of ChangeCipherSpec

The ChangeCipherSpec message is a simple indicator that tells the other side: “From this point forward, I will encrypt all messages using the session keys we just agreed on.” It synchronises the encryption state. The Finished message that follows is the first encrypted message; it includes a hash of the entire handshake, allowing both sides to verify that no one tampered with the handshake.

How the Browser Verifies a Certificate

When the server sends its certificate, the browser must decide whether to trust it. It does not contact the Certificate Authority (CA) for every connection. Instead, it performs these checks:

Chain of trust – The server’s certificate is usually not directly signed by a root CA. Instead, it’s signed by an intermediate CA, which is signed by a root CA. The server sends the full chain (its certificate + intermediates). The browser checks that each certificate in the chain is valid and that the root CA is in its trust store (a pre‑installed list of trusted root certificates that comes with the operating system or browser).
Digital signature verification – Using the public key of the root CA (which is pre‑trusted), the browser verifies the signature on the intermediate certificate. Then, using the intermediate’s public key, it verifies the signature on the server’s certificate. If the signatures match, the browser knows that the server’s public key is vouched for by a trusted CA.
Domain name – the certificate’s Subject Alternative Name (SAN) or Common Name must match the domain in the URL.
Expiration – the certificate must be valid now.
Revocation (optional) – the browser may check with the CA to see if the certificate has been revoked before its expiration.

If all checks pass, the browser accepts the server’s public key as authentic. If any check fails, the browser shows a security warning.

This process happens entirely on the client side—no live call to the CA is required for the basic signature verification, because the root CA’s public key is already trusted and stored locally.

Where Do the Private Keys Come From?

Browser (client): For each new connection, the browser generates a temporary (ephemeral) private key entirely in memory. This key is used only during the handshake to compute the shared secret, then discarded. It is never transmitted.
Server: The server also generates a temporary ephemeral private key for each session. This key is used together with the browser’s ephemeral public key to compute the shared secret. In addition, the server has a long‑term private key that corresponds to the public key inside its TLS certificate. This long‑term key is never used for encryption; it is used only to digitally sign the server’s ephemeral public key during the handshake, proving that the ephemeral key belongs to the legitimate server.

The diagram below shows the flow from ephemeral keys to the symmetric session keys that actually encrypt the HTTP data:

How is the actual HTTP data encrypted? From the shared secret derived during the handshake, both sides independently generate symmetric session keys (the same keys on both ends). These symmetric keys are used to encrypt and decrypt all HTTP traffic. The ephemeral private keys and the server’s long‑term private key are never used to encrypt or decrypt the web content itself.

Why forward secrecy? Because the shared secret is derived solely from the ephemeral key pair, the long‑term private key is only used for signing. Even if an attacker later steals the server’s long‑term private key, they cannot decrypt past sessions, the ephemeral keys used for those sessions are gone. This is forward secrecy.

The Application Layer: HTTP

HTTP (Hypertext Transfer Protocol) is the language of the web requests like GET /index.html and responses with status codes and content. In HTTPS, HTTP messages are never sent in the clear over the network; they are placed inside the encrypted TLS tunnel.

Putting It Together: HTTPS

HTTPS is not a separate protocol; it’s a URI scheme that tells the client: "Use HTTP, but wrap it in TLS over TCP." The formal description is HTTP over TLS over TCP.

So when you see a padlock in your browser, you know the stack is:

HTTP
│
TLS (encryption + authentication)
│
TCP (reliable transport)

Summary

TCP provides reliable transport.
TLS adds encryption, authentication, and integrity on top of TCP.
HTTP is the application protocol that runs inside the TLS tunnel.
HTTPS is simply HTTP over TLS over TCP – a scheme, not a separate protocol.
The TLS handshake negotiates parameters, authenticates the server, establishes ephemeral keys, and confirms the connection.
Certificates are verified by building a chain of trust to a pre‑trusted root CA.
Forward secrecy ensures that past sessions cannot be decrypted even if the server’s long‑term private key is later stolen.
Asymmetric encryption is used only during the handshake; symmetric encryption protects the actual HTTP data.
Understanding this stack helps you debug connection issues, configure TLS termination correctly, and build secure systems with confidence.

The Hidden Cost of Letting AI Write Your Code

Labeeb Ahmad — Sun, 29 Mar 2026 17:07:30 +0000

There’s a comfortable lie going around. AI coding tools let you move faster, ship more, worry less. Just describe what you want, review what comes out, and get on with your life.

That’s not wrong. But it’s incomplete in a way that’s going to bite a lot of people.

Abstractions Always Leak

Every abstraction, no matter how elegant, eventually exposes the messy reality it was trying to hide. AI-assisted coding is an abstraction. A powerful one. But it leaks.

At some point and this comes faster than people expect, you’ll hit a bug the AI can’t explain, a performance problem it can’t diagnose, or a design decision that’s quietly poisoning your system. When that moment arrives, you can’t prompt your way out. You have to think. Not the fast kind. The slow, meticulous, System-2(i.e., the slow brain) kind.

That bottleneck doesn’t disappear because the AI wrote the code. It just gets deferred.

You Can’t Build a Mental Model You Never Had to Build

When you write code from scratch, you’re making decisions, hitting friction, asking why. That friction is annoying. It’s also how understanding gets encoded.

With AI-generated code, you get output that works, enough to pass tests, enough to ship. And because it works, there’s no obvious reason to dig deeper. You never built the model. You never had to hold the abstraction in your head long enough for it to become intuition.

This shows up later when you can’t reason about the system under load, don’t know which parts are fragile, and can’t make confident decisions about what to change. You’re maintaining code you don’t really understand, except this time, you wrote it.

So What Do You Do?

Read the code the AI generates, actually trace it, not just skim it. When something isn’t clear, that’s exactly the moment to slow down, not move on.

The best developers using these tools aren’t the ones who trust them most. They’re the ones who know exactly when to stop trusting them. You have to question the output generated by these tools.

Finding Slow Queries in PostgreSQL (Without Guessing)

Labeeb Ahmad — Sat, 28 Mar 2026 02:34:47 +0000

Here’s the quantitative method used by DBAs and tools like pganalyze and AWS Performance Insights.

Connect to your database and create the extension:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Then tell PostgreSQL to load it at startup. The easiest way is with ALTER SYSTEM (no need to edit config files):

ALTER SYSTEM SET shared_preload_libraries = 'pg_stat_statements';

Now restart PostgreSQL. If you’re using Docker:

docker restart <your-pg-container-name>

The extension now tracks every query, grouping similar ones together.

Find the Queries That Cost the Most

After the restart, run some queries so the extension collects data. Then run:

SELECT 
    query,
    calls,
    round(total_exec_time::numeric, 2) AS total_ms,
    round(mean_exec_time::numeric, 2) AS avg_ms,
    round((100 * total_exec_time::numeric / 
          sum(total_exec_time::numeric) OVER ())::numeric, 2) AS pct_of_total
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

The pct_of_total column shows what percentage of your database’s total execution time that query pattern represents. If a query shows 50% there, optimizing it could cut your database load in half.

Note: pg_stat_statements accumulates data until reset. To get fresh trends, reset with SELECT pg_stat_statements_reset(); before measuring.

Decide How to Fix It

Look at the avg_ms column:

If avg_ms is high (e.g., >100ms), the query itself is slow. Use EXPLAIN ANALYZE to find missing indexes or inefficient joins.
If avg_ms is low but calls is huge, the query is cheap per call but called too often. Reduce calls via caching, batching, or fixing N+1 queries.

Your threshold for "high" depends on your app's latency requirements & context.

No more guessing. With **pg_stat_statements **you can:

See which queries consume the most total CPU time.

Distinguish between slow queries and too‑frequent queries.

This approach is data‑driven, repeatable, and used in production every day. When things get slow, you’ll know exactly where to start.