Bulletproof TLS Newsletter

Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Received monthly by more than 50,000 subscribers. Written by Hanno Böck.

Various software vendors lately have been found to have shipped private keys for certificates within their software. This problematic practice can lead to security vulnerabilities and will inevitably lead to the revocation of certificates if the key is discovered. The latest examples of these cases include Blizzard’s battle.net, Origin from Electronic Arts, Microsoft Dynamics 365 for Operations, and mandatory communication software for lawyers from Germany called besonderes elektronisches Anwaltspostfach (beA).

A common use case for such certificates arises when software wants to run a local HTTPS server. This often is done to allow communication with a web page and local software.

Blizzard bundles certificate and key for localbattle.net

Tavis Ormandy discovered that Blizzard’s battle.net software embedded a certificate for the localbattle.net domain, signed by GoDaddy. This domain points to the local IP 127.0.0.1. Because the software runs the HTTPS server locally, this automatically means the software must contain the private key. This situation therefore is considered a key compromise. According to the Baseline Requirements, a set of rules for certificate authorities, if a key compromise is reported to a certificate authority, the certificate must be revoked within 24 hours.

In addition to being a key compromise, such certificates also can allow attacks. An attacker in a man-in-the-middle position could change the DNS reply for localbattle.net and thus redirect to an attacker-controlled server. Because the attacker can extract the certificate and private key from the software, he can impersonate that server.

After the certificate was revoked, Blizzard changed battle.net to locally generate a certificate that gets imported into the system’s certificate store.

Because the private keys were randomly generated on each system, this is an acceptable solution if implemented properly. However, in a thread on Reddit many users wrongly interpreted the newly installed root certificate as a security risk.

Later, it was discovered that the Blizzard client had another valid certificate for localbattle.net embedded that was signed by Digicert. In some situations, this certificate was used even after the initial fix. This was another key compromise, so the certificate was revoked again.

Electronic Arts also used a publicly trusted certificate for its Origin software, for the clienttolocalhostonly.com domain. Now that this certificate has been revoked, the software uses HTTP connections instead of HTTPS.

In both cases, the software tried to create a local HTTPS server with a publicly trusted certificate. This is never acceptable. Recently, the W3C agreed to a possible solution: browsers can consider connections to the local IP 127.0.0.1 part of a secure context, even if they’re made via HTTP. This doesn’t create a security issue because connections to the local IP never go over any network. Firefox and Chrome already support this.

HTTPS man-in-the-middle attack against all German lawyers

Independent of these events, Markus Drenger discovered a few days before Christmas that communications software provided by the German Federal Bar (Bundesrechtsanwaltskammer, BRAK) had a very similar problem. Besondere elektronisches Anwaltspostfach (beA), which translates to “special electronic lawyers postbox,” was developed by the company Atos. Its web interface communicated with the bealocalhost.de domain, pointing to 127.0.0.1. TeleSec issued a certificate for that domain.

What made this case particularly interesting is that, in theory, German lawyers must use the beA software starting January 1st; it’s shut down for now, however.

After the certificate was revoked, the German Federal Bar tried to provide a fast solution and created a self-signed root certificate for bealocalhost.de. The lawyers were asked to import this certificate into their local root certificate store.

This made matters much worse. Because this was a root certificate—with the private key being part of the software—it allowed anyone to issue certificates for arbitrary domains. An attacker thus could perform man-in-the-middle attacks against google.com or any other domain—and all German lawyers were asked to install that certificate.

After this problem was uncovered by the author of this newsletter on the German news site Golem.de, the German Federal Bar shut down the system. It’s been offline since then. It’s worth pointing out that the bundled certificate wasn’t the only security problem for beA: the software also has a broken end-to-end encryption, and the server is still vulnerable to the ROBOT attack.

Remote login to Dynamics 365 allowed extraction of private key for wildcard certificate

Microsoft’s Dynamics 365 for Operations presents another slightly different case in which a private key for a publicly trusted certificate was compromised. Software developer Matthias Gliwka discovered that sandbox instances of Dynamics 365 used a wildcard certificate to deliver the web interface. Customers can use the rdesktop protocol to log into their instances, so Gliwka was able to extract the private key.

Over the course of several months, Microsoft ignored Gliwka’s reports. However, after the author of this newsletter learned about this case, both Mozilla and the responsible certificate authority, Digicert, were informed. Thereafter, Microsoft was forced to resolve the issue quickly. The certificate was revoked, and new instances of Dynamics 365 use individually created certificates for each instance.

