8 ms·

Basically, yes. Browser vendors have had an agreement for some time now to only expose new APIs in secure contexts in order to encourage HTTPS adoption.

wyager 5y ago
I'm not sure I feel great about gating feature A behind completely unrelated feature B just because manufacturers like feature B. Even if feature B is concretely pretty good (which is debatable for https as it exists now), this seems bad on principle.
- bhawks 5y ago
  The browser security model is trivially defeated without the usage of https. IT is not an orthogonal or unrelated feature. Making all new API development available only when content is delivered via a mechanism that provides the foundation for the rest of web security is good engineering practice.
- jorl17 5y ago
  I'm interested: why do you think it is debatable if HTTPS is "concretely pretty good" as it exists now?
  - Nextgrid 5y ago
    It's not always necessary. Think fully offline networks that can't/won't use a CA anyway, or networks where physical/machine access is the intended layer of security (a web server running on localhost). In these scenarios a self-signed certificate will rarely improve security because most users will click through the warning anyway in case of an MITM attack.
    - pornel 5y ago
      Browsers make an exception for localhost and treat it as a secure context. It's also possible to get a certificate from a CA using any public IP address, and then reuse that cert for LAN. Certs are bound to domain names, not IP addresses.
      - jonhohle 5y ago
        Why should an org expose details of private infrastructure publicly? For anyone with more than a few internal tools this becomes untenable or unreasonable quickly and sharing a wildcard cert has diminishing returns as its shared between apps, teams, etc.
    - unqueued 5y ago
      Users should not have to rely on the network being isolated for security. Even when I have an offline network, I still use SSH whenever possible. Yes, I don't benefit from initial verification, but I pin the certificate from then on. I don't think that the current "all or nothing" paradigm that we use with SSL in browsers makes any sense. I have been really disappointed over the last few years deploying network connected devices and trying to make their services available in a secure way. It is not really possible for ipcams, routers, etc to offer services in HTTPS in a semi-online network. There should be a kind of 'encrypted but unverified' mode. Even the worst failure mode is no worse than a plaintext connection.
      - Nextgrid 5y ago
        Let’s say I sell a physical device that allows you to use a browser as its UI. You just plug an Ethernet cable and point your browser to its web server. Security is done by physical access. Anything else is just extra complexity and points of failure, and if an attacker can get physical access to the LAN cable, he can just as well walk to the machine directly and change the settings on the control panel. HTTPS, with its current UX, would be a net negative in this case.
        eternityforest 5y ago
        unqueued 5y ago
        > HTTPS, with its current UX, would be a net negative in this case. I would just replace "HTTPS" with "SSH", and see if that statement is still reasonable. Even though SSH is not perfect when you can't verify the initial connection to a host on a local network, using TELNET instead is not a solution. I have yet to hear a reason why HTTP is better than self signed and pinned HTTPS; why possibly insecure is worse than insecure. The only justifications I have heard are UX justifications, and those are really just a critique of the UX, not the protocol. > Security is done by physical access. Anything else is just extra complexity and points of failure, and if an attacker can get physical access to the LAN cable, he can just as well walk to the machine directly and change the settings on the control panel. That is an extremely fragile solution. By default ethernet is very open. It is very easy to bridge it with other devices or routers to announce themselves and start routing. It happens all the time on what are supposed to be closed networks, I've seen it. And many networks are semi-offline. You may need to have limited internet access. Or the network configuration may change in the future.
- judge2020 5y ago
  If it helps, it really doesn’t care what certificate the page it signed with, whether that be localhost, Mozilla CA participants, or maybe even a future CA fork for Russia if that happens. Plaintext HTTP is just not advisable even on a private network when some inline network device like LAN turtle could be passively exfiltrating traffic.
makeitdouble 5y ago
I am in agreement with wyager, this feature looks like it could be heavily beneficial to a shipping company's internal web app for instance, or other applications that could be running completely isolated from the global network (or running on the machine itself for that matter). Forcing https in these applications is a waste of time and money for orthogonal purposes. I guess it could be seen as a cost of dev. for any web based application from now on, but it's sad to me to see the barrier to entry get higher for these reasons.
- jupp0r 5y ago
  If it's cheaper for you to run an http than an https server then you are holding it wrong.
  - arjvik 5y ago
    Internal domains, where getting a certificate to client devices is painful
    - pests 5y ago
      You can use a public CA like LetsEncrypt then. Exposes you to the certificate log but you should be secured already anyways. Just have to use the DNS challenge (unless you wanna poke a hole for certbot) to grab it
      - makeitdouble 5y ago
        Looking at guides for LetsEncrypt on internal IPs/domains, it seems to be as painful as creating and managing your own CA: https://geontech.com/using-letsencrypt-ssl-internally/ https://geontech.com/using-letsencrypt-ssl-internally/
        pests 5y ago
        I had a chance to skim through the link you posted - they are doing the http challenge verification (in step 6) for some reason which involves forwarding their domain into their internal network. The DNS methods we already mentioned does not involve any of that - just a simple zone file change or a few clicks in a web UI to add a new record.

