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.

SWEET32 – Attacks on 64 bit block ciphers

Older block ciphers like Triple-DES and Blowfish encrypt data in blocks of 64 bits. It is well known that the block size limits the amount of data that can be encrypted safely with the same key. After encrypting 2^32 blocks of data with the same key block collisions become very likely due to the birthday paradox.

Karthikeyan Bhargavan and Gaëtan Leurent showed that this weakness can be used to practically attack TLS connections using old cipher modes with Triple-DES and OpenVPN connections using Blowfish. They named their attack SWEET32. Both attack scenarios require several hundred gigabytes of data and take between 20 and 40 hours. These attacks also may be mitigated by factors like limits for Keep-Alive connections in web servers.

In TLS the issue can be completely avoided by disabling Triple-DES-based cipher suites. However Triple-DES is still supported by many servers because it's a compatibility option for old clients. Most notably Windows XP's own TLS implementation and applications using it (like Internet Explorer) support no stronger cipher modes. It remains to be seen whether SWEET32 will cause widespread deprecation of Triple-DES.

HEIST/TIME – Old timing attack gets new attention

At the Black Hat USA conference researchers presented an attack called HEIST. The attack combines compression-based attacks on TLS using the HTTP compression feature with a timing side-channel using Javascript.

However, almost all the pieces of the HEIST attack had been presented previously. The first compression-based attack on TLS was called CRIME, yet it wasn't very practical, as it used the TLS compression functionality that almost no one used anyway. BREACH then used the HTTP compression feature. An attack called TIME, presented at Black Hat EU 2013, provided the extension to Javascript-timing. However, unlike CRIME and BREACH, the TIME attack never got widespread attention. Therefore this attack scenario was forgotten and is now rediscovered. Nick Sullivan has summarized the history of these attacks.

Mitigation of this attack is difficult. The implementation of Same-Site Cookies can prevent compression attacks in some scenarios.

PAC and WPAD leak HTTPS URLs

A very old feature for proxy autoconfiguration can cause security issues for HTTPS connections. PAC and WPAD (Web Proxy Auto-Discovery) allow systems to automatically configure browser proxy settings. WPAD files allow Javascript code that gets executed on each URL request. This can be used to leak URLs via DNS requests. The WPAD specification file can be fetched over various methods, all of them without any protection.

Several researchers have recently independently described these weaknesses in WPAD. There were two talks at the Black Hat conference (1, 2) and one at Def Con one at Def Con.

WPAD was proposed as a draft to the IETF in 1999, but it never became an official RFC. But all major browsers still support it. Some browser vendors were not vulnerable to the attack because they stripped the URL, others have implemented similar protections in response to the recent findings.

Short News

