scan.pqprobe.com

What runs from 159.69.181.191 and 2a01:4f8:c013:e07b::1, and how to opt out.

What these addresses do

The addresses 159.69.181.191 and 2a01:4f8:c013:e07b::1 originate scans for pqprobe.com, a measurement of post-quantum preparedness in TLS deployments on the public internet. Every address a target name resolves to is dialed, IPv4 targets from the first address here and IPv6 targets from the second. Each scan cycle, the scanner makes two kinds of short-lived connection to a small published target list:

• HTTPS, port 443. One full TLS handshake, then a series of short connections that each send a single ClientHello, read the server's first reply, and close without completing the handshake. Each of those ClientHellos offers one protocol version, one cipher suite, or one key-exchange group, so that what the server accepts is observed rather than inferred. Old versions and weak suites are among the offers for that reason; an acceptance is recorded, never used. Each address the hostname resolves to is dialed separately: the full series against the first address of each address family, three connections against any others. We record the negotiated TLS version, cipher suite, key-exchange group, certificate chain, and which offers the server accepted, refused, or left unanswered.
• SMTP, ports 25 and 587 with STARTTLS, port 465 with TLS from the first byte. On 25 and 587 every connection reads the greeting, sends EHLO scan.pqprobe.com and STARTTLS, and continues only after the server's 220: first one full TLS handshake, ended with QUIT, then the same single-ClientHello series as HTTPS, each probe on a connection of its own with its own greeting, EHLO and STARTTLS before it. On 465 the connections are TLS from the start, as on 443. We record the same TLS parameters as above, and whether STARTTLS was offered.

What these addresses do not do

• No MAIL FROM, no RCPT TO, no DATA. An SMTP session ends at the TLS handshake, or at the server's first TLS reply on a probe connection. The scanner never reaches the mail-content stage of the protocol and never delivers mail.
• No authentication attempts. No AUTH, no credential probing, no STARTTLS-downgrade testing.
• No vulnerability exploitation. Offering a version or suite and recording the answer is the whole of the measurement. The only handshake carried to completion is the one default handshake; every probe connection ends at the server's first reply.
• No port sweeps. Only the ports above, and only against hosts on the published list.
• No payload retention beyond the TLS parameters listed above. Banners and EHLO responses are not published.

Cadence and load

One cycle every 24 hours. The current target list is under 1,500 hosts. Per-address load is one full handshake plus up to about sixty single-ClientHello connections per cycle, each open for one round trip and sent one after another, never in parallel against the same host. Probes to one address are spaced at least 25 milliseconds apart; when the host resets, refuses or closes a probe connection without answering, or leaves a single-group probe unanswered, the scanner sends its default hello once more: answered, the close or the silence is recorded as the host declining that probe and the spacing stays; unanswered after a close, the spacing doubles, up to 400 milliseconds, and the probe is sent again at the wider spacing. A host that needed the wider spacing gets it from the first probe of its next cycle. A probe that gets no answer at all is retried once after a pause of a few seconds and does not widen the spacing; once a host stops answering a kind of probe, the remaining probes of that kind are skipped for the cycle.

Identifying this traffic in your logs

Source IP

159.69.181.191

2a01:4f8:c013:e07b::1

Reverse DNS

scan.pqprobe.com

HTTPS SNI

the target hostname

SMTP EHLO host

scan.pqprobe.com

Why this scan exists

Post-quantum cryptography is being added to TLS implementations now because adversaries can record encrypted traffic today and decrypt it later, once cryptographically relevant quantum hardware exists. Knowing whether public TLS deployments actually negotiate post-quantum key exchange, as opposed to merely supporting it in their crypto library, requires connecting to those deployments and observing the handshake. That measurement is what runs from these addresses.

Operator

pqprobe is operated by Davi Ottenheimer.

The scanner is closed source. Its behavior, the ports it touches, and what it records are described on this page and at pqprobe.com/docs; questions about either go to the address below.

Opt out

To remove a host or network from the scanner, email abuse@pqprobe.com with the hostname, IP, or CIDR. No account, form, or repository access is needed; the email address is the whole process.

What happens then:

• The entry is added to the scanner's exclusion list.
• Scanning of that host or network stops within one scan cycle, 24 hours, of the next deployment.
• The exclusion is permanent unless you write again to reverse it.

You do not need to explain why, and a request from anyone operating the address is honored without further checks.

If you are reporting suspected abuse rather than requesting an opt-out, the same address reaches the operator directly.

Why publish this page

Mail and web operators reading their logs deserve a way to identify unfamiliar inbound connections and a working path to stop them. Publishing the operator, the scope, and an opt-out address turns an unidentified scanner into a known, accountable one. This page is the canonical reference; if anything here is unclear or out of date, write to the address above.

Last updated 2026-07-27.