Minnow Server is a Secure Web Server for Microcontrollers

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.

Minnow Server Secure Websocket

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.

13
Leave a Reply

avatar
3 Comment threads
10 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
5 Comment authors
Willhelmdgpcnxsoftcrashoverride Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
crashoverride
Guest
crashoverride

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.

dgp
Guest
dgp

>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.

dgp
Guest
dgp

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.

Willhelm
Guest
Willhelm

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

dgp
Guest
dgp

>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!

Willhelm
Guest
Willhelm

Seems you missed this part: MQTT with its wildcard subscription is just ripe for attacks regardless of using passwords/TLS/whatever

dgp
Guest
dgp

>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”.

Willhelm
Guest
Willhelm

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!!!

dgp
Guest
dgp

>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.

Member

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.