7 ms·

> 1) internal corporation services, websites and webapps If not for hostname validation, how would you even /know/ that you're talking to the "internal corpora

> 1) internal corporation services, websites and webapps If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? And how would you feel if people on the same LAN could see and modify all your interactions with those services? 2) services that run in a local private network like on a Raspberry Pi Depending on the type of service you may or may not want TLS. If you visit the service by IP address and specific port anyway, you can easily add an exception for your internal IP. This will never be used like so by non-tech-savvy people. 3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services I cannot think of any reason to /not/ want to use HTTPS on this. It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting. Don't blame browsers for warning people for their insecure systems and appliances. Instead blame their creators or manufacturers as they're the ones who can fix this situation. edit: formatting

cryo 9y ago
> It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting. The Philips hue bridge REST API is accessible in the local network like http://192.168.1.123/api/ http://192.168.1.123/api/ .... which is great since apps/wepapps can talk to the bridge without a cloud or philips server inbetween. And this is the very problem, it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server, keeping the very cool feature to talk only within the local network to the bridge. Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings?
- bjpbakker 9y ago
  > it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server I don't see why not. The alternative is freedom. Philips doesn't have to lock their devices. That's a choice they made, sadly the choice that most companies make. > Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings? The fact that your browser warns you about insecure communication happening from that web page, that's a good thing. Even iff you deliberately choose accept that and believe that there's no other way for this particular service/device. The simple fact that you accept some insecure traffic, doesn't make it secure.
  - 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.
- cm2187 9y ago
  If it is an http API, you don't really need a public certificate. You can have a long term selfsigned certificate on the device and you check that the thumbprint hasn't changed every time you connect from your client. These big warning windows are for connecting to it from a browser, not a RestClient.
  - cryo 9y ago
    >These big warning windows are for connecting to it from a browser, not a RestClient. Which in my case is a webapp running in a browser :)
    - Jaruzel 9y ago
      Why not just proxy the REST requests through your own backend HTTPS server-app ?
    - akvadrako 9y ago
      So any random webpage can talk to your Hue bridge? I'm surprised they even allow such cross-domain requests, but this anyway doesn't seem safe.
      - cryo 9y ago
        Cross-domain is needed, otherwise an app/webapp couldn't talk to the bridge since the bridge only serves the REST API. However in order to send control commands and query light states the app/webapp needs to authenticate and create a account, which is only possible for a few seconds after pressing a physical bridge button.
