7 ms·

I dont get everyones gripe about the lack of HTTPS as long as there's firmware signing. HTTPS as a protocol ages extremely fast, trust anchors always change, a

I dont get everyones gripe about the lack of HTTPS as long as there's firmware signing. HTTPS as a protocol ages extremely fast, trust anchors always change, and there's no guarantee that today's state of the art won't be completely incompatible with TLS implementations in 5 years. For HTTPS to work properly on an embedded device, it needs to have an up to date OpenSSL library and updated certificate anchors. These are always packed as part of the firmware image itself, so any update to certificate anchors or OpenSSL would require an entire new image to be deployed. This isn't a problem for websites because updating is usually as simple as apt-get upgrade, but this is a massive problem for embedded devices because publishing a new firmware image usually means pumping a few hundred hours of QA time into the image, then back and forthing with your manufacturer to get them to use the new image on newly minted units. This isn't even considering the changes in OpenSSL over time. Many older routers simply cannot use HTTPS for updates because newer versions of OpenSSL simply won't fit on the flash. Then there's the question of how end-of-life will be handled. People often use products long after they've gone EOL. You have to ask yourself what happens when someone plugs in a lighting unit that has an old firmware version on it, and the unit can't communicate with the update server because the product was EOL'd 5 years ago. There won't be a transition firmware for such an old product, and the people who know how to roll the firmware images probably don't even work there any more. That user is now SOL unless you have a method for manually updating firmware.

peeters 10y ago
I mentioned this elsewhere, but signing can tell you whether it's an authentic object, but usually not whether it's THE authentic object you had requested. So you then need something extra to validate that what you got is what you wanted, for example check the version number in the signed image. But how do you know what version number you should be looking for without HTTPS? In this case the article points out that the metadata itself is downloaded over HTTP.
- hawski 10y ago
  A silly solution: Recreate a package every day, week or month and update package date to current time. A device will refuse to install an update that is older than factory specified interval. Of course the problem then is that your device now needs to have secure channel to NTP servers. Possibly they could use radio synchronization instead - same as used in radio controlled watches. It could be exploited, but it would be much harder to do remotely by network. It needs a bit of gymnastics, but it may still be easier on the long run than HTTPS. Your mileage can vary. Edit: Dear downvoter: Was I overly dumb or inaccurate with my proposition?
  - gcr 10y ago
    Simpler solution: just refuse to install a firmware update that doesn't verify, or whose version number is less than the currently installed version.
dubya 10y ago
I agree. I had to dust off my WRT54G for a few days when my modern router died. I accidentally switched it to https only, and none of Safari, Chrome and Firefox would connect to it because of the SSL version.
- lorenzhs 10y ago
  That's unrelated. The lights need to be able to connect, not your browser. It's not about having a website where you can download a new image, it's about having the lights download a new firmware image. What browsers do or do not support doesn't matter. The WRT54G is also 15 years old. That's probably longer than the lifespan of a smart lighting system.
  - toast0 10y ago
    > The WRT54G is also 15 years old. That's probably longer than the lifespan of a smart lighting system. This is probably true, but also depressing. Dumb lighting systems have a very long lifespan, essentially as long as the wiring survives, which is mostly until a remodel or a catastrophic failure; but a smart lighting system is only expected to last 10 years at which time we have to rebuild the system at great expense with whatever is new and hip and trendy (not to mention, the ten year old system was already greatly expensive).
    - lorenzhs 10y ago
      If you haven't replaced your lighting system in the last ten years, now might be a good time to buy LEDs. They have improved in reliability, colour spectrum (warm white), and price. Incandescent bulbs are no longer sold in the EU. All the smart stuff and home automation is still very new and in a state of flux. I hope it will settle down in the next few years.
slau 10y ago
I understand where you're coming from, but you're making a logical leap: you assume that HTTP over TLS somehow means that it needs to be interoperable with the full and real internet. This device presumably already ships with a public key that verifies the integrity of the images it downloads. Why not ship with a single CA (owned by IKEA), or even single certificate? It doesn't even need to be signed by a public CA, this can all be self-signed by the org. This completely solves the issue with regards to anchors, as you call them. The next thing you mention is firmware update post-EOL. Again, TLS doesn't change much about this. If we apply Occam's razor, what is more likely: that Ikea's servers are upgraded beyond compatibility with today's TLS stack, or that the servers are shut down? Once EOL hits, you're SOL anyway. PS: A current nginx or Apache can still easily communicate with IE6. PPS: I'm not saying that I think TLS is required in this case. Just that the right argumentation has to be used.
- deleted 10y ago
  [deleted]
