FTP is still advertised for download of this OS, but any tampering or otherwise corrupted files will not pass a signature test when signify is invoked.
The keys are rotated for every release, the next expected key is always included in the current OpenBSD release.
This system would be safe to fetch sensitive content over cleartext http.
EDIT: Here is a paper on signify:
Date: Wed, 31 May 2023 14:13:10 UTC
Valid-Until: Wed, 07 Jun 2023 14:13:10 UTC
which allows spotting any tries of "downgrading" repository to previous version with potentially insecure packagesOf course, you still have to get current time somehow but I guess once RTC is set the device can assume the changes in time won't be huge and just use any kind of https source for that.
Which is why it might be more future proof to embed your own non expiring cert and use an out-of-band signature verification for firmware rather than relying on being able to establish an HTTPS connection forever.
If you have working signature infrastructure you don't need encryption. There is some danger, attacker can see what you are getting, but that's far lower than "the update broke"
No harm in also running HTTPS on top of that as you can renew the TLS certificate without issue.
So the HTTP request leaks information about the update and could be MITM, but the result could at best be an older version? (Which could be a known exploitable one!)
https://security.googleblog.com/2015/12/an-update-on-sha-1-c...
Even OCSP was affected: https://cabforum.org/2022/01/26/ballot-sc53-sunset-for-sha-1...
It's also useful to issue short lived certs and use the expiry date to handle revocation rather than maintaining a CRL.
Or, the cert could have been issued by an authority which issued the cert despite compliance problems.
Web PKI is different than code signing, but if you look at the discussions within the CAB forum, there are very good reasons to limit certificate lifetime.
Public CAs are not very secure as NSA proved and I am not sure why there is no better alternative yet.