4 ms·

Sennheiser discloses monumental blunder that cripples HTTPS on PCs and Macs

17 points by vinnyglennon 8y ago

xg15 8y ago
I feel articles like this frequently don't mention that the reason why so many companies make this kind of mistake is because there is still no safe way to have a HTTPS website directly communicate with a local device. The best thing you can do is to generate a new root CA cert on every install with a randomized private key - however, even then, you will have to solve shipping this generated cert to the device you want to talk with...
- Crosseye_Jack 8y ago
  If you read the article to the bitter end it states > That’s because it installed a server certificate for the computer’s localhost, i.e. 127.0.0.1. Not only is it a violation of CA/Browser Forum: Baseline Requirements to issue certificates for non-routable IP addresses, it’s not at all clear that Sennheiser has complied with the same processes that certificate authorities are required to follow in securing their root keys. Which highlights a few things. A) the article expects anyone creating private CA’s to follow the Baseline Requirements for public CA but those requirements are the reason you can’t use public CA’s in the first place. B) what does it matter if the cert was signed for localhost instead of localhost.company.tld? The issue is that you have a CA installed and I have the private key for it. I can mint certs for localhost.company.ltd all day long and if I’m in a position to mitm I could also interfere with the dns for localhost.company.com anyway. Anyways enough picking on the article over small details (I won’t even start about the key handling issue), but it does highlight that the cert was for localhost, so delivery of the certs to the websocket server wouldn’t be too much of an issue in this case.
  - xg15 8y ago
    > Which highlights a few things... Yeah, that sounds a lot like the author misunderstood what actually happened and why it was bad. > the article expects anyone creating private CA’s to follow the Baseline Requirements for public CA but those requirements are the reason you can’t use public CA’s in the first place. Not that it matters much, but I believe you can fulfill that requirement by using the "localhost.company.tld" trick - it's just another unnecessary hoop to jump through. Of course the requirement "don't tell everyone and their grandma about your private key" is a bit harder to keep... > but it does highlight that the cert was for localhost, so delivery of the certs to the websocket server wouldn’t be too much of an issue in this case. Ah, true. Because the article was about headphones, I was imagining some kind of rube-goldberg setup where the headphones themselves pretended to be a USB network interface and terminated the websocket connection. But upon reading again, the connection is for the setup/utility program, not the actual hardware.
- olliej 8y ago
  Uhh there are plenty of ways. Those pretty peering graphics new devices have are used to establish trust (sharing per device certificates or encryption keys). You can also establish over Bluetooth or audio - you just need a small side channel to create the initial trust.
  - xg15 8y ago
    Interesting. Do you have more info about that? I heard about web bluetooth, but thought it was still being specified. What peering graphics do you mean?
    - olliej 8y ago
      You know the patterns you use to peer more or less all IoT devices that have a screen? Or smart watches, etc. Alternatively you could use a code printed on the device, and drive a secret from that. The important thing is that you have to use a non-network side channel first. In this case I assume they’re doing something like an electron app and so their “app” has to communicate of http of some kind, so it already should have app level privileges. If nothing else: if your set up app can install a root certificate then your setup app can do something better than installing a root cert.
      - xg15 8y ago
        Maybe I misunderstand you, but those patterns would always be indirect, would they? Either a device is fully cloud-based, in which case setup consists of giving it the WiFi settings and connecting it to some account - or they communicate locally via e.g. Bluetooth, however then they need some privileged app/helper process to communicate with. But to my knowledge, it's not possible to have it communicate directly with the browser without going through intentionally-scary-and-confusing setup screens or opening security vulnerabilities.
        olliej 8y ago
        Yes, they have to be indirect, that’s the point. If it’s purely cloud based then you’re communicating with the hosts cloud services which can be wrapped in a standard cert and tls connection. In this case they were installing a local server - so you wouldn’t get https issues unless you were also spoofing a domain. In which case it’s correct for you to get warnings (imagine if they inserted your-bank.com -> their localhost server. If you have an app or installer, which they clearly did, then you have other options: * directly insert a leaf certificate (not a root cert) into the platform key store * don’t try to hide that you’re running a local host server. * use an app (this is an option) If I were doing this and couldn’t use Bluetooth, visuals, or sound to make the side channel, I would have the setup program install a leaf certificate derived from something the user can copy from the hardware - serial number or whatever. Or you can have the cloud host provision a leaf cert itself.
rlpb 8y ago
This perfectly demonstrates the risk of giving arbitrary third party vendors "root" on your devices.
tinus_hn 8y ago
This is a duplicate of https://news.ycombinator.com/item?id=18550760 https://news.ycombinator.com/item?id=18550760
olliej 8y ago
The dumbest thing here is that localhost is considered a secure connection so they shouldn’t even have needed tls - does anyone know why they felt it was necessary? Are websockets not correctly treating localhost as a secure connection?

17 points by vinnyglennon 8y ago

xg15 8y ago

I feel articles like this frequently don't mention that the reason why so many companies make this kind of mistake is because there is still no safe way to have a HTTPS website directly communicate with a local device. The best thing you can do is to generate a new root CA cert on every install with a randomized private key - however, even then, you will have to solve shipping this generated cert to the device you want to talk with...

Crosseye_Jack 8y ago
If you read the article to the bitter end it states > That’s because it installed a server certificate for the computer’s localhost, i.e. 127.0.0.1. Not only is it a violation of CA/Browser Forum: Baseline Requirements to issue certificates for non-routable IP addresses, it’s not at all clear that Sennheiser has complied with the same processes that certificate authorities are required to follow in securing their root keys. Which highlights a few things. A) the article expects anyone creating private CA’s to follow the Baseline Requirements for public CA but those requirements are the reason you can’t use public CA’s in the first place. B) what does it matter if the cert was signed for localhost instead of localhost.company.tld? The issue is that you have a CA installed and I have the private key for it. I can mint certs for localhost.company.ltd all day long and if I’m in a position to mitm I could also interfere with the dns for localhost.company.com anyway. Anyways enough picking on the article over small details (I won’t even start about the key handling issue), but it does highlight that the cert was for localhost, so delivery of the certs to the websocket server wouldn’t be too much of an issue in this case.
- xg15 8y ago
  > Which highlights a few things... Yeah, that sounds a lot like the author misunderstood what actually happened and why it was bad. > the article expects anyone creating private CA’s to follow the Baseline Requirements for public CA but those requirements are the reason you can’t use public CA’s in the first place. Not that it matters much, but I believe you can fulfill that requirement by using the "localhost.company.tld" trick - it's just another unnecessary hoop to jump through. Of course the requirement "don't tell everyone and their grandma about your private key" is a bit harder to keep... > but it does highlight that the cert was for localhost, so delivery of the certs to the websocket server wouldn’t be too much of an issue in this case. Ah, true. Because the article was about headphones, I was imagining some kind of rube-goldberg setup where the headphones themselves pretended to be a USB network interface and terminated the websocket connection. But upon reading again, the connection is for the setup/utility program, not the actual hardware.
