Bulletproof TLS Newsletter #9
eDellRoot certificate endangers users of Dell computers
30 November 2015
This issue was distributed to 21,114 email subscribers.

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.

This month, it gives us great pleasure to welcome Hanno Böck to our team. Hanno is joining us as the principal author of this and future editions of Bulletproof TLS Newsletter. With his help we expect to deliver to you fresh news every month as well as provide a much better coverage.

In this issue:

  1. eDellRoot certificate endangers users of Dell computers
  2. Certificate Transparency uncovers illegitimate certificates from Symantec
  3. Research on email TLS security
  4. Chrome developers consider deprecating Diffie-Hellman
  5. NPN deprecation makes HTTP/2 deployment harder
  6. Firefox warning on insecure forms
  7. Post-quantum cryptography
  8. Shared private keys on many embedded devices
  9. Other news

eDellRoot certificate endangers users of Dell computers

Some computers from Dell come with preinstalled root certificates called eDellRoot or DSDTestProvider and corresponding private keys. This opens up a severe security vulnerability. Attackers can use this key to sign certificates for arbitrary hosts that will be accepted by the affected computers for HTTPS connections.

The private keys for both certificates have been published online. I had been aware of this issue before it received public attention and had contacted Dell weeks before the incident became public. I never received a reply from Dell. An online check allows users to test whether they are vulnerable. Dell has now issued a statement with instructions on how to remove the certificate and has also published a removal tool.

The incident is in very similar to the Superfish and Komodia incidents that were discovered earlier this year.

Certificate Transparency uncovers illegitimate certificates from Symantec

In September Google reported finding evidence that Symantec had erroneously issued certificates for google.com and other domains. It turned out that these certificates had been issued by Symantec employees for tests. Google found these certificates through the logs of the Certificate Transparency system.

In response to the incident, Symantec announced on its official blog that the employees responsible for the certificate issuance were dismissed. Symantec also published a report of the incident.

About a month later Google announced that this report from Symantec was incomplete. In the first version of the report Symantec had identified 23 certificates that were issued in error. However Google's own engineers quickly found more erroneous certificates in the Certificate Transparency logs. Many of them had been issued for unregistered domains, which is clearly forbidden according to the CA/Browser Forum's Baseline Requirements. In the end it turned out that Symantec had issued more than 2,000 erroneous certificates.

Google now demands that Symantec publishes an analysis of why they were unable to detect the scale of the incident at first. They also expect a third-party security audit of Symantec's certificate issuing process and an implementation of the Certificate Transparency system for all future Symantec certificates starting June 1st 2016.

Shortly after that incident Comodo engineer Rob Stradling wrote to the CA/Browser Forum's mailing list saying that Comodo checked their own systems for certificates issued for invalid domains, including internal domain names and IP addresses. Comodo identified eight such certificates issued by themselves. Stradling also wrote that they found similar certificates issued by other certificate authorities.

Research on email TLS security

Researchers are increasingly looking at security of TLS in the email protocols SMTP, POP3 and IMAP. Three research papers have been published lately on that topic.

A team from the University of Michigan and Google found widespread evidence for STARTTLS stripping in SMTP. This stems from the fact that almost all SMTP connections use STARTTLS only in an opportunistic way. While many servers enable encryption via STARTTLS, they almost never require encryption, because that would stop many emails from being delivered. Many servers use self signed certificates.

Researchers from SBA Research performed an Internet-wide scan on the IPv4 space and looked for the TLS settings used. The data was published on scans.io. Similar scans had been done before for HTTPS, but this is the first time such an extensive scan has been done on email protocols. The work of SBA Research highlights the fact that many email servers use weak or outdated encryption. Aaron Zauner presented the important points of the research at the Hack.lu conference.

A similar Internet-wide scan was performed by researchers from Data61 Sydney, ICSI Berkeley and the Technical University of Munich. Their data also includes IRC and XMPP/Jabber connections.

Chrome developers consider deprecating Diffie-Hellman

In an email sent to Google's Security-dev group, Google developer David Benjamin announced plans to deprecate the classic Diffie-Hellman key exchange in Chrome. As a first step, it is planned to offer DHE-based cipher suites only as a fallback if the first handshake fails.

In response to the Logjam research paper, Chrome raised the minimum group size for Diffie-Hellman to 1,024 bit. That already led to several complains from users with legacy devices using weak key exchanges. However, even 1,024 bit is not considered very secure these days. But increasing the minimum size further is hardly feasible. According to Benjamin, 95% of the connections using Diffie-Hellman use a 1,024 bit group.

Diffie-Hellman connections are rare anyway. According to Benjamin, only 2% of Chrome's connections use the classic algorithm. Most major websites use Elliptic Curve Diffie-Hellman exchange. If classic Diffie-Hellman gets deprecated, users will likely still be able to connect to most websites not supporting elliptic curves using RSA handshakes. However, this will mean they will lose forward secrecy.

NPN deprecation makes HTTP/2 deployment harder

The latest version of Chrome deprecates the use of the NPN protocol to negotiate HTTP/2. NPN (Next Protocol Negotiation) was used to allow server and client to upgrade a transport layer protocol to a higher version over the TLS layer. It is now superseded by ALPN.

In a post on his personal blog, Matthias Geniar points out that due to this change many servers will lose the ability to negotiate an HTTP/2 connection with the new Chrome version. OpenSSL supports ALPN, but only since version 1.0.2. Many Linux distributions, among them the stable versions of Debian and Red Hat, rely on the older OpenSSL version 1.0.1 that only supports NPN.

In response to this, Chrome developers have reverted the change and delayed the NPN deprecation.

Firefox warning on insecure forms

There is a number of websites that use an encrypted HTTPS connection for user logins, however the site delivering the form itself is served over unencrypted HTTP. This is vulnerable to an attack called SSL Stripping: an active attacker can simply modify the form and thus either redirect the login directly to a server he controls, or just remove the encryption from the login. The term SSL Stripping was coined by Moxie Marlinspike in a talk back in 2009.

Mozilla developers plan a change in Firefox 44 that will display a warning symbol on web pages using such problematic forms. If an HTTP web page includes a form with an HTTPS target, the warning symbol will appear in the URL bar. Firefox 44 will be released in January 2016.

Post-quantum cryptography

An announcement by the NSA has accelerated the discussion on post-quantum cryptography. In the past the NSA has suggested the use of the so-called Suite B algorithms that are based on elliptic curves. In the new announcement the NSA suggests that users who haven't switched to Suite B algorithms yet should delay that switch and prepare for an upcoming change to quantum-resistant algorithms. A paper by Neal Koblitz and a blog post by Matthew Green give an overview of the discussion spurred by the NSA announcement.

Meanwhile the EU-supported research project PQCRYPTO has recently published a first set of recommendations for algorithms that provide security against quantum computer attacks. Another research team published a background paper and source code for a faster variant of the supposedly quantum resistant Ring Learning With Errors-Algorithm.

Shared private keys on many embedded devices

A research project by the company SEC Consult looked for private keys in firmware images of embedded devices. The researchers found 580 different keys belonging to a large number of devices, including DSL routers, VoIP phones and Cameras. Around 50 vendors are affected, among them most of the large manufacturers of home routers.

By correlating these findings with data from Internet-wide scans they found out that 9% of all HTTPS hosts and 6% of all SSH hosts on public IPv4 addresses used one of these keys. Encrypted connections to these devices can thus be intercepted by attackers. SEC Consult plans to publish the private keys they found. Cert/CC has published an advisory.

Other news