4 ms·

> > > it's not possible for Philips to add HTTPS support to the hue bridge > > I don't see why not. > That's not a constructive argument. I don't see how they

> > > it's not possible for Philips to add HTTPS support to the hue bridge > > I don't see why not. > That's not a constructive argument. I don't see how they could make it work? Missing from your quote: The alternative is freedom. Philips doesn't have to lock their devices. If Philips (and other companies, obviously this doesn't relate to just Philips) would provide a community access to their devices and software rather than locking them out, I believe that this problem would not exist. The original issue is that having a public website (used over TLS) that interacts with local network devices without TLS shows warnings about insecure communication. Again, the warning is shown because it /is/ insecure. There are plenty alternatives of securely interacting with an IOT device. Plain HTTP from a public website is just not one of them. For example, look at how Apple's Homekit has implemented that. Homekit is not usable from a public web page in a web browser. That's a good thing. (aside: I'm not a big fan of Homekit but their security is not bad) So if vendors are annoyed with browser warnings, it's because /they/ are doing the wrong thing, not the browsers. > sufficiently sophisticated attacker will just extract them and become able to impersonate some Philips device Just like on any website. Just because something isn't 100% unbreakable, doesn't mean it's a bad idea (you do lock your doors, don't you?)

cryo 9y ago
> Missing from your quote: The alternative is freedom. Philips doesn't have to lock their devices. > If Philips (and other companies, obviously this doesn't relate to just Philips) would provide a community access to their devices and software rather than locking them out, I believe that this problem would not exist. The problem is technical and won't be fixed by just opening the software. > There are plenty alternatives of securely interacting with an IOT device. Please name just one which works for webapps, beside HTTPS. > So if vendors are annoyed with browser warnings, it's because /they/ are doing the wrong thing, not the browsers. Homekit is nice but not available to webapps, apps of course can take advantage of several security mechanisms. My whole rant is about browsers and HTTPS in non public networks. For webapps which want to talk to IoT devices there is only HTTPS and there is _no_ sane way to provide robust, local!, access to a LAN device via HTTPS. Here are some requirements: (actually real, I'm working on a IoT'ish product) * webapp must be served via HTTPS, either from the IoT device or vendor site * it just works! if webapp served from IoT device, the user shall not be required to install certificate or set exception (because it then looks like scary as hell malware) * the webapp must work offline (service worker or appcache) without internet connection * webapp must be able to talk directly to the device, no cloud or vendor server inbetween * the IoT device which provides a secured REST API might be in in a LAN which is NOT connected to the internet -- so the '<random-stuff-id>.vendor.com DNS resolves to device IP with an Lets Encrypt CA' approach won't work here (otherwise nice hack) To my knowledge it's technically not possible to build such a HTTPS secured webapp in a local network today without breaking the mentioned requirements.
- bjpbakker 9y ago
  > The problem is technical and won't be fixed by just opening the software. I strongly disagree. Main reason is that if Philips opened their firmware to the public, it would have had different protocols by now than just HTTP with a poor mans JSON API. > Homekit is nice but not available to webapps, apps of course can take advantage of several security mechanisms. That's why basically my point is to /not/ use a web app to control local insecure IOT devices. > Please name just one which works for webapps, beside HTTPS. Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC). * update: I just noticed another comment [1] that mentions Plex with a link to some technical details [2]. [1] https://news.ycombinator.com/item?id=14751768 https://news.ycombinator.com/item?id=14751768 [2] https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
  - qb45 9y ago
    > it would have had different protocols by now than just HTTP with a poor mans JSON API. Sure, but now you can't control the gadget from the browser and the vendor needs to write an application or something for whatever shitty OS you want to use. > Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC). Not that simple. Public CAs will likely only give you certs for domains you own (like plex.direct) and your users generally don't have nameservers authoritative for such domains on their LANs (maybe you could pull it off if you are a router vendor, but not with IoT light bulbs) so they have to query your public nameserver and the system fails without Internet connection. And there is no easy solution: if your light bulb could register an xxx.philips.com domain via UPnP on your router or via SMB on your Windows box, it would be very much unclear what exactly should prevent it from registering philips.com as well.
