7 ms·

This totally sucks for web based services and sites which don't have a (user friendly) chance to use HTTPS. Think of LAN only IoT devices which aren't proxy th

by cryo 9y ago

This totally sucks for web based services and sites which don't have a (user friendly) chance to use HTTPS. Think of LAN only IoT devices which aren't proxy through a external company site, have no domain, are accessed through (local area network IP) and maybe run in non internet environment. I wish there was a solution for web based encryption for this application domain and browser vendors start to think out of their internet only box. ... same goes for service workers.

quotheth 9y ago
OK, so in your example they create a certificate and use HTTPS and I'm unsure what the problem is. And why would they think outside of their internet only box when they're providing an internet browser?
- tokenizerrr 9y ago
  It's impossible to get a valid SSL certificate for an appliance running within someone their lan, without having to open ports. And opening ports would make the appliance even more vulnerable to attack.
  - quotheth 9y ago
    > It's impossible to get a valid SSL certificate for an appliance running within someone their lan Can you not just create a certificate and push it to the system as a trusted cert? > And opening ports would make the appliance even more vulnerable to attack. Presumably there is already some sort of communication going on if they're receiving Chrome updates.
    - tokenizerrr 9y ago
      > Can you not just create a certificate and push it to the system as a trusted cert? If you were to control the user's machine, yes. But imagine you bought a shiny new internet connected coffee pot. Once you turn it on it does the following: 1. Coffeepot Determines its LAN IP address (e.g. 192.168.1.100) 2. Coffeepot connects to the coffeepot cloud service to register a dynamic DNS entry (e.g. user1.coffeepot.com) to point to its LAN IP address. 3. User is told they can access their coffeepot WebUI by going to user1.coffeepot.com, which resolves to 192.168.1.100 This is secure since the coffeepot can only be controlled if you are in the same network. Yet, since the coffeepot webui can only be reached if you are in its network, it is nearly impossible to get a valid SSL certificate on the coffeepot appliance. > Presumably there is already some sort of communication going on if they're receiving Chrome updates. There is a difference between outgoing network traffic and incoming network traffic. Only the latter requires open ports.
      - WorldMaker 9y ago
        2.alternative: Coffeepot connects to the coffeepot cloud service to register a dynamic DNS entry (e.g. user1.coffeepot.com) to point to its LAN IP address and sends a Certificate Signing Request for user1.coffeepot.com? If you are already registering a dynamic DNS, a CSR shouldn't be that much additional overhead?
        tokenizerrr 9y ago
        Actually, now that I think about it, with the Let's Encrypt DNS challenge this might actually be viable... That's pretty recent, though. And they rate limit harshly. I was thinking about the HTTP validation, which would definitely fail, due to the DNS resolving to a LAN IP. Which a CA would obviously not be able to verify.
        WorldMaker 9y ago
        Right, that burden becomes coffeepot.com's. Supposedly they would already be doing due diligence to make sure that the dynamic DNS requests were from legitimate coffeepots that they themselves manufactured (rather than say the fraudulent activities of a botnet using their open DNS for communications). At that point they should also have enough security information to verify if they should sign a certificate presented to them by their manufactured coffeepot under their certificate authority delegation to *.coffeepot.com. To my knowledge you can even piggy back off of ACME's protocol work from Let's Encrypt, even if the auth/validation checks are different for the different security models.
        tokenizerrr 9y ago
        > under their certificate authority delegation to *.coffeepot.com. Where can I get a certificate with the CA flag set for mydomain.com? I did not know this was an option for mere mortals.
        WorldMaker 9y ago
  - Ajedi32 9y ago
    It's definitely not impossible. Plex does it automatically: 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-... Now that fully automated certificate issuance is becoming more mainstream (thanks to Let's Encrypt) I foresee this sort of thing becoming much more common in the future.
    - tokenizerrr 9y ago
      Unless I'm misunderstanding they did that by partnering with a CA. Becoming a semi-trusted CA themselves. This is not an option for most organizations.
      - Ajedi32 9y ago
        That was only necessary because, at the time, there was no other way to get a large number of wildcard certs issued for their domain in an automated fashion. With ACME that will no longer be the case. Let's Encrypt will allow you to do basically the same thing for free with ~20 devices a week[1] starting on February 27[2], for example. In the future, commercial CAs may choose to offer similar services with more relaxed rate limits. [1]: https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/ [2]: https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html https://letsencrypt.org/2017/07/06/wildcard-certificates-com...
        tokenizerrr 9y ago
        Yeah, would be nice if ACME with DNS validation was widespread. But right now it's still not viable due to Let's Encrypt's rate limits.
        pfg 9y ago
        It's fairly trivial to request a rate limit adjustment from Let's Encrypt[1]. [1]: https://docs.google.com/forms/d/e/1FAIpQLSetFLqcyPrnnrom2Kw802ZjukDVex67dOM2g4O8jEbfWFs3dA/viewform https://docs.google.com/forms/d/e/1FAIpQLSetFLqcyPrnnrom2Kw8...
  - deleted 9y ago
    [deleted]
  - fulafel 9y ago
    It's possible, why not? Just use your own servers as a cert signing service for your IoT device as part of the bootstrap process if you are unwilling to have any services running on it. Or ship the device with the signed cert. You can have the host name in the DNS even though it's not accessible from everywhere.
    - Zarel 9y ago
      > Or ship the device with the signed cert. Certs expire sometimes. And the device doesn't necessarily have an internet connection. What then?
      - deleted 9y ago
        [deleted]
