Casper P2P TLS-1.3 P-521 pre-auth ECDSA verify burn

A Casper node's P2P listener is a TLS-1.3 acceptor that performs a full P-521 ECDSA signature verification on the client's self-signed certificate BEFORE any admission gate, allowlist, or per-peer cap. An unauthenticated peer can flood fresh-cert-per-connection TLS-1.3 handshakes (no application bytes ever sent), forcing the node to burn crypto-CPU on one P-521 cert.verify() per connection — with no pre-crypto admission gate at all: the verify runs before the allow_handshake guard and before the per-peer concurrency cap (network.rs:555, default 0 = unlimited), which is only applied after the crypto completes.

Why this matters

The exposed party is any Casper node running the default P2P listener configuration. The TLS-1.3 acceptor runs unconditionally at tasks.rs:341 (server_setup_tls), meaning the TLS handshake executes before the allow_handshake guard at tasks.rs:370 and before the per-peer cap at network.rs:555 (whose default is 0 = unlimited). Post-TLS, the node runs validate_self_signed_cert (tls.rs:500-540), which verifies an attacker-controlled certificate using P-521 ECDSA with SHA512 — an asymmetric-crypto operation that is computationally expensive relative to a simple connection filter.

Two properties make this more than a theoretical cost. First, the crypto work happens pre-authentication — the attacker needs no valid server pubkey, no completed handshake, and no application-layer protocol compliance. A single connection to a fresh IP address suffices to force one full P-521 signature verification. Second, there is no pre-crypto gate — no rate limit, no allowlist, and no per-peer cap runs before the verify. The single concurrency counter (network.rs:555) defaults to unlimited and is applied after the crypto, so it does not bound this cost. A single source suffices; the ceiling is the node's crypto-CPU capacity, not any admission or rate gate.

The impact is availability-only: honest peer connection degradation from pre-auth crypto-CPU saturation. The node continues to produce blocks on Casper's separate PoS consensus path; this is not a consensus halt, nor is there any funds or authentication bypass. The ceiling is fullnode peering availability, not chain halt.

How the attack works

• Entry point: the TLS-1.3 ClientHello that an unauthenticated peer sends to Casper's P2P port. The malicious field rides inside the client's self-signed X.509 certificate (serial 1, subject == issuer, curve SECP521R1, ECDSA-SHA512 signature).
• Preconditions: the attacker can reach the P2P port from any IP. No auth, no allowlist entry, no valid server pubkey, no completed application handshake required. Remote, unauthenticated, pre-consensus.
• Processing path:
  1. TLS handshake runs unconditionally. server_setup_tls at tasks.rs:341 sets up the TLS-1.3 acceptor configured in tls.rs (SslVerifyMode::PEER, verify callback returning true). This runs before allow_handshake (the admission guard at tasks.rs:370) and before the per-peer cap (network.rs:555).
  2. Certificate verification is P-521 ECDSA. Post-handshake, validate_self_signed_cert at tls.rs:500-540 calls cert.verify() on the attacker's self-signed certificate. The curve is SECP521R1, the hash is SHA512, and this is a full ECDSA signature verification — expensive asymmetric-crypto work.
  3. Per-peer cap is post-crypto. The per-peer cap at network.rs:555 has a default value of 0 (unlimited) and is applied after the TLS handshake and certificate verify complete. The attacker sends a fresh certificate per connection, so each connection burns the full P-521 verify cost regardless of any cap.
• Boundary crossed: attacker-controlled certificate bytes reach a full P-521 ECDSA verify on the server's crypto-CPU, before any admission decision or per-connection cost gate.
• Resulting behaviour: crypto-CPU burn and honest-peer connection degradation. A single IP can drive continuous churn — no pre-crypto per-source cap or admission gate exists to stop it. The ceiling is the node's crypto-CPU capacity.

The mechanism is a pre-auth asymmetric-crypto cost-gating gap, not a memory-safety bug or authentication bypass. P-521 ECDSA with SHA512 is the curve/hash pair used; the verify cost is the attack surface.

Affected systems

