7 ms·
> That file contains a bunch of links to firmware updates, all of which are also downloaded over http (and not https). The firmware images themselves appear to
by okket 10y ago
> That file contains a bunch of links to firmware updates, all of which are also downloaded over http (and not https). The firmware images themselves appear to be signed, but downloading untrusted objects and then parsing them isn't ideal.
Why? What security benefit do you gain by using HTTPS when you already check the signature/hash of the firmware file?
- floatingatoll 10y agoClosing an easy attack vector by using HTTPS seems a safe bet here, with no particular drawbacks. Are there chip-level power concerns that could make their IoT thing unable to do SSL, but able to validate firmware signatures?
- toast0 10y agoHTTPS for firmware download is a maintenance nightmare. In a couple of months, TLS 1.3 is going to be finalized, and then calls for everyone to drop support for TLS 1.2 will begin. But they can't drop TLS 1.2 support, without breaking firmware updates for all the unopened boxes out there. They probably should have signed the json listing of firmware images though, in addition to just the firmware images.
- yxhuvud 10y agoI guess what they could do to avert that is to have versioned (by subdomain) upgrade sites where each version is as secure as the associated device.
- true_religion 10y agoPeople even support TLS 1.0 for Enterprise clients. I feel like you'll support your legacy protocols for at least 20 years.
- deleted 10y ago[deleted]
- patrickmn 10y agoMetadata leakage aside: If you run a parser on unauthenticated input, bugs in your parser can be exploited. This is partly why mac-then-encrypt is a bad idea (you have to decrypt to verify the MAC.)
- deleted 10y ago[deleted]
- brians 10y agoThere's a parser on unauthentic input either way. Given the choice to do it online with NSS or OpenSSL or offline with the same library, I think it's a hair safer to do it offline---but this will be swamped by other factors particular to the project.
- patrickmn 10y agoYeah, don't get me wrong. Not implementing TLS because you're worried about attack surface is a bad idea. But if all you're doing is verifying a gpg signature on some firmware, a TLS stack is probably overkill.
- dom0 10y ago> Not implementing TLS because you're worried about attack surface is a bad idea. [citation needed]
- patrickmn 10y agoIf you're doing things that should be done over an encrypted channel, but forego TLS (or a suitable alternative like Noise Framework or WireGuard) because it adds attack surface, you are adding more risk than you are removing. A better solution would be to separate the parts of the stack that are sensitive from the parts that do things that you don't trust/are not in your control. This could be openbsd/POSIX style separation between your sensitive and the TLS-terminating process, or ideally placing them on completely separate machines. (Just make sure you trust your internal network if you aren't going to encrypt traffic on the inside...)
- peeters 10y agoParser exploits aside, HTTPS would help ensure the signed image you received was the one you asked for. So say there's an exploitable security flaw in 1.1.5 of the firmware and the firmware requests an upgrade from http://whatever.com/images/latest.img http://whatever.com/images/latest.img. Someone could return the legitimate 1.1.5 image instead, and assuming no other version validation, cause a downgrade that will allow further attacks. If you assume there IS further version validation, then the question is how do you know what version you should be expecting without HTTPS?
- okket 10y agoTo prevent downgrade attacks, include a list of banned signatures/hashes of previous versions in an upgrade? Plus only allow higher version numbers? Downside: Reverting is not possible if you make a serious mistake in an upgrade. If you can't initiate another upgrade process, bricking is possible... I don't know much about the world of really small devices aka IoT, but from my laymen perspective: Is a full TLS stack still a huge obstacle there? Sane signature checks are at least a step in the right direction.
- sneak 10y agoA device running 1.0 could still be upgraded to a vulnerable signed 1.1 when a patched 1.2 with blacklist is current on the site.
- 0x0 10y agoA device running a vulnerable signed 1.1 could still be denied an upgrade to 1.2 by a MITM blocking port 443 even if you used HTTPS.
- peeters 10y agoYeah but it's kind of irrelevant because the device is already vulnerable in your example. The point of this was to say that you can turn a safe device into a vulnerable device as part of a multi-phase attack.
- daenney 10y ago> Why? What security benefit do you gain by using HTTPS when you already check the signature/hash of the firmware file? B/c without HTTPS you can't verify you're actually talking to IKEA's update servers. Even if there's firmware signature implemented an attacker could still MITM you over HTTP and simply not serve you a file with updates. Which means that they can prevent your devices from upgrading, i.e to receive an update that closes a known flaw they might be exploiting.