dragonwriter 9y ago
> Think of LAN only IoT devices which aren't proxy through a external company site, have no domain, are accessed through (local area network IP) and maybe run in non internet environment. As long as it's a “Not Secure” omnibox warning, I don't see it as a problem even there. Now, if they adopted the “block with non-obvious escape hatch” approach used for certificate errors for HTTP, that would be a problem.
foolfoolz 9y ago
the future of IoT is HTTPS with client side X.509 authentication. you don’t need internet to make that happen. but if you are web based and not using HTTPS... i can only ask why not? internal CAs are free
- deleted 9y ago
  [deleted]
- tokenizerrr 9y ago
  Please tell me how to painlessly install a CA on a user their computer? Imagine buying a network connected coffeepot. You plug it in and you're done.
  - foolfoolz 9y ago
    all you need is a certificate on the device and an app in the app store. or an installer they can download to their computer. you don’t need a full on traditional CA. you just need to verify (one) certificates. sign the certificate in the manufacturing plant and put it in the coffee maker l. give the CA cert out in the app or the installer. now you can verify if the coffee maker talking to you over HTTPS is legit and probably get it’s serial number off the cert too. your CA keys never see the public. you could go even more secure and use that as a bootstrap to a per customer CA and generate a new cert on install, but this is a coffee maker right?
    - tokenizerrr 9y ago
      What app store? Which OS? Do you now suddenly have to write software for all OSes to install the certificate? Something that you didn't even have to think about doing before. The entire reason you went for a webui to begin with.
      - foolfoolz 9y ago
        this is only in the pure local no internet case. with internet it’s a no-install plug in and done you don’t need to install any certificates in any case. the server just needs to validate the client is well signed
stouset 9y ago
Unfortunately, this is a problem that will never go away, no matter how slowly and gracefully we transition. There is no alternative that allows these devices to continue to operate without friction that doesn’t also enable current device manufacturers to kick the can down the road by releasing new HTTP-only devices. If we want to keep making the web a safer place, these kinds of cutoffs have to happen. Infinite backward compatibility simply holds everyone back for the sake of decreasingly-relevant devices and irresponsible manufacturers of new hardware and the customers who purchase their products. The sooner we get to universal HTTPS the better.
- notatoad 9y ago
  so the solution to the warning is to make your offline IoT devices secure, but how do you actually do that? i have an IoT product that runs a web server and needs to be accessible by users when the internet connection isn't available. how do I enable HTTPS on it? (this is not a hypothetical. it's a problem i actually need to solve) as far as i can tell, my options are: - install a self-signed cert on the device and force my users to click through all the warnings chrome throws up about untrusted certs - create my own CA cert and sign the cert with that, and convince the user to install my CA cert as a trusted cert (which is not possible on iOS) - get a cert signed by a trusted authority, and get the user to add an entry to their /etc/hosts file that maps the domain the cert is valid for whatever address the device is assigned - distrubute a native (electron?) app that interfaces with my device and trusts my cert, and disallow direct browser access. - find some sketchy SSL issuer who is willing to issue certs for *.local domains and run an mDNS resolver on my device - Use HTTP instead of HTTPS and the only downside is a little badge in the address bar saying "not secure" I'd love to have HTTPS everywhere, but i honestly don't know how to make it happen.
  - madeofpalk 9y ago
    > install my CA cert as a trusted cert (which is not possible on iOS) FWIW, unless we're talking about different things, you can install and trust custom CA certs on iOS. https://developer.apple.com/library/content/qa/qa1948/_index.html#//apple_ref/doc/uid/DTS40017603-CH1-SECINSTALLING https://developer.apple.com/library/content/qa/qa1948/_index...
