An IDS probe cannot see TLS

IDS labs have genuine teaching value. You stand up Suricata, wire in DVWA, replay a few web attacks and watch the rules fire live, which helps a great deal in understanding how a probe works. The problem is not the lab, it is the move to production, where one structural detail changes everything: TLS.

Why the lab works

If the lab works so well, it is precisely because DVWA runs over HTTP. The traffic flows in clear text, the probe reads it byte by byte and signatures can inspect requests as well as responses without the slightest difficulty. It is the same comfort you get when you pull out tcpdump on an unencrypted flow, or hack together a homemade sniffer to watch the packets go by: as long as the payload is readable, all is well.

In a real environment, that comfort disappears. Web traffic is encrypted and a probe placed in promiscuous mode, which merely observes a copy of the traffic, now sees nothing but TLS flows. It can tell that something is happening, it can read envelope metadata, but the application content stays closed to it, so Suricata can no longer inspect what actually matters.

Why you do not decrypt on the fly

The temptation would be to decrypt the flow as it passes, on the probe, without touching either the client or the server. That is a fundamentally hard problem and it is hard by design. TLS was built precisely to stop a third party in the middle from reading or altering the conversation, so any device claiming to inspect content from a mere copy of the traffic runs straight into what the protocol was conceived to prevent.

In other words, network mirroring, which remains an excellent approach on clear-text traffic, loses much of its point the moment the payload is encrypted end to end.

Inspect where TLS is terminated

The answer is not to force the encryption, but to stand where it ends on its own.

For production web traffic, the complementary approach is to place inspection at the reverse proxy, that is, at the exact spot where TLS is terminated and the traffic becomes readable again. You can fold in a WAF there, or export application logs to a collector such as Wazuh to correlate them elsewhere.

This approach has several virtues. It does not touch the target servers any more than mirroring would, it slots into a building block that usually already exists in the architecture and above all it sees the traffic in clear text without imposing a whole mirroring infrastructure. It is the same spirit as putting a TLS terminator in front of sensitive infrastructure, easy to maintain and to audit, rather than piling up proprietary technologies that are hard to audit and nearly impossible to patch live. For more on that edge placement, see ingress hardening and for a concrete reverse-proxy case in front of a closed application, nginx in front of Perforce .

Your IDS is blind

• A plain-HTTP IDS lab is excellent for learning, but it hides the production blind spot.
• In the real world, web traffic is encrypted and a promiscuous probe sees only TLS.
• Decrypting on the fly without touching client or server is fundamentally hard, TLS is made for that.
• You inspect where TLS is terminated: reverse proxy, WAF, application logs shipped to Wazuh.
• This approach leaves the target servers untouched, reuses an existing block and avoids all mirroring.