5 ms·

> 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

> 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.
- mjg59 10y ago
  Isn't the same true of whatever signing certificate you're using to provide signed images? You'd still need to either control DNS or be able to interfere with traffic to do anything.
  - simcop2387 10y ago
    Pretty much I think. I don't know a way around it either and I think it's only going to get worse for now as more states look at passing laws like California or more Companies end up with FTC suits and settlements like trendnet (20 years of mandated 3rd party auditing)
  - omgtehlion 10y ago
    The difference is: to sign images your private key do not need to leave your build farm (or single build machine) and when you discontinue the product, you just wipe the server, keeping already built (and signed) images. But to serve updates via https you have to constantly keep the certifcate on internet-facing servers.
    - mjg59 10y ago
      They're using Cloudflare as their frontend, and if they're broken we're basically so fucked anyway I don't think lights are going to be our biggest concern
      - Nexxxeh 10y ago
        Might be, if the lights are in YOUR house. If one's bathroom and hallway lights gets hijacked or disabled remotely, it becomes an immediate safety issue if you're in that bathroom in the middle of the night. Also are there any protections against cycling them quickly (or really slowly, depending on how you look at it) to trigger seizures? Didn't someone recently get done for sending a seizure-inducing gif to an epileptic?
        uxp 10y ago
yunolisten 10y ago
> BearSSL is only 25KB and there are even microcontrollers Thank you, came here to mention this. So many people seem to think that OpenSSL is the ONLY tool to be used.
- dchest 10y ago
  BearSSL is my favourite crypto software of 2016, however it's still in alpha stages of development and is not production ready, Ikea couldn't use it for this product: https://www.bearssl.org/todo.html https://www.bearssl.org/todo.html
josteink 10y ago
> 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 Famous last words. I'm also in favor of keeping IOT devices as simple as possible. In that regard, dropping HTTPS is a no-brainer (as long as some verification is done through other means). I'm making a bet that anyone here who religiously advocates HTTPS on embedded devices never have tried it in practice and over time.
- johnp_ 10y ago
  There's a TLS 1.2 Long Term Support draft in the works, specifically for those devices with "multi-year or even decade-long update cycles": https://tools.ietf.org/html/draft-gutmann-tls-lts-07 https://tools.ietf.org/html/draft-gutmann-tls-lts-07
  - josteink 10y ago
    It only takes a single incident like Heartbleed, Shellshock, Backblaze or whatever to render a formerly assumed secured component or protocol insecure. And if you're building something on a platform where you can't rely on the ability to upgrade past the latest SSL security vulnerability in the future, you effectively can't count on HTTPS to provide the security you need for the lifetime of the device. That means you'll have to implement additional means of securing your data anyway, so what value does HTTPS provide in those cases? In some cases the library affected may now instead provide a security risk in itself, which you wouldn't have had you only gone with plain HTTP. So it can be argued that deploying HTTPS in environments where the ability to perform updates are limited is a security risk in itself and should be avoided at all cost. So if you're going to have to implement your own security anyway, why bother with all the additional work, complexity and security-risks using HTTPS involves? Especially considering you probably won't gain anything out of it, except more work. Counter to popular HN religion, HTTPS everywhere is actually not always going to represent a security benefit. In lots of cases, plain HTTP just makes sense. Edit: Not to mention the increase in complexity brought you by HTTPS effectively means you now need to provide more updates for your devices, or leave them vulnerable and hope nobody notices. Basically, blindly applying HTTPS where it doesn't provide value, now just increased the cost for companies w.r.t. maintaining their devices in the future. If a company sees increased per-device-lifetime-costs associated with updates, guess how many companies will then decide on limiting the number of models they are willing to provide updates for, labelling older models "obsolete"? All in all, HTTPS in cases like this represent a negative value proposition both for the companies and the customers.
kuschku 10y ago
11 years. What do I do in 20 years? 30? Will all my tech just break? People are still using furniture and lamps from their great-grandparents. Do we have to become a society producing so much garbage?
- p49k 10y ago
  Well, the device can auto-update - this just means that it would need to be plugged in within 11 years of manufacture in order to be able to receive firmware updates, not that it would break after 11 years. And reastically, the server could even eliminate that requirement by supporting old protocols just for the updating old firmware.
- collinmanderson 10y ago
  Basically, anything hooked up to the internet needs to be updated over time to stay secure (whether it's patching security holes, new protocols, or using new methods of security.) Don't buy products that hook up to the internet if you want them to last 20 years, unless you're sure the manufacturer will continue to update it. (Don't buy anything with a non-standard battery either.)
mobiletelephone 10y ago
Any thoughts on PolarSSL?
- feld 10y ago
  PolarSSL is now mBedTLS
- cybergibbons 10y ago
  Less well tested than OpenSSL, but historically has been relatively secure.

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.

