31 March 2016
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. Maintained by Hanno Böck.
Several large E-Mail providers published a draft for a new standard called SMTP Strict Transport Encryption (SMTP STS). The goal of the draft is to provide better protection for communication between mail servers over SMTP.
SMTP server-to-server connections can be encrypted via STARTTLS, but right now the encryption only protects against passive attackers. An active attacker can easily strip the TLS encryption. In addition, certificates used for these connections usually aren’t checked, because many server operators use self-signed certificates for their mail servers.
The aim of SMTP STS is to solve this problem by providing a DNS mechanism to publish policies. These policies can either be distributed over HTTPS or via DANE.
DANE is an already existing mechanism with similar goals, but it relies on DNSSEC. Most of large Internet companies haven’t deployed DNSSEC and many security professionals are skeptical about the protocol. Therefore an alternative that does not rely on DNSSEC may finally provide a widespread way to better secure the connections between mail servers.
The CA/Browser Forum decided that certificate authorities should stop issuing certificates with signatures using the weak SHA-1 algorithm by January 1st 2016. Recently a large payment operator - Worldpay - asked for an exception of this rule. They had a large number of payment devices that relied on publicly trusted certificates and didn't support better algorithms. Mozilla then decided to grant an exception and allow the issuance of some certificates by Symantec under certain conditions. It is unclear whether other browser vendors also agreed to this issuance.
After that a discussion started on the CA/Browser Forum's mailing list. Symantec asked for a generic solution, because other payment providers had similar problems. However this was met with skepticism. Symantec was unwilling to name the companies that requested this exception. Developers from Google and Mozilla rejected any further exceptions without an open debate about the cases and without the affected parties participating in the discussion.
A research team from Universities of Adelaide, Tel Aviv and Pennsylvania was able to successfully use a CPU cache timing sidechannel to uncover a secret RSA key from OpenSSL encryption operations. They named their attack Cachebleed.
Cachebleed exploits the behavior of Intel’s Sandy Bridge architecture. If there is a concurrent access of two processes to the same cache bank only one process can access it, the other access is delayed. These cache bank conflicts allow one process to learn something about the cache access patterns of another process.
For a successful attack around 16.000 RSA encryption observations need to be made. This allows learning around 60 percent of the bits of the private key. The rest of the key can be recovered in a few minutes on a powerful server with the Heninger-Shacham algorithm.
The OpenSSL releases 1.0.2g and 1.0.1s contain countermeasures against this attack. On the more modern Haswell architecture cache bank conflicts no longer occur and therefore the attack does not apply.
Both the OpenSSL developers and the attack authors consider Cachebleed a low severity issue. It only applies if both an attacker and a victim can execute processes on the same machine. In typical cloud environments the attack is usually not practical, because there is too much noise from other processes.
The certificate authority StartCOM/StartSSL will soon log all certificates issued to several public Certificate Transparency (CT) log servers. Right now most certificate authorities only do this for extended validation certificates.
The certificates will also contain a signed certificate timestamp (SCT). This is a proof that a certificate has been submitted to a log before being issued.
The idea of certificate transparency is to have public logs of all TLS certificates. It has successfully helped in the past to uncover misissuances of certificates.
OpenSSL released the versions 1.0.2g and 1.0.1s that fix several security issues. The most severe issue was the DROWN vulnerability which we covered in a special newsletter. DROWN itself is not a software bug, it’s a protocol issue with SSLv2, therefore by default OpenSSL now disables this old protocol.
The other issues fixed were mostly memory corruption issues, but they all affect rarely used features or places where attacker controlled input is unlikely. Guido Vranken has blogged about some of the issues, including one that is not fixed yet.
This subscription is just for the newsletter; we won't send you anything else.
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof SSL and TLS, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 1,500 students who have benefited from more than a decade of deep TLS and PKI expertise.