Cryptography & Security Newsletter

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.

CloudFlare and Facebook propose to delay SHA1 deprecation

It seemed that the fate of SHA1 certificate signatures had been decided, but it appears that this old and insecure signature algorithm is not going away quietly. On the one hand, major browser vendors had announced plans to deprecate the support for certificates using this algorithm, and the CA/Browser forum had decreed that SHA1 must not be used for certificate signatures past 2015. On the other hand, some large companies are complaining that giving up on SHA1 might mean loss of access for many users.

In December, CloudFlare and Facebook voiced their concerns. They still observe a significant number of connections from devices that are not capable of using the stronger SHA256 algorithm. These connections—up to 6% in some cases—come mostly from developing countries.

These companies currently deploy both SHA1 and SHA256 in parallel, serving SHA1 certificates to clients that don’t support anything better. They believe that they can reliably detect such cases and that the detection mechanism can’t be exploited. To continue to use this dual deployment mechanism, Facebook and CloudFlare proposed a new mechanism for certificate validation called Legacy Validation, which would allow companies to continue to use SHA1 certificates in the future provided they can guarantee that they will only use it with old browsers. (Besides, up-to-date browsers will simply stop accepting SHA1, meaning such certificates, even if issued past 2015, just won’t work in them any more.)

It is not entirely clear which devices are responsible for the significant number of devices that don’t support SHA256. One known reason are Windows XP computers without Service Pack 3. For those machines updating them with this Service Pack can solve the issue. Of course that won’t close other security issues in Windows XP that were never fixed due to its end of life. Alternative browsers like Firefox are also an option for users of those old systems.

CloudFlare’s blog post mentions old Android devices before version 2.3 as a reason, but it seems that Android has better support for SHA256 than previously believed. Even the older Android 2 versions are already capable of supporting SHA256 certificates. Facebook highlights Symbian devices as a major reason they see connection failures with SHA256 certificates.

The proposal has now been submitted to CA/Browser forum for discussion.

Juniper VPN backdoors discovered

On December 17, Juniper disclosed existence of unauthorized code in some of their products. This code could have been used by "knowledgeable attackers" to gain administrative access and decrypt VPN connections. Although we don't know the full details yet, it appears that there were at least two backdoors; one with a special SSH password and another focused on traffic decryption using a modified Dual EC DRBG.

Does Kazakhstan plan a man-in-the-middle attack on its citizens?

In November, Kazakhtelecom issued a press release to announce that its customers will have to install a national security certificate starting in January 2016. The text indicated that this would be needed to allow traffic analysis on encrypted HTTPS connections.

A few days after that the press release was removed from the web page, but it can still be read through the Internet Archive. It is currently not clear if that means that the plans for the national security certificate have been cancelled.

Kazakhtelecom is a major Kazakhstan ISP. Requiring users to install a certificate that allows traffic analysis would be a unique and very drastic move. It could potentially endanger the security of all Internet users in the country if the certificate’s key gets leaked or abused by the people in charge.

The concept of installing a root certificate into a browser to allow traffic analysis is not new, although it’s controversial. Many security products use this technique to intercept and analyze traffic, especially in Enterprise environments. But these products are usually only used in private networks of companies. Other products that use similar TLS interception techniques have caused major security issues in the past, the most prominent example is the software Superfish that was found preinstalled on Lenovo laptops earlier this year.

Certificate search engine Censys

Researchers from the University of Michigan created a search engine for certificates called Censys. In the past years these researchers had used Internet-wide scans to collect information about certificates and TLS configurations, publishing a lot of their raw data via the scans.io web site. Now, their extensive collection of certificates is searchable through Censys. A background paper on the search engine was published at the CCS conference.

Let’s Encrypt public beta starts

The certificate authority Let’s Encrypt opened its service to the general public on December 3rd. Let’s Encrypt aims to make it both easier and cheaper for server operators to get valid TLS certificates.

Let’s Encrypt implements a new protocol to issue certificates called ACME. A lot of people were unhappy with the official Let’s Encrypt client software, because its code is quite complicated and requires a large number of dependencies. But there are already alternative implementations of the ACME protocol for users looking for a more lightweight solutions like acme-tiny (Python).

A few days after the launch a smaller incident happened. Let’s Encrypt had issued six certificates for domains that were using a technology called Certificate Authority Authorization (CAA) to forbid that. The concept of CAA is that domain operators can restrict the certification authorities they want to use by publishing them via a DNS record. The CAA check of Let’s Encrypt was not working properly and thus it was possible to get certificates despite the CAA record disallowing it. The issue was fixed a few hours after it had been reported.

OpenSSL security update and bugs in Bignum libraries

