DEV Community: Daan Acohen

Is your REST API actually Quantum-Safe? How to test it in 2026.

Daan Acohen — Sat, 28 Mar 2026 18:16:42 +0000

The 2026 Reality: Why PQC Matters Now

If you’ve been seeing the term Post-Quantum Cryptography (PQC) pop up in your security audits lately, there’s a reason for it. We’ve officially entered the era where traditional encryption (like RSA and ECC) is no longer considered "future-proof."

The "Harvest Now, Decrypt Later" (HNDL) Threat

You might think, "I don't need to worry about quantum computers yet; they aren't powerful enough to break my API today."

That is a dangerous assumption. Threat actors are currently practicing HNDL: they are intercepting and storing encrypted traffic today, waiting for the day a quantum computer is powerful enough to crack it. If your API is sending sensitive user data or long-lived secrets using classical encryption right now, that data is effectively a "time bomb" waiting to be decrypted in the future.

This is why NIST standardized ML-KEM (FIPS 203). It’s a quantum-resistant algorithm designed to protect data against these future threats. But as developers, how do we actually know our infrastructure is using it?

The "False Positive" Trap

Suppose your organization has spent months upgrading API gateways and load balancer certs to support these new standards. You run your standard verification:

curl -I https://api.production.internal/v1/status

The output looks perfect: HTTP/2 200 OK. You’ve got a green lock in the browser. You're done, right?

Maybe not. A standard 200 OK doesn't tell you if your connection was actually negotiated using a quantum-resistant algorithm or if it quietly fell back to classical X25519 because of a single mismatched cipher suite or an outdated library.

Why `curl` isn't enough for PQC testing

curl is the GOAT for general API work, but for PQC diagnostics, it has a few "blind spots":

OS Dependencies: curl uses your system’s TLS library (OpenSSL, Schannel, etc.). If your local machine's library hasn't been updated to the absolute latest NIST standards, curl can't test them properly.
Handshake Noise: Digging through curl -v to find the negotiated key exchange group is a chore. It’s too much noise for a quick sanity check.
Silent Fallbacks: Most clients are designed to connect at any cost. They won't warn you if you’ve downgraded to a "vulnerable" classical connection.

The Workflow: From Guessing to Knowing

Instead of squinting at verbose logs, I now use Kemforge for manual "sanity checks" during development:

kemforge -v https://api.dev.local/health

Kemforge pipes security diagnostics directly to stderr. Before the JSON response even hits your terminal, you get a clear, explicit confirmation of the negotiated key exchange. If you see ML-KEM or X25519MLKEM768, you know the configuration is actually working.

Doing the "Quantum-Safe" Check

Because it provides explicit feedback, it’s incredibly easy to see directly if it HTTPS call is quantum safe, typically:

* TLS DATA:
* TlsVersion: 1.3
* Cipher:   TLS_AES_256_GCM_SHA384
* KeyExchangeGroup: X25519
* This server is not protected against quantum attacks as the key exchange group does not contain MLKEM.
*

* TLS DATA:
* TlsVersion: 1.3
* Cipher:   TLS_AES_128_GCM_SHA256
* KeyExchangeGroup: X25519MLKEM768
* This server supports post quantum cryptography so the server has protection against quantum attacks.
*

Conclusion

In 2026, we can't just assume our TLS configurations are correct. We need client-side verification that isn't tied to the whims of our operating system's libraries.

Being able to grab a static Go binary and get an immediate, cross-platform diagnostic on any API—regardless of the backend language—is a massive time-saver for anyone responsible for API security.

How is your team verifying PQC on your endpoints? Are you relying on server-side logs, or have you integrated client-side diagnostics into your dev loop? Let me know in your comment.

Check out Kemforge on GitHub or install it directly.

On Windows:

winget install ConnectingApps.Kemforge

on macOS:

brew tap ConnectingApps/kemforge
brew install kemforge

Windows Servers Are a Cryptographic Liability: Entire Countries Can Be Left Exposed to Quantum Attacks

Daan Acohen — Fri, 20 Mar 2026 19:39:03 +0000

In backend development, choosing between Windows and Linux often feels like a matter of preference.

But under the hood, that choice determines something much deeper:

Do you control your cryptography — or does your OS vendor?

In a world moving toward post-quantum cryptography (PQC), that question is no longer theoretical.

What Is Post-Quantum Cryptography (PQC)?

Today’s internet security relies heavily on cryptographic algorithms like:

RSA
ECC (Elliptic Curve Cryptography)

These are used in TLS to:

exchange keys
secure HTTPS traffic

They are considered secure against classical computers.

However, a sufficiently powerful quantum computer could break these algorithms using techniques like Shor's algorithm.

That leads to a well-known threat model:

Store now, decrypt later

An attacker can:

Capture encrypted traffic today
Store it
Decrypt it in the future once quantum capabilities exist

Post-Quantum Cryptography (PQC) refers to new algorithms designed to:

remain secure even against quantum computers

These are currently being standardized and gradually introduced into TLS (often in hybrid form).

The Hidden Detail Most Developers Miss

On Windows, TLS is handled by Schannel, a built-in OS component.

On Linux, TLS is handled in user space:

OpenSSL
BoringSSL
wolfSSL

This difference is invisible in code — but critical in practice.

Same Code, Different Reality

.NET (Windows → Schannel)

var client = new HttpClient();
var response = await client.GetAsync("https://example.com");

Uses Schannel
No control over TLS

PowerShell

Invoke-WebRequest https://example.com

Uses WinHTTP → Schannel

Python (Partial Independence)

import requests
requests.get("https://example.com")

Uses OpenSSL
But often embedded in Windows-based infrastructure

Go (Independent)

resp, _ := http.Get("https://example.com")

Uses Go’s crypto/tls
Fully independent

Rust (rustls)

let body = reqwest::get("https://example.com").await?.text().await?;

Can use rustls
Fully independent

Node.js

https.get('https://example.com', res => {
  res.on('data', chunk => process.stdout.write(chunk));
});

Uses OpenSSL internally
Not Schannel

curl (Two Worlds)

curl https://example.com

Windows → often Schannel
Linux → OpenSSL

Check:

curl -V

The Asymmetry

Stack	TLS Backend (Windows)	Control
.NET	Schannel	None
PowerShell	Schannel	None
IIS	Schannel	None
Python	OpenSSL (usually)	Partial
Go	crypto/tls	High
Rust	rustls/OpenSSL	High
Node.js	OpenSSL	High
curl	Schannel (default)	Low

Why PQC Changes Everything

To defend against quantum threats:

TLS must support new algorithms
systems must migrate before attackers catch up

On Linux / Go / Rust:

you can upgrade
experiment
deploy early

On Windows:

you cannot replace Schannel
you cannot add new algorithms
you must wait

You do not control when you become quantum-resistant

A Concrete Scenario: The Netherlands Falls Behind

Imagine the following:

PQC support is rolled out globally
Microsoft introduces PQC in Schannel
but rollout is delayed or restricted

Now assume:

The Netherlands does not receive these updates in time

Meanwhile:

Dutch hospitals run:
- Windows Server
- IIS
- .NET APIs

All protected by:

classical TLS

Outside the Netherlands

Other regions:

adopt PQC-enabled TLS
deploy hybrid cryptography
reduce exposure

The Result

Region	Crypto State
Netherlands	Classical TLS
Others	PQC / Hybrid

The Risk

Attackers can:

Target Dutch systems
capture encrypted traffic
store it

Years later:

quantum capabilities mature
classical crypto breaks

Result:

historical medical data becomes decryptable

Not because systems failed.

But because:

they could not evolve

Why This Is Hard to Fix

Organizations cannot simply:

replace Schannel
rewrite .NET systems
migrate instantly

Especially:

hospitals
large enterprises
government systems

They are constrained by:

legacy systems
vendor software
operational risk

This Is Not Just Technical — It’s Geopolitical

Microsoft is a US-based company.

That means:

it operates under US law
it can be compelled by the US government
legal and political pressure can be applied

If Microsoft controls:

TLS capabilities (Schannel)
PQC rollout
algorithm availability

