5 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 could

by qb45 9y ago

> > 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? Even if they somehow solve the problem of giving these devices domain names and even if they generate separate private key for each unit, the key and cert are going to be embedded in the firmware and a sufficiently sophisticated attacker will just extract them and become able to impersonate some Philips device. How the user of another device is going to tell whether he is connecting to his device or to malicious neighbor impersonating neighbor's device to establish Philips-signed HTTPS with the victim and then another connection to victim's device and MITM the victim? You would have to make all users install a trusted certificate authority tied to their individual device. Which is a UX disaster in current browsers and also a security disaster, because if this becomes a norm, sooner or later somebody will sell you a toy device bundled with a CA crafted to give him the ability to impersonate any website. And you'll trust this CA because you want to play with the toy. This maybe could be made to work with some improvements in browser UI. Make it easier to add new roots of trust. Make it easier to learn and/or limit what websites these certs will be authorized to authenticate. But nothing like that exists now. > The fact that your browser warns you about insecure communication happening from that web page, that's a good thing. [...] The simple fact that you accept some insecure traffic, doesn't make it secure. True. As somebody pointed out elsewhere in this thread, this warning will become another EU cookie banner nothingburger.

Dylan16807 9y ago
> That's not a constructive argument. I don't see how they could make it work? Give each one a subdomain that resolves to its local IP, and give it a valid certificate for that subdomain. > extract them and become able to impersonate some Philips device. Or the attacker could just have a real, non-impersonated Philips device. If the user deliberately points their browser at the wrong device's site, nothing can save them. This is a very different problem from securing access to the correct site. > You would have to make all users install a trusted certificate authority tied to their individual device. That's not true, and I don't even understand what benefit that would have. If you have a way to deliver a CA, instead you should deliver the correct address of the device. This makes 'MitM' impossible without any downsides.
bjpbakker 9y ago
> > > 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.
michaelt 9y ago
I don't see how they could make it work? Plex achieves this with a very convoluted setup [1] - they set up a DNS server so that 1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct returns IP address 1.2.3.4, then they issue a single user a wildcard certificate for *.625d406a00ac415b978ddb368c0d1289.plex.direct Of course, you have to get a special deal from a CA at who-knows-what-cost - likely meaning open source projects need not apply. And you get a dependency on cloud infrastructure, if they stop issuing certs you end up in a bad place. And you get a giant, ugly URL. And you have to make a DNS lookup so traffic leaves your network anyway. It's an ugly solution with a lot of downsides - but I doubt the CA/Browser Forum plans to give people much choice in the matter, so it's their way or the highway :-| [1] 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-...
- icebraining 9y ago
  I don't see why you couldn't do that with Let's Encrypt, especially since they just announced they'll start giving out free wildcard certs.
  - greggman 9y ago
    wildcard certs are not a solution to this problem. Sharing a private cert with all customers isn't what the solution does. every customer gets their own cert second letsenrypt has low limits of 20 certs per week. so imagine VLC added a Plex like streaming feature. they'd need far far more than 20 certs a day given how large their user base is
    - qb45 9y ago
      BTW, who really is Let's Encrypt, why should I trust them, why should I trust they won't disappear once plain HTTP is no longer supported by cargo-cult-security-conscious browsers? It seems to me like providing certificates isn't exactly free, in itself.
      - icebraining 9y ago
piscisaureus 9y ago
I would suggest that browsers should support some kind of TOFU for self-signed certificates used by non-publicly accessible web servers. What if they'd just ask the user to accept and install a certificate when connecting to a local server for the first time?

by qb45 9y ago

Dylan16807 9y ago

> That's not a constructive argument. I don't see how they could make it work? Give each one a subdomain that resolves to its local IP, and give it a valid certificate for that subdomain. > extract them and become able to impersonate some Philips device. Or the attacker could just have a real, non-impersonated Philips device. If the user deliberately points their browser at the wrong device's site, nothing can save them. This is a very different problem from securing access to the correct site. > You would have to make all users install a trusted certificate authority tied to their individual device. That's not true, and I don't even understand what benefit that would have. If you have a way to deliver a CA, instead you should deliver the correct address of the device. This makes 'MitM' impossible without any downsides.

bjpbakker 9y ago

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

michaelt 9y ago

I don't see how they could make it work? Plex achieves this with a very convoluted setup [1] - they set up a DNS server so that 1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct returns IP address 1.2.3.4, then they issue a single user a wildcard certificate for *.625d406a00ac415b978ddb368c0d1289.plex.direct Of course, you have to get a special deal from a CA at who-knows-what-cost - likely meaning open source projects need not apply. And you get a dependency on cloud infrastructure, if they stop issuing certs you end up in a bad place. And you get a giant, ugly URL. And you have to make a DNS lookup so traffic leaves your network anyway. It's an ugly solution with a lot of downsides - but I doubt the CA/Browser Forum plans to give people much choice in the matter, so it's their way or the highway :-| [1] 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-...

icebraining 9y ago
I don't see why you couldn't do that with Let's Encrypt, especially since they just announced they'll start giving out free wildcard certs.
- greggman 9y ago
  wildcard certs are not a solution to this problem. Sharing a private cert with all customers isn't what the solution does. every customer gets their own cert second letsenrypt has low limits of 20 certs per week. so imagine VLC added a Plex like streaming feature. they'd need far far more than 20 certs a day given how large their user base is
  - qb45 9y ago
    BTW, who really is Let's Encrypt, why should I trust them, why should I trust they won't disappear once plain HTTP is no longer supported by cargo-cult-security-conscious browsers? It seems to me like providing certificates isn't exactly free, in itself.
    - icebraining 9y ago

piscisaureus 9y ago

I would suggest that browsers should support some kind of TOFU for self-signed certificates used by non-publicly accessible web servers. What if they'd just ask the user to accept and install a certificate when connecting to a local server for the first time?