- xg15 9y ago
  I think this is part of the larger problem of the relentless "cloud first" movement that the whole industry seems to have adopted. I feel like there isn't any new software, device or standard in development by now that doesn't demand constant internet access and a dedicated background service. Even basic things that should have no business relying on internet access get swalloed by that. (Browsers, operating systems, cars...) The economic incentives that push everyone in that direction are obvious but I think in the end that will lead to more harm than good. That being said, I can understand that making IoT devices directly accessible from web page JS fü could cause some security headaches: As an example, apparently a lot of recent exploits were caused by programs opening a loopback-only REST service for IPC. Those services weren't secured because, hey, if someone can talk to loopback, the system is compromised anyway. The developers didn't realize that any webpage open in a browser can do that via script (respecting CORS) and so even loopback services should be considered exposed to the internet. I can imagine that an IoT device offering a browser-accessible REST interface might cause similar non-obvious attack vectors. So at the least, it would have to implement some kind of user management and authentication - which might be challenging for small devices. I think what we really need is some kind of dedicated standard for browsers talking to things on the LAN. Such a standard could then handle discovery, certificate management and authentication/permissions in one go - and would enable browsers to present a good UI for those steps. However, right now everyone seems to busy developing intricate rube-goldberg machines[1] to care and the agenda of the browser vendors seems to go in the opposite direction - so I don't have high hopes. I think practically, the most feasible step right now is to forego browsers and build an app instead. Then you have to deal with the headaches of app development but at least you get a nice user experience without any backend services... [1] https://twitter.com/isotopp/status/877444175708475393 https://twitter.com/isotopp/status/877444175708475393
qb45 9y ago
> Just like on any website. Just because something isn't 100% unbreakable, doesn't mean it's a bad idea (you do lock your doors, don't you?) Don't you think it's a completely different thing to extract keys from a remote server (try https://news.ycombinator.com/ https://news.ycombinator.com/ for example) and a physical gadget you own? Doubly so if the gadget is open source, as you apparently prefer.
- bjpbakker 9y ago
  Not really, for a hacker both are remote servers, aren't they? I agree that in practice many security updates are not provided for IOT devices (another reason for FOSS), so it might get easier and at the same time less relevant to extract the keys. If a gadget is open source doesn't mean the private keys are.. Most internet servers are running open source software (BSD, Linux). In my opinion the manufacturer should /not/ have your gadget's private key. But that's not really related to this problem.
  - qb45 9y ago
    I was talking about a different scenario: I buy the same kind of light bulb you own, extract its private key and use it to either: 1. impersonate your light bulb, because they both have the same key 2. impersonate my light bulb, because you and your browser can't tell the difference To prevent such attacks, each device needs its own certificate and key and then furthermore you need one of the following: 1. each certificate is signed by a unique CA which you add to your browser's list of trusted CAs so that it doesn't trust other devices' certs because they are signed by different CAs 2. each device has a globally unique domain and you type this domain into the browser 3. maybe some other equally cumbersome solution
    - Dylan16807 9y ago
      > 1. impersonate your light bulb, because they both have the same key Definitely don't give both the same key. > 2. impersonate my light bulb, because you and your browser can't tell the difference Who cares if you can impersonate your own lightbulb? > 1. each certificate is signed by a unique CA This doesn't change either scenario. If they shared a key then custom CAs don't stop impersonation. If each device has its own key and CA then they still can't impersonate your device, and they still can impersonate their device. > 2. each device has a globally unique domain and you type this domain into the browser Typing in "jzhf.hue.com" sound easier than figuring out what IP has been assigned to the device.

cryo 9y ago

> Missing from your quote: The alternative is freedom. Philips doesn't have to lock their devices. > If Philips (and other companies, obviously this doesn't relate to just Philips) would provide a community access to their devices and software rather than locking them out, I believe that this problem would not exist. The problem is technical and won't be fixed by just opening the software. > There are plenty alternatives of securely interacting with an IOT device. Please name just one which works for webapps, beside HTTPS. > So if vendors are annoyed with browser warnings, it's because /they/ are doing the wrong thing, not the browsers. Homekit is nice but not available to webapps, apps of course can take advantage of several security mechanisms. My whole rant is about browsers and HTTPS in non public networks. For webapps which want to talk to IoT devices there is only HTTPS and there is _no_ sane way to provide robust, local!, access to a LAN device via HTTPS. Here are some requirements: (actually real, I'm working on a IoT'ish product) * webapp must be served via HTTPS, either from the IoT device or vendor site * it just works! if webapp served from IoT device, the user shall not be required to install certificate or set exception (because it then looks like scary as hell malware) * the webapp must work offline (service worker or appcache) without internet connection * webapp must be able to talk directly to the device, no cloud or vendor server inbetween * the IoT device which provides a secured REST API might be in in a LAN which is NOT connected to the internet -- so the '<random-stuff-id>.vendor.com DNS resolves to device IP with an Lets Encrypt CA' approach won't work here (otherwise nice hack) To my knowledge it's technically not possible to build such a HTTPS secured webapp in a local network today without breaking the mentioned requirements.

