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 Ivan Ristić.

RC4 finally going away

It seems that RC4 is finally going away. In early September, Google, Microsoft and Mozilla all announced that they will be removing RC4 from their respective browsers in early 2016. Their announcement was a culmination of wide efforts to stop using RC4, one of the oldest and most popular ciphers. Before that, the IETF published RFC 7465 in February 2015 to prohibit RC4 deployments.

There are several reasons for the slow demise of RC4, the biggest probably being the fact that the attacks demonstrated so far are difficult to carry out in practice. Another factor is that RC4 can be used to mitigate some other security problems, which many consider to be more serious.

SSL Labs has long warned about RC4, using varying penalties depending on the exact server configuration. A server with RC4 currently gets a B if it's using RC4 only with old protocols or a C if it's using it with modern protocols. With the next update scheduled for October, RC4-only servers will start getting Fs. Additional penalties will probably be added in the future.

Chrome's treatment of EV certificates

Chrome continues to work on Certificate Transparency (CT) and the infrastructure is slowly coming along. Starting with Chrome 41, released in March 2015, CT is required in order to properly recognise EV certificates. This requirement applies to the certificates issued in January 2015 and later; all earlier certificates have been whitelisted. The fact that CAs are slow to start supporting CT and that Chrome's requirements keep changing, led to many EV certificates failing to get proper recognition.

Increased efforts to use only good crypto

Until a couple of years ago there was little support for modern protocols. Useful documentation on how to configure servers for encryption was difficult to find, leading to predictably bad results. I am happy to report that those days seem to be behind us. Now, it's common to see strict requirements for good cryptography.

In April, the PCI Security Standards Council issued a revised version of their DSS standard to deprecate SSL and TLS 1.0. Companies have until June 2016 to migrate to more secure protocols.

HTTP/2, released in May, requires at least TLS 1.2 and allows only strong cipher suites that provide forward secrecy. And, although HTTP/2 fell short of requiring encryption, current browser implementation do require it.

In June, the United States CIO issued a memorandum requiring all publicly accessible government web sites to provide service only via a secure connection. To encourage sites to upgrade, they built a dashboard to follow HTTPS deployments.

Also in June, Apple announced a new feature called App Transport Security (ATS), which means that all application communication will be encrypted by default. On the server side, they require at least TLS 1.2, strong cipher suites, strong private keys, and SHA2 certificates. ATS will be deployed in iOS 9 and OS X El Capitan.

In the same month (June seems to have been a particularly good month for TLS), Facebook announced that, starting with October, applications that don't support SHA2 won't be able to connect to their platform.

New attacks and vulnerabilities

Although the summer was pretty quiet compared to previous years, we did see some new attacks and vulnerabilities. Some of them were quite interesting and serious, but, for one reason or another, didn't have a strong impact on the ecosystem overall.

In July, there was a new OpenSSL vulnerability, which allowed authentication bypass by an active network attacker. Fortunately, the problem had been introduced only weeks prior to the discovery and there was no time for the vulnerable version to propagate widely.

In August, Hlauschek et al. published their paper on Key Compromise Impersonation (KCI) attacks on TLS. Their work highlighted issues with static DH and ECDH keys, which are very rarely used in TLS and, clearly, don't belong in the standard at all.

In early September, Florian Weimer and Red Hat announced their discovery that some RSA implementations are vulnerable to side-channel attacks, which could lead to private key leakage. However, it seems that only a very small number of servers have been affected.

Finally, this week saw an announcement of an attack against some elliptic curve implementations that could also lead to private key leakage; the Bouncy Castle and Oracle JCE libraries were found vulnerable. However, the vulnerability is in a seldom used feature (against static ECDH keys), which means that there won't be many servers affected by this problem.