Super Funicular

Posted on Oct 14

If Nothing on the Camera Listens, Something Else Has To: Outbound-Only vs. a Local Viewer, and Where the Trust Moves

#networking #security #iot #android

Earlier this week we published a two-phone test for whether your phone security camera is reachable from the internet on IPv6. In the comments, a reader described how they sidestep the whole question in their own apps: the phone never listens for incoming connections. Everything is outbound. The phone dials out, and nothing can dial in.

That is a good design, and it is worth taking seriously, because it is the other half of the picture. There are really only two shapes a remote camera can take. Each one is safe in a different place, and each one fails in a different place. This piece lays them side by side.

The two shapes

Shape A: the camera listens. The phone runs a small server. Your browser opens a connection to the phone. A local web viewer works this way.

Shape B: the camera dials out. The phone opens a connection from itself to some other machine, and keeps it open or pushes data through it. You then watch from that other machine, not from the phone. Cloud cameras work this way. So does pushing a live stream to a platform like YouTube Live.

The difference is not "local versus cloud" or "secure versus insecure". The difference is who is allowed to start the conversation. That one choice decides where the risk ends up.

Shape A: what keeps a listening camera private

When the camera listens, two separate things have to hold:

Reachability. Strangers must not be able to get a packet to the listening port.
Authorization. If they do, the page must refuse them.

On IPv4 home Wi-Fi, reachability is usually handled by NAT, by accident. The phone has a private address, and the router has nothing to match an unsolicited incoming connection to, so it drops it.

On IPv6 there is usually no NAT. The phone has a globally valid address, and reachability becomes the job of the router's IPv6 firewall. The IETF's guidance for home routers, RFC 6092, recommends refusing unsolicited inbound connections by default, but it is an informational document, and it also says a "transparent mode" that lets everything in "MAY be the default configuration." That is why the test in the earlier article exists: you check, rather than assume.

So Shape A fails open at the network edge. If the firewall is off, or a pinhole was opened and forgotten, the listening port is exposed, and only the page's password stands in the way.

What Shape A gets right is that nobody else is involved. The video goes from the phone to your browser on the same network. There is no third party that has to exist, stay honest, or stay in business.

Shape B: what an outbound-only camera trades

When the camera only dials out, there is nothing on the phone for a stranger to connect to. There is no port for a firewall to get wrong. That is the reader's point, and it is correct.

But a viewer still has to reach the video somehow. If neither side can call the other directly, they need somewhere to meet: a relay, a broker, a cloud service, or a streaming platform. And that meeting point now carries the two jobs the router and the page carried in Shape A.

Reachability moves to the meeting point. It is reachable from the whole internet by design. That is its purpose.
Authorization moves to the meeting point too. It decides who may see which camera.

That is not a flaw. It is a trade. But it means the safety of Shape B is only as good as the meeting point's answer to one question: what does a stranger need to know to be connected to a camera?

When the meeting point asks for too little

We wrote about a case where the answer was "very little" in Operation CameraSwarm. Dahua's P2P feature lets a camera behind NAT be found through a vendor relay by its serial number. ITRES Labs, analysing an earlier incident, described the mechanism on older firmware: "the relay establishes the route without prior authentication, leaving login checks to the device's web application."

Read that against the two jobs above. The cameras were behind NAT, so the router was doing its part. The relay then provided reachability anyway, from anywhere, to anyone holding a serial number. Reachability and authorization had been split, and the first step needed only an identifier.

Shape B did not remove the exposure. It moved it to a place the owner could not inspect or configure.

The outbound connection is still a channel

One more subtlety. "Outbound-only" describes who opens the connection, not which way data can flow once it is open. A long-lived outbound connection to a broker is a two-way pipe. The meeting point can send things back down it: commands, configuration, firmware. That is often the point. It also means the camera trusts whatever is on the far end of that pipe.

Side by side

	Shape A: camera listens (local viewer)	Shape B: camera dials out (relay, cloud, stream push)
Who starts the connection	The viewer	The camera
Open port on the phone	Yes	No
Third party required	No	Yes, the meeting point
What keeps strangers out	Router (NAT on IPv4, firewall on IPv6) + page password	Meeting point's access rules
Can the owner inspect it	Yes: router settings, the two-phone test	Usually not
Typical failure	Firewall off or pinhole left open	Meeting point authorizes on too little
Where the video travels	Phone to your browser	Phone to the meeting point, then to the viewer

Neither column is free of risk. They put the risk in different hands.

A stream push is Shape B with a meeting point you already know

Pushing a live stream to YouTube Live is a clean example of Shape B. The phone opens an outbound connection to YouTube's ingest servers and sends video. Nothing connects in to the phone. Viewers watch on YouTube.

The meeting point here is a large platform, and the authorization question becomes a setting you control: the stream's visibility. YouTube lets a stream be public, unlisted, or private. That choice is now your access rule. An unlisted link is closer to "anyone who knows the address" than to a password, so treat it that way.

This is also a case where Shape B is honest about its trade: you know exactly who the third party is, and you chose them.

So which one should a phone camera use?

Use the shape that matches where you watch from.

You only watch at home, on the same Wi-Fi. Shape A fits. No third party, no account, and the video never leaves your network. Run the two-phone test once, and again after a router reset, firmware update, or change of ISP. Keep a password on the page.
You need to watch from outside. Do not open an inbound port to make Shape A reach the internet. Use Shape B with a meeting point you chose on purpose and can describe in one sentence: who runs it, and what a stranger would need in order to watch. Our earlier comparison of ways to watch from outside without port forwarding walks through the options.
You use both. That is fine, as long as each path is checked on its own terms. The local viewer still depends on the router. The outbound stream still depends on the platform's settings.

The rule from the Kimwolf piece still holds: a camera should never need an open inbound port to the internet to be useful. Shape A keeps its port on the local network. Shape B has no port at all. What it has instead is a meeting point, and that deserves the same scrutiny you would give a router.

The short version

A remote camera either listens or dials out. The choice decides where the risk lives.
Listening keeps third parties out, but depends on your router: NAT on IPv4, a firewall that may not be on for IPv6.
Dialling out removes the open port, but needs a meeting point that is reachable by everyone and decides who gets in.
When a meeting point connects strangers on too little, such as a serial number, the exposure has not gone away. It has moved somewhere you cannot see.
Pick the shape for how you watch, and check the part that carries the risk.

Background Camera RemoteStream happens to offer both shapes: a live view served from the phone for browsers on your own Wi-Fi, and an optional push to YouTube Live when you want to watch from outside. It records with the screen off to the phone's own storage. No account, no cloud storage, no subscription. More at superfunicular.com.

Sources

DEV Community