3 ms·
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
by 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 agoI 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.