rocky1138 9y ago
I didn't read anything in the article that said that HTTP will stop working, only that it'll be marked as not secure in the new Chrome. If you understand the security risks involved and are okay with continued use of bare HTTP, it shouldn't make any difference to you.
deleted 9y ago
[deleted]
fulafel 9y ago
You can totally set up a domain for an IoT device that has restricted accessibility.

by cryo 9y ago

quotheth 9y ago

OK, so in your example they create a certificate and use HTTPS and I'm unsure what the problem is. And why would they think outside of their internet only box when they're providing an internet browser?

tokenizerrr 9y ago
It's impossible to get a valid SSL certificate for an appliance running within someone their lan, without having to open ports. And opening ports would make the appliance even more vulnerable to attack.
- quotheth 9y ago
  > It's impossible to get a valid SSL certificate for an appliance running within someone their lan Can you not just create a certificate and push it to the system as a trusted cert? > And opening ports would make the appliance even more vulnerable to attack. Presumably there is already some sort of communication going on if they're receiving Chrome updates.
  - tokenizerrr 9y ago
    > Can you not just create a certificate and push it to the system as a trusted cert? If you were to control the user's machine, yes. But imagine you bought a shiny new internet connected coffee pot. Once you turn it on it does the following: 1. Coffeepot Determines its LAN IP address (e.g. 192.168.1.100) 2. Coffeepot connects to the coffeepot cloud service to register a dynamic DNS entry (e.g. user1.coffeepot.com) to point to its LAN IP address. 3. User is told they can access their coffeepot WebUI by going to user1.coffeepot.com, which resolves to 192.168.1.100 This is secure since the coffeepot can only be controlled if you are in the same network. Yet, since the coffeepot webui can only be reached if you are in its network, it is nearly impossible to get a valid SSL certificate on the coffeepot appliance. > Presumably there is already some sort of communication going on if they're receiving Chrome updates. There is a difference between outgoing network traffic and incoming network traffic. Only the latter requires open ports.
    - WorldMaker 9y ago
      2.alternative: Coffeepot connects to the coffeepot cloud service to register a dynamic DNS entry (e.g. user1.coffeepot.com) to point to its LAN IP address and sends a Certificate Signing Request for user1.coffeepot.com? If you are already registering a dynamic DNS, a CSR shouldn't be that much additional overhead?
      - tokenizerrr 9y ago
        Actually, now that I think about it, with the Let's Encrypt DNS challenge this might actually be viable... That's pretty recent, though. And they rate limit harshly. I was thinking about the HTTP validation, which would definitely fail, due to the DNS resolving to a LAN IP. Which a CA would obviously not be able to verify.
        WorldMaker 9y ago
        Right, that burden becomes coffeepot.com's. Supposedly they would already be doing due diligence to make sure that the dynamic DNS requests were from legitimate coffeepots that they themselves manufactured (rather than say the fraudulent activities of a botnet using their open DNS for communications). At that point they should also have enough security information to verify if they should sign a certificate presented to them by their manufactured coffeepot under their certificate authority delegation to *.coffeepot.com. To my knowledge you can even piggy back off of ACME's protocol work from Let's Encrypt, even if the auth/validation checks are different for the different security models.
        tokenizerrr 9y ago
        > under their certificate authority delegation to *.coffeepot.com. Where can I get a certificate with the CA flag set for mydomain.com? I did not know this was an option for mere mortals.
        WorldMaker 9y ago
- Ajedi32 9y ago
  It's definitely not impossible. Plex does it automatically: 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-... Now that fully automated certificate issuance is becoming more mainstream (thanks to Let's Encrypt) I foresee this sort of thing becoming much more common in the future.
  - tokenizerrr 9y ago
    Unless I'm misunderstanding they did that by partnering with a CA. Becoming a semi-trusted CA themselves. This is not an option for most organizations.
    - Ajedi32 9y ago
      That was only necessary because, at the time, there was no other way to get a large number of wildcard certs issued for their domain in an automated fashion. With ACME that will no longer be the case. Let's Encrypt will allow you to do basically the same thing for free with ~20 devices a week[1] starting on February 27[2], for example. In the future, commercial CAs may choose to offer similar services with more relaxed rate limits. [1]: https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/ [2]: https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html https://letsencrypt.org/2017/07/06/wildcard-certificates-com...
      - tokenizerrr 9y ago
        Yeah, would be nice if ACME with DNS validation was widespread. But right now it's still not viable due to Let's Encrypt's rate limits.
        pfg 9y ago
        It's fairly trivial to request a rate limit adjustment from Let's Encrypt[1]. [1]: https://docs.google.com/forms/d/e/1FAIpQLSetFLqcyPrnnrom2Kw802ZjukDVex67dOM2g4O8jEbfWFs3dA/viewform https://docs.google.com/forms/d/e/1FAIpQLSetFLqcyPrnnrom2Kw8...