• OpenSSL 1.1.0 has been released. The new version supports ChaCha20, X25519, Certificate Transparency, DANE/TLSA and many other smaller improvements. This release includes a lot of cleanup work that happened in the past years. Crucial parts that had severe bugs in the past, including the state machine, have been rewritten. The API has changed significantly, many structures and functions are now opaque.
• Comodo's domain validation e-mails allowed the injection of HTML code. This enabled an attack that would allow an unauthorized person to issue certificates for other people's domains.
• At Black Hat, Marco Ortisi presented a tool that allows performing an attack on weaknesses in the RSA-CRT-optimization. Faulty calculations in the CRT operation can allow an attacker to calculate a private key. Last year Florian Weimer showed that several devices were vulnerable to this kind of attack.
• TLS 1.3 will deprecate the compression feature of TLS. For some protocols this means they now lack the possibility to compress their data. The NNTP community has reacted to this and a draft for a compression feature in NNTP itself is now being discussed.
• Apple has been lagging behind in terms of modern TLS support for a long time. Up until recently, Apple's Mail software didn't support anything newer than TLS 1.0. According to a customer who was in contact with Apple's support, the new iOS beta versions support TLS 1.2 in the Mail application.
• Yelp is now using HTTPS by default.
• The interior ministers of France and Germany have proposed actions against encrypted communication. However, it's not entirely clear what they proposed, because the German and French version of their mutual declaration have significant differences. The German ministry was unable to explain these differences when asked by the blog Netzpolitik.org.
• Let's Encrypt announced that it now fully supports Ipv6.
• The Let's Encrypt/IESG root certificate is now shipped in Mozilla's certificate authority list.
• NSS released the new version 3.26. The changes are only minor, most notably the support for NPN has been disabled and it now ships with the Let's Encrypt/IESG root certificate.
• An attack using Unicode Emoji allows changing the look of the browser address bar. While this is not explicitly mentioned by its finder, this naturally also allows an HTTPS web page to appear with a wrong URL and thus impersonate a protected foreign web page.
• The WolfSSL library is now able to run with Intel's SGX functionality.
• The axTLS library released version 2.0.0 with support for TLS 1.2.
• BoringSSL has an extensive test suite for the TLS functionality. David Benjamin and Eric Rescorla have now adjusted this test suite to work with NSS. The test suite could be adapted to work with other TLS stacks as well.
• The Intel Crosswalk library had a vulnerability that allowed launching a Man in the Middle attack with forged TLS certificates.
• Microsoft disabled support for the RC4 cipher in Edge and Internet Explorer.
• The certificate authority Wosign had several security incidents that led to a discussion on a Mozilla mailing list. Most notably, an unauthorized certificate for github.com was issued in 2015. Mozilla is currently discussing how it should react to these incidents.
• A Github repository collects keys with deliberately defect properties for testing purposes.
• The Nettle library recently changed their code for modular exponentiation with private values to use a timing safe variant provided by GMP. As the author of this newsletter pointed out, this change may have unintended consequences: The timing-safe function does not accept inputs where the modulus is an even number. This can lead to crashes when one tries to load a specially crafted broken private key with an even modulus.
• Several vulnerabilities in MatrixSSL were discovered by the author of this newsletter. We already mentioned this in last month's newsletter. A more detailed explanation and a proof of concept code are now available.
• Blackberry has filed a patent lawsuit against the company Avaya. One of the patents affects the use of elliptic curve cryptography in OpenSSL. Blackberry owns the company Certicom which owns several patents affecting elliptic curve cryptography.
• For 18 years Libgcrypt and GnuPG had a vulnerability in their random number generator. Researchers from the Karlsruher Institute of Technology (KIT) found out that if one can observe 580 bytes from the random number generator, the next 20 bytes can easily be predicted. GnuTLS has used Libgcrypt in the past, however current versions use Nettle instead.
• The tool trytls allows checking TLS implementations for certificate validation issues and weak algorithms. An overview of TLS stacks in various programming languages and Linux distributions shows that there is still widespread support for dangerous and outdated algorithms like RC4 and MD5.
• Google developers published a paper about security indicators in browsers at the Usenix Symposium on Usable Privacy and Security (SOUPS).
• Google has enabled HTTP Strict Transport Security (HSTS) for its main domain www.google.com.
• Many encrypted messengers of questionable quality have been published in recent years. The messenger Bubcon seems to be a particularly bad example. According to an analysis by members of the Chaos Computer Club Hannover, the claimed End-to-End-encryption simply does not exist. In addition, the messenger uses a self-signed certificate that the Bubcon operators have not created themselves, instead they took an example certificate they found on Github. Finally, they didn’t verify the certificate at all.
• The CA/Browser Forum approved Ballot 169, which introduces clearer rules for domain validation. The old wording of the Baseline Requirements was unclear in that it allowed undefined other methods to validate domains. The new wording only allows a specified list of methods to validate domain ownership.
• HP iLO (Integrated Lights-Out) devices were vulnerable to Vaudenay’s padding oracle attack. This was reported by the author of this newsletter. This attack is possible if a TLS implementation sends different error codes for MAC errors and padding errors. Owners of iLO devices should upgrade their firmware to version 1.88.
• David Benjamin announced that Chrome will soon support RSA-PSS signatures in TLS. They will be part of TLS 1.3. It is possible to use them in the same way in the existing TLS 1.2 standard.
• On the TLS working group list, a discussion has started on whether TLS 1.3 should be called 2.0 instead, due to the large amount of changes.
• The SSL Labs test now detects Google’s post-quantum cipher suites.