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.

Nonce reuse makes GCM connections insecure

Modern TLS applications today frequently use AES and the Galois/Counter-Mode (GCM) as their symmetric encryption mode. GCM uses a 12 byte initialization vector (IV), in which eight bytes have to be set by the implementation and are required to be a nonce. It is absolutely crucial for the security of GCM that an implementation never reuses the same nonce with the same key.

The author of this Newsletter (Hanno Böck) discovered that there are real-world implementations that repeat the nonce value, which makes them insecure. Even though the number of affected hosts is low (184 HTTPS servers), there are some notable users of vulnerable servers, including the credit card company Visa.

Some of the affected devices came from Radware and the company subsequently published security updates. Other devices could not be identified, so it must be assumed that vulnerable implementations still exist.

Repeating a nonce means that an attacker can learn the authentication key and use it to inject malicious content into HTTPS web pages.

Furthermore, the research identified 70,000 hosts which use a random nonce value. This is risky — if the same encryption key is used to encrypt a large number of connections (around 2^32), then a repeating nonce becomes likely. Devices from A10 and IBM Lotus Domino are affected by this and have published security updates.

The possibility of nonce reuse vulnerabilities has led to discussions about cipher modes that use a synthetic IV (SIV).

Another Padding Oracle in OpenSSL

Padding Oracles have long been an issue for CBC-based cipher suites in TLS. The latest security update of OpenSSL fixes another variant of these attacks. Padding Oracle attacks rely on the fact that an attacker can learn information about a ciphertext based on different errors that happen on the recipient side of an encrypted message.

Juraj Somorovsky discovered a new variant of a padding oracle in OpenSSL. OpenSSL did not properly check the length of encrypted TLS records and whether they are long enough to hold the HMAC authentication tag and the padding bytes. Somorovsky discovered this vulnerability with his tool TLS-Attacker. The bug was introduced with the fix for another padding oracle, the Lucky Thirteen attack. Somorovsky also found a very similar bug in MatrixSSL.

Cloudflare developer Filippo Valsorda wrote a detailed explanation of the OpenSSL vulnerability and published an online test for it.

The OpenSSL updates fix another severe security vulnerability in the ASN.1 parser code. Several independent bugs can be used together to cause a memory corruption.

Blogspot, Wired, Heroku, Bit.ly and Ars Technica on their way to HTTPS

The switch to a fully encrypted web seems to have taken up some speed lately. Google announced that all Blogspot-hosted sites are now available over HTTPS and users can set an option that will forward all HTTP traffic to HTTPS. The link shortening service Bit.ly also announced full HTTPS support. Customer-branded domains will automatically get Let’s Encrypt certificates in the future.

Joining the HTTPS move, the cloud platform Heroku also announced free HTTPS support. Heroku will use SNI, a TLS feature that allows multiple different certificates on one IP address, for their HTTPS service. It is widely supported in modern browsers, but Windows XP and some old Android versions don’t support this extension.

Switching to HTTPS has been notoriously difficult for news web sites. The main culprits are third party content and advertising. Many ad networks don’t deliver their ads over HTTPS and it is not possible to include active unencrypted HTTP content on an HTTPS web page. Wired is working on transitioning their web site to HTTPS. The main web page is still delivered over unencrypted HTTP, but the security news section is HTTPS. Ars Technica author Cyrus Farivar said that their web site will also switch to HTTPS soon.

Post-Quantum Cryptography developments

The BoringSSL developers are experimenting with a key exchange algorithm that may be resistant against attacks with quantum computers. David Benjamin committed code for a combination of the elliptic curve key exchange X25519 and the New Hope algorithm. The latter is based on the Ring-Learning-With-Errors problem.

Microsoft researchers published an optimized version of the SIDH key exchange (code, paper). This experimental encryption algorithm is based on supersingular isogenies in elliptic curves. SIDH is also a candidate for post quantum cryptography.

Daniel Bernstein and others published a paper on a variant of the NTRU algorithm called NTRU Prime. The basic design of this algorithm was already proposed by Bernstein in 2014 in his blog.

While the development of post-quantum cryptography gains speed, many cryptographers were unhappy with the EU commission publishing a “Quantum Manifesto”. In this manifesto the EU announces a big research program towards several Quantum technologies. Post-quantum cryptography isn’t mentioned in the manifesto at all. On the other hand it makes questionable promises about future quantum communication networks and even a Quantum Internet based on Quantum key distribution algorithms. Daniel Bernstein published a lengthy critique and the author of this Newsletter (Hanno Böck) wrote a critical comment on Golem.de (in German).

Short News

• GnuTLS released version 3.5.0. Main developer Nikos Mavrogiannopoulos sums up the most important changes, which include support for SHA-3, the X25519 key exchange and TLS false start.
• StartCOM announced StartAPI, a new API that enables automatic creation of certificates. They are also introducing a service called StartPKI, which will provide custom-branded intermediate certificates for large customers.
• Industrie- und Handelskammer Stuttgart published TLS-Check, a perl script which checks servers’ TLS settings. They used this tool to evaluate the TLS settings of companies in the south-western Baden-Württemberg region of Germany.
• Eric Lawrence gave an overview of the current state of TLS version intolerance and browser fallbacks. TLS version intolerance bugs have caused browsers to implement fallbacks in the past that enabled security vulnerabilities, the most notable one being POODLE. Today most browsers have disabled, or plan to disable these dangerous fallbacks.
• Chrome finally disabled the NPN negotiation mechanism for HTTP/2 in version 51. The only mechanism supported now is the newer ALPN mechanism. Matthias Geniar points out that most major Linux distributions don’t have support for ALPN yet. Chrome announced disabling of NPN before, but delayed it. It seems however that the time for NPN is over.
• Chrome developer Ryan Sleevi announced that the Certificate Transparency log operated by Izenpe showed inconsistencies and that Chrome will no longer consider it to be a qualified log. We already mentioned in the April newsletter that other Certificate Transparency logs had trouble as well.
• Android N, the next version of Android, will have a new API that allows apps to implement certificate pinning in an easy way.
• The Electronic Frontier Foundation (EFF) announced Certbot, a client for the ACME protocol used by Let’s Encrypt and written in Python. Certbot was previously known as the Let’s Encrypt client. While the ACME protocol was developed by Let’s Encrypt, it is a standard that can be used by other certificate authorities as well.
• cURL announced a vulnerability that allows bypassing certificate checks. The vulnerability only affects cURL if it’s using mbedTLS or PolarSSL. cURL supports a variety of TLS backends. The most commonly used ones, like OpenSSL and GnuTLS, are not affected.
• Google announced that Gmail’s web and SMTP server will stop supporting RC4 and SSLb3 on June 16th. Both the RC4 algorithm and the SSLv3 are considered insecure and deprecated.
• Several web projects are tracking if and how municipalities use HTTPS for their web sites: a project by the Open Knowledge Foundation Germany, and similar projects in the Netherlands and Norway.
• The nginx web server is now able to use multiple certificates with different key types (RSA, ECDSA) on one host.
• Chrome developer Ryan Sleevi announced that until several concerns are addressed Chrome will not accept name redaction in certificates added to Certificate Transparency logs.
• Let’s Encrypt now allows creation of certificates with the OCSP Must Staple feature.