Hi all,

I have signed up for a managed plan to test some features of Cloudron. I really love the promise of a platform that is fundamentally based on managed containers.

The Question/Premise: Assume I want to support students enrolled in a class or academic program. I want each student to be able to have a blog, and perhaps one or more Wekan boards, and so on. From my experimentation, it looks like a single Cloudron instance cannot meet this need?

I created an administrator account and a student account. When I chose WP as one of my apps, both the administrator and the student are writing to the same blog. As a result, each "user" does not have their own blog space on a single (in this case, managed) Cloudron instance. However, each user does have their own Wekan board. Perhaps I'll have my students maintain microblogs in Wekan...

It seems to me that, given the current structure of Cloudron, that to provide every student with their own spaces, I would need:

1. To have a VM for each student, and
2. Provision Cloudron to that VM

We would create common admin accounts on each student VM, and they could then choose which apps to run on each virtual machine. Or, each student could be an admin of their own Cloudron instance. Details, details...

I guess the point of the question is: if I want to get into the space that every one of my students has a "domain of one's own," eg.

astudent.dept.institution.edu

then is it likely that I must run a separate Cloudron instance for every student, or is there a way to simply run one server, with a bunch of RAM, and have each student running their own apps in their own containers?

(All of this might be my own confusion in some way, but I really do think I'm logged into two different browser instances, as two different Cloudron users, and still seeing the same WP instance in both cases. Hence my question.)

Many thanks,
Matt

Hi all,

I'm working on a mosquitto (MQTT) package. I'm... wrestling with testing a variety of clients, and am uncertain where I have a failure with an SSL handshake from one of my devices. Hence, I'm fishing.

When I configure mosquitto, I need to give it the following for TLS to work (in theory?):

certfile /etc/letsencrypt/live/mqtt.example.com/cert.pem
cafile /etc/letsencrypt/live/mqtt.example.com/chain.pem
keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem

Using the TLS addon, I seem to be able to provide... two of these three (certfile and keyfile)? If I'm using the cloudron base image, is there a path I can pass to mosquitto in its config to get a valid cafile?

Why I'm fishing up this stream: I'm wondering if the absence of the cafile is something that could break a TLS handshake? (Some clients I test work fine; some don't. I'm wondering if there's a cipher mismatch or TLS v1.2 vs v1.3 problem here...)

Many thanks,
Matt

@girish In the case, it has to do with embedded systems.

Tasmota is a FOSS firmware that runs on a variety of ESP8266 and ESP32-based devices. (https://en.wikipedia.org/wiki/ESP8266) Think "cheap, wifi-enabled switches and sensors." The 8266 is a wifi-enabled chip (2.4GHz only) that runs at 80MHz, has around 80K of RAM, and typically between 512K and 4MB of external flash (for static code and data storage).

As a result, fitting a full SSL implementation is not an option. BearSSL is used in this context, and a limited number of algorithms are therefore made available from that library. There's only one RSA-based cipher that is included in Tasmota (IIRC).

Hence, I'm going to see if I can package Mosquitto so that one of the TLS ports can use the system-wide LE certs (which could, for example, be used by server-side home orchestration/automation packages like Home Assistant to talk to the MQTT server), but also allow a second port to use the self-signed certs (that can interact with low-spec embedded devices).

Long story short, the SSL limitations are more about the resource constraints of the systems involved (e.g. small IoT devices) than it is about out-of-date software. (mosquitto is an Eclipse foundation project, and effectively the reference standard for MQTT as a protocol, and BearSSL as a library implements more ciphers; MQTT is not the problem, Bear's limitations, somewhat. The limitations of the ESP8266-based IoT hardware is definitely a problem for doing EC ciphers.)

@girish For reference, these are the constraints if we're trying to support Tasmota-based IoT devices using BearSSL:

Your SSL/TLS server must support TLS 1.2 and the RSA_WITH_AES_128_GCM_SHA256 cipher - which is the case with the default Mosquitto configuration
 
The server certificate must have an RSA private key (max 2048 bits) and the certificate must be signed with RSA and SHA256 hash. This is the case with default LetsEncrypt certificates.

The docs are obviously dated, because I don't know that those LE defaults still apply.

@girish In the case, it has to do with embedded systems.

Tasmota is a FOSS firmware that runs on a variety of ESP8266 and ESP32-based devices. (https://en.wikipedia.org/wiki/ESP8266) Think "cheap, wifi-enabled switches and sensors." The 8266 is a wifi-enabled chip (2.4GHz only) that runs at 80MHz, has around 80K of RAM, and typically between 512K and 4MB of external flash (for static code and data storage).

As a result, fitting a full SSL implementation is not an option. BearSSL is used in this context, and a limited number of algorithms are therefore made available from that library. There's only one RSA-based cipher that is included in Tasmota (IIRC).

Hence, I'm going to see if I can package Mosquitto so that one of the TLS ports can use the system-wide LE certs (which could, for example, be used by server-side home orchestration/automation packages like Home Assistant to talk to the MQTT server), but also allow a second port to use the self-signed certs (that can interact with low-spec embedded devices).

Long story short, the SSL limitations are more about the resource constraints of the systems involved (e.g. small IoT devices) than it is about out-of-date software. (mosquitto is an Eclipse foundation project, and effectively the reference standard for MQTT as a protocol, and BearSSL as a library implements more ciphers; MQTT is not the problem, Bear's limitations, somewhat. The limitations of the ESP8266-based IoT hardware is definitely a problem for doing EC ciphers.)

For anyone following along at home... I have, in "draft" form:

1. A Home Assistant app, and
2. An MQTT instance that:
   • uses self-signed certs, and
   • listens on 8883 (the default secure port) with TLS

The self-signed certs are because I'm working against the constraints of BearSSL, which means I need 2048-bit RSA CA/keys and SHA256.

However, the test is that I now have a Sonoff Basic switch that is chattering away at my Home Assistant instance over TLS-secured MQTT.

There's a bunch of cleanup I'd like to do in order to make these apps usable for others. The MQTT container alone might be generally usable... perhaps I can put the LetsEncrypt certs on the default port, and put the self-signed certs on a different port (e.g. 8883 for LE, and 9993 for the self-signed certs...)

And, now that I've thought about it some more.

1. Being able to run a TLS-protected MQTT server is good. It allows full-featured clients to talk to the sever. That said,
2. Embedded devices will need the CA compiled in. (Or, I might be able to get away with a fingerprint. That said...)
3. It would require an RSA cert, no larger than 2048 bits.

This could be more annoying than it is worth. Certainly, having an RSA cert that would play with BearSSL would be nice, but it might not be in the cards.

I'll have to think about whether there are other options/approaches available.

@girish, Based on

https://git.cloudron.io/cloudron/box/-/blob/master/src/acme2.js#L279

which is part of the function Acme2.prototype.createKeyAndCsr, suggesting... it is where the key and CSR are created...

let key = safe.child_process.execSync('openssl ecparam -genkey -name secp384r1');

which suggests a key based on an EC.

But, this is a few minutes of code spelunking. I'm going to hold for a bit, and see if you have any thoughts. I'll do some more reading, but I have a suspicion solving this is going to require more access to box than an app packager currently has.

I wonder if I can include a self-signed cert in the app package that matches the domain as a stop-gap?

Anyway. Thoughts welcome, and thank you.

@girish I have learned more things.

I know/understand certs and PKI at a high level, not at a here's now it works level. I'm in the process of learning more of here's how it works to solve this.

I was able to stand up a container with mosquitto running just fine, and as long as the clients that talked to it were running on full-featured hosts, everything "just worked" (e.g. running mosquitto_sub on another Linux host). This works for a cloudron-packaged version of Home Assistant, which bundles an MQTT client, and performs auto-discovery. It has happily discovered my MQTT container, which is good, and sends messages to it.

However, my mosquitto container did not work with my (one) piece of IoT test hardware. Specifically, it did not work for my little "smart switch," based on an ESP8266 (a Sonoff Basic). This is an 80MHz device with KB of RAM and 1MB of flash. As a result, the Tasmota team uses BearSSL as the SSL implementation, and it only deals with one encryption algorithm and TLSv1.2. It is known to work with mosquitto (being an Eclipse foundation "standard" of sorts in the MQTT broker world). As proof that it works, I can build an insecure container (meaning I configure mosquitto to use comms unencrypted by TLS), and the Tasmota device will talk to the container just fine. That confirmed for me that it wasn't a network issue... it is definitely a cert/encryption question.

But, it looks like there's a cert question w.r.t. the LetsEncrypt certs that cloudron pulls down. Or, that's where I'm going to investigate next.

From a developer on the Tasmota end of things:

I used the laptop version of BearSSL and I got the same error:

build/brssl client mqtt.example.com:443 -cs ECDHE_RSA_WITH_AES_128_GCM_SHA256
WARNING: no configured trust anchor
connecting to: 1.2.3.4 connected.
Algorithms:
    RNG:           rdrand
    AES/CTR:       pwr8
    GHASH (GCM):   pclmul
    EC:            all_m31
    RSA (vrfy):    i62
 ERROR: SSL error 296 (received alert 40)

Using OpenSSL shows that Server public key is 384 bit
We don't support EC keys for servers, they need to be RSA 2048 or 4096. In general we don't support ECDSA. You need to generate a new certificate with RSA private/public key

Now, this is where I need to do more learning. Does cloudron pull an elliptic-curve-based cert (as opposed to an RSA-based cert), and that's going to be something I need to work around? (For example, I could bundle self-signed certs into the mosquitto container, or generate them when the container is launched, or...). Or, is there something I don't (yet) know about cloudron that will let me solve/work around this?

If y'all have insight, I welcome it. In the meantime, I'm going to go digging into the box source, and find out what happens when cloudron requests LE certs on my behalf.

When I'm done, I'll document all of this somewhere, so that people following after me don't have to walk the same path.

Cheers,
M

@girish Many thanks; that was useful to know about/something I did not know existed (the LE cert page), but sadly didn't solve my problem. (I was hoping for magic.)

I'm going to call it a day; it is clear that mosquitto should support the cipher that tasmota is offering, but I keep getting

error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher

on the broker side. I hoped that this might be a "missing piece."

When I have this figured out, I'll feel better about suggesting there possibility of a viable MQTT container.

(My goal here is to pair it with Home Assistant, and know that Tasmota, an open source firmware for home automation devices, will work with the MQTT broker.)

Hi all,

I'm working on a mosquitto (MQTT) package. I'm... wrestling with testing a variety of clients, and am uncertain where I have a failure with an SSL handshake from one of my devices. Hence, I'm fishing.

When I configure mosquitto, I need to give it the following for TLS to work (in theory?):

certfile /etc/letsencrypt/live/mqtt.example.com/cert.pem
cafile /etc/letsencrypt/live/mqtt.example.com/chain.pem
keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem

Using the TLS addon, I seem to be able to provide... two of these three (certfile and keyfile)? If I'm using the cloudron base image, is there a path I can pass to mosquitto in its config to get a valid cafile?

Why I'm fishing up this stream: I'm wondering if the absence of the cafile is something that could break a TLS handshake? (Some clients I test work fine; some don't. I'm wondering if there's a cipher mismatch or TLS v1.2 vs v1.3 problem here...)

Many thanks,
Matt

Hi all,

I have signed up for a managed plan to test some features of Cloudron. I really love the promise of a platform that is fundamentally based on managed containers.

The Question/Premise: Assume I want to support students enrolled in a class or academic program. I want each student to be able to have a blog, and perhaps one or more Wekan boards, and so on. From my experimentation, it looks like a single Cloudron instance cannot meet this need?

I created an administrator account and a student account. When I chose WP as one of my apps, both the administrator and the student are writing to the same blog. As a result, each "user" does not have their own blog space on a single (in this case, managed) Cloudron instance. However, each user does have their own Wekan board. Perhaps I'll have my students maintain microblogs in Wekan...

It seems to me that, given the current structure of Cloudron, that to provide every student with their own spaces, I would need:

1. To have a VM for each student, and
2. Provision Cloudron to that VM

We would create common admin accounts on each student VM, and they could then choose which apps to run on each virtual machine. Or, each student could be an admin of their own Cloudron instance. Details, details...

I guess the point of the question is: if I want to get into the space that every one of my students has a "domain of one's own," eg.

astudent.dept.institution.edu

then is it likely that I must run a separate Cloudron instance for every student, or is there a way to simply run one server, with a bunch of RAM, and have each student running their own apps in their own containers?

(All of this might be my own confusion in some way, but I really do think I'm logged into two different browser instances, as two different Cloudron users, and still seeing the same WP instance in both cases. Hence my question.)

Many thanks,
Matt