[FEATURE] Support for custom path for MQTT over WebSockets

[kuolemaaa]

By default Owntracks tries to establish a connection, using MQTT over WS, contacting <hostname>:<port>/mqtt

It would be cool if there is a way to change that path to something else, customized. Even if one should use the editor in the configuration manager.

[ckrey]

Note: If we implement this, we will need to do this in the iOS app too.

[kuolemaaa]

I also want to add that I would write something about the path used by Owntracks in the log/debug since it only say
[...] Connecting to ws://<hostname>:<port>?# timeout = 30s when it tries to establish a WS connection using a HTTP GET /mqtt.

I was loosing my mind since I though Owntracks asked for / and not /mqtt, I can get that maybe it is the default behaviour for MQTT over WS but I didn't know that and I am not an expert in those.

[...] Connecting to ws://<hostname>:<port>/mqtt?# timeout = 30s I think is better

---

for ref:

GET /mqtt HTTP/1.1
Host: ...
Upgrade: websocket
Connection: Upgrade
[...[

[ckrey]

@kuolemaaa why do you think you need to modify the path? We try to implement standard behaviour not edge cases.

[kuolemaaa]

@ckrey I would like to use MQTT over WS over TLS using a secret long path as a security measure when (or better "where") I cannot use mTLS

[jpmens]

Security by obscurity ("hiding behind a long path") is never a good idea.

[kuolemaaa]

nice textbook answer.

In MQTT over WS over TLS I dont think the path is communicated before the TLS channel is correctly established.

I'm trying to obfuscate my endpoint here, not base my entire security stack on it. Endpoint that will be communicated inside a TLS connection, then WS will do its security stuff and MQTT will do its own authentication stuff.

Not so different from using long random strings that we still send through the wire nowadays (passwords, tokens, you name it)

[growse]

nice textbook answer.

What's your threat model? Why is MQTT credentials insufficient, but MQTT credentials + secret path acceptable?

Not so different from using long random strings that we still send through the wire nowadays (passwords, tokens, you name it)

The state of the art is to explicitly not put secrets on the wire.

A VPN feels like a better control if you want to restrict who can SYN to your endpoint.

[github-actions]

Marking issue with request for more data as stale, due to no updates.