olliej 8y ago
Uhh there are plenty of ways. Those pretty peering graphics new devices have are used to establish trust (sharing per device certificates or encryption keys). You can also establish over Bluetooth or audio - you just need a small side channel to create the initial trust.
- xg15 8y ago
  Interesting. Do you have more info about that? I heard about web bluetooth, but thought it was still being specified. What peering graphics do you mean?
  - olliej 8y ago
    You know the patterns you use to peer more or less all IoT devices that have a screen? Or smart watches, etc. Alternatively you could use a code printed on the device, and drive a secret from that. The important thing is that you have to use a non-network side channel first. In this case I assume they’re doing something like an electron app and so their “app” has to communicate of http of some kind, so it already should have app level privileges. If nothing else: if your set up app can install a root certificate then your setup app can do something better than installing a root cert.
    - xg15 8y ago
      Maybe I misunderstand you, but those patterns would always be indirect, would they? Either a device is fully cloud-based, in which case setup consists of giving it the WiFi settings and connecting it to some account - or they communicate locally via e.g. Bluetooth, however then they need some privileged app/helper process to communicate with. But to my knowledge, it's not possible to have it communicate directly with the browser without going through intentionally-scary-and-confusing setup screens or opening security vulnerabilities.
      - olliej 8y ago
        Yes, they have to be indirect, that’s the point. If it’s purely cloud based then you’re communicating with the hosts cloud services which can be wrapped in a standard cert and tls connection. In this case they were installing a local server - so you wouldn’t get https issues unless you were also spoofing a domain. In which case it’s correct for you to get warnings (imagine if they inserted your-bank.com -> their localhost server. If you have an app or installer, which they clearly did, then you have other options: * directly insert a leaf certificate (not a root cert) into the platform key store * don’t try to hide that you’re running a local host server. * use an app (this is an option) If I were doing this and couldn’t use Bluetooth, visuals, or sound to make the side channel, I would have the setup program install a leaf certificate derived from something the user can copy from the hardware - serial number or whatever. Or you can have the cloud host provision a leaf cert itself.

rlpb 8y ago

This perfectly demonstrates the risk of giving arbitrary third party vendors "root" on your devices.

tinus_hn 8y ago

This is a duplicate of https://news.ycombinator.com/item?id=18550760 https://news.ycombinator.com/item?id=18550760

olliej 8y ago

The dumbest thing here is that localhost is considered a secure connection so they shouldn’t even have needed tls - does anyone know why they felt it was necessary? Are websockets not correctly treating localhost as a secure connection?