I have already addressed security in a different post but on a different, related project: Security and sandboxing
Today I address "antipatterns" as described in https://blog.cloudflare.com/iot-security-anti-patterns/
Let's review the 4 points that are raised :
HTTP Pub/Sub
There is no such thing in the basic HTTaP protocol. There is no redirection or even mention of a third-party URL in the server because the whole thing is meant to be self-contained and autonomous.
DOS is prevented through several passive means:
- Only one client can be connected at a time
- The connection protocol requires exchange of several messages, ensuring that there is no (basic) IP spoofing
- All resources/services that could allow arbitrary "traffic amplification" must be unlocked by a small "are you a fast real-time computer" challenge (to prevent traffic replay)
IoT Device as TLS Server
Encryption is a difficult thing to do, particularly for this class of devices where most corners are cut.
Encryption is not required for now and I don't think I'll use a library, at least for the final version. This is a server-side requirement, since most HTTP clients transparently manage HTTPS.
The suggestion to use a 3rd party server for authentication actually helps a lot, to separate the authentication nightmare from the protocol itself. The HTTaP server can inquire or refresh a key once it starts, which helps a lot when several HTTaP servers are running in parallel (easier and dynamic key management, no more one-configuration-file-per-server nightmare).
But that's for a v2 of the protocol.
Unencrypted Bootloader
This is out of the scope of the protocol.
Database-as-IPC
The HTTaP server can be seen as a sort of database, in a way... but the protocol itself shields against backend implementation variations and their effects.
Note : for security over unreliable networks, whitequark suggests using a nginx layer in this minimalist Python server. I'm not fluent with cryptography and security protocols so I can't devise the best approach...
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.