HTTP and HTTPS Service Discovery With OTserver Otter

Overview

Industrial devices often expose a web interface alongside their automation protocols. Otter records the response from that interface as service evidence. A title or Server header does not become a device model, operating system, or firmware version.

What Otter requests

For each eligible target, Otter sends one paced GET / to TCP 80 and one to TCP 443. Each request has a two-second deadline and a 64 KiB body limit. The probe does not use proxies, follow redirects, authenticate, send cookies, or retry requests.

HTTP and HTTPS observations retain their own evidence and port source. If body collection fails after headers arrive, Otter keeps the status and Server header already received.

HTTPS trust and scope

For this discovery probe, HTTPS certificate and hostname validation are disabled. A successful response therefore does not establish the server’s authenticated identity or certificate validity. This behavior is separate from TLS settings for uploads and managed controller connections.

With ARP enabled, the probe uses discovered, unambiguous ARP/DCP MAC/IP pairs. Explicit --no-arp permits independent IP probing; replies without a correlated MAC remain unresolved endpoint evidence.

Both listeners are enabled by default and share the HTTP/HTTPS toggle. Use --no-http or noHttp: true in otter.json to disable them together.

Compare discovery protocols or review discovery scope and authorization.