Then:

external influence can affect when entire countries become quantum-safe

Conclusion: Rethink Your Stack Before It’s Too Late

The core issue is not theoretical.

It is architectural.

If your systems depend on Schannel:

you do not control your cryptography
you do not control when new algorithms arrive
you cannot react independently

That is not security.

That is dependency.

This Forces a Strategic Question

Organizations must ask:

Do we control our cryptographic evolution?

If not:

you are exposed to delays you cannot fix.

Architecture Matters

Platform

Windows → vendor-controlled crypto
Linux → operator-controlled crypto

Programming languages

Control differs per ecosystem:

Go → full control
Rust → full control
Node.js → strong control
Python → partial
.NET → none (on Windows)

TLS boundaries

Move TLS out of OS-controlled layers
prefer user-space TLS stacks

Tooling Matters Too

Even curl is not neutral.

On Windows:

it often uses Schannel

A Practical Alternative: kemforge

If you want to avoid Schannel:

kemforge

Features:

written in Go → independent TLS stack
not tied to Schannel
same CLI arguments as curl
open source

Repository:

https://github.com/ConnectingApps/kemforge

Includes:

installation steps
usage examples

Final Takeaway

This is the uncomfortable reality:

Cryptography is not just math, it is control.

If you:

depend on Schannel
cannot upgrade independently
cannot adopt PQC when needed

Then your systems are not just technically constrained.

They are:

strategically constrained

And in a post-quantum world:

that constraint can turn into exposure faster than you expect.

Is Your Rust App Ready for the Quantum Age? Find out with pqctracer

Daan Acohen — Tue, 24 Feb 2026 15:19:59 +0000

Quantum computers are coming — and when they arrive, much of today's encrypted internet traffic could be cracked wide open. That's not science fiction anymore; it's the reason NIST has already standardized post-quantum cryptography (PQC) algorithms, and why browsers like Chrome already negotiate post-quantum TLS handshakes by default.

But here's the uncomfortable truth: even if your client supports PQC, you have no idea whether your actual HTTPS connections are quantum-safe — unless you instrument them.

That's exactly the problem pqctracer solves.

A Quick Primer: What Is Post-Quantum Cryptography?

Classical key-exchange algorithms like X25519 are considered vulnerable to a sufficiently powerful quantum computer running Shor's algorithm. Once that threshold is crossed, any recorded TLS traffic from today could be retroactively decrypted — a threat known as "harvest now, decrypt later."

Hybrid schemes like X25519MLKEM768 defend against this by combining a classical algorithm with a post-quantum one. The connection stays secure even if one of the two is eventually broken.

The catch? PQC only works if both the client and the server support it. A client that prefers post-quantum handshakes will silently fall back to classical X25519 when the server doesn't support the hybrid group — and you'll never know unless you look.

You can also check whether your browser and a given web server support PQC over at quantumsafeaudit.com.

Introducing pqctracer

pqctracer is a reusable Rust library that wraps reqwest and rustls (with prefer-post-quantum enabled) to give you a TLS-aware HTTP client that captures the exact key-exchange group and cipher suite negotiated for every request.

No guesswork. No assumptions. Just facts straight from the TLS handshake.

The source code is available on GitHub: https://github.com/ConnectingApps/RustPqcTracer

Key features

Captures the negotiated TLS key-exchange group (e.g. X25519MLKEM768) per request
Captures the negotiated cipher suite (e.g. TLS13_AES_256_GCM_SHA384) per request
Built on reqwest + rustls with prefer-post-quantum support
Single shared connection-pooled client with lock-free per-request capture context across .await points

See It in Action

Here's all it takes to audit your outbound connections:

use pqctracer::TlsAwareClient;

async fn trace_host(tls_client: &TlsAwareClient, host: &str) {
    let url = format!("https://{}", host);
    println!("Requesting: {}", url);

    let req = reqwest::Client::new()
        .get(&url)
        .build()
        .expect("failed to build request");

    let result = tls_client.execute(req).await.expect("request failed");

    let group = result.group.as_deref().unwrap_or("Not available");
    let cipher = result.cipher.as_deref().unwrap_or("Not available");

    println!("Status code: {}", result.response.status());
    println!("Negotiated group: {}", group);
    println!("Cipher suite: {}", cipher);
}

#[tokio::main]
async fn main() {
    // Install aws-lc-rs as the process-level crypto provider (required when
    // `prefer-post-quantum` is enabled).
    rustls::crypto::aws_lc_rs::default_provider()
        .install_default()
        .expect("failed to install crypto provider");

    // Build the reusable TLS-aware client once.
    let tls_client = TlsAwareClient::new();

    trace_host(&tls_client, "www.google.com").await;
    println!();
    trace_host(&tls_client, "www.bing.com").await;
}

And here's what you get back:

Requesting: https://www.google.com
Status code: 200 OK
Negotiated group: X25519MLKEM768
Cipher suite: TLS13_AES_256_GCM_SHA384

Requesting: https://www.bing.com
Status code: 200 OK
Negotiated group: X25519
Cipher suite: TLS13_AES_256_GCM_SHA384

This output tells the whole story. Google supports the hybrid post-quantum group X25519MLKEM768 — so the handshake upgrades to a quantum-safe key exchange. Bing, on the other hand, only negotiates the classical X25519 group. Even though our client is fully PQC-capable, the connection to Bing gets zero post-quantum protection because the server doesn't support it yet.

Why This Matters for Your Services

If you're building or operating services that make outbound HTTPS calls — API clients, microservices, data pipelines — you probably have no visibility into what TLS groups are actually being negotiated. You might assume you're quantum-safe because you're using a modern TLS stack. But as the example above shows, that assumption is wrong half the time (or more).

pqctracer gives you the observability layer to:

Audit which third-party APIs and services you depend on actually support PQC
Track adoption over time as servers upgrade
Alert when a critical connection falls back to a classical group

Get Started

Add pqctracer to your Cargo.toml and start auditing your connections today. The crate is published at https://crates.io/crates/pqctracer and the full source code lives at https://github.com/ConnectingApps/RustPqcTracer.

The quantum threat isn't theoretical anymore — but the tools to defend against it are already here. Now you can see exactly where you stand.

Is Your Node.js App Quantum-Safe? Tracing PQC in TLS Connections

Daan Acohen — Fri, 20 Feb 2026 21:39:06 +0000

Post-Quantum Cryptography (PQC) is no longer a distant concern — it is happening now. Google Chrome, Cloudflare, and major cloud providers have already started deploying hybrid post-quantum key exchange in TLS connections. But how do you actually verify, from code, that your Node.js HTTPS requests are using quantum-safe cryptography? That is exactly what pqc-tracer solves.

What Is Post-Quantum Cryptography (PQC)?

Classical public-key cryptography — RSA, ECDH, and elliptic curve algorithms like X25519 — relies on mathematical problems (factoring large numbers, discrete logarithm) that are computationally hard for classical computers. A sufficiently powerful quantum computer running Shor's algorithm can solve these problems efficiently, breaking the confidentiality of any TLS session secured by these algorithms.

Post-Quantum Cryptography refers to algorithms believed to be resistant even against quantum computers. NIST standardized several PQC algorithms in 2024, most notably:

ML-KEM (Module Lattice Key Encapsulation Mechanism, also known as CRYSTALS-Kyber) — used for key exchange in TLS.
ML-DSA (CRYSTALS-Dilithium) — used for digital signatures.

In practice, TLS deployments today use hybrid key exchange, combining a classical algorithm with a PQC algorithm. For example, X25519MLKEM768 combines classical X25519 with ML-KEM-768. This ensures security even if one of the two algorithms is broken.

Why Do We Need a Tool to Check PQC Usage?

TLS handshake details are not exposed by default in high-level HTTP client APIs. When you do fetch('https://example.com') or use Node's https.get(...), you get a response — but you have no visibility into which key exchange group was negotiated during the TLS handshake.

A tool like pqc-tracer fills this gap. It:

