Many embedded systems have a limited amount of memory, which would normally run programs with smaller footprints than on desktops or servers. For example, nginx and Apache2 are the common web servers, but on hardware with limited memory, smaller footprint web servers may be required, so that’s why I wrote a list of web servers for embedded systems running Linux/uClinux many years ago.
But now, even platforms based on microcontrollers often need to run web server usually for configuration. We’ve already shown how to use Arduino to serve a simple web page and did the same in Getting Started with NodeMCU Board Powered by ESP8266 WiSoC but using Lua programming language instead. It may be more convenient to run a proper web server however, as it’s easier to change the interface, and we previously covered MicroWebSrv lightweight web server that works on platforms running MicroPython such as Pycom boards.
Real Time Logic offers another open source alternative with their Minnow Server that supports secure connection using secure Websockets instead of HTTPS since the latter consumes too many resources as explained in detail in a blog post. The server is optimized for Single Page Applications (SPA) requiring just one websocket connection to further lower the memory footprint.
Minnow Server supports lwIP raw TCP API port for bare metal targets, as well as various operating systems real-time or not:
- FreeRTOS-TCP
- Microchip Harmony TCP/IP
- Keil MDK
- MQX and RTCS from NXP
- ThreadX and NetX from Express Logic
- POSIX including Linux, Mac, VxWorks, QNX
- Windows Standard Windows and Win CE
- lwIP lwIP Netconn API for RTOS enabled systems
A CSS/HTML5 reference example shows how to build a real-time web user interface for device management, includes real-time updates of LEDs and a thermostat gauge, and shows how to do firmware upload over WebSockets. The complete SPA requires only 41 Kbytes of flash storage, and the company claims it requires very little RAM for the communication. The WebSocket communication library is written in JavaScript and can be reused in other applications.
The source code and instructions to get started with Minnow Server are all available on Github.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
It should be pointed out that the project describes itself (on github) as “A super small and fast embedded HTTP(S) WebSocket server”. Nowhere does it claim to be “a Secure Web Server for Microcontrollers”. This distinction is important as micro controllers (and FreeRTOS) lack any concept of security as applicable to this topic: no user account permissions, no memory protection, no containers, etc.
They cover “secure WebSockets” and “user authentication” in their blog post linked in the article.
For clarity, the project provides a library that accepts incoming HTTP(S) connections and implements the handshake to convert them to WS(S). This allows TLS encryption but does not make any security guarantees outside what SharkSSL (the underlying crypto lib) provides (encryption).
Encryption is not the same as security. This is especially applicable to WS(S) based applications. These applications will typically need to parse their own network packets on the server making them far more susceptible to buffer overflow, pointer arithmetic, or other bug based exploits. On a micro controller, an attacker achieves “kernel” level access to the system rather than simply “user” or even “root”.
The purpose of this post is to hopefully save some developer time trying to explain to their boss why this will not make their IoT offering “secure”.
😉
You are making the assumption that such code is more susceptible to buffer overrun, etc. I think this depends more on the coding style and programmer. Some people should never have been programmers.
>important as micro controllers (and FreeRTOS) lack any concept of security as applicable to this topic:
Mostly true but cortex m’s do have some limited memory protection via the MPU and there is a FreeRTOS port that gives you some isolation between threads.
I’m not sure I get the point really. Implementing client side MQTT is a few hundred lines of code.
Making it “secure” is a case of dropping in a TLS library.
I believe crashoverride already mentioned that Encryption (TLS) is not the same as security. Was that difficult to understand? Sorry for the sarcasm, but MQTT is probably the least secure protocol EVER! MQTT with its wildcard subscription is just ripe for attacks regardless of using passwords/TLS/whatever. Here are a few educational videos for you: https://youtu.be/o7qDVZr0t2c https://youtu.be/g3o_-AiswF0
>I believe crashoverride already mentioned that Encryption (TLS) is not the same as security.
TLS makes the communication “secure”
>Was that difficult to understand?
The misunderstanding seems to be entirely on your side.
>Sorry for the sarcasm, but MQTT is probably the least secure protocol EVER!
>MQTT with its wildcard subscription is just ripe for attacks regardless of using passwords/TLS/whatever.
This is why you have server and client certs so you can verify both ends of the connection and have ACLs in your broker to isolate devices from each other etc.
>Here are a few educational videos for you: https://youtu.be/o7qDVZr0t2c https://youtu.be/g3o_-AiswF0
Those videos just show that connecting stuff to a public broker is a bad idea. Who would have thunk it!
Seems you missed this part: MQTT with its wildcard subscription is just ripe for attacks regardless of using passwords/TLS/whatever
>is just ripe for attacks regardless of using passwords/TLS/whatever
Even with mosquitto you can use client certs with ACLs to isolate clients into a “namespace” created from their clientid. That way clients cannot sub to “#” to see all of the broker traffic and they also can’t subscribe or publish to a namespace that belongs to another client. The ability to abuse wilcards goes down dramatically when the broker has ACLs configured properly.
If you’re really concerned there’s actually no reason you couldn’t create a broker that creates a completely unique environment per connected client. You would lose the ability to publish to multiple clients maybe but if you need that level of isolation then maybe you don’t want that either way.
Anyhow. It’s very easy to google “something something hack”. Get some defcon or whatever videos and then just paste the link as your proof. The hard thing is actually digesting the videos and taking the key arguments from the videos and validating them for yourself.
Most of the videos is based on badly configured brokers that allow you to subscribe to “#”, the connected devices being stupid i.e. allowing passwords etc to be transmitted over MQTT or just misuse of MQTT by using it to transmit private data even though it’s meant to be a shared channel. These aren’t really arguments against the MQTT protocol which is pretty simple. The general takeaway seems to be “don’t put a broker onto the internet unless you know how to configure one properly”.
So you figured out mosquitto (one of many brokers) can do ACL and have layered access. Did you read the docs before or after my comments? The fact remains that a default broker installation has zero security and that is what most people end up using. MQTT will go to the history of being the most exploited protocol EVER!!!
>So you figured out mosquitto (one of many brokers) can do ACL
It seems like you just worked that out because I told you..
>The fact remains that a default broker installation has zero security
And that’s a shame but that’s true for a lot of services you can install via a package manager.
“Most hacked protocol eva!” has to go to DNS really. It’s easy to manipulate and serves as a starting point for many attacks.
To be picky, i have heard that “secure” is not a term used by serurity experts/reserchers, there is only 2 modes, potential failure and failure.