Bulletproof TLS Newsletter #15
WordPress.com and others enable HTTPS by default
28 April 2016
Author: Hanno Böck

This issue was distributed to 26,034 email subscribers.

Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space.

In this issue:

  1. WordPress.com and others enable HTTPS by default
  2. Researchers improve the BREACH attack
  3. Certificate validation in programming languages
  4. Let’s Encrypt leaves beta and works on browser inclusion
  5. Other news

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.


Other news