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.

Share this:

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard
Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
13 Comments
oldest
newest
crashoverride
crashoverride
5 years ago

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.

crashoverride
crashoverride
5 years ago

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… Read more »

Willhelm
Willhelm
5 years ago

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.

dgp
dgp
5 years ago

>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
dgp
5 years ago

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
Willhelm
5 years ago

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
dgp
5 years ago

>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… Read more »

Willhelm
Willhelm
5 years ago

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

dgp
dgp
5 years ago

>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… Read more »

Willhelm
Willhelm
5 years ago

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
dgp
5 years ago

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

Anton Fosselius
5 years ago

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.

Khadas VIM4 SBC