We reported about similar cases of private keys in applications, affecting Spotify and Cisco, in our June Newsletter.

Short news

• LinkedIn had a problem in which several of their certificates for country subdomains expired — which prompted some people to highlight the importance of automated certificate renewal.
• A blog post explains the use of Let’s Encrypt with Kubernetes.
• Extended Validation (EV) Certificates continue to be the topic of heated debates. Scott Helme wrote a lengthy blog post covering many of the arguments. James Burton was able to get an EV Certificate for "Identity Verified" and Ian Carroll did the same for "Stripe.Inc" by creating companies with those names. On Mozilla’s security policy mailing list, Ryan Sleevi asks: “Has any consideration been given to removing or deprecating EV certificates?”
• We covered the ROBOT attack in a special newsletter. Several TLS implementations were affected by variations of the classic 1998 Bleichenbacher RSA vulnerability. Since that newsletter, we have discovered that two more products are affected: Palo Alto Networks devices and IBM Domino web servers.
• Researchers have published data tracking the deployment of the CAA DNS record. Scott Helme also posted similar data on CAA.
• PhishLabs discusses the fact that more and more phishing pages use HTTPS.
• Cloudflare explains in a blog post how it uses BoringSSL for TLS termination.
• Filippo Valsorda gave a talk at 34C3 about the exploitation of a carry bug in the elliptic curve function for P-256 in Go TLS. We mentioned the bug in our May newsletter.
• Troy Hunt provides a Pluralsight training: “What Every Developer Must Know about HTTPS.”
• A blog post explains how certificates can sometimes be used for cross-site scripting (XSS).
• Researchers from ElevenPaths found various ways to bypass or perform DoS attacks on HSTS (and HPKP) in browsers by overloading the local database.
• The project Internetwache explains how Certificate Transparency can be used as a source for subdomains.
• Troy Hunt blogs about his conversation with NatWest (a UK bank) about its lack of HTTPS.
• A Twitter user observed that Tor exit nodes inject cryptocurrency miner JavaScript into web pages, highlighting another reason we should prefer HTTPS, which guarantees the integrity of transmitted data and avoids such attacks.
• NIST is working on standardizing postquantum cryptography algorithms and has published the first round of submissions. Some algorithms have already been broken; a public archive of the mailing list posts is available.
• In the FreeBSD bug tracker, a discussion has started about the lack of HTTPS on some FreeBSD web services.
• A blog post explains how to back-door the Micali-Schnorr random number generator if you control the parameters. This random number generator is similar to the infamous Dual EC DRBG.
• The German company AVM International has added a feature to FRITZ!Box DSL routers that allows for getting Let’s Encrypt certificates for them. As a side effect, all host names of those routers are now public via Certificate Transparency.
• MatrixSSL has fixed various security vulnerabilities in version 3.9.5.
• During the Black Hat conference, Eric Filiol presented a method to back-door encryption algorithms. The Register cites him making claims that indicate AES may be back-doored as well — which almost nobody else believes. Filiol had previously claimed to have broken AES, but these claims were never confirmed.
• ITIF has published some statistics about TLS on US government web pages.
• Hyperfox is a tool to perform man-in-the-middle attacks on TLS with a local root certificate.
• Lars Klint wrote a tutorial on how to use HSTS and preloading with Cloudflare.
• Cloudflare shared some information about the CPU costs of TLS and cryptography.
• Nadia Heninger, Tanja Lange, and Dan Bernstein gave a talk about lattice-based cryptography at 34C3.
• OpenSSL has fixed a vulnerability in the Montgomery multiplication and another one in the SSL_read/SSL_write functions.
• Nick Sullivan from Cloudflare summarizes the problems with TLS 1.3 and broken middleboxes.
• AlwaysOnSSL is a new free and automated certificate authority. It’s run by CertCenter and Digicert. Another free certificate authority also was announced: API-Crypt. However, no details about the background of the latter CA are yet known. After the browser exclusion of WoSign and StartCom, Let’s Encrypt was the only free certificate authority left. It seems this is changing now and that we’ll have more than one free certificate authority again going forward.
• Researchers have analyzed keys from TLS certificates for certain biases in the key-generation process from various TLS implementations and presented their results at the ACSAC conference in Puerto Rico. This method is an improvement over previous research presented at USENIX 2016 by the same authors. The authors also discovered the ROCA attack with this method.