OpenSSL fixed several security bugs with the release of the versions 1.0.2e, 1.1.0q, 1.0.0t and 0.9.8zh. One of the fixed bugs is a bug I discovered in the BN_mod_exp() function, which is part of OpenSSL’s Bignum implementation. In some corner cases the function will produce wrong results. The bug was found with the help of the fuzzing tool american fuzzy lop. A similar bug was found earlier this year in the squaring function BN_sqr in OpenSSL.

OpenSSL announced that these were the last updates for the old 1.0.0 and 0.9.8 versions. Future security fixes won’t be backported to these old versions; everyone should upgrade to one of the newer version trees.

New SSL Labs version 1.21.13 with HTTP/2 simulation and validation

Now that HTTP/2 is gaining in popularity, we’re starting to see configuration issues coming from the fact that HTTP/2 generally doesn’t allow the use of legacy ciphers even if they’re not outright insecure. In version 1.21.13, SSL Labs improved its handshake simulation to detect HTTP/2 negotiation and warn if the selected protocols and cipher suites are not appropriate. If this is something you care about, I recommend that you use the development server, which correctly simulates both NPN and ALPN negotiation. (NPN is a legacy negotiation mechanism that is being phased out. ALPN is the official way to negotiate HTTP/2.)

Short News

• Researchers from the Ruhr University Bochum have published a paper with potential attacks on the QUIC and TLS 1.3 protocol using the Bleichenbacher vulnerability. The Bleichenbacher vulnerability affects only RSA encryption, which has been deprecated in both TLS 1.3 and QUIC, but if a server provides backwards compatibility to older TLS versions that use a vulnerable RSA encryption implementation, then a cross-protocol attack can be mounted.
• Developers from Ubuntu have noted that the GnuTLS version used in Ubuntu LTS (long term support) was shown to be vulnerable to the POODLE TLS attack. I analyzed this issue and found out that older versions of GnuTLS didn’t check the first padding byte in CBC encryption modes.
• Microsoft issued a security advisory in which they state that a private key for a certificate for *.xboxlive.com was inadvertently leaked. An update for all supported Windows versions will block the certificate.
• A company called CryptoPeak has sued several companies for the supposed use of technologies covered by a patent owned by them. According to the legal papers the company sees the use of elliptic curve cryptography in TLS as violation of their patent. However the patent doesn’t even mention elliptic curves.
• Replay attacks can be a problem for HTTPS. Thai Duong, Thiago Valverde and Quan Nguyen from the Google Security Team published a potential vulnerability affecting web applications. Browsers will resend HTTPS requests if they don’t get an answer from a server. An attacker can use this to cause a browser to send a request multiple times, thus possibly causing an action in a server application to be executed more than once.
• OpenSSL released the first alpha of its upcoming version 1.1.0. The most significant change is the support for the ChaCha20/Poly1305 cipher suite. Other notable changes include support for the extended master secret, which was developed as a response to the Triple Handshake attack and the OCB encryption block mode. Some deprecated features, among them SSLv2, were removed.
• Chrome developer Ryan Sleevi announced the removal of an old root certificate from Symantec from the Chrome browser. The certificate had already been removed from other browsers for being too weak (only 1024 bits). The removal caused some unexpected problems, because under Windows and OS X the certificate management might use the now blocked Symantec certificate to build alternative certificate chains. Therefore the removal of the cert was temporarily reverted.
• In light of the Dell certificate issue that we covered in the last Newsletter I was informed that certain drivers for CSR Harmony bluetooth chips that are used in some Lenovo laptops also ship with a preinstalled root certificate. But unlike in the Dell case these don’t ship with the private key included. It turned out that these certificates were used during the development of the driver and were not supposed to be shipped in the driver release.
• LibreSSL released versions 2.2.5 and 2.1.9. These fix two security vulnerabilities that also affected OpenSSL.
• Andrew Ayer posted details on an attack on an earlier version of the ACME protocol used by Let’s Encrypt. The attack relies on a misunderstanding of RSA signatures. An RSA signature is not necessarily bound to a specific key, so it is possible for an attacker to construct a new key for an existing signature.
• Google wants to increase the number of HTTPS URLs in its search engine index. In cases where both HTTP and HTTPS web pages are available and serve the same content, Google will under certain conditions use the HTTPS URL even when existing links point to HTTP.
• The Chrome browser has a new Security Panel in its DevTools. This can help debug certificate and mixed content warnings.
• The PCI Security Standards Council, responsible for setting standards for credit card payment systems, has published an update on its requirements for future support and deprecation of SSL and TLS versions. In June 2018 all compliant systems must move away from all classic SSL (v2 and v3) and TLS 1.0 versions. By June 2016 TLS 1.1 must be offered.