Key compromise and root cert with exposed key in German lawyer software (beA) | Hacker News Reader

Key compromise and root cert with exposed key in German lawyer software (beA)

groups.google.com

Importing the self-signed certificate itself into the root certificate store is actually an okay solution for this, assuming it's done properly (no CA bit set).

(obviously, that's not what they did)

No, not if you still use a shared key.

Had the same story 3 days ago on the front page for a different software: https://news.ycombinator.com/item?id=15982161

Actually the battle.net story has been distorted quite a bit. What they do now is more or less the right thing: They create new keys for every system.

The problem was what they did before: They had a publicly trusted cert for their local webserver.

Right, but there's no need to share the keys.

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.

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:

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.

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.

They also asked users to import it into the Mozilla store, which (for mostly historically reasons) is separate. Feels like Mozilla should be revoking that specifically.

Ultimately, I have no idea what they are even trying to achieve here. If this is all localhost communication, HTTPS isn't doing anything.

Probably they're trying to avoid "not secure" warnings from browser which are displayed if http-served web page contains password input fields (Chrome 56+, since October 2017).

These don't appear for localhost, though.

It’s not localhost as domain, it’s a real registered domain that points to the loopback address.

It should still not show the warning then, right? Because you're still talking to localhost, and that is ultimately what matters.

And what is the motivation behind having a domain you need internet for to resolve to point towards localhost to use with a certificate only localhost is meant to have? This is all sorts of effed up.

I'm guessing it's so the end-users can just say "go to www.[bla].de", similar to going to gmail.com...

"be a localhost .de"

Why cant they just use a HOSTS file entry? What is the need for DNS?

If there is no need for DNS then why use the public, commercial CA system? That system relies on domainname registration credentials as "authentication".

Not sure I understand the design of this software. What is the purpose of the web server?

No, "besonderes elektronisches Anwaltspostfach localhost .de".

The web server is because it's a locally hosted web app. The DNS name is so a certificate authority will issue them a certificate.

The whole thing is probably written as a web app, that's why they need a web server. It probably uses React and runs on node.js... "we need HTTPS, the easiest thing to do is be a root certificate", thought the JavaScript Full-Stack developer...

the whole thing is basically a webmail service, but the client provides crypto-functions to encrypt and decrypt messages locally using a smart card reader. The client software has an API which is provided as a webservice on localhost:9998 (FQDN: bealocalhost.de). At first they ran this service with a certificate that was signed by a trusted CA. I reported them for disclosing the private key of that cert. Communication between the client (java-application) and the webmail service (website) is done via javascript in the browser, which connects to services on localhost using websockets.

Why is a server on localhost using HTTPS instead of HTTP? Oh, I know, because "no one should be using unencrypted HTTP in 2017". This is the fruit the SSL security theater mania has borne.

Reply on news.ycombinator.com