bjpbakker 9y ago
> The problem is technical and won't be fixed by just opening the software. I strongly disagree. Main reason is that if Philips opened their firmware to the public, it would have had different protocols by now than just HTTP with a poor mans JSON API. > Homekit is nice but not available to webapps, apps of course can take advantage of several security mechanisms. That's why basically my point is to /not/ use a web app to control local insecure IOT devices. > Please name just one which works for webapps, beside HTTPS. Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC). * update: I just noticed another comment [1] that mentions Plex with a link to some technical details [2]. [1] https://news.ycombinator.com/item?id=14751768 https://news.ycombinator.com/item?id=14751768 [2] https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
- qb45 9y ago
  > it would have had different protocols by now than just HTTP with a poor mans JSON API. Sure, but now you can't control the gadget from the browser and the vendor needs to write an application or something for whatever shitty OS you want to use. > Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC). Not that simple. Public CAs will likely only give you certs for domains you own (like plex.direct) and your users generally don't have nameservers authoritative for such domains on their LANs (maybe you could pull it off if you are a router vendor, but not with IoT light bulbs) so they have to query your public nameserver and the system fails without Internet connection. And there is no easy solution: if your light bulb could register an xxx.philips.com domain via UPnP on your router or via SMB on your Windows box, it would be very much unclear what exactly should prevent it from registering philips.com as well.
xg15 9y ago
I think this is part of the larger problem of the relentless "cloud first" movement that the whole industry seems to have adopted. I feel like there isn't any new software, device or standard in development by now that doesn't demand constant internet access and a dedicated background service. Even basic things that should have no business relying on internet access get swalloed by that. (Browsers, operating systems, cars...) The economic incentives that push everyone in that direction are obvious but I think in the end that will lead to more harm than good. That being said, I can understand that making IoT devices directly accessible from web page JS fü could cause some security headaches: As an example, apparently a lot of recent exploits were caused by programs opening a loopback-only REST service for IPC. Those services weren't secured because, hey, if someone can talk to loopback, the system is compromised anyway. The developers didn't realize that any webpage open in a browser can do that via script (respecting CORS) and so even loopback services should be considered exposed to the internet. I can imagine that an IoT device offering a browser-accessible REST interface might cause similar non-obvious attack vectors. So at the least, it would have to implement some kind of user management and authentication - which might be challenging for small devices. I think what we really need is some kind of dedicated standard for browsers talking to things on the LAN. Such a standard could then handle discovery, certificate management and authentication/permissions in one go - and would enable browsers to present a good UI for those steps. However, right now everyone seems to busy developing intricate rube-goldberg machines[1] to care and the agenda of the browser vendors seems to go in the opposite direction - so I don't have high hopes. I think practically, the most feasible step right now is to forego browsers and build an app instead. Then you have to deal with the headaches of app development but at least you get a nice user experience without any backend services... [1] https://twitter.com/isotopp/status/877444175708475393 https://twitter.com/isotopp/status/877444175708475393

qb45 9y ago

> Just like on any website. Just because something isn't 100% unbreakable, doesn't mean it's a bad idea (you do lock your doors, don't you?) Don't you think it's a completely different thing to extract keys from a remote server (try https://news.ycombinator.com/ https://news.ycombinator.com/ for example) and a physical gadget you own? Doubly so if the gadget is open source, as you apparently prefer.

bjpbakker 9y ago
Not really, for a hacker both are remote servers, aren't they? I agree that in practice many security updates are not provided for IOT devices (another reason for FOSS), so it might get easier and at the same time less relevant to extract the keys. If a gadget is open source doesn't mean the private keys are.. Most internet servers are running open source software (BSD, Linux). In my opinion the manufacturer should /not/ have your gadget's private key. But that's not really related to this problem.
- qb45 9y ago
  I was talking about a different scenario: I buy the same kind of light bulb you own, extract its private key and use it to either: 1. impersonate your light bulb, because they both have the same key 2. impersonate my light bulb, because you and your browser can't tell the difference To prevent such attacks, each device needs its own certificate and key and then furthermore you need one of the following: 1. each certificate is signed by a unique CA which you add to your browser's list of trusted CAs so that it doesn't trust other devices' certs because they are signed by different CAs 2. each device has a globally unique domain and you type this domain into the browser 3. maybe some other equally cumbersome solution
  - Dylan16807 9y ago
    > 1. impersonate your light bulb, because they both have the same key Definitely don't give both the same key. > 2. impersonate my light bulb, because you and your browser can't tell the difference Who cares if you can impersonate your own lightbulb? > 1. each certificate is signed by a unique CA This doesn't change either scenario. If they shared a key then custom CAs don't stop impersonation. If each device has its own key and CA then they still can't impersonate your device, and they still can impersonate their device. > 2. each device has a globally unique domain and you type this domain into the browser Typing in "jzhf.hue.com" sound easier than figuring out what IP has been assigned to the device.