iancarroll 10y ago
> HTTPS as a protocol ages extremely fast You do not need to frequently upgrade TLS versions to be secure. TLSv1.2 will likely be fine for many years and TLSv1.1 has been fine for 11 years. If you do need to upgrade, it won't be often, but the QA is the only hard part. > trust anchors always change Indeed an issue, especially with the public PKI, but you can roll your own root certificate with a lifespan of 50 years or something. This is somewhat dangerous as there's now a non-expiring trust anchor instead of the usual 1-3 year key rotation, but it's still practical, especially if HTTPS is only a layer of protection around your already signed firmware. > there's no guarantee that today's state of the art won't be completely incompatible with TLS implementations in 5 years Well, TLS is designed to negotiate the version to avoid this exact issue, but even if TLSv1.x is not backwards compatible there is nothing blocking the update server from supporting the older version? > Many older routers simply cannot use HTTPS for updates because newer versions of OpenSSL simply won't fit on the flash. OpenSSL is far from the only implementation here. BearSSL is only 25KB and there are even microcontrollers with their own TLS stack built into hardware, like the CC3220 from TI, which I've been using at my job. There are concerns there too with updating TLS, but again, should be a relatively rare concern. > the people who know how to roll the firmware images probably don't even work there any more Indeed another issue. But realistically, yes, IoT devices are going to have a finite lifetime if they depend on cloud services.
- simcop2387 10y ago
  > Indeed an issue, especially with the public PKI, but you can roll your own root certificate with a lifespan of 50 years or something. This is somewhat dangerous as there's now a non-expiring trust anchor instead of the usual 1-3 year key rotation, but it's still practical, especially if HTTPS is only a layer of protection around your already signed firmware. As you say this is dangerous but it's not as obvious how dangerous. To work with this trust anchor and keep it secur e you've now got a lot of physical and software security you now have to deal with for the next 50 years even if you stop supporting a given device. Since if anyone gets a hold of that root certificate they can all the sudden pretend to be you to everyone continuing to use your devices and you've now got a massive PR issue, if not legal liability. It's not an easy problem to deal with.
stable-point 10y ago
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 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.
- toast0 10y ago
  An attacker who can change the http content, could also block access to https upgrade servers, ensuring stale firmware.
- deleted 10y ago
  [deleted]
- problems 10y ago
  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 10y ago
    The are less drastic options. You can start warning loudly if the servers haven't responded for weeks.
    - lexicality 10y ago
      Via what? Flashing the apartment lights?
      - 10y ago
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

peeters 10y ago

I mentioned this elsewhere, but signing can tell you whether it's an authentic object, but usually not whether it's THE authentic object you had requested. So you then need something extra to validate that what you got is what you wanted, for example check the version number in the signed image. But how do you know what version number you should be looking for without HTTPS? In this case the article points out that the metadata itself is downloaded over HTTP.

hawski 10y ago
A silly solution: Recreate a package every day, week or month and update package date to current time. A device will refuse to install an update that is older than factory specified interval. Of course the problem then is that your device now needs to have secure channel to NTP servers. Possibly they could use radio synchronization instead - same as used in radio controlled watches. It could be exploited, but it would be much harder to do remotely by network. It needs a bit of gymnastics, but it may still be easier on the long run than HTTPS. Your mileage can vary. Edit: Dear downvoter: Was I overly dumb or inaccurate with my proposition?
- gcr 10y ago
  Simpler solution: just refuse to install a firmware update that doesn't verify, or whose version number is less than the currently installed version.

dubya 10y ago

I agree. I had to dust off my WRT54G for a few days when my modern router died. I accidentally switched it to https only, and none of Safari, Chrome and Firefox would connect to it because of the SSL version.

