Hacker News Reader

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

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

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.

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.

This cuts both ways though - maybe your package parsing and signature verification code has a security flaw in it, in which case you'll find yourself wishing you had the protection of only trying to parse packages from the HTTPS-verified legitimate source.

So the answer to the question posed earlier, "...so what value does HTTPS provide in those cases?" is that it avoids have a single point of failure in your security architecture.

It's also worth pointing out that most of those protocol-level TLS vulnerabilities mentioned wouldn't have been exploitable in the far more restricted setting of "device that phones home to check for updates".

> It only takes a single incident like Heartbleed, Shellshock, Backblaze or whatever to render a formerly assumed secured component or protocol insecure.

Yes, just as your firmware verification and update mechanism and every other interface your device provides to the outside world. That's just a general argument against feature creep.

> [...] so what value does HTTPS provide in those cases?

Defense in Depth.

> [...] provide a security risk in itself [...]

Just like any other component. I'd argue that a slimmed down , globally deployed implementation of a several decades battle-tested protocol has a lower security risk than some vendor specific, device specific, single-developer self-designed integrity and authenticity scheme.

Overall, if your IoT device handles any potentially confidential user data at all you already need a TLS stack, so enabling it for the firmware update mechanism doesn't add any more of an attack surface.

If you only ever need authenticity and integrity HTTP is already more complex than necessary and you'd be better served with a simpler protocol. (e.g. CoAP)

> I'd argue that a slimmed down , globally deployed implementation of a several decades battle-tested protocol has a lower security risk than some vendor specific, device specific, single-developer self-designed integrity and authenticity scheme.

Is there a TLS client library released in April 2007 or earlier you are comfortable running today?

Is there a data signature checking library released in April 2007 or earlier you are comfortable running today? Note that OpenSSL didn't support TLS 1.1 or 1.2 until OpenSSL 1.0.1 release march 2012

My guess is that if you took the signature checks from an OpenSSL build from 2007, they're either still fine today if you used them separate from the TLS stack, or they're broken enough that you can easily bypass certificate authentication. From a brief look at the openssl vulnerability list, it's also likely that there's a certificate handling bug that you could exploit to bypass the checks anyway.

HTTP may be more complex than necessary, but it travels through firewalls with pretty good ease, and it's not that complex if you speak HTTP 1.0 without transfer-encoding, and only need to understand response headers enough to discard them. HTTP 0.9 is even easier, but some transparent proxies have trouble finding the destination server, so the Host header available in HTTP 1.0 is helpful to ensure requests can be routed. The MVP HTTP 1.0 client is:

   int where = 0;
   char rnrn[4] = "\r\n\r\n";
   int c;
   fprintf(fd, "GET %s HTTP/1.0\r\nHost: %s\r\n\r\n", url, host);
   shutdown (SHUT_WR, fd);
   while (c = read(fd, buf, 1)) {
     if (!c) { return -1; } // bad server
     if (buf[0] == where[0]) {
        ++where;
        if (where == 4) {
           break;
        }
     } else {
        where = 0;
     }
   }
   // here comes the data
   // be sure to have a reasonable sized buffer
   // and stop reading when its full
   // check the signature before you process the data

That's not really that complex (I didn't test the code, it's an illustration). You could also abort without checking the signature if the server sends data beyond your buffer, but the signature check should fail anyway. You could look for a content-length header as well, but header parsing is some amount of work.

Specifically, in the case of the firmware running on the Trådfri gateway, it already supports TLS.

Yeah, https may be insecure in 5 years so we better use http and be insecure from the start. Never mind that https likely is insecure only in rather esoteric scenarios that cannot occur when you're only downloading firmware upgrades.

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?

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.

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

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

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

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

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.

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)

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.

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

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?

We're getting into the territory of "Guns don't kill people, people kill people with guns".

If someone has Epilepsy this might be a concern, but as the story around the gif sent to Kurt Eichenwald, which you reference, points out gifs don't hurt people, assholes do. It's not IKEA's responsibility to ensure that every product they sell cannot be used in any destructive manner. People have to take responsibility for purchasing and introducing new components into their home, much like I as a software developer have to take responsibility for every line of code that I write which has the potential to have a bug that compromises the system I deploy it on, or enables someone to leak the database the application is connected to. IKEA sells knives, for christ sakes.

No we aren't.

Can these items be hijacked, what is the risk of that happening, and what is the damage they can cause?

> It's not IKEA's responsibility to ensure that every product they sell cannot be used in any destructive manner.

No, but they have a reasonable due of care.

I'm not saying that they shouldn't go on sale without the protections I mentioned. But it's surely a reasonable question to ask if those protections are in there, so as to better understand the risks.

>People have to take responsibility for purchasing and introducing new components into their home,

Yeah, but what ARE the risks? You can't answer my question, so how am I supposed to make an informed decision if I'm epileptic?

I know the balance of risks of knives. Everyone does. How many people know the potential risks of Zigbee-connected bulbs with a wifi hub?

I don't want to alarm anyone, but in many countries someone can walk up and switch off your power from the external meter box. They could even turn it off and on constantly to flash.

Just saying #perspective

No-one is flicking my lightswitch from across the globe. The chances of some 4Chan troll doing it are slim.

You can generate your own CA certificate, and then use that to generate SSL certificates.

Typical organisations who need their own CA will create a root CA with a 20 to 30 year lifetime. This CA is then used to sign a sub-CA (sometimes called Principal CA, or Issuance CA), with a lifetime of 5-10 years.

The sub-CA is then used to sign a TLS cert, with a lifetime of 1-2 years.

This means that you only trust the root CA. Whether the TLS certificate gets compromised or not is irrelevant and completely besides the point, because the CA doesn't get compromised, and can revoke the compromised certificates.

I can go into detail about a few banks and governments whose CA I setup. Especially the smart card/PIN code distribution to unlock the root CA and sub-CAs was fun.

This comment screams KISS

This is not at all complicated to implement.

Any thoughts on PolarSSL?

PolarSSL is now mBedTLS

Less well tested than OpenSSL, but historically has been relatively secure.