wyager 5y ago

I'm not sure I feel great about gating feature A behind completely unrelated feature B just because manufacturers like feature B. Even if feature B is concretely pretty good (which is debatable for https as it exists now), this seems bad on principle.

bhawks 5y ago
The browser security model is trivially defeated without the usage of https. IT is not an orthogonal or unrelated feature. Making all new API development available only when content is delivered via a mechanism that provides the foundation for the rest of web security is good engineering practice.
jorl17 5y ago
I'm interested: why do you think it is debatable if HTTPS is "concretely pretty good" as it exists now?
- Nextgrid 5y ago
  It's not always necessary. Think fully offline networks that can't/won't use a CA anyway, or networks where physical/machine access is the intended layer of security (a web server running on localhost). In these scenarios a self-signed certificate will rarely improve security because most users will click through the warning anyway in case of an MITM attack.
  - pornel 5y ago
    Browsers make an exception for localhost and treat it as a secure context. It's also possible to get a certificate from a CA using any public IP address, and then reuse that cert for LAN. Certs are bound to domain names, not IP addresses.
    - jonhohle 5y ago
      Why should an org expose details of private infrastructure publicly? For anyone with more than a few internal tools this becomes untenable or unreasonable quickly and sharing a wildcard cert has diminishing returns as its shared between apps, teams, etc.
  - unqueued 5y ago
    Users should not have to rely on the network being isolated for security. Even when I have an offline network, I still use SSH whenever possible. Yes, I don't benefit from initial verification, but I pin the certificate from then on. I don't think that the current "all or nothing" paradigm that we use with SSL in browsers makes any sense. I have been really disappointed over the last few years deploying network connected devices and trying to make their services available in a secure way. It is not really possible for ipcams, routers, etc to offer services in HTTPS in a semi-online network. There should be a kind of 'encrypted but unverified' mode. Even the worst failure mode is no worse than a plaintext connection.
    - Nextgrid 5y ago
      Let’s say I sell a physical device that allows you to use a browser as its UI. You just plug an Ethernet cable and point your browser to its web server. Security is done by physical access. Anything else is just extra complexity and points of failure, and if an attacker can get physical access to the LAN cable, he can just as well walk to the machine directly and change the settings on the control panel. HTTPS, with its current UX, would be a net negative in this case.
      - eternityforest 5y ago
      - unqueued 5y ago
        > HTTPS, with its current UX, would be a net negative in this case. I would just replace "HTTPS" with "SSH", and see if that statement is still reasonable. Even though SSH is not perfect when you can't verify the initial connection to a host on a local network, using TELNET instead is not a solution. I have yet to hear a reason why HTTP is better than self signed and pinned HTTPS; why possibly insecure is worse than insecure. The only justifications I have heard are UX justifications, and those are really just a critique of the UX, not the protocol. > Security is done by physical access. Anything else is just extra complexity and points of failure, and if an attacker can get physical access to the LAN cable, he can just as well walk to the machine directly and change the settings on the control panel. That is an extremely fragile solution. By default ethernet is very open. It is very easy to bridge it with other devices or routers to announce themselves and start routing. It happens all the time on what are supposed to be closed networks, I've seen it. And many networks are semi-offline. You may need to have limited internet access. Or the network configuration may change in the future.
judge2020 5y ago
If it helps, it really doesn’t care what certificate the page it signed with, whether that be localhost, Mozilla CA participants, or maybe even a future CA fork for Russia if that happens. Plaintext HTTP is just not advisable even on a private network when some inline network device like LAN turtle could be passively exfiltrating traffic.

makeitdouble 5y ago

I am in agreement with wyager, this feature looks like it could be heavily beneficial to a shipping company's internal web app for instance, or other applications that could be running completely isolated from the global network (or running on the machine itself for that matter). Forcing https in these applications is a waste of time and money for orthogonal purposes. I guess it could be seen as a cost of dev. for any web based application from now on, but it's sad to me to see the barrier to entry get higher for these reasons.

jupp0r 5y ago
If it's cheaper for you to run an http than an https server then you are holding it wrong.
- arjvik 5y ago
  Internal domains, where getting a certificate to client devices is painful
  - pests 5y ago
    You can use a public CA like LetsEncrypt then. Exposes you to the certificate log but you should be secured already anyways. Just have to use the DNS challenge (unless you wanna poke a hole for certbot) to grab it
    - makeitdouble 5y ago
      Looking at guides for LetsEncrypt on internal IPs/domains, it seems to be as painful as creating and managing your own CA: https://geontech.com/using-letsencrypt-ssl-internally/ https://geontech.com/using-letsencrypt-ssl-internally/
      - pests 5y ago
        I had a chance to skim through the link you posted - they are doing the http challenge verification (in step 6) for some reason which involves forwarding their domain into their internal network. The DNS methods we already mentioned does not involve any of that - just a simple zone file change or a few clicks in a web UI to add a new record.