DEV Community

Daan Acohen
Daan Acohen

Posted on

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

#tls #webdev #dotnet

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
Enter fullscreen mode Exit fullscreen mode

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 { }
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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:

  1. It hooks into Kestrel’s TLS authentication flow.
  2. After handshake, it inspects SslStream.
  3. It calls into OpenSSL (libssl.so.3) via P/Invoke.
  4. It retrieves the negotiated group using OpenSSL control APIs (SSL_ctrl) and resolves human-readable names (SSL_group_to_name).
  5. It stores group/cipher values in connection context.
  6. 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

Top comments (0)