Post-quantum TLS (X25519MLKEM768) for app domains on port 443

[marcusquinn]

Connections to app domains on port 443 currently use classic X25519. I checked one of my app domains: TLS 1.3 negotiated X25519. The host nginx is 1.24.0 with OpenSSL 3.0.13 (Ubuntu 24.04), which has no ML-KEM support.

This matters because of "harvest now, decrypt later": recorded traffic (logins, session tokens, API calls, secrets shown in dashboards) could be decrypted later by a quantum computer — or AI math attacks on current encryptions.

Inside an app container, nginx 1.28.3 with OpenSSL 3.5.5 already serves TLS 1.3 with the hybrid X25519MLKEM768 group. My NetBird package does this on its dedicated client port. App packages can't change port 443, though, because that's the host nginx.

Request: build or ship the host nginx against OpenSSL 3.5+, and offer hybrid post-quantum key exchange with classic fallback, e.g. ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;. Current Chrome, Edge, Firefox and Safari would use it automatically, and older clients would keep using X25519. An admin toggle would be fine too.

Happy to help test.

[huehner]

Hi @marcusquinn ,
you should be able to that much easier by updating your Ubuntu 24.04 host OS to 26.04 (LTS)

26.04 ships recent enough openssl + nginx build against that.
Also mentioned / explained here:
https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users/#post-quantum-cryptography-support
https://discourse.ubuntu.com/t/post-quantum-support-in-the-upcoming-26-04-lts/76840

On a cloudron.io running on 26.04 that is enough to get PQ key-exchange out of the box.

If cloudron.io wants to fork + maintain both openssl + nginx packaging to get same on older 24.04 LTS is topic for them

But personally i don't think that might be a very good idea. As that would be lots of work to do + get stable + keep updated constantly (!).
Especially if you continue thinking to do that work more fully and not 'just' the external nginx
But probably also

• host openssh
• haraku + dovcecot (mail-server incoming + outgoing)
• probably more things to check and test

[marcusquinn]

@huehner thanks — just discovered that shortly after posting. We're all good then, and safe from the future

[marcusquinn]

Follow-up with measured results, now that I've moved three Cloudron servers to Ubuntu 26.04, for anyone finding this post and wondering...

Short version: upgrading the host OS to Ubuntu 26.04 makes Cloudron's own port-443 nginx negotiate hybrid post-quantum key exchange (X25519MLKEM768) by default. Cloudron needs no config change, and classic clients still connect.

What I measured (openssl s_client -groups <group> against each dashboard and app domain on 443, before and after the upgrade):

Host OS	OpenSSL	nginx	X25519MLKEM768	SecP256r1MLKEM768	X25519	P-256
Ubuntu 24.04	3.0.x	1.24	refused	refused	accepted	accepted
Ubuntu 26.04	3.5.5	1.28.3	accepted (negotiated by default)	refused	accepted	accepted

• Same result on Cloudron 10.0.5 and 10.1.5.
• Cloudron's generated nginx config has no ssl_ecdh_curve directive, so it inherits OpenSSL 3.5's default group list. That list prefers X25519MLKEM768.
• With no group forced, a modern client now negotiates X25519MLKEM768. Older clients fall back to X25519/P-256 as before.

So for anyone asking how to get PQ TLS on the Cloudron dashboard and apps, the answer today is to upgrade the host to 26.04 following the official guide (https://docs.cloudron.io/guides/upgrade-ubuntu-26). This needs no packaging or app changes.

Upgrade notes from doing three servers (Hetzner Cloud, 22.04/24.04 → 26.04), in case they save someone time:

1. Take a fresh Cloudron backup and a provider snapshot first. Hetzner snapshots do not include attached Volumes, so the Cloudron backup is what covers data stored on them.
2. If an earlier dpkg run hung in shim-signed/GRUB configuration, compare debconf-show grub-pc grub-efi-amd64 with /dev/disk/by-id/. Stale device IDs make the GRUB prompt loop even in noninteractive mode.
3. Hetzner Cloud x86 guests boot via BIOS. Before each reboot, I ran grub-install --target=i386-pc /dev/sda && update-grub.
4. Older Hetzner images can have both a cloud-init ifupdown config and netplan defining the same interface. After the upgrade, networking.service failed with "address already assigned". The netplan config was correct, so I backed up and disabled the duplicate ifupdown file.
5. On 26.04, follow the guide's MySQL 8.4 step (stop box, install mysql-server, re-run the box setup script, start box). After that, cloudron-support --troubleshoot passed cleanly and every app came back with the same state and health as my pre-upgrade baseline, including four Nextcloud instances.
6. Check whether sudo-rs was installed and switch back to classic sudo if needed (the guide covers this).
7. During the package phase, SSH may be unreachable for a while, but apps kept serving. On the server where I watched, Nextcloud still returned 200 the whole time.

Port 443 is the host's nginx, so this is the only way an app package can get PQ there. App-specific listeners on their own ports (for example a NetBird native gRPC port) still need their own TLS config.

[robi]

@marcusquinn said:

On 26.04, follow the guide's MySQL 8.4 step (stop box, install mysql-server, re-run the box setup script, start box). After that, cloudron-support --troubleshoot passed cleanly and every app came back with the same state

Can you expand to include the path/to/the/box/setup-script?

[necrevistonnezr]

@robi said:

@marcusquinn said:

On 26.04, follow the guide's MySQL 8.4 step (stop box, install mysql-server, re-run the box setup script, start box). After that, cloudron-support --troubleshoot passed cleanly and every app came back with the same state

Can you expand to include the path/to/the/box/setup-script?

https://docs.cloudron.io/guides/upgrade-ubuntu-26#post-upgrade