[stable-point]

The firmware signature ensures the updates are authentic, but not that they are fresh. An attacker could force devices to stay on an older authentic but vulnerable piece of software.

The Google Omaha design docs discuss this a little bit: https://github.com/google/omaha/blob/master/doc/cup.html

I think plain HTTP is not appropriate for most update schemes Interestingly, Google Omaha actually chose not to use TLS to ensure freshness, but has something custom.

[problems]

An attacker could just as easily block the SSL connections - unless you're suggesting it fail if it can't check for a firmware update, but that proposal would mean that if your servers are gone the devices are bricked. Many of such devices function fine in a Lan only setting behind a nat where they're virtually untouchable.

Disallowing downgrades via a signed datestamp is about the best you can do. Anything else will either be trivially blocked or result in other user problems.

[viraptor]

The are less drastic options. You can start warning loudly if the servers haven't responded for weeks.

[lexicality]

Via what? Flashing the apartment lights?

[viraptor]

Reporting to the app controlling them.

[toast0]

An attacker who can change the http content, could also block access to https upgrade servers, ensuring stale firmware.