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.

WordPress.com and others enable HTTPS by default

The blog hosting service WordPress.com has enabled HTTPS by default for all web pages hosted on the service. They already supported HTTPS for webpages on their own subdomain, but it wasn’t available by default for custom domains. WordPress.com uses certificates from Let’s Encrypt.

Other providers are also taking the step to a web that’s HTTPS-encrypted by default, for example the provider InterNetX cooperates with Symantec’s Encryption Everywhere initiative to provide certificates for customers.

Researchers improve the BREACH attack

At the Black Hat Asia conference in Singapore Dimitris Karakostas and Dionysis Zindros presented new research on the BREACH attack. At the same time they released a framework that allows executing these attacks.

The BREACH attack abuses the compression of HTTP connections to learn about secrets in a connection. Typical secrets that can be attacked by BREACH are CSRF tokens, but other attacks are also possible. The original BREACH attack was presented at Black Hat 2013 and was limited to stream ciphers. The major result of the new research is that the new attacks also work against block ciphers, which are usually used these days.

The researchers published a framework named Rupture that allows execution of the new attacks. Most of the attacks can be mitigated by using a new technology called First-Party Cookies, which is currently a draft at the IETF and will be supported in Chrome 51.

Certificate validation in programming languages

Researchers from Sucuri analyzed the certificate validation functionality of HTTPS connections in the programming languages PHP and Python. In response to that post, SourceClear looked at the same issues in Ruby libraries.

They found that the current versions of the programming languages get most things right. Almost all relevant problems only affect outdated versions. The article points out the issue of revocation checks, which are skipped by all implementations, but given the unreliability of OCSP servers there is currently no stable and secure way to verify the revocation status of TLS certificates.

Let’s Encrypt leaves beta and works on browser inclusion

The certificate authority Let’s Encrypt announced that they have officially ended their beta phase. Also some of the rate limits have been increased recently. Previously it was only possible to get 5 certificates per week for a given domain, this has now been raised to 20.

On Mozilla’s security policy mailing list a discussion was started about the inclusion of the root certificate from Let’s Encrypt. Right now certificates from Let’s Encrypt are cross-signed by IdenTrust and therefore trusted by all common browsers, however in the long term Let’s Encrypt wants to have its own root certificate in the browser’s root stores.

Short News

• Facebook wrote about the effects Certificate Transparency had on their certificate issuance process. They report that monitoring the Certificate Transparency logs caused them to notice that a subdomain for which they had transferred control to a third party got a certificate issued without their knowledge. The certificate wasn’t issued maliciously, it just showed Facebook an internal policy violation.
• Security researchers from the Ruhr-University Bochum published a Java-based tool TLS-Attacker that allows testing various attacks against TLS stacks and includes a protocol fuzzer. The code is freely available under the free Apache-2 license. Juraj Somorovsky will present some of the bugs uncovered by TLS-Attacker at the AppSec Europe 2016 conference in June.
• OpenBSD developer Ted Unangst wrote a blog post about the current development of LibreSSL.
• The Chrome browser developers require the Certificate Transparency logs included in the browser to guarantee 99% uptime. A number of log providers seem to struggle with that requirement. Chrome developer Ryan Sleevi announced that the log from Certly.IO was removed from Chrome. A log by the certificate authority WoSign won’t be included in Chrome, because it also failed to meet the uptime requirements.
• Netcraft published a detailed article about the deployment of HTTP Public Key Pinning (HPKP). Very few web pages deploy HPKP at the moment, according to Netcraft the number is below 0,1%. Probably even more notable is that from the few sites that do deploy HPKP, a number of them get it wrong. Netcraft found that a third of those pages had errors in their HPKP headers. This is especially worrying because HPKP, when used wrongly, is a risky technology. If a webmaster pins a site to certain keys and loses access to all pinned keys the site may be unreachable for several weeks.
• Microsoft updated its requirements for the inclusion of certificate authorities into its root certificate program.
• During the IETF 95 meeting in Buenos Aires CloudFlare organized a TLS 1.3 Hackathon. The participants of the Hackathon worked on NSS, the TLS library used by Mozilla products, and Mint, a Go-Implementation of the TLS 1.3 draft. The Hackathon participants achieved a successful TLS 1.3 connection between Firefox and an experimental server from CloudFlare.
• The IRC community is working on a standard to enforce TLS for connections to servers of the chat protocol. It is developed under the name IRCv3.3 Strict Transport Security.
• A new block cipher mode for AES has been proposed in the IETFs CFRG. AES-GCM-SIV uses a so-called synthetic Initialization Vector. This prevents nonce misuse issues in GCM. A nonce is a value that must be unique, however implementations may get this wrong. A draft of a standard for AES-GCM-SIV is available.
• Falko Strenzke from Cryptosource published a research paper about the security of OpenSSL’s random number generator. He uncovered a couple of flaws and design failures, however none of them seem to lead to severe security vulnerabilities.
• A development that received major attention in the past month was that WhatsApp enabled end-to-end encryption for all messages using the Signal protocol. WhatsApp made an unusual choice for the transport encryption part. Instead of TLS, their protocol uses a different transport encryption mechanism: the Noise protocol, developed by Trevor Perrin.
• Mozilla developer Martin Thomson mentioned a potential problem in implementing empty TLS extensions. According to a mail on the TLS working group list, there are TLS implementations that will fail if a connection sends an empty extension as the last one. One such implementation is the WebSphere Application Server. This was previously discovered by the Chrome developers, who implemented workarounds that make sure that an empty extension is never added as the last extension.