Bulletproof TLS Newsletter

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.

SMTP Strict Transport Security may improve transport encryption for email

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.

SHA-1 debate continues with payment operators asking for exceptions

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.

Cachebleed Attack uses CPU cache as a sidechannel

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.

StartCOM will publish all certificates to Certificate Transparency logs

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 update mitigates DROWN and fixes various minor security issues

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.

Short news

• A use-after-free vulnerability and a buffer overflow were discovered in Mozilla’s NSS encryption library. Both vulnerabilities are in the ASN.1 decoding routines. Both issues are fixed in Firefox 45 and in NSS 3.21.1.
• Another ASN.1 memory corruption issue was discovered in the cryptographic libraries of OS X and fixed with Apple’s March security updates.
• The code that is used for Google’s web interface to submit domains to their HSTS preload list in Chrome was published on Github.
• The community certificate authority CAcert has re-signed its root certificate. The previous root certificate was still using the MD5 signature algorithm. This was not a security issue, because the self signature of a root certificate has no relevance, but it caused some browsers and tools to show warnings. The CAcert root is currently not included in any major browser.
• A research team analyzed how Internet providers manipulate traffic and inject false content into connections. The manipulation of traffic is a major reason why TLS-protected traffic and HTTPS is desirable even in situations where no secret data is transmitted.
• On the IETF TLS mailing list there was a discussion about RSA-PSS and TLS 1.3. PSS is an improved signature padding mechanism for RSA. For TLS 1.3 it was planned to transition to RSA-PSS, older TLS versions only support the older padding mechanism PKCS #1 1.5. A hardware vendor that wasn’t named had reservations about this move and thus it was proposed to include backwards compatibility to the weaker PKCS #1 1.5 mechanism. However many people in the TLS working group rejected this proposal and wanted to avoid including weaker mechanisms in TLS 1.3.
• The CESG, a research group of the british GCHQ, published a whitepaper about quantum key distribution, a method of doing key exchanges based on physical quantum effects. The conclusion is largely negative towards quantum key distribution: “QKD has fundamental practical limitations, does not address large parts of the security problem, and is poorly understood in terms of potential attacks.”
• A research team has investigated potential sidechannel attacks against ECDSA on mobile phones and was able to present some practical attacks.
• Certificate Transparency is a protocol that logs TLS certificates in a public append-only log. The major Certificate Transparency logs only include certificates of browser-trusted certificate authorities. Google now started a log specifically for untrusted certificate authorities. These can be authorities that have been removed from browsers and authorities that might get trusted in the future.
• Symantec started a product called Encrypt Everywhere. The goal is to cooperate with web hosting companies to offer domain validated certificates and HTTPS by default. The first partners for this program are InterNetX, CertCenter and Hostpoint.
• Yahoo published some statistics about the use of STARTTLS for SMTP connections.They also offer some recommendations for mail server operators.
• Netcraft published an article with an overview about the challenges in deploying HTTP Public Key Pinning (HPKP). The article tries to explain why so few web pages have deployed HPKP yet.
• Several updated drafts for the use of TLS for DNS connections have been published. Currently DNS is always unencrypted. DNSSEC, a technology that existed for a long time, but hasn’t seen widespread adoption yet, only adds signatures to DNS, it doesn’t encrypt.
• Whitfield Diffie and Martin Hellman received this year’s Turing Award. The key exchange discovered by Diffie and Hellman and named after them is seen as the starting point of public key cryptography. It is still used in TLS today, often in a more modern variant based on elliptic curves.
• The author of this Newsletter (Hanno Böck) discovered that the ProFTPD server uses 1024 bit Diffie Hellman parameters even if it was configured with user-defined longer parameters. 1024 bit is considered risky and may be breakable by a powerful attacker. ProFTPD versions 1.3.5b and 1.3.6rc2 fix the issue.
• A team of researchers from Johns Hopkins University discovered a vulnerability in Apple’s iMessage encryption. The flaw is not directly related to TLS, but the use of TLS with key pinning for transport encryption makes the attack much harder.
• Peter Gutmann published a draft for a long-term support profile for TLS 1.2.
• Security researcher David Wong published proof of concept code to exploit backdoored Diffie Hellman parameters.
• A rumor about a claimed security vulnerability in the domain validation process of StartCOM/StartSSL has made some headlines. Someone claimed that he was able to change the mail address used during the validation. This looked like a severe security vulnerability. However according to StartCOM this was only possible because a mail address was used that was in the whois of the respective domain name. Therefore there was no security risk and it wouldn’t have been possible to use this to issue unauthorized certificates.
• Let’s Encrypt will soon use a new intermediate certificate to enable compatibility with Windows XP. The old certificate used features that were incompatible with the old Windows version.
• A variant of the AES GCM algorithm with a synthetic initialization vector has been proposed as a draft in the IETF’s CFRG. The security of the normal GCM algorithm relies on a nonce value in the initialization vector that must be unique, a non-unique nonce can break the security of the scheme. AES-GCM-SIV avoids this risk.