3 ms·

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

by 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.
cybergibbons 9y ago
Specifically, in the case of the firmware running on the Trådfri gateway, it already supports TLS.

by johnp_ 9y ago

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.

cybergibbons 9y ago

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