DoS Attacks in Available MQTT Implementations (2021)
st.fbk.eu
st.fbk.eu
Why has the security field degenerated to such a shitshow?
Welcome to the shitshow, it's always been this way in computing, security is always an afterthought.
Not everywhere.
Some places take security seriously. Banks do not fuck around on this front.
Some places security is where they shove all the diversity hires. It's not an afterthought it's a dark corner no one cares about.
Other places have security as theater. I know of quite a few companies who have security tools implemented just to have someone to blame when the fuck up happens. XXX was our provider, were sorry sue them, were going to!
The reality is that the decision makers heard what they should do, and made a choice, not understanding the risk. In that regard some of them are getting better (see theater), and making it worse.
So, I have a fair bit of insight into bank operations and their programming practices.
The vast majority of it is security theater. There is quite a bit of decent code near the core moving money portions, but once you start getting into the webapp side of things it quickly devolves into "Please do the basic minimum to ensure security of this application".
Historically, the "MQ" in "MQTT" came from the IBM MQ (then 'MQSeries') product line, where it stands for "Message Queue". However, the protocol provides publish-and-subscribe messaging (no queues, in spite of the name).[8] In the specification opened by IBM as version 3.1 the protocol was referred to as "MQ Telemetry Transport".[9][10] Subsequent versions released by OASIS strictly refers to the protocol as just "MQTT", although the technical committee itself is named "OASIS Message Queuing Telemetry Transport Technical Committee".[2] Since 2013, "MQTT" does not stand for anything.[11][8]
It would not be possible to shard topics across multiple nodes if there was an ordering requirement per client.
I do understand the ability implied by the lack of guarantee, it just seems entirely unnecessary, especially for home automation. Sharding in general only seems useful for surveillance companies in the business of massively centralizing computing infrastructure to begin with. And furthermore with MQTT it seems similar scalability could be achieved by scaling out across clients rather than across topics. There is little need to disaggregate if you don't aggregate in the first place!
I haven't looked at the HA space, but I guess that explains this absolutely atrocious example they give of a Kafka schema in AsyncAPI.
https://github.com/asyncapi/spec/blob/master/examples/street...
I assume the reason was to keep topics to a single responsibility; if a trigger wants to subscribe to light.state= [on,off] notifications, it only wakes up if that single topic gets notified. It would not have to process light.color notifications or light.brightness notifications.
Sending the smallest payload to the "correct" topic was probably the goal, especially meaning that battery-operated devices only had to monitor the one topic. (Sending gets more complicated, but maybe it balances out in terms of reducing un-needed wakes due to events you do not care about.)
But I agree, that means you lose atomic state change events, unless you also had a topic that had the entire state.
I understand the rationale for multiple topics. I went down this road when I was trying to design the layout for my own MQTT-controlled device. I would have really liked taking advantage of topics as something closer to an in-system semantic model, rather than only using MQTT for a bare minimum stream and then stuffing more layers on top.
FWIW It's not merely losing atomic state changes that's the problem, but rather that updates can end up out of order. For example sending the commands [/light/brightness = 30, /light/state = on] can end up turning the light on with the previous (perhaps full) brightness before dimming it. And mitigating this by creating an additional topic with the entire state undoes most of the advantages of splitting it out in the first place, leaving more complexity and resource usage for little gain.
Published: Jun 5, 2021