- lorenzhs 9y ago
  We have the same issue with Glowing Bear (https://github.com/glowing-bear/glowing-bear https://github.com/glowing-bear/glowing-bear). It's a web frontend for an IRC client (WeeChat) that connects directly to WeeChat via WebSockets. Sort of like self-hosted irccloud without a cloud. We really want everyone to use encrypted connections [0] and push people onto the TLS version of Glowing Bear. But some people host their WeeChat on their local network, and you can't (realistically) get a certificate for a local IP. So for those people we need to open an unencrypted websocket (ws://1.2.3.4), which isn't possible from an https site. Ideally we'd like to disallow unencrypted connections to non-local destinations but that's practically impossible to determine in JS. It's a super annoying problem. Disallowing unsafe websockets from secure origins is one of those policies that is a really good idea 99.5% of the time but for those last 0.5% of use cases, it's a major pain in the bum. [0] WeeChat has a /exec command to execute arbitrary commands, and the client has access to that --- not great when you transmit your password in plain text.
Xcelerate 9y ago
> If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? Because a crap ton of Linux software comes with its own set of bundled root CAs instead of using the system defaults. Welcome to the configuration nightmare that is setting up Anaconda, npm, AWS CLI, Python (Requests library), Git, etc. for working with something like Zscaler.
- tgragnato 9y ago
  Zscaler performs TLS interception in order to analyse the traffic and “protect the users”. [https://support.zscaler.com/hc/en-us/articles/205059995-How-does-Zscaler-protect-SSL-traffic- https://support.zscaler.com/hc/en-us/articles/205059995-How-...] The issue is that Zscaler may have flaws, and that even if the validation is performed flawlessly then the introduced risk is not zero… Usually one would have to trust the root CAs, but with TLS interception we have to trust the trust of the MiTM software in the root CAs. This increases the attack surface instead of decreasing it. For a security appliance it’s a pretty bad job; sure, there may be reasons why you want to look into traffic, but then the aim is to control the communication. And control doesn’t come for free.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
syrrim 9y ago
>If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? If you control physical hardware, and you control all the users on it (as a corporate network), then you can know that nothing is amiss. >And how would you feel if people on the same LAN could see and modify all your interactions with those services? The fact that they physically can doesn't mean they will. For 2 & 3: https has two modes: self signed, and certified. Certified requires that you have a public facing domain name, such as "news.ycombinator.com". Devices on private networks can't have public domain names. Consumer devices on public networks could have domain names, but this would be very difficult to configure. Without a domain name, https must be done as self signed. With self signed, when you first interact with the server, it could be anyone. Self signed https only gives you the guarantee that any further interaction besides this first one are with the same server as the first one. It should be clear that you can still be MITMed under this mode, so long as the attacker can intersect the first message you send after a reboot. If you're scared of network ninjas sneaking into your house in the middle of the night and intersecting your packets, self signed https is no better than http.
- wang_li 9y ago
  >With self signed, when you first interact with the server, it could be anyone. Self signed https only gives you the guarantee that any further interaction besides this first one are with the same server as the first one. If I create a CA and install that CA's public key in my browser, then use that CA to sign the cert for a device on my network, why exactly will it "be anyone"? Unrelated, but this push for HTTPS for everything isn't without downsides. Many apps gather extensive data when running on my devices and they communicate that data back to some central location, sometimes under the guise of functionality, sometimes straight up nefariously, but always with a side effect of giving that central entity a complete record of what I'm doing and often also exfiltrates my data (contacts, etc.) Honestly, I've been tempted to set up a transparent TLS terminating proxy at my home to give myself some possibility of seeing wtf is coming and going from my network.
  - Vendan 9y ago

cryo 9y ago

> It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting. The Philips hue bridge REST API is accessible in the local network like http://192.168.1.123/api/ http://192.168.1.123/api/ .... which is great since apps/wepapps can talk to the bridge without a cloud or philips server inbetween. And this is the very problem, it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server, keeping the very cool feature to talk only within the local network to the bridge. Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings?

bjpbakker 9y ago
> it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server I don't see why not. The alternative is freedom. Philips doesn't have to lock their devices. That's a choice they made, sadly the choice that most companies make. > Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings? The fact that your browser warns you about insecure communication happening from that web page, that's a good thing. Even iff you deliberately choose accept that and believe that there's no other way for this particular service/device. The simple fact that you accept some insecure traffic, doesn't make it secure.
- 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.
cm2187 9y ago
If it is an http API, you don't really need a public certificate. You can have a long term selfsigned certificate on the device and you check that the thumbprint hasn't changed every time you connect from your client. These big warning windows are for connecting to it from a browser, not a RestClient.
- cryo 9y ago
  >These big warning windows are for connecting to it from a browser, not a RestClient. Which in my case is a webapp running in a browser :)
  - Jaruzel 9y ago
    Why not just proxy the REST requests through your own backend HTTPS server-app ?
  - akvadrako 9y ago
    So any random webpage can talk to your Hue bridge? I'm surprised they even allow such cross-domain requests, but this anyway doesn't seem safe.
    - cryo 9y ago
      Cross-domain is needed, otherwise an app/webapp couldn't talk to the bridge since the bridge only serves the REST API. However in order to send control commands and query light states the app/webapp needs to authenticate and create a account, which is only possible for a few seconds after pressing a physical bridge button.
lorenzhs 9y ago
We have the same issue with Glowing Bear (https://github.com/glowing-bear/glowing-bear https://github.com/glowing-bear/glowing-bear). It's a web frontend for an IRC client (WeeChat) that connects directly to WeeChat via WebSockets. Sort of like self-hosted irccloud without a cloud. We really want everyone to use encrypted connections [0] and push people onto the TLS version of Glowing Bear. But some people host their WeeChat on their local network, and you can't (realistically) get a certificate for a local IP. So for those people we need to open an unencrypted websocket (ws://1.2.3.4), which isn't possible from an https site. Ideally we'd like to disallow unencrypted connections to non-local destinations but that's practically impossible to determine in JS. It's a super annoying problem. Disallowing unsafe websockets from secure origins is one of those policies that is a really good idea 99.5% of the time but for those last 0.5% of use cases, it's a major pain in the bum. [0] WeeChat has a /exec command to execute arbitrary commands, and the client has access to that --- not great when you transmit your password in plain text.

Xcelerate 9y ago

> If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? Because a crap ton of Linux software comes with its own set of bundled root CAs instead of using the system defaults. Welcome to the configuration nightmare that is setting up Anaconda, npm, AWS CLI, Python (Requests library), Git, etc. for working with something like Zscaler.

tgragnato 9y ago
Zscaler performs TLS interception in order to analyse the traffic and “protect the users”. [https://support.zscaler.com/hc/en-us/articles/205059995-How-does-Zscaler-protect-SSL-traffic- https://support.zscaler.com/hc/en-us/articles/205059995-How-...] The issue is that Zscaler may have flaws, and that even if the validation is performed flawlessly then the introduced risk is not zero… Usually one would have to trust the root CAs, but with TLS interception we have to trust the trust of the MiTM software in the root CAs. This increases the attack surface instead of decreasing it. For a security appliance it’s a pretty bad job; sure, there may be reasons why you want to look into traffic, but then the aim is to control the communication. And control doesn’t come for free.

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

syrrim 9y ago

>If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? If you control physical hardware, and you control all the users on it (as a corporate network), then you can know that nothing is amiss. >And how would you feel if people on the same LAN could see and modify all your interactions with those services? The fact that they physically can doesn't mean they will. For 2 & 3: https has two modes: self signed, and certified. Certified requires that you have a public facing domain name, such as "news.ycombinator.com". Devices on private networks can't have public domain names. Consumer devices on public networks could have domain names, but this would be very difficult to configure. Without a domain name, https must be done as self signed. With self signed, when you first interact with the server, it could be anyone. Self signed https only gives you the guarantee that any further interaction besides this first one are with the same server as the first one. It should be clear that you can still be MITMed under this mode, so long as the attacker can intersect the first message you send after a reboot. If you're scared of network ninjas sneaking into your house in the middle of the night and intersecting your packets, self signed https is no better than http.

wang_li 9y ago
>With self signed, when you first interact with the server, it could be anyone. Self signed https only gives you the guarantee that any further interaction besides this first one are with the same server as the first one. If I create a CA and install that CA's public key in my browser, then use that CA to sign the cert for a device on my network, why exactly will it "be anyone"? Unrelated, but this push for HTTPS for everything isn't without downsides. Many apps gather extensive data when running on my devices and they communicate that data back to some central location, sometimes under the guise of functionality, sometimes straight up nefariously, but always with a side effect of giving that central entity a complete record of what I'm doing and often also exfiltrates my data (contacts, etc.) Honestly, I've been tempted to set up a transparent TLS terminating proxy at my home to give myself some possibility of seeing wtf is coming and going from my network.
- Vendan 9y ago