Filippo Valsorda wrote an article “How Plex is doing https for all its users” two years ago. In the article, Filippo explains how the self-hosted media server Plex can offer TLS to secure all connections, including those to the user’s servers.
Plex is a server software running on your machine, and a discovery service somewhere out on the internet. Using your login, you connect to the discovery service, and then connects directly to your server, using XHR.
The XHR part means you are on a page https://plex.tv/web.app, and because that is a https page, the XHRs also need to be encrypted and trusted. That means your server needs to be able to do https, and that means your server needs to have a valid certificate to do this.
How does your server get this cert?
To get a certificate, you first need a domain name. You get that via a wildcard DNS record under plex.direct, and a bit of DNS server fairy dust. So anything.plex.direct resolves, and in fact someip.somehash.plex.direct resolved to someip.
To get a certificate for that name, they got a wildcard cert for each hash. So when you set up a box, the wildcard cert for the hash will be generated. So each user (hash) gets their own certificate and key pair, and can then be connected with a valid TLS connection. The private key is handed to that server, which is safe, because it’s unique for that somehash.plex.direct. So each server can be identified by knowing the private key for that certificate, no matter what the actual IP is, and the XHR requirements are satisfied, too.
Now, let’s have a look at the beA: The “Besonderes elektronisches Anwaltspostfach” is a special electronic mailbox for attorneys. It’s purpose is to deliver secure electronic communication between attorneys and other institutions of the law in Germany.
For some reason, DE-MAIL, which has been purposefully built to deliver secure electronic communication between everyone else has not been used and DE-MAIL technology has not been repurposed in a second, closed instance for law firms. Instead something has been built from scratch.
Also, it’s a bit unclear how that works with international communication in case non-german entities are involved.
The beA is a webmail client, so your browser talks to an external website. To authenticate, the clients needs to process data from a chipcard. A browser cannot do that, only a local operating client can do that. So a local server is installed.
For that local server, a DNS record has been set up.
;; ANSWER SECTION: bealocalhost.de. 3202 IN A 127.0.0.1
A certificate for bealocalhost.de has been issued by T-Systems. The server has been shipped to everybody, including the private and public key of the bealocalhost.de certificate.
beA issued a new cert in response to this, but of course due to the architecture, had to ship the private key to everybody, again. Also, all clients and servers are still using the same keypair, and can hence not really be distinguished. beA is now offline over the holidays, “for maintenance”.
Of the 165.000 users that are required to use beA starting 1.1.2018, only 71.500 have created an account so far. The rest can’t because beA is now offline for maintenance (and actually requires a re-architecture similar to what Plex did).
Meanwhile, Blizzard is trying to solve the same problem, with a solution that is yet again broken, but subtly differently: They are trying to install a self-signed cert, requiring root access, in order to be able to access localbattle.net.
;; ANSWER SECTION: localbattle.net. 21599 IN A 127.0.0.1
in order to enable web-to-app communication using, you guessed it, XHR.
The root cause for the localhost server, which makes the local cert necessary, seems to be access to a card reader, an USB device. That driver is actually not necessary, because a way to access local USB devices from the web exists in modern browsers.
According to further research, the installed software is also not codesigned. The JAR is 1024-bit DSA signed, the cert is expired in 2014, the cryptostandard used expired around the same time and is considered insecure.
Apparently, the beA mailsystem cannot deliver to law firms, only to natural persons. If that person is on vacation or out sick, the mail cannot be opened. The workaround is to share signature cards and PIN codes, which completely compromises the 2FA system that these cards are part of.
Finally, obviously there is no technical system and no process to refresh certificates anywhere. That is funny, because the original cert issued by T-System was of course time-limited and would have expired at some point in time in the not too far future.
This article has been written with input from Maik Zumstrull. If I have butchered some of his explanations, that’s entirely my fault, though.