- deleted 9y ago
  [deleted]
- fulafel 9y ago
  It's possible, why not? Just use your own servers as a cert signing service for your IoT device as part of the bootstrap process if you are unwilling to have any services running on it. Or ship the device with the signed cert. You can have the host name in the DNS even though it's not accessible from everywhere.
  - Zarel 9y ago
    > Or ship the device with the signed cert. Certs expire sometimes. And the device doesn't necessarily have an internet connection. What then?
    - deleted 9y ago
      [deleted]

dragonwriter 9y ago

> Think of LAN only IoT devices which aren't proxy through a external company site, have no domain, are accessed through (local area network IP) and maybe run in non internet environment. As long as it's a “Not Secure” omnibox warning, I don't see it as a problem even there. Now, if they adopted the “block with non-obvious escape hatch” approach used for certificate errors for HTTP, that would be a problem.

foolfoolz 9y ago

the future of IoT is HTTPS with client side X.509 authentication. you don’t need internet to make that happen. but if you are web based and not using HTTPS... i can only ask why not? internal CAs are free

deleted 9y ago
[deleted]
tokenizerrr 9y ago
Please tell me how to painlessly install a CA on a user their computer? Imagine buying a network connected coffeepot. You plug it in and you're done.
- foolfoolz 9y ago
  all you need is a certificate on the device and an app in the app store. or an installer they can download to their computer. you don’t need a full on traditional CA. you just need to verify (one) certificates. sign the certificate in the manufacturing plant and put it in the coffee maker l. give the CA cert out in the app or the installer. now you can verify if the coffee maker talking to you over HTTPS is legit and probably get it’s serial number off the cert too. your CA keys never see the public. you could go even more secure and use that as a bootstrap to a per customer CA and generate a new cert on install, but this is a coffee maker right?
  - tokenizerrr 9y ago
    What app store? Which OS? Do you now suddenly have to write software for all OSes to install the certificate? Something that you didn't even have to think about doing before. The entire reason you went for a webui to begin with.
    - foolfoolz 9y ago
      this is only in the pure local no internet case. with internet it’s a no-install plug in and done you don’t need to install any certificates in any case. the server just needs to validate the client is well signed

stouset 9y ago

Unfortunately, this is a problem that will never go away, no matter how slowly and gracefully we transition. There is no alternative that allows these devices to continue to operate without friction that doesn’t also enable current device manufacturers to kick the can down the road by releasing new HTTP-only devices. If we want to keep making the web a safer place, these kinds of cutoffs have to happen. Infinite backward compatibility simply holds everyone back for the sake of decreasingly-relevant devices and irresponsible manufacturers of new hardware and the customers who purchase their products. The sooner we get to universal HTTPS the better.

notatoad 9y ago
so the solution to the warning is to make your offline IoT devices secure, but how do you actually do that? i have an IoT product that runs a web server and needs to be accessible by users when the internet connection isn't available. how do I enable HTTPS on it? (this is not a hypothetical. it's a problem i actually need to solve) as far as i can tell, my options are: - install a self-signed cert on the device and force my users to click through all the warnings chrome throws up about untrusted certs - create my own CA cert and sign the cert with that, and convince the user to install my CA cert as a trusted cert (which is not possible on iOS) - get a cert signed by a trusted authority, and get the user to add an entry to their /etc/hosts file that maps the domain the cert is valid for whatever address the device is assigned - distrubute a native (electron?) app that interfaces with my device and trusts my cert, and disallow direct browser access. - find some sketchy SSL issuer who is willing to issue certs for *.local domains and run an mDNS resolver on my device - Use HTTP instead of HTTPS and the only downside is a little badge in the address bar saying "not secure" I'd love to have HTTPS everywhere, but i honestly don't know how to make it happen.
- madeofpalk 9y ago
  > install my CA cert as a trusted cert (which is not possible on iOS) FWIW, unless we're talking about different things, you can install and trust custom CA certs on iOS. https://developer.apple.com/library/content/qa/qa1948/_index.html#//apple_ref/doc/uid/DTS40017603-CH1-SECINSTALLING https://developer.apple.com/library/content/qa/qa1948/_index...

rocky1138 9y ago

I didn't read anything in the article that said that HTTP will stop working, only that it'll be marked as not secure in the new Chrome. If you understand the security risks involved and are okay with continued use of bare HTTP, it shouldn't make any difference to you.

deleted 9y ago

[deleted]

fulafel 9y ago

You can totally set up a domain for an IoT device that has restricted accessibility.