30 November 2015
Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Hanno Böck.
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.
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.
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.
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.
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.
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.
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.
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.
This subscription is just for the newsletter; we won't send you anything else.
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.