Every find, every insert, every cursor batch and every ok: 0 - decoded from the wire, without a driver instrumentation, without a profiler on the database, without touching the application.

After PostgreSQL, MySQL, Redis and MQTT, the next datastore natively decoded by Spider Analyzer is MongoDB.

When a container starts, its TLS handshakes happen in the first seconds. If Gocipher attaches its probes late, the secrets of the connections opened in that window are lost, and the matching sessions stay unreadable. Gocipher 1.12.0 and Controller 3.3.0 close most of that gap.

Every publish, every delivery, every acknowledgement, every refused connection - decoded from the wire, without a broker plugin, without a bridge, without touching the devices.

After HTTP, PostgreSQL, Redis, gRPC, Kafka, MySQL and DNS, the next protocol natively decoded by Spider Analyzer is MQTT.

With pub/sub, the hard question is rarely "is the broker up?". It is "who actually reads this topic?", "why is nobody getting these messages?", "which service still listens on that old channel?". The broker knows part of the answer, and your code knows the rest, spread across many repositories.

Spider already sees both sides of every exchange. The Topic Map draws them: producers on the left, channels and topics in the middle, consumers on the right. It started with MQTT. It now covers Redis pub/sub and Kafka.

Gocipher has always needed a place to hook. For OpenSSL it is libssl.so. For Go it is the key-log writer inside the binary. A Java application has neither: the JDK ships its own TLS stack, JSSE, written in Java and running inside the JVM. There is nothing native to put an eBPF probe on. So until now, HTTPS between two Spring Boot services showed up in Spider as a TCP session whose content could not be read.

Gocipher now captures the TLS secrets of running JVMs, on JDK 8, 11, 17 and 21. There is no change to the application, no -javaagent flag and no restart.

Gocipher captures TLS secrets by hooking the TLS library of the application: OpenSSL, Go's crypto/tls, and now the JDK's JSSE. Some runtimes give it nothing to hook. Envoy, and so every Istio sidecar, ships its own BoringSSL inside a static binary. A Rust service using rustls has no libssl at all. For these, Spider showed a TCP session whose content could not be read.

Those runtimes can still be asked to write their TLS key log, the same NSS format that SSLKEYLOGFILE produces for Wireshark. The key log fallback reads that log, without any file.

HTTP/3 moves HTTP off TCP and onto QUIC, over UDP. For anyone observing traffic from the network, that is a step backwards. Everything after the first few packets is encrypted, the packet numbers included. Streams, retransmissions and ordering all live inside that encryption. Headers are compressed against a table that is built on separate streams. Most network tools stop at "UDP 443, some bytes".

Spider now decodes HTTP/3 into the same HTTP communications as HTTP/1.x and HTTP/2: method, URI, status, headers, bodies, gRPC calls and SSE events. There is no proxy, no sidecar, and no change to the client or the server.

QUIC encrypts nearly everything, the handshake included. A passive sniffer sees UDP datagrams full of random-looking bytes and a few connection IDs. Spider now reads DNS over QUIC (DoQ, RFC 9250) from that traffic: every query, every answer, one communication per exchange. It does this without a proxy, without a sidecar and without touching the client or the server.

This post explains how.

"It's always DNS." Everyone running Kubernetes has said it, usually after an hour spent on the wrong suspect. A pod that takes five seconds to start talking to its database. A SERVFAIL that only happens on one node. A service that resolves fine from your laptop and not from the cluster.

The problem is rarely that DNS is complicated. It is that nobody sees it. Until now, Spider didn't either: it showed the HTTP call that came after the lookup, never the lookup itself.

That changes. Spider now decodes DNS from the wire and turns every question into one communication - over UDP, over TCP and over DNS-over-TLS.