Makes an outgoing HTTPS request using Node's native TLS stack.
Intercepts the established TLS socket and, using native FFI calls into libssl.so.3, reads the negotiated key exchange group directly from the OpenSSL SSL* object.
Returns both the TLS trace (group name + cipher suite) and the full HTTP response.

This lets you answer the question: "Is this HTTPS connection actually quantum-safe?"

This is particularly valuable for:

Security auditors checking whether production services have enabled PQC.
Developers verifying their Node.js version supports PQC before deploying to production.
Researchers monitoring the rollout of PQC across the internet.

How Does `pqc-tracer` Work?

The library uses koffi — a fast FFI library for Node.js — to call two OpenSSL C functions directly from native libssl.so.3:

SSL_ctrl(ssl, 134, 0, NULL) — queries the negotiated key exchange group ID (NID). Constant 134 is SSL_CTRL_GET_NEGOTIATED_GROUP from OpenSSL's ssl.h.
SSL_group_to_name(ssl, groupId) — converts the numeric group ID to a human-readable name like "X25519MLKEM768" or "X25519".

The native SSL* pointer is accessed from Node's internal TLS socket through stderr-level fd capture of OpenSSL's SSL_trace output, which surfaces the group name via OpenSSL's own diagnostic output.

Linux only. This approach depends on Node's use of OpenSSL as its TLS backend and libc.so.6 for fd-level redirection. macOS and Windows use different native TLS libraries and are not supported.

Installation

npm install pqc-tracer

Requirements:

Node.js >= 20
Linux

Basic Usage

import { executeRequest } from 'pqc-tracer';

const request = {
  hostname: 'www.example.com',
  port: 443,
  path: '/',
  method: 'GET',
};

executeRequest(request).then(({ tlsTrace, response }) => {
  console.log(`Negotiated Group: ${tlsTrace.group}`);
  console.log(`Cipher Suite: ${tlsTrace.cipherSuite}`);
  console.log(`HTTP Status: ${response.statusCode}`);
}).catch(console.error);

What You Get

The TlsTrace interface exposes:

interface TlsTrace {
  group: string;       // e.g. "X25519MLKEM768"
  cipherSuite: string; // e.g. "TLS_AES_256_GCM_SHA384"
}

If group is X25519MLKEM768, your connection is using a hybrid PQC key exchange — you are quantum-safe. If it is X25519 or P-256, your connection uses only classical key exchange.

Full Response Type

interface HttpResponse {
  statusCode: number | undefined;
  statusMessage: string | undefined;
  headers: IncomingHttpHeaders;
  httpVersion: string;
  body: string;
}

interface RequestResult {
  tlsTrace: TlsTrace;
  response: HttpResponse;
}

Low-Level API

If you want to integrate PQC tracing into your own request logic:

import { startStderrCapture, stopStderrCapture, getTlsTrace } from 'pqc-tracer';

// Before your TLS handshake:
startStderrCapture(); // redirects fd 2 to a temp file

// ... perform your HTTPS request ...

// After the handshake completes:
const traceOutput = stopStderrCapture(); // restores stderr, returns captured output
const tlsTrace = getTlsTrace(socket, traceOutput);
console.log(tlsTrace.group);

Does the Node.js Version Matter for PQC?

Absolutely — and this is the most important practical insight from this project.

Node.js bundles its own version of OpenSSL. PQC support in TLS (specifically ML-KEM via X25519MLKEM768) was added in OpenSSL 3.5.0. Whether your HTTPS connections are quantum-safe depends entirely on which OpenSSL version your Node.js build ships with.

The NodePqcReader repository contains a Docker-based test that runs the same HTTPS request to www.google.com under Node 20, 22, and 24 to compare results.

The Dockerfile

FROM ubuntu:24.04

ENV NVM_DIR=/root/.nvm
ENV NODE_VERSION_BUILD=22
ENV NODE_VERSION_RUN_1=20
ENV NODE_VERSION_RUN_2=22
ENV NODE_VERSION_RUN_3=24

