
Sennheiser discloses monumental blunder that cripples HTTPS on PCs and Macs - vinnyglennon
https://arstechnica.com/information-technology/2018/11/sennheiser-discloses-monumental-blunder-that-cripples-https-on-pcs-and-macs/
======
xg15
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
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
> _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
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?

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

------
tinus_hn
This is a duplicate of

[https://news.ycombinator.com/item?id=18550760](https://news.ycombinator.com/item?id=18550760)

