Enforce TLS — for data that’s someone’s business

Enforce TLS is a per-device flag you can arm at L0, L1 or L2: with it on, the endpoint refuses plaintext at the door and the payload is unreadable on the wire. Today that means HTTPS, the one TLS listener; MQTTS and TLS-wrapped TCP are planned and do not serve yet.

Two questions, two switches

Levels answer who is allowed to send. This flag answers who can read it. They are independent, and neither contains the other: against a network attacker, encryption wins; against a token leaked into a proxy log, a signature wins, because the attacker still doesn’t have the key. Keeping them apart means you buy an HMAC implementation only if you need integrity, and a TLS stack only if you need confidentiality.

Which matters, because of the five ways into Warble — https., http., mqtt., tcp. and udp. — exactly one can carry TLS. The other four still get the full auth ladder.

What it buys you

Confidentiality, once it’s enforced. With the flag off, whoever can see your traffic can read it, at every level; with it on, an observer learns only that something talked to Warble. This is the floor for business data, customer sites, and anything with a privacy expectation.

The one-click case: a fleet that already speaks HTTPS gets guaranteed encryption the moment you arm this, with zero key distribution and no firmware change.

You turn enforcement on when the firmware is ready

Off is the default, and that is deliberate: it is a debugging aid. Point the device at the TLS endpoint and the platform shows you exactly what arrives — over TLS or in the clear — without going dark while your firmware settles. When its messages are confirmed arriving over TLS, flip the switch: from that moment plaintext is rejected at the door and not stored. Before you flip it, the portal says the plain truth on the device — TLS observed · not enforced — and does not claim a confidentiality it isn’t enforcing.

You can arm it before the evidence arrives — the portal asks you to confirm rather than stopping you, because it is your firmware and you may already know what it sends. If the device is still posting in the clear, every packet is refused from that second; turning the switch back off is the way out. The one combination the API turns down outright is arming it on a spec that declares MQTT, TCP or UDP: there is no TLS listener there at all, so the switch would silence the device permanently while claiming to secure it.

How to protect yourself on the wire

Have a clock. TLS certificate validation needs roughly-correct time; battery devices that sleep for weeks should NTP-sync on wake before connecting (or you’ll debug “works on bench, fails in field” for a day — ask us how we know).
Budget the RAM. An ESP32 does TLS comfortably; an ATmega does not. If your MCU can’t, remember that’s exactly the gap L2 exists to fill — integrity on a plaintext link, no TLS stack required.
Pin our CA, not our certificate. Certificates rotate; the CA doesn’t. Firmware that pins the leaf cert bricks its connectivity on our next renewal.
Encryption is not authentication. An unreadable message from the wrong sender is still the wrong sender. At L0 with this armed, anyone who learns the hardware id can still post as your device — over a link nobody can read. Pick the level as well as the flag.
It protects the pipe, not your account: portal password hygiene and rotating device credentials for decommissioned units still matter.

The quiet upside

Nothing about your dashboard, decoders, or routines changes when you arm this — the flag only changes what the transport demands. Prototype naked on the bench, enforce TLS across the fleet for the customer install, and the cloud side of your project doesn’t notice. The device does: the clock, the RAM and the pinned CA above are firmware work.