mjg59 10y ago
Isn't the same true of whatever signing certificate you're using to provide signed images? You'd still need to either control DNS or be able to interfere with traffic to do anything.
- simcop2387 10y ago
  Pretty much I think. I don't know a way around it either and I think it's only going to get worse for now as more states look at passing laws like California or more Companies end up with FTC suits and settlements like trendnet (20 years of mandated 3rd party auditing)
- omgtehlion 10y ago
  The difference is: to sign images your private key do not need to leave your build farm (or single build machine) and when you discontinue the product, you just wipe the server, keeping already built (and signed) images. But to serve updates via https you have to constantly keep the certifcate on internet-facing servers.
  - mjg59 10y ago
    They're using Cloudflare as their frontend, and if they're broken we're basically so fucked anyway I don't think lights are going to be our biggest concern
    - Nexxxeh 10y ago
      Might be, if the lights are in YOUR house. If one's bathroom and hallway lights gets hijacked or disabled remotely, it becomes an immediate safety issue if you're in that bathroom in the middle of the night. Also are there any protections against cycling them quickly (or really slowly, depending on how you look at it) to trigger seizures? Didn't someone recently get done for sending a seizure-inducing gif to an epileptic?
      - uxp 10y ago

yunolisten 10y ago

> BearSSL is only 25KB and there are even microcontrollers Thank you, came here to mention this. So many people seem to think that OpenSSL is the ONLY tool to be used.

dchest 10y ago
BearSSL is my favourite crypto software of 2016, however it's still in alpha stages of development and is not production ready, Ikea couldn't use it for this product: https://www.bearssl.org/todo.html https://www.bearssl.org/todo.html

josteink 10y ago

> 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 Famous last words. I'm also in favor of keeping IOT devices as simple as possible. In that regard, dropping HTTPS is a no-brainer (as long as some verification is done through other means). I'm making a bet that anyone here who religiously advocates HTTPS on embedded devices never have tried it in practice and over time.

johnp_ 10y ago
There's a TLS 1.2 Long Term Support draft in the works, specifically for those devices with "multi-year or even decade-long update cycles": https://tools.ietf.org/html/draft-gutmann-tls-lts-07 https://tools.ietf.org/html/draft-gutmann-tls-lts-07
- josteink 10y ago
  It only takes a single incident like Heartbleed, Shellshock, Backblaze or whatever to render a formerly assumed secured component or protocol insecure. And if you're building something on a platform where you can't rely on the ability to upgrade past the latest SSL security vulnerability in the future, you effectively can't count on HTTPS to provide the security you need for the lifetime of the device. That means you'll have to implement additional means of securing your data anyway, so what value does HTTPS provide in those cases? In some cases the library affected may now instead provide a security risk in itself, which you wouldn't have had you only gone with plain HTTP. So it can be argued that deploying HTTPS in environments where the ability to perform updates are limited is a security risk in itself and should be avoided at all cost. So if you're going to have to implement your own security anyway, why bother with all the additional work, complexity and security-risks using HTTPS involves? Especially considering you probably won't gain anything out of it, except more work. Counter to popular HN religion, HTTPS everywhere is actually not always going to represent a security benefit. In lots of cases, plain HTTP just makes sense. Edit: Not to mention the increase in complexity brought you by HTTPS effectively means you now need to provide more updates for your devices, or leave them vulnerable and hope nobody notices. Basically, blindly applying HTTPS where it doesn't provide value, now just increased the cost for companies w.r.t. maintaining their devices in the future. If a company sees increased per-device-lifetime-costs associated with updates, guess how many companies will then decide on limiting the number of models they are willing to provide updates for, labelling older models "obsolete"? All in all, HTTPS in cases like this represent a negative value proposition both for the companies and the customers.

kuschku 10y ago

11 years. What do I do in 20 years? 30? Will all my tech just break? People are still using furniture and lamps from their great-grandparents. Do we have to become a society producing so much garbage?

p49k 10y ago
Well, the device can auto-update - this just means that it would need to be plugged in within 11 years of manufacture in order to be able to receive firmware updates, not that it would break after 11 years. And reastically, the server could even eliminate that requirement by supporting old protocols just for the updating old firmware.
collinmanderson 10y ago
Basically, anything hooked up to the internet needs to be updated over time to stay secure (whether it's patching security holes, new protocols, or using new methods of security.) Don't buy products that hook up to the internet if you want them to last 20 years, unless you're sure the manufacturer will continue to update it. (Don't buy anything with a non-standard battery either.)

mobiletelephone 10y ago

Any thoughts on PolarSSL?

feld 10y ago
PolarSSL is now mBedTLS
cybergibbons 10y ago
Less well tested than OpenSSL, but historically has been relatively secure.