• Severity: Medium (per NR-2026-039) — pre-auth crypto-CPU burn with availability-only impact (honest peer degradation, not consensus halt).
• Chain: Casper.
• Implementation: casper-node. Source-traced at commit ee2fe18.
• Component: P2P TLS-1.3 acceptor (SslVerifyMode::PEER) → validate_self_signed_cert (P-521 ECDSA verify).
• Gated on: the attacker reaching the P2P port. There are no pre-crypto gates — no per-source rate limit, allowlist, or admission gate runs before the P-521 verify; the per-peer concurrency cap (network.rs:555) defaults to unlimited and runs post-crypto. A node with a per-source-IP rate limit applied before the TLS handshake, and with slots reserved for established peers, is not affected by this path. No other chains or clients are claimed.

Evidence

• Publicly documented: none as a CVE. This is NullRabbit original source-traced research; Kraken-listed, non-Coinbase asset → publish-track under NullRabbit's disclosure-scope policy (availability-only DoS is out of paid scope).
• Source-traced (not live-measured): the server-side crypto-CPU burn is source-traced, not independently measured on a production-shape node. The advisory explicitly states: "the server-side crypto-CPU burn is the source-traced mechanism, not an independent server-side CPU measurement." No measured latency, handshake-rate, or core-saturation numbers are asserted.
• Independently reproduced by NullRabbit (lab, traffic-modelled): the published corpus reproducer (casper_p521_preauth_verify_burn, source_class=original, shipped in NullRabbit/nr-bundles-public) captures the wire signature — a churn of inbound TLS-1.3 handshakes with fresh P-521 certificates, each triggering the server's cert.verify() pre-auth. The reproducer targets a local self-owned mock and demonstrates the pre-auth-connection-churn pattern; it does not measure server-side CPU saturation.
• Not established: no live/mainnet CPU measurement, no handshake-rate or core-saturation figures. The advisory stands on the source trace, not on measured saturation numbers. The P-521 verify cost is a property of the curve/hash pair and Rustls/OpenSSL's implementation, not a measured value from this reproducer.

Operator actions

Available today (per NR-2026-039):

• Cost-gate the pre-auth crypto per source IP — apply a per-source-IP rate limit or cheap proof-of-work BEFORE the TLS handshake runs, so an unauthenticated peer cannot force unbounded P-521 ECDSA verifies.
• Make the per-peer cap a real admission gate — the per-peer cap at network.rs:555 defaults to 0 (unlimited) and is applied after the crypto. Move a rate/admission decision ahead of the TLS handshake.
• Reserve slots for established peers — ensure fresh-socket churn cannot displace or starve honest, verified peers.

Canonical references

• NRDAX technique: NRDAX-T0205 — pre-handshake-crypto-cpu-burn (family compute_amp).
• NullRabbit advisory: NR-2026-039 — Casper, Conflux & Icon: pre-auth crypto-CPU burn (published 2026-07-13).
• Evidence bundle (Hugging Face): NullRabbit/nr-bundles-public — primitive casper_p521_preauth_verify_burn (5 bundles shipped).
• Upstream primary sources: casper-node tls.rs:500-540 (validate_self_signed_cert), tasks.rs:341 (server_setup_tls), network.rs:555 (per-peer cap, post-crypto).

Related attacks

• Same family: compute_amp — pre-auth asymmetric-crypto cost-gating gaps. NR-2026-039 also documents cfx_ecies_preauth_ecdh_burn (Conflux, secp256k1 ECDH) and icon_goloop_preauth_ecdh_burn (Icon, P-256 ECDH) — all pre-auth, all source-traced, all availability-only.
• Same technique class: NRDAX-T0205 (pre-handshake-crypto-cpu-burn) also covers Bitcoin Core BIP-324 v2 transport pre-auth secp256k1 ellswift-ECDH — a different implementation, same class.
• Measured sibling: NR-2026-037 (Qtum BIP-324) is the same family but carries an independent CPU measurement on a DigitalOcean production shape, which this Casper finding does not have.

Track attacks affecting Casper and other Kraken-listed chains on NRDAX and in NullRabbit research.

Source-traced mechanism + wire-signature reproducer. No measured production CPU saturation numbers.