4 ms·

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.

• josteink 9y 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.
  • caf 9y ago
    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".
  • johnp_ 9y ago
    > 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)
    • toast0 9y ago
      > 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.