3 ms·

Is this really a common practice? Why ask users to import the certificate into the root certificate store instead of packaging the self-signed certificate with

by avita1 9y ago

Is this really a common practice? Why ask users to import the certificate into the root certificate store instead of packaging the self-signed certificate with and specially loading it from the application. That seems easier from the users' perspective and more secure as you aren't touching the global certificate store.

Xylakant 9y ago
The application in question is afaik a browser. As far as I ‘be been following this disaster, the client spins up a local webserver which then is accessed with your systems browser. So they have to use the cert store that the browser uses - which is the system store for some of them. The problem in this case is not the cert in itself, the local webserver needs the private key. It also uses a non-local domain (bealocalhost.de or something akin to that) which resolved to 127.0.0.1. This is another design brainfart - it assumes that no webserver is running locally, the DNS is in no way protected, making it trivial for anyone who controls DNS to reroute that domain and since they have access to the key, MiTM is trivial. :sigh:
- theossuary 9y ago
  I disagree that using a non-local domain is a bad idea. As long as each client generates it's own key and certificate for the local webserver then a MitM isn't possible, even if they take over DNS. Using non-local DNS makes setting up DNS so much easier; and if they took over your DNS you already got some pretty serious problems. The real problem is they embedded and distributed secrets, instead of generating them. It's funny a game company can do security better than a software firm working for a government. It's sad that I'm not surprised. I'd bet money that people developing this software knew this was a problem, but government regulation required they use an external CA instead of a self-signed cert because "self-signed certs are always less secure", and nobody was empowered to make this issue known or do something better.
Spooky23 9y ago
It’s become a common practice due to the changes in how browsers handle local, expired or self signed certificates. The “right” answers (use public CA, setup a local PKI) are complex and deliver low value. PKI is complex, and certificate expiry is a major source of outages.

by avita1 9y ago

Xylakant 9y ago

The application in question is afaik a browser. As far as I ‘be been following this disaster, the client spins up a local webserver which then is accessed with your systems browser. So they have to use the cert store that the browser uses - which is the system store for some of them. The problem in this case is not the cert in itself, the local webserver needs the private key. It also uses a non-local domain (bealocalhost.de or something akin to that) which resolved to 127.0.0.1. This is another design brainfart - it assumes that no webserver is running locally, the DNS is in no way protected, making it trivial for anyone who controls DNS to reroute that domain and since they have access to the key, MiTM is trivial. :sigh:

theossuary 9y ago
I disagree that using a non-local domain is a bad idea. As long as each client generates it's own key and certificate for the local webserver then a MitM isn't possible, even if they take over DNS. Using non-local DNS makes setting up DNS so much easier; and if they took over your DNS you already got some pretty serious problems. The real problem is they embedded and distributed secrets, instead of generating them. It's funny a game company can do security better than a software firm working for a government. It's sad that I'm not surprised. I'd bet money that people developing this software knew this was a problem, but government regulation required they use an external CA instead of a self-signed cert because "self-signed certs are always less secure", and nobody was empowered to make this issue known or do something better.

Spooky23 9y ago

It’s become a common practice due to the changes in how browsers handle local, expired or self signed certificates. The “right” answers (use public CA, setup a local PKI) are complex and deliver low value. PKI is complex, and certificate expiry is a major source of outages.