lorenzhs 10y ago
That's unrelated. The lights need to be able to connect, not your browser. It's not about having a website where you can download a new image, it's about having the lights download a new firmware image. What browsers do or do not support doesn't matter. The WRT54G is also 15 years old. That's probably longer than the lifespan of a smart lighting system.
- toast0 10y ago
  > The WRT54G is also 15 years old. That's probably longer than the lifespan of a smart lighting system. This is probably true, but also depressing. Dumb lighting systems have a very long lifespan, essentially as long as the wiring survives, which is mostly until a remodel or a catastrophic failure; but a smart lighting system is only expected to last 10 years at which time we have to rebuild the system at great expense with whatever is new and hip and trendy (not to mention, the ten year old system was already greatly expensive).
  - lorenzhs 10y ago
    If you haven't replaced your lighting system in the last ten years, now might be a good time to buy LEDs. They have improved in reliability, colour spectrum (warm white), and price. Incandescent bulbs are no longer sold in the EU. All the smart stuff and home automation is still very new and in a state of flux. I hope it will settle down in the next few years.

slau 10y ago

I understand where you're coming from, but you're making a logical leap: you assume that HTTP over TLS somehow means that it needs to be interoperable with the full and real internet. This device presumably already ships with a public key that verifies the integrity of the images it downloads. Why not ship with a single CA (owned by IKEA), or even single certificate? It doesn't even need to be signed by a public CA, this can all be self-signed by the org. This completely solves the issue with regards to anchors, as you call them. The next thing you mention is firmware update post-EOL. Again, TLS doesn't change much about this. If we apply Occam's razor, what is more likely: that Ikea's servers are upgraded beyond compatibility with today's TLS stack, or that the servers are shut down? Once EOL hits, you're SOL anyway. PS: A current nginx or Apache can still easily communicate with IE6. PPS: I'm not saying that I think TLS is required in this case. Just that the right argumentation has to be used.

deleted 10y ago
[deleted]

iancarroll 10y ago

> HTTPS as a protocol ages extremely fast You do not need to frequently upgrade TLS versions to be secure. TLSv1.2 will likely be fine for many years and TLSv1.1 has been fine for 11 years. If you do need to upgrade, it won't be often, but the QA is the only hard part. > trust anchors always change Indeed an issue, especially with the public PKI, but you can roll your own root certificate with a lifespan of 50 years or something. This is somewhat dangerous as there's now a non-expiring trust anchor instead of the usual 1-3 year key rotation, but it's still practical, especially if HTTPS is only a layer of protection around your already signed firmware. > there's no guarantee that today's state of the art won't be completely incompatible with TLS implementations in 5 years Well, TLS is designed to negotiate the version to avoid this exact issue, but even if TLSv1.x is not backwards compatible there is nothing blocking the update server from supporting the older version? > Many older routers simply cannot use HTTPS for updates because newer versions of OpenSSL simply won't fit on the flash. OpenSSL is far from the only implementation here. BearSSL is only 25KB and there are even microcontrollers with their own TLS stack built into hardware, like the CC3220 from TI, which I've been using at my job. There are concerns there too with updating TLS, but again, should be a relatively rare concern. > the people who know how to roll the firmware images probably don't even work there any more Indeed another issue. But realistically, yes, IoT devices are going to have a finite lifetime if they depend on cloud services.

simcop2387 10y ago
> Indeed an issue, especially with the public PKI, but you can roll your own root certificate with a lifespan of 50 years or something. This is somewhat dangerous as there's now a non-expiring trust anchor instead of the usual 1-3 year key rotation, but it's still practical, especially if HTTPS is only a layer of protection around your already signed firmware. As you say this is dangerous but it's not as obvious how dangerous. To work with this trust anchor and keep it secur e you've now got a lot of physical and software security you now have to deal with for the next 50 years even if you stop supporting a given device. Since if anyone gets a hold of that root certificate they can all the sudden pretend to be you to everyone continuing to use your devices and you've now got a massive PR issue, if not legal liability. It's not an easy problem to deal with.

stable-point 10y ago

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 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.

toast0 10y ago
An attacker who can change the http content, could also block access to https upgrade servers, ensuring stale firmware.
deleted 10y ago
[deleted]
problems 10y ago
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 10y ago
  The are less drastic options. You can start warning loudly if the servers haven't responded for weeks.
  - lexicality 10y ago
    Via what? Flashing the apartment lights?
    - 10y ago

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]