4 ms·

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 i

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.

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.