RUN apt-get update && apt-get install -y curl ca-certificates && rm -rf /var/lib/apt/lists/*

# Install nvm and the required Node versions
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.2/install.sh | bash && \
    . "$NVM_DIR/nvm.sh" && \
    nvm install $NODE_VERSION_BUILD && \
    nvm install $NODE_VERSION_RUN_1 && \
    nvm install $NODE_VERSION_RUN_3

WORKDIR /app

# 1. Build pqc-tracer first (its dist/ is gitignored, so we must build it here)
COPY pqc-tracer ./pqc-tracer
WORKDIR /app/pqc-tracer
RUN . "$NVM_DIR/nvm.sh" && nvm use $NODE_VERSION_BUILD && npm install && npm run build

# 2. Build the main project
WORKDIR /app
COPY package.json package-lock.json ./
COPY src ./src
COPY tsconfig.json ./
RUN . "$NVM_DIR/nvm.sh" && nvm use $NODE_VERSION_BUILD && npm install && npm run build

COPY run.sh ./
RUN chmod +x run.sh

CMD ["./run.sh"]

The Run Script (`run.sh`)

#!/bin/bash
set -e

. "$NVM_DIR/nvm.sh"

echo "=== Running with Node $NODE_VERSION_RUN_1 ==="
nvm use $NODE_VERSION_RUN_1
echo "OpenSSL Version"
node -p "process.versions.openssl"
node dist/index.js

echo "=== Running with Node $NODE_VERSION_RUN_2 ==="
nvm use $NODE_VERSION_RUN_2
echo "OpenSSL Version"
node -p "process.versions.openssl"
node dist/index.js

echo "=== Running with Node $NODE_VERSION_RUN_3 ==="
nvm use $NODE_VERSION_RUN_3
echo "OpenSSL Version"
node -p "process.versions.openssl"
node dist/index.js

This script uses nvm to switch between Node versions and prints the bundled OpenSSL version before running the tracer against www.google.com.

The Main Script (`src/index.ts`)

import { executeRequest } from 'pqc-tracer';

const request = {
  hostname: 'www.google.com',
  port: 443,
  path: '/',
  method: 'GET',
  headers: {
    'User-Agent': 'NodePqcReader/1.0',
  },
};

executeRequest(request).then(({ tlsTrace, response }) => {
  console.log(`Negotiated Group: ${tlsTrace.group}`);
  console.log(`Cipher Suite: ${tlsTrace.cipherSuite}`);
  console.log(`HTTP Status: ${response.statusCode}`);
  console.log(`Response Preview: ${response.body.slice(0, 10)}`);
}).catch(console.error);

Container Output

This is the actual output from a GitHub Actions run of the container:

=== Running with Node 20 ===
Now using node v20.20.0 (npm v10.8.2)
OpenSSL Version
3.0.17
Negotiated Group: X25519
Cipher Suite: TLS_AES_256_GCM_SHA384
HTTP Status: 200
Response Preview: <!doctype 
=== Running with Node 22 ===
Now using node v22.22.0 (npm v10.9.4)
OpenSSL Version
3.5.4
Negotiated Group: X25519MLKEM768
Cipher Suite: TLS_AES_256_GCM_SHA384
HTTP Status: 200
Response Preview: <!doctype 
=== Running with Node 24 ===
Now using node v24.13.1 (npm v11.8.0)
OpenSSL Version
3.5.5
Negotiated Group: X25519MLKEM768
Cipher Suite: TLS_AES_256_GCM_SHA384
HTTP Status: 200
Response Preview: <!doctype

What Does This Output Tell Us?

Node Version	Exact Version	Bundled OpenSSL	Negotiated Group	Quantum-Safe?
20	v20.20.0	3.0.17	X25519	❌ No
22	v22.22.0	3.5.4	X25519MLKEM768	✅ Yes
24	v24.13.1	3.5.5	X25519MLKEM768	✅ Yes

The results are striking:

Node 20 bundles OpenSSL 3.0.17, which does not support ML-KEM. Connections to Google (which offers X25519MLKEM768) fall back to classical X25519.
Node 22 bundles OpenSSL 3.5.4 — and that is already enough for full PQC support. The connection to Google negotiates X25519MLKEM768, a hybrid PQC key exchange.
Node 24 bundles OpenSSL 3.5.5, also negotiating X25519MLKEM768.

The cipher suite (TLS_AES_256_GCM_SHA384) remains the same across all versions — this is the symmetric encryption used after key exchange and is already quantum-resistant at 256-bit strength.

The takeaway: Node 20 is the odd one out. Both Node 22 and Node 24 ship with OpenSSL 3.5 and support PQC out of the box. If you are still on Node 20, you are missing quantum-safe key exchange entirely.

Why Node.js Has an Advantage Over Python and .NET

Here is where Node.js shines compared to other languages: Node bundles its own OpenSSL.

In most Linux distributions, Python and .NET use the system's shared OpenSSL (/usr/lib/x86_64-linux-gnu/libssl.so.3 or similar). This means:

On Ubuntu 24.04, the system OpenSSL is 3.0.x — no PQC support.
To get PQC in Python, you would need to compile OpenSSL 3.5 from source, set LD_LIBRARY_PATH, and possibly recompile Python itself or use a custom ssl module.
.NET on Linux also links against the system OpenSSL by default. Getting ML-KEM support requires either a custom OpenSSL build or waiting for the distribution to ship 3.5.

Node.js sidesteps all of this. When you install Node 24 via nvm, it ships with its own OpenSSL 3.5 statically or dynamically linked — no system-level changes required. PQC just works, immediately, without any manual setup.

This makes Node.js currently the most accessible runtime for experimenting with and deploying PQC in outgoing HTTPS requests on Linux.

Summary

Aspect	Detail
Package	`pqc-tracer`
GitHub	ConnectingApps/NodePqcReader
Minimum Node for PQC	Node 22 (bundles OpenSSL 3.5+)
PQC group to look for	`X25519MLKEM768`
Platform	Linux only
Key advantage vs Python/.NET	Node bundles its own OpenSSL — no system-level setup needed

If you want to audit whether your Node.js services are making quantum-safe connections, pqc-tracer gives you a simple, programmatic way to find out. Install it, run it against your endpoints, and check whether you're seeing X25519MLKEM768 — or still stuck in the classical world.

Verify Post-Quantum TLS Negotiation from Python `requests` on Linux

Daan Acohen — Thu, 19 Feb 2026 16:41:50 +0000

Post-quantum cryptography (PQC) is no longer a “someday” topic. Standards are published, vendors are shipping hybrid TLS key exchange groups, and security teams are being asked a deceptively simple question:

Are we actually negotiating PQC (or hybrid PQC) on real connections—outside the lab?

pqcreader is a small Python package that wraps Python requests calls and exposes TLS handshake metadata—especially the negotiated key exchange group (where hybrid PQC shows up) and the cipher suite.

PyPI: https://pypi.org/project/pqcreader/
Source repo: https://github.com/ConnectingApps/PyPqcReader

PQC in two minutes: why it matters

“Harvest now, decrypt later”

Even before large-scale quantum computers exist, attackers can record encrypted traffic today and attempt to decrypt it later when they do. If the data has a long confidentiality lifetime (think: customer data, credentials, health data, intellectual property, state secrets), that risk is practical rather than academic.

NIST has finalized initial post-quantum encryption standards

In 2024, NIST finalized its first post-quantum encryption standards, including FIPS 203 (ML-KEM) (derived from CRYSTALS-Kyber and renamed ML-KEM).

NIST announcement: https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards

TLS migration reality: hybrid key exchange

Most deployments won’t jump directly from “classical-only” to “PQC-only.” The common path is hybrid key exchange: combine classical ECDHE with a post-quantum KEM so that the handshake remains secure even if one component becomes vulnerable.

IETF hybrid TLS design draft: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

What pqcreader does

pqcreader focuses on a very operational capability:

Wrap an HTTP request (via requests)
Extract TLS handshake details that are not typically easy to retrieve from standard Python APIs
Print the negotiated group and cipher suite

This is especially useful when testing hybrid PQC deployments, where the negotiated group can be the difference between “we think it’s enabled” and “it is actually happening on the wire.”

OpenSSL (example of hybrid groups such as X25519MLKEM768): https://docs.openssl.org/3.6/man3/SSL_CTX_set1_curves/

⚠️ Important constraints

The project states (verbatim):

⚠️ IMPORTANT: This library is Linux-only. It will NOT work on Windows, macOS, or any other operating system. The library uses Linux-specific OpenSSL library loading and relies on system-level integration that is not available on other platforms. Please ensure you are running on a Linux system before attempting to use this library.

In addition, it is CPython-only and described as experimental across Python/OpenSSL variants. In practice, you should treat pqcreader as a diagnostic probe (CI checks, rollout validation, troubleshooting), not as a core production dependency.

Installation

pip install pqcreader

Requirements (from the project)

Python 3.10+
Linux operating system (required for OpenSSL tracing)
OpenSSL 3.x

Quick start: trace a real `requests.get()`

Basic usage (from the README)

import requests
from pqcreader import pqcreader_request

# Wrap any requests call
response, tls_trace = pqcreader_request(
    lambda: requests.get("https://www.google.com", timeout=10)
)

print(f"Status: {response.status_code}")
print(f"Negotiated Group: {tls_trace.group}")
print(f"Cipher Suite: {tls_trace.cipher_suite}")

What you’re looking for

If your client, server, and OpenSSL runtime negotiate a hybrid PQC group, the group name is typically where you’ll see it. Hybrid group names are ecosystem-specific, but OpenSSL documentation includes examples like X25519MLKEM768.

OpenSSL curves/groups doc (includes hybrid group examples): https://docs.openssl.org/3.6/man3/SSL_CTX_set1_curves/

These helpers are useful for quick probes you can drop into:

CI smoke tests (to detect negotiation regressions)
environment verification during rollout (dev/staging/prod)
incident response diagnostics (confirm crypto posture quickly)

How it works (high level)

The package intercepts HTTPS connections (via urllib3 under requests), accesses the underlying OpenSSL socket, and queries OpenSSL for handshake metadata.

This is a practical approach for answering the one question that matters operationally:

“What did we negotiate for this request, in this environment, at runtime?”

Where pqcreader fits in a PQC readiness workflow

A pragmatic engineering workflow for PQC readiness looks like this:

Standards awareness: understand what is being standardized and deployed (e.g., ML-KEM).
https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
Protocol design: understand hybrid TLS 1.3 construction and expected negotiation behavior.
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
Runtime verification: confirm what is negotiated by your real clients and endpoints.
That is where pqcreader provides immediate value.

Links

pqcreader on PyPI: https://pypi.org/project/pqcreader/
Source repository: https://github.com/ConnectingApps/PyPqcReader
NIST PQC standards announcement: https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
IETF hybrid TLS design draft: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
OpenSSL groups/curves documentation (hybrid examples): https://docs.openssl.org/3.6/man3/SSL_CTX_set1_curves/

If you want, Mr Acohen, I can also format it to dev.to conventions (front matter, recommended tags, and a tighter opening hook) while keeping the “direct links only” rule and keeping every README code block intact.

Trace Whether Your .NET `HttpClient` Calls Are Quantum-Safe (PQC) 🚦

Daan Acohen — Wed, 18 Feb 2026 15:55:09 +0000

Post-quantum cryptography (PQC) has a reputation for sounding “future-ish” and theoretical—until you realize the uncomfortable reality:

Data you encrypt today can be harvested today and decrypted later when a sufficiently capable quantum computer arrives. This is the “harvest now, decrypt later” problem, and it’s the reason PQC has moved from academic curiosity to real-world migration work.

As .NET developers, we ship software that talks to lots of endpoints—internal services, SaaS APIs, identity providers, payment gateways, telemetry backends. And most of those calls happen through one thing:

✅ HttpClient

If PQC readiness matters to your organization (and it increasingly does), you need a simple answer to a simple question:

Which of my outgoing HTTPS calls are already negotiating quantum-resistant key exchange—and which are not?

That’s exactly what PqcTracer provides: it makes TLS negotiation details visible, so you can see whether connections are using post-quantum / hybrid key exchange (for example, groups like X25519MLKEM768).

NuGet: https://www.nuget.org/packages/ConnectingApps.PqcTracer
Source repo: https://github.com/ConnectingApps/PqcTracer

Why PQC matters (in practical developer terms)

Most TLS connections today rely on key exchange mechanisms based on classical cryptography (commonly elliptic curve or RSA). The concern is that Shor’s algorithm on a sufficiently powerful quantum computer would break RSA and elliptic-curve cryptography, undermining the security assumptions behind today’s TLS handshakes.

The industry response is Post-Quantum Cryptography: algorithms designed to resist both classical and quantum attacks. A particularly important piece is key establishment. One of the NIST-standardized directions here is ML-KEM (formerly known as Kyber), used in modern TLS stacks as part of a hybrid key exchange—combining classical + post-quantum components.

In practice, if you see a negotiated TLS group like:

X25519MLKEM768

…you’re looking at a hybrid that includes ML-KEM, i.e., a strong indicator that the connection is negotiating in a way designed to be quantum-resistant.

But here’s the engineering problem: you usually don’t see this from application code.

The typical .NET situation: “TLS happens somewhere below me”

In .NET, outgoing HTTPS calls go through HttpClient, and TLS negotiation is handled by platform crypto + the underlying TLS library. Your app typically doesn’t expose:

Which key exchange group was negotiated
Which cipher suite was chosen

You can reach for packet capture tooling, but:

it’s heavy for day-to-day dev,
often not feasible in production,
and not the kind of visibility you want to bolt onto every service.

You want something code-level, repeatable, and easy to wire in.

Enter PqcTracer: TLS trace headers for your outgoing `HttpClient` calls

PqcTracer is a .NET library that traces TLS negotiation details for both incoming and outgoing HTTPS traffic. This article focuses on the part most applications care about immediately:

✅ Outgoing traffic (HttpClient)

Once enabled, you can extract TLS trace info from the response and answer:

What TLS group did we negotiate?
What cipher suite did we use?
Does the group indicate ML-KEM (and therefore PQC/hybrid readiness)?

Install

Use the NuGet package:

https://www.nuget.org/packages/ConnectingApps.PqcTracer

dotnet add package ConnectingApps.PqcTracer

Project source:

https://github.com/ConnectingApps/PqcTracer

Outgoing traffic: two ways to trace TLS on `HttpClient`

PqcTracer gives you two approaches, depending on whether you build HttpClient manually or rely on DI with IHttpClientFactory.

Both produce the same trace output.

Approach 1: Direct handler usage (quick, explicit, great for utilities)

This is the simplest possible wiring: create a TlsTracingHandler, pass it into HttpClient, and then query the trace from the response.

Exact example code (as documented):

using ConnectingApps.PqcTracer;

using var handler = new TlsTracingHandler();
using var client = new HttpClient(handler);

try
{
    using var response = await client.GetAsync("https://www.google.com");
    response.EnsureSuccessStatusCode();

    var trace = response.GetTlsTrace();
    if (trace != null)
    {
        Console.WriteLine($"Negotiated Group: {trace.Group}");
        Console.WriteLine($"Cipher Suite: {trace.CipherSuite}");
    }
    else
    {
        Console.WriteLine("TLS Trace not found.");
    }
}
catch (Exception ex)
{
    Console.WriteLine($"Error: {ex.Message}");
}

When to use it

Small tools / diagnostics
One-off probes in CI
Console apps that verify endpoints
Situations where you want zero DI setup

Approach 2: DI with `IHttpClientFactory` (production-friendly)

If you are building services the “modern .NET way”, you likely use IHttpClientFactory already (named clients, typed clients, policies, resilience, handler lifetimes). PqcTracer supports that flow via an extension method:

✅ AddTlsTracing()

Exact example code (as documented):

using ConnectingApps.PqcTracer;
using Microsoft.Extensions.DependencyInjection;

// Register the HttpClient via DI
var services = new ServiceCollection();
services.AddHttpClient("GoogleClient").AddTlsTracing();

var serviceProvider = services.BuildServiceProvider();

// Resolve IHttpClientFactory from the service provider
var httpClientFactory = serviceProvider.GetRequiredService<IHttpClientFactory>();

// Create the client using the factory
using var client = httpClientFactory.CreateClient("GoogleClient");

try
{
    using var response = await client.GetAsync("https://www.google.com");
    response.EnsureSuccessStatusCode();

    var trace = response.GetTlsTrace();
    if (trace != null)
    {
        Console.WriteLine($"Negotiated Group: {trace.Group}");
        Console.WriteLine($"Cipher Suite: {trace.CipherSuite}");
    }
    else
    {
        Console.WriteLine("TLS Trace not found.");
    }
}
catch (Exception ex)
{
    Console.WriteLine($"Error: {ex.Message}");
}

Why this is usually the right choice

Fits naturally into ASP.NET Core apps
Works with named/typed clients
Plays well with established HttpClient lifetime management
Easy to apply selectively (trace only specific clients)

Interpreting the output: what you’re actually looking for

Example output shown in the README (on a system without PQC-capable OpenSSL) is:

Negotiated Group: x25519
Cipher Suite: TLS_AES_256_GCM_SHA384

The key line is the group:

x25519 → classical ECDH (not PQC)
X25519MLKEM768 → hybrid classical + ML-KEM (PQC-oriented)

In other words, with PqcTracer in place, you can programmatically (or operationally) identify which outbound connections are already negotiating hybrid/PQC groups and which are not.

Why this NuGet package is useful (beyond “cool demo output”)

In real systems, PQC isn’t a switch you flip once. It’s a migration:

Some endpoints support hybrid groups, others don’t.
Some environments have the right TLS stack, others lag behind.
Third-party APIs may roll out support gradually.
You need visibility per call path, not just “we upgraded something”.

PqcTracer turns that uncertainty into data. It enables:

PQC compliance auditing across outbound API calls
Migration tracking over time (are we improving week over week?)
Security monitoring (are critical calls still classical-only?)
Debugging TLS negotiation without packet captures

The best part is that it’s application-integrated: you instrument your actual HttpClient usage, not a synthetic test harness that drifts away from reality.

Platform note (important before you try it)

PqcTracer currently targets Linux, using OpenSSL 3.x via P/Invoke to extract negotiated TLS group details.

Also, if you want to see ML-KEM groups, you need a PQC-capable OpenSSL version (the README notes OpenSSL 3.5.0 or later for ML-KEM support).

Wrap-up

If PQC is on your roadmap (or on your auditor’s checklist), you do not want to “assume TLS is fine.”

With PqcTracer, you can:

instrument outgoing HttpClient traffic,
extract the negotiated TLS group and cipher suite,
and identify which connections are already negotiating hybrid/PQC key exchange.

Start here:

And then do the satisfying part: run your service, call your real dependencies, and finally see what’s happening in your TLS handshakes.

Quantum-Safe TLS Is Not a Future Problem. It’s a Visibility Problem.

Daan Acohen — Tue, 17 Feb 2026 15:57:53 +0000

Most teams can answer “Do we use HTTPS?”
Far fewer can answer “Are we already negotiating post-quantum key exchange in real traffic?”

That gap matters.

If an attacker records encrypted traffic today and breaks the key exchange years later with a cryptographically relevant quantum computer, sensitive historical data can be exposed. This is the “harvest now, decrypt later” risk model driving post-quantum migration efforts globally. NIST standardized ML-KEM for this transition in FIPS 203:
https://csrc.nist.gov/pubs/fips/203/final

For engineering teams, the first practical step is not a massive rewrite. It is observability.

That is where ConnectingApps.PqcTracer comes in:
https://github.com/ConnectingApps/PqcTracer
https://www.nuget.org/packages/ConnectingApps.PqcTracer

What this NuGet package gives you

ConnectingApps.PqcTracer lets your ASP.NET Core app trace TLS handshake details for incoming HTTPS requests and expose them as response headers.

In plain terms, you can immediately see:

Which TLS key exchange group was negotiated
Which cipher suite was negotiated
Whether hybrid post-quantum groups such as X25519MLKEM768 are appearing in your request flow

That gives platform and security teams an objective way to measure PQC adoption inside the company.

Why this is suddenly actionable

OpenSSL 3.5 introduced and enabled stronger PQC behavior in mainstream TLS usage, including hybrid ML-KEM groups such as X25519MLKEM768 in defaults/keyshares:
https://openssl-library.org/post/2025-04-08-openssl-35-final-release/

So the question is no longer “Is PQC real yet?”
The question is “Can we verify what our services are negotiating right now?”

Install

dotnet add package ConnectingApps.PqcTracer

NuGet package page:
https://www.nuget.org/packages/ConnectingApps.PqcTracer

Use it in two lines of integration

PqcTracer exposes two extension methods:

TraceTlsConnection() to capture TLS negotiation data during handshake in Kestrel
UseTlsTraceHeaders() to emit those values in HTTP response headers

Example `Program.cs`

using ConnectingApps.PqcTracer;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddControllers();

builder.WebHost.TraceTlsConnection();

// Learn more about configuring OpenAPI at https://aka.ms/aspnet/openapi
builder.Services.AddOpenApi();

var app = builder.Build();

app.UseTlsTraceHeaders();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

public partial class Program { }

What you will see in responses

After integration, responses can include headers like:

X-Tls-Cipher: TLS_AES_256_GCM_SHA384
X-Tls-Group: X25519MLKEM768

Interpretation:

X-Tls-Group tells you the negotiated key exchange group.
If it contains MLKEM, your connection used a post-quantum-capable hybrid key exchange.
X-Tls-Cipher tells you the negotiated symmetric cipher suite.

For a security program, this is high-value telemetry that can be aggregated immediately.

Technical depth for medior/senior engineers

Under the hood, PqcTracer follows a practical architecture:

It hooks into Kestrel’s TLS authentication flow.
After handshake, it inspects SslStream.
It calls into OpenSSL (libssl.so.3) via P/Invoke.
It retrieves the negotiated group using OpenSSL control APIs (SSL_ctrl) and resolves human-readable names (SSL_group_to_name).
It stores group/cipher values in connection context.
Middleware writes those values into response headers.

This is a smart design for production environments because it avoids packet-capture complexity and surfaces negotiation data directly where application teams can use it.

Platform requirements you should know upfront

From the project design and README behavior:

Current support is Linux only
It relies on OpenSSL via libssl.so.3
For ML-KEM visibility/support, you need OpenSSL 3.5.0+

Project link for details and updates:
https://github.com/ConnectingApps/PqcTracer

Where this helps immediately inside a company

PQC readiness checks: prove whether traffic already negotiates hybrid PQC groups
Migration dashboards: track percentage of requests using ML-KEM-capable groups
Client compatibility analysis: identify legacy clients negotiating classical-only groups
Audit evidence: provide concrete runtime proof for architecture and compliance discussions

Bottom line

Post-quantum migration is often treated as a strategic roadmap item.
But roadmaps without runtime evidence are just assumptions.

If your company wants a clear, engineering-grade view of whether PQC is already present in web requests, start with instrumentation.

ConnectingApps.PqcTracer is a small integration that gives you exactly that visibility:
https://www.nuget.org/packages/ConnectingApps.PqcTracer
https://github.com/ConnectingApps/PqcTracer

Also see:
https://github.com/ConnectingApps
https://quantumsafeaudit.com

Post-Quantum TLS in .NET 10 on Linux: ML-KEM in a Real Dockerized HTTP Client

Daan Acohen — Sat, 14 Feb 2026 21:53:15 +0000

Quantum-safe cryptography is moving from “future topic” to “engineering backlog item.”
The reason is simple: encrypted traffic captured today may be decrypted in the future once sufficiently capable quantum systems exist. If your data needs long-term confidentiality, this risk is relevant now.

A practical migration path is hybrid TLS key exchange: combine a classical key exchange (for interoperability) with a post-quantum one (for quantum resistance). In the .NET ecosystem, this becomes especially interesting with .NET 10 and ML-KEM support.

This article walks through the PQCHttpClient demo repo and explains exactly how it proves post-quantum hybrid TLS negotiation from a .NET app on Linux containers:

GitHub repo: https://github.com/ConnectingApps/PQCHttpClient
.NET 10 libraries (PQC APIs): https://learn.microsoft.com/dotnet/core/whats-new/dotnet-10/libraries
OpenSSL TLS groups (including hybrid ML-KEM groups): https://docs.openssl.org/3.6/man3/SSL_CTX_set1_curves/

Why this matters for .NET developers

If you run .NET workloads on Linux (VMs, containers, Kubernetes), your TLS and crypto behavior depends on native platform libraries. For ML-KEM scenarios, that means:

.NET 10 gives you the managed API surface (System.Security.Cryptography.MLKem)
Linux runtime support depends on the OpenSSL version actually loaded at runtime
OpenSSL 3.5+ is the key enabler for ML-KEM TLS group support in this context

So this is not just about targeting net10.0; it is also about deterministic runtime linking.

What the demo proves

The project demonstrates three concrete things:

Capability detection: MLKem.IsSupported reports whether ML-KEM is truly available in the runtime environment.
Real HTTPS traffic: standard HttpClient call, no custom handshake code.
Negotiation evidence: response header output shows which key exchange group was used.

This makes it a strong proof-of-concept for teams evaluating PQC readiness in production-like container environments.

Program.cs (why it is effective)

// HttpClient GET request demonstration
// Performs a GET request to GitHub API and displays status code and response headers

using (var client = new HttpClient())
{
    Console.WriteLine($"ML-KEM supported: {System.Security.Cryptography.MLKem.IsSupported}");
    try
    {
        // Set User-Agent header (required by GitHub API)
        client.DefaultRequestHeaders.Add("User-Agent", "pqcheader-console-app");

        // Execute GET request
        Console.WriteLine("Sending GET request to https://www.quantumsafeaudit.com..");
        Console.WriteLine();

        var response = await client.GetAsync("https://www.quantumsafeaudit.com");

        // Ensure the request was successful
        response.EnsureSuccessStatusCode();

        // Display status code
        Console.WriteLine($"Status Code: {(int)response.StatusCode} {response.StatusCode}");
        Console.WriteLine();

        // Display response headers
        Console.WriteLine("Response Headers:");
        Console.WriteLine(new string('-', 50));

        foreach (var header in response.Headers)
        {
            Console.WriteLine($"{header.Key}: {string.Join(", ", header.Value)}");
        }

        // Also display content headers if present
        if (response.Content.Headers.Any())
        {
            Console.WriteLine();
            Console.WriteLine("Content Headers:");
            Console.WriteLine(new string('-', 50));

            foreach (var header in response.Content.Headers)
            {
                Console.WriteLine($"{header.Key}: {string.Join(", ", header.Value)}");
            }
        }
    }
    catch (HttpRequestException ex)
    {
        Console.WriteLine($"Error making HTTP request: {ex.Message}");
    }
    catch (Exception ex)
    {
        Console.WriteLine($"Unexpected error: {ex.Message}");
    }
}

Key takeaways for readers

MLKem.IsSupported is a runtime truth signal, not a compile-time guarantee.
The app uses ordinary HttpClient; PQ/hybrid negotiation happens in the underlying TLS stack.
Showing response headers gives concrete handshake observability (important in demos and audits).

Dockerfile (the critical engineering part)

# =============================================================================
# Stage 1: Build OpenSSL 3.5 from source
# =============================================================================
FROM ubuntu:24.04 AS openssl-builder

RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    ca-certificates \
    curl \
    perl \
    && rm -rf /var/lib/apt/lists/*

ARG OPENSSL_VERSION=3.5.0
RUN curl -fsSL https://github.com/openssl/openssl/releases/download/openssl-${OPENSSL_VERSION}/openssl-${OPENSSL_VERSION}.tar.gz \
    -o /tmp/openssl.tar.gz \
    && tar -xzf /tmp/openssl.tar.gz -C /tmp

WORKDIR /tmp/openssl-${OPENSSL_VERSION}

RUN ./Configure \
    --prefix=/opt/openssl-3.5 \
    --openssldir=/opt/openssl-3.5/ssl \
    linux-x86_64 \
    shared \
    no-tests \
    && make -j$(nproc) \
    && make install_sw install_ssldirs

# =============================================================================
# Stage 2: .NET 10 SDK with custom OpenSSL — build the app
# =============================================================================
FROM mcr.microsoft.com/dotnet/sdk:10.0-preview-noble AS build

# Copy OpenSSL 3.5 from builder stage
COPY --from=openssl-builder /opt/openssl-3.5 /opt/openssl-3.5

# Make the system use our OpenSSL 3.5
ENV LD_LIBRARY_PATH=/opt/openssl-3.5/lib64:/opt/openssl-3.5/lib
ENV PATH="/opt/openssl-3.5/bin:${PATH}"

WORKDIR /src

# Copy project file first for layer caching
COPY pqcheader.csproj ./
RUN dotnet restore

# Copy source and build
COPY Program.cs ./
RUN dotnet publish -c Release -o /app --no-restore

# =============================================================================
# Stage 3: Runtime image with custom OpenSSL
# =============================================================================
FROM mcr.microsoft.com/dotnet/runtime:10.0-preview-noble AS runtime

# Install minimal runtime dependencies for OpenSSL
RUN apt-get update && apt-get install -y --no-install-recommends \
    ca-certificates \
    && rm -rf /var/lib/apt/lists/*

# Copy OpenSSL 3.5 libraries
COPY --from=openssl-builder /opt/openssl-3.5 /opt/openssl-3.5

# Configure dynamic linker to find OpenSSL 3.5 FIRST (before system OpenSSL)
RUN echo "/opt/openssl-3.5/lib64" > /etc/ld.so.conf.d/openssl-3.5.conf \
    && echo "/opt/openssl-3.5/lib" >> /etc/ld.so.conf.d/openssl-3.5.conf \
    && ldconfig

# Also set LD_LIBRARY_PATH as belt-and-suspenders
ENV LD_LIBRARY_PATH=/opt/openssl-3.5/lib64:/opt/openssl-3.5/lib
ENV SSL_CERT_DIR=/etc/ssl/certs

WORKDIR /app
COPY --from=build /app .

# Verify OpenSSL version at build time
RUN /opt/openssl-3.5/bin/openssl version

ENTRYPOINT ["dotnet", "pqcheader.dll"]

What makes this production-relevant

Version control over crypto backend: avoids silently using distro-default OpenSSL.
Isolated OpenSSL prefix: explicit, auditable dependency placement.
Deterministic loader behavior: ld.so.conf.d + ldconfig + LD_LIBRARY_PATH.
Build-time validation: openssl version check inside the image.

For security-sensitive software, this is exactly the pattern you want: deterministic cryptography behavior across environments.

How to run

docker build -t pqcheader-mlkem .
docker run --rm pqcheader-mlkem

You should see output like:

ML-KEM supported: True
successful HTTP status
response headers including negotiated key exchange group details

Practical interpretation of results

When you see ML-KEM supported: True, it means your runtime stack actually supports ML-KEM in that environment.
When the server indicates a hybrid group such as X25519MLKEM768, it means the connection negotiated a hybrid classical+PQC key exchange.

That distinction is important:

Capability (IsSupported) tells you what the client can do.
Negotiation result tells you what this specific TLS session actually did.

Final thoughts

For .NET teams, this project is a strong template for early PQC adoption:

no app-layer TLS customization required,
clear runtime capability checks,
explicit Linux/OpenSSL dependency management in Docker,
observable handshake outcome.

If your domain has long-lived confidentiality requirements, this is an excellent starting point to move from theory to implementation.

Alpine-Like Container Security, Debian-Like Compatibility: Why I Picked Chiseled for .NET

Daan Acohen — Thu, 12 Feb 2026 16:31:00 +0000

If you build .NET services in containers, you’ve likely heard the default advice: pick the smallest image.

For production workloads, that rule is incomplete. In practice, runtime image selection is a trade-off between native compatibility, security posture, and image footprint. To make that trade-off concrete, I built a focused benchmark comparing Debian, Alpine, and Ubuntu Chiseled in a native-library scenario: https://github.com/ConnectingApps/DockerImageSizes

For official context on Chiseled containers in .NET, see Microsoft’s announcement: https://devblogs.microsoft.com/dotnet/announcing-dotnet-chiseled-containers/

Why this test is useful for real .NET workloads

A managed-only sample often hides the real problems. Many .NET services eventually rely on native Linux libraries, either directly through P/Invoke or indirectly through dependencies.

So this benchmark uses a .NET 8 app that calls libuuid.so.1 from C#. That creates a clear runtime compatibility signal in each base image.

using System;
using System.Runtime.InteropServices;

class Program
{
    [DllImport("libuuid.so.1")]
    private static extern void uuid_generate(byte[] buffer);

    static void Main()
    {
        Console.WriteLine("Generating UUID using native glibc library...");

        try
        {
            var buffer = new byte[16];
            uuid_generate(buffer);
            Console.WriteLine("Success.");
        }
        catch (Exception ex)
        {
            Console.WriteLine("Exception:");
            Console.WriteLine(ex);
        }
    }
}

Minimal project file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>
</Project>

Docker image variants compared

The benchmark compares these runtime bases:

Debian: mcr.microsoft.com/dotnet/runtime:8.0
Alpine: mcr.microsoft.com/dotnet/runtime:8.0-alpine
Ubuntu Chiseled: mcr.microsoft.com/dotnet/runtime:8.0-jammy-chiseled

Debian Dockerfile

# ===== Build stage =====
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY NativeDemo.csproj .
RUN dotnet restore
COPY Program.cs .
RUN dotnet publish -c Release -o /app

# ===== Runtime stage =====
FROM mcr.microsoft.com/dotnet/runtime:8.0

RUN apt update && apt install -y libuuid1

WORKDIR /app
COPY --from=build /app .

ENTRYPOINT ["dotnet", "NativeDemo.dll"]

Alpine Dockerfile

# ===== Build stage =====
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY NativeDemo.csproj .
RUN dotnet restore
COPY Program.cs .
RUN dotnet publish -c Release -o /app

# ===== Runtime stage =====
FROM mcr.microsoft.com/dotnet/runtime:8.0-alpine

WORKDIR /app
COPY --from=build /app .

ENTRYPOINT ["dotnet", "NativeDemo.dll"]

Ubuntu Chiseled Dockerfile

# ===== Build stage (.NET) =====
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY NativeDemo.csproj .
RUN dotnet restore
COPY Program.cs .
RUN dotnet publish -c Release -o /app

# ===== Extract libuuid from Ubuntu =====
FROM ubuntu:22.04 AS uuidstage
RUN apt update && apt install -y libuuid1

# ===== Runtime stage =====
FROM mcr.microsoft.com/dotnet/runtime:8.0-jammy-chiseled

WORKDIR /app
COPY --from=build /app .

COPY --from=uuidstage /usr/lib/x86_64-linux-gnu/libuuid.so.1 /usr/lib/

ENTRYPOINT ["dotnet", "NativeDemo.dll"]

Reproduction commands

docker build -f Dockerfile.debian -t demo-debian .
docker run demo-debian

docker build -f Dockerfile.alpine -t demo-alpine .
docker run demo-alpine

docker build -f Dockerfile.chiseled -t demo-chiseled .
docker run demo-chiseled

Optional vulnerability scans:

trivy image demo-debian
trivy image demo-alpine
trivy image demo-chiseled

Measured results

These values are from this repository’s benchmark measurement and can change over time as upstream base images are updated.

Variant	Runtime base image	Measured size	Trivy summary (measured)	Native `libuuid.so.1` call
Debian	`mcr.microsoft.com/dotnet/runtime:8.0`	213 MB	87 CVEs (1 critical, 2 high, 24 medium, 60 low)	✅ Works
Alpine	`mcr.microsoft.com/dotnet/runtime:8.0-alpine`	84 MB	0 CVEs	❌ Fails (`DllNotFoundException`)
Ubuntu Chiseled	`mcr.microsoft.com/dotnet/runtime:8.0-jammy-chiseled`	85.5 MB	3 CVEs (all low)	✅ Works

Interpretation for .NET developers

The key point is not that one distro is always “best.” The key point is that measurable trade-offs appear immediately once native dependencies are involved.

In this benchmark:

Alpine is smallest and cleanest on the reported scan, but fails the tested glibc-native call.
Debian works, but has substantially larger footprint and higher vulnerability count in this measurement.
Ubuntu Chiseled is near Alpine in size while still passing the tested native call, with low reported CVE count.

That combination is why Chiseled often looks attractive for production .NET services that need both lean images and practical native compatibility.

Practical decision model

A pragmatic policy for teams:

Start with Ubuntu Chiseled for production services.
Use Alpine when musl compatibility is proven for your full dependency chain.
Use Debian when you intentionally prioritize convenience/broad compatibility over minimal footprint.
Always validate native behavior inside the exact runtime image you ship.

That keeps the decision engineering-driven and reproducible.

Source material:

TUnit + Dependency Injection in .NET Tests: One Registration, Zero Boilerplate

Daan Acohen — Sun, 08 Feb 2026 14:42:11 +0000

Introduction

If your production app uses dependency injection, your tests should too.

With TUnit, you can inject dependencies directly into your test class in a clean, first-class way using DependencyInjectionDataSourceAttribute<TScope>. TUnit’s own docs explicitly recommend this approach for user-provided services.

👉 Example repository used in this article:
https://github.com/ConnectingApps/TUnitPublicDemo

The real problem

Many .NET teams do this well in production:

register services in IServiceCollection
resolve dependencies via constructor injection

But tests often drift into ad-hoc setup:

repeated new calls
test-specific composition roots
fixture patterns that diverge from runtime wiring

That drift increases maintenance cost and weakens refactor safety.

Why TUnit is interesting here

TUnit provides a dedicated DI data source pattern for test dependencies (DependencyInjectionDataSourceAttribute<TScope>), instead of hiding everything behind framework internals.

Also useful context: TUnit positions itself as a modern .NET testing framework with source generation and fast execution characteristics

Main pattern (from the repo)

The repository demonstrates one simple architectural rule:

Use the same service registration extension in production and in tests.

1) Put registrations in one extension method

public static class DependencySetup
{
    public static IServiceCollection AddGravity(this IServiceCollection services)
    {
        services.AddSingleton<IGravityConfiguration, GravityConfiguration>();
        services.AddScoped<IGravityCalculator, GravityCalculator>();
        return services;
    }
}

2) Use it in production (`Program.cs`)

builder.Services.AddGravity();

3) Use it in tests via a TUnit DI attribute

Create a custom attribute inheriting from DependencyInjectionDataSourceAttribute<TScope>, build your ServiceProvider, and resolve constructor parameters from there.

4) Inject dependencies directly into the test class

[GravityDI]
public class GravityCalculatorTests(IGravityCalculator calculator)
{
    [Test]
    [Arguments(100.0, Planet.Earth, 980.7)]
    [Arguments(100.0, Planet.Moon, 162.0)]
    [Arguments(100.0, Planet.Mars, 371.0)]
    public async Task CalculateForce_ReturnsCorrectForce(
        double mass, Planet planet, double expected)
    {
        var result = calculator.CalculateForce(mass, planet);
        await Assert.That(result).IsEqualTo(expected);
    }
}

Result: tests consume dependencies exactly like production code.

Comparison with other popular test frameworks

xUnit: DI is commonly achieved via external libraries and fixture-based patterns; xUnit itself does not natively provide a general-purpose test-class DI container model in the same way this TUnit pattern does.
NUnit: DI is generally extension-driven (e.g., nunit.dependencyinjection / related packages), not a built-in, single canonical DI path for test class construction.
MSTest: DI patterns are commonly custom or sample-based rather than framework-native conventions.

This is exactly why the TUnit approach in your repo feels elegant: fewer moving parts, clear composition root, and constructor-injected tests.

Why this pattern scales

When app and tests share a single registration method:

Refactors are safer (service graph changes once)
Less setup duplication (lower maintenance)
Cleaner tests (behavior-focused, not wiring-focused)

That is especially valuable in medium/large .NET solutions where DI registrations evolve frequently.

Try it quickly

git clone https://github.com/ConnectingApps/TUnitPublicDemo.git
cd TUnitPublicDemo
dotnet build

Run tests:

cd Gravity.Test
dotnet run

Run API:

cd Gravity
dotnet run

Closing thought

If constructor injection is your production default, this TUnit model gives you the same ergonomics in tests—with minimal ceremony and better symmetry across the codebase.

If you want a concrete reference implementation, start here:
https://github.com/ConnectingApps/TUnitPublicDemo

DEV Community: Daan Acohen

Is your REST API actually Quantum-Safe? How to test it in 2026.

The 2026 Reality: Why PQC Matters Now

The "Harvest Now, Decrypt Later" (HNDL) Threat

The "False Positive" Trap

Why curl isn't enough for PQC testing

The Workflow: From Guessing to Knowing

Doing the "Quantum-Safe" Check

Conclusion

Windows Servers Are a Cryptographic Liability: Entire Countries Can Be Left Exposed to Quantum Attacks

What Is Post-Quantum Cryptography (PQC)?

The Hidden Detail Most Developers Miss

Same Code, Different Reality

.NET (Windows → Schannel)

PowerShell

Python (Partial Independence)

Go (Independent)

Rust (rustls)

Node.js

curl (Two Worlds)

The Asymmetry

Why PQC Changes Everything

A Concrete Scenario: The Netherlands Falls Behind

Outside the Netherlands

The Result

The Risk

Why This Is Hard to Fix

This Is Not Just Technical — It’s Geopolitical

Conclusion: Rethink Your Stack Before It’s Too Late

This Forces a Strategic Question

Architecture Matters

Platform

Programming languages

TLS boundaries

Tooling Matters Too

A Practical Alternative: kemforge

Final Takeaway

Is Your Rust App Ready for the Quantum Age? Find out with pqctracer

A Quick Primer: What Is Post-Quantum Cryptography?

Introducing pqctracer

Key features

See It in Action

Why This Matters for Your Services

Get Started

Is Your Node.js App Quantum-Safe? Tracing PQC in TLS Connections

What Is Post-Quantum Cryptography (PQC)?

Why Do We Need a Tool to Check PQC Usage?

How Does pqc-tracer Work?

Installation

Basic Usage

What You Get

Full Response Type

Low-Level API

Does the Node.js Version Matter for PQC?

The Dockerfile

The Run Script (run.sh)

The Main Script (src/index.ts)

Container Output

What Does This Output Tell Us?

Why Node.js Has an Advantage Over Python and .NET

Summary

Verify Post-Quantum TLS Negotiation from Python `requests` on Linux

PQC in two minutes: why it matters

“Harvest now, decrypt later”

NIST has finalized initial post-quantum encryption standards

TLS migration reality: hybrid key exchange

What pqcreader does

⚠️ Important constraints

Installation

Requirements (from the project)

Quick start: trace a real requests.get()

Basic usage (from the README)

What you’re looking for

How it works (high level)

Where pqcreader fits in a PQC readiness workflow

Links

Trace Whether Your .NET `HttpClient` Calls Are Quantum-Safe (PQC) 🚦

Why PQC matters (in practical developer terms)

The typical .NET situation: “TLS happens somewhere below me”

Enter PqcTracer: TLS trace headers for your outgoing HttpClient calls

Why `curl` isn't enough for PQC testing

How Does `pqc-tracer` Work?

The Run Script (`run.sh`)

The Main Script (`src/index.ts`)

Quick start: trace a real `requests.get()`

Enter PqcTracer: TLS trace headers for your outgoing `HttpClient` calls

Outgoing traffic: two ways to trace TLS on `HttpClient`

Approach 2: DI with `IHttpClientFactory` (production-friendly)

Example `Program.cs`

2) Use it in production (`Program.cs`)