There are a few different reasons to hit the brakes on a Postgres query. Maybe it’s taking too long to finish. Maybe you realised you forgot to create an index that will make it orders of magnitude quicker. Maybe there’s some reason the results are no longer needed. Or maybe you, or your LLM buddy, […]

Neon

When you press Ctrl-C in psql to cancel a running Postgres query, the CancelRequest is sent as a new, separate TCP connection using a special protocol magic number. Critically, psql always sends this request unencrypted — even when the original connection uses strict TLS settings. This exposes a Denial-of-Service vulnerability: anyone who can intercept network traffic can replay the cancellation request to cancel any future queries on that connection. While Postgres 17 added encrypted cancellation support in libpq, and Postgres 18 introduced longer secret keys (up to 256 bytes) via protocol v3.2, psql itself still doesn't use these features by default. The post also covers how this unencrypted CancelRequest breaks SNI-based Postgres proxies like Elephantshark, and how the fix involves mapping (process ID, secret key) pairs to destination hostnames. Mitigations include using Postgres 18 with min_protocol_version=3.2, using a VPN, or avoiding Ctrl-C in psql.

Ctrl-C in psql gives me the heebie-jeebies