IETF published TLS 1.3 as RFC 8446 (Proposed Standard) )

I haven’t heard of any evidence that we need hurry with migration to TLS 1.3, especially that Omnia doesn’t affect what TLS version you use on traffic passing through Omnia.

What comes to mind

  1. access to front ends - Foris & LuCI
  2. DoT resolver traffic
  3. nextCloud traffic
  4. other services on the router with TLS traffic, e.g. OpenVPN, transmission web gui (?)

Sure it needs the respective libraries (gnuTLS / OpenSSL) in a version supporting TLS 1.3


I’m using:

to audit security on my sites. They are served from behind a Omnia with lighttpd acting as a reverse proxy and delivering the SSL certs.

I can’t get the best security rating for lack of TLS 1.3 and the version of openssl on the Omia seems old:

# openssl version
OpenSSL 1.0.2u  20 Dec 2019

with TLS 1.3 support added in 1.1.1 as far as I can tell:

Either way it seems this is easily solved now just by updating the openssl version installed on the Omnia. openssl 1.1.1 is available on hte OpenWRT repos:

And so it would just be a question now of of bringing it over and delivering with Omnia updates.

TLS 1.3 is now it seems and expected standard for top notch security (to get an A rating at Qualsys). And so yes it wasn’t a hurry, but I think the time has come and it’s easy to do to bring 1.1.1 into the Omnia update scheme.

root@turris:~# openssl version
OpenSSL 1.1.1h  22 Sep 2020
root@turris:~# cat /etc/turris-version 

That’s the stable 5.x (HBS :snail: )

# cat /etc/turris-version 

Like wow! I thought the Omnia kept itself up to date.l How on earth do I have 3.11.21 and you gave 5.1.2.? What’s going on there?

Try tos3to4 command or re-flash with TOS 5.

I see this on Foris:

Is this zero risk? As in I take a Schnapps snapshot then try tos3to4?

Mind you I checked and can’t find tos3to4 on my Omnia.

And how to reflash with 5? Forgiving the ignorance, having bought a router that keeps itself up to date -
or not it seems :wink:

Migration is serious risk. You must install migration package first.

Re-flash is smooth but with data loss.

3.x is still supported, i.e. it receives security updates.

I guess this is the best reference thread for 3.x -> 5.x auto-migration?

Thanks. Looks complicated and something to schedule. The migration looks viable, and can fallback on a Schnapps snapshot it seems (which is the security I’d want). Reflashing sounds like more more work as I have a load of local configs, and I should assemble a summary of them before proceeding. They include extensive:

  1. static DHCP definitions for the LAN
  2. DDNS configs for a half dozen domain names that point here
  3. lighttpd configs for same domains
  4. Local utils installed (but can be republished to a reflash)
  5. knotd reconfig to respect /etc/hosts (for avoiding hairpin traffic on local domains)
  6. The obvious: the WAN connection config (pppoe account and password at a minimum)
  7. Directing of syslog to a USB drive for persistence and SSD wear reduction

Maybe more, I should do an audit to be sure.

But as I understand it the TOS 5 is considered stable, but the migration is still considered experimental, and reflashing is clean and secure (but demands a complete reconfig).

Wowsers, I had hoped the Omnia would follow the update trail seamlessly. Or is that still the plan? That migration moves form experimental to something 3.x users just receive with confidence? Seems not as the changes have been fairly significant and the risks a simple reality.


Plan is an automatic migration for all TOS 3 devices.

1 Like

That’s good to know. So the hope is to make the migration stable and not experimental and then roll it out? I may be happy to wait ;-).

Let’s hope the development plan doesn’t change.

1 Like

Is there a way to keep up to date on that?

Yes, read new forum posts carefully and see further router notifications.

If you wanted to try the migration now: Doing a schnappshot before migration is definitely a good idea, but I’d strongly recommend you to make a full copy of the system drive (maybe via btrfs send is the easiest). And a plain old copy (or rsync) of /etc in case everything else fails. And be wary that any changes to persistent data (the external storage you mentioned) might not be reversible by schnapps (e.g. LXC configs if you run LXC and store it on the external drive; not sure about lighttpd). And definitely uninstall ddns before you try the migration - many of the providers have bugs in their update scripts which halt the upgrade in the middle. Just uninstall, upgrade, verify functionality, reinstall.

1 Like

Busy as I am and that my only driver is get TLS 1.3 right now I can afford to wait. I just hope Turriss stabilises and secure a 3 to 5 upgrade path so we can all migrate with minimal if any residual risk (risk never goes away, but with a good schnappshot to roll back to, it can be orchestrated with minimal risk. The problem many no doubt face is that upgrade tinkering on the gateway router is downtime for everything behind it (families servers and more in my case).