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.

SLOTH attack targets old hash functions

Researchers from the Prosecco team at INRIA published a number of attacks that exploit the use of weak hash functions in TLS and other protocols. They called their attack SLOTH (Security Losses from Obsolete and Truncated Transcript Hashes). The most severe attack is affecting the systems that use of client certificates and continue to support RSA-MD5 signatures.

It’s been known since 2005 that MD5 hash collisions are easy to carry out. Many practitioners have argued in the past that the hash collisions don’t matter in certain scenarios and that the security of many protocols only relies on the so-called second preimage resistance. The INRIA researchers debunked many of these claims with their new publication.

The most notable scenario where an attack is possible is when client certificates are used. If a user authenticates himself at a malicious server using a client that supports RSA-MD5 signatures, then the server can use the information provided to impersonate the user on some other target server (which must also support RSA-MD5).

A surprising aspect of this is that TLS 1.2 is vulnerable to this attack while prior versions are not. The reason for this is that TLS 1.2 allows negotiation of the signature algorithm (prior versions always use a concatenation of MD5 and SHA1) and, crucially, still supports the insecure MD5 as an option. This is very surprising given the fact that TLS 1.2 was published in 2008—several years after practical attacks against MD5 were announced.

This attack is made worse by the fact that various implementations accept RSA-MD5 signatures even if they advertise that they don’t do this. Several cryptographic libraries have received updates in response to this research, including NSS, GnuTLS, BouncyCastle and mbedTLS. An old version of OpenSSL (before 1.0.1f) was also affected.

CurveSwap - is it a risk?

In a talk at the 32th Chaos Communication Congress (32C3), Nick Sullivan from CloudFlare mentioned a new potential attack against the TLS handshake called CurveSwap. The attack is based on the fact that the negotiation of the elliptic curve used for a TLS connection is unauthenticated. The attack poses only a theoretical risk, but it may be advisable to disable potentially weak elliptic curves.

In order to exploit this attack it would be necessary to calculate a discrete logarithm in some weak curve that is supported by both the server and the client. If an attacker could do that, he could force the connection to this weak curve.

At the moment this attack is only theoretical, because TLS doesn’t support elliptic curves weak enough to allow an attacker to attack them successfully. However, it seems reasonable to remove support for potentially weak curves from TLS implementations as a precaution. Almost all TLS implementations default to the NIST P-256 or stronger curves. Removing all curves weaker than 256 bits should cause no issues. Some preliminary research in the past years has generally questioned the security of binary curves, therefore disabling them seems reasonable as well.

Update on the Juniper backdoor

In the December Newsletter we briefly mentioned the discovery of backdoors in some Juniper devices. Since then, several researchers uncovered further interesting information. Questions still remain on whether Juniper itself added the backdoors or if they were planted by some other third parties.

Ralph-Philipp Weinmann published its analysis of one of the backdoors that is related to the Dual EC DRBG random number generator. It’s been known for a long time that whoever creates the parameters for Dual EC can also create a secret parameter that will allow them to attack the random numbers. According to Weinmann, Juniper did not use the standard parameters for Dual EC which are likely backdoored by the NSA. When the backdoor was introduced, these parameters were changed. So it looks like there was an original backdoor that later got changed into a different backdoor by someone else. Dual EC was chained with another random number generator (ANSI X9.31), which would have neutralized this backdoor. But Willem Pinckaers found out that the code contained a bug and therefore this second random number generator was not active.

Further research on the matter was presented by Hovav Shacham at the Real World Crypto conference. When Dual EC was originally introduced into ScreenOS, another change happened at the same time: The nonce for the IKE-part of the IPSEC protocol was extended from 20 to 32 bytes. As it turns out, 32 bytes is just enough to enable an attack on Dual EC. It seems therefore possible that Dual EC might had been originally added in order to create a backdoor, but that someone else (not Juniper) later changed the parameters to take control over the backdoor.

Juniper published a blog post explaining the use of Dual EC and announced that it will remove this questionable random number generator in future versions of ScreenOS.

The second backdoor in the Juniper devices was a default SSH password. H. D. Moore from Rapid7 published that password in his blog post.

Juniper isn’t the only company apparently having problems with backdoors into their devices. A mail on the Full Disclosure mailing list exposed another potential SSH authentication backdoor in devices from the company Fortinet. This wasn’t a simple SSH password backdoor like in the Juniper case, instead it was a custom SSH authentication method. Fortinet published a statement in which it denied that this was a backdoor. This only affects older versions of the FortiOS firmware and was fixed in 2014.

A few days later Cisco also published a security advisory announcing that some of their devices had a default SSH password in several router models.

Update on SHA1 certificates

In the December Newsletter we talked about plans of CloudFlare and Facebook to continue using SHA1-signed certificates. They proposed a new certificate validation method called Legacy Validation (LV) that would allow them to continue to support SHA1 certificates in the future. Recently Twitter also joined that call. Some certification authorities seem to have plans to issue certificates without the formal process of changing the rules of the CA/Browser-Forum.

Comodo has pulled one of its old root certificates that is no longer used for normal issuances from browsers and uses it to deliver SHA1-signed certificates. Symantec has recently also pulled an old root certificate from browsers and announced that it no longer intends to comply with the Baseline Requirements with this root certificate. Symantec has not publicly declared what it intends to do with this certificate, nor answered a question on whether it plans to use this certificate in a similar way as Comodo. It only said that the certificate “will now be repurposed to provide transition support for some of our enterprise customers’ legacy, non-public applications”.

Chrome developer Ryan Sleevi posted two long texts (Part 1, Part 2) where he explains why he thinks the LV proposal is a bad idea. Nick Sullivan from CloudFlare joined the debate and explained how entropy in the serial number of certificates can mitigate attacks against the weak hash function.

For Mozilla, the removal of SHA1-support caused some trouble. On January 1st Firefox 43 stopped supporting certificates signed with the SHA1 algorithm. It turns out that some software products using man-in-the-middle attacks to intercept TLS traffic support only SHA1. As a result, they stopped working when Firefox disabled SHA1 certificate support. Therefore Mozilla has temporarily re-enabled SHA1 support in Firefox 43.0.4.

OpenSSH vulnerability in rarely used roaming code

OpenSSH client had a severe vulnerability (CVE-2016-0777) that could leak the user’s private key to a malicious server. The faulty code was part of a roaming feature that SSH implements, but which is rarely used, because OpenSSH server code does not support it. Therefore this vulnerability has some similarities to both the Heartbleed and Shellshock bugs. All three affected a rarely used feature that was enabled by default.

The vulnerability was discovered by Qualys and is based on an integer overflow that will cause a memory overread. Therefore a server can read some parts of a user’s memory. Due to the IO buffering of the libc functions, this memory might contain pieces of a user’s private key.

Filippo Valsorda added a check for the vulnerable roaming code to a test server he runs. (The test was originally designed to show user identification based on their SSH public keys on their Github accounts.)

Qualys also found a buffer overflow (CVE-2016-0778), but that is only exploitable in rare circumstances when a user enables several non-standard features. The OpenSSH release 7.1p1 fixes both issues and also another out of bounds read error (CVE-2016-1907) found by Ben Hawkes.

Short news

• An attack called HTTPS Bicycle was published by Guido Vranken. Nicolas Griffin explains the attack in a blog post. The Bicycle attack exploits the fact that TLS stream ciphers don’t hide the length of the encrypted data. This is not surprising, it is documented in the TLS 1.2 standard (chapter 6, page 15). An attacker knowing the victim’s browser and the exact details of an HTTP request may be able to extract the length of the data. This may, for example, give an attacker information about the number of characters of a password. Stream ciphers in TLS are not widely used these days, but according to the paper the Galois/Counter Mode (GCM) also leaks the length of the content.
• The 32nd Chaos Communication Congress (32C3) in Hamburg had a number of talks related to cryptography and TLS, apart from Nick Sullivan’s talk that we already mentioned:
  • An introduction to Post-Quantum cryptography by Dan Bernstein and Tanja Lange
  • Research on the security of TLS in SMTP by Zakir Durumeric (we mentioned the research in the November Newsletter)
  • Debunking myths about entropy by Filippo Valsorda
  • Logjam by Nadia Heninger and J. Alex Haldermann
• The Real World Crypto conference featured a large number of interesting talks. Unfortunately no videos are available, but slides from most talks can be found on the conference webpage.
• Originally, the Go TLS library did not implement CBC cipher mode in constant time. That made them vulnerable to the Lucky Thirteen attack. Filippo Valsorda wrote a patch to fix this.
• Dan Bernstein mentioned on Twitter that a paper he and Tanja Lange wrote about the security of the NIST elliptic curves was rejected from the IACR preprint server. This was perceived as very unusual, because the IACR preprint server has very lax publishing requirements.
• Filippo Valsorda found out that the python-rsa package implemented RSA in a way that made it vulnerable to Daniel Bleichenbacher’s signature forgery attack. This attack was discovered in 2006, and variants of it have been found many times since. The most prominent one was the BERserk attack against Firefox. Valsorda also found out that code he had written himself - as part of the youtube-dl tool - had the same vulnerability. However, in this case it wasn’t exploitable, because it used a hardcoded key with an exponent of 65537. The attack only works with keys with an exponent of 3. A safety precaution against this attack is therefore also to avoid keys with very small exponents.
• Microsoft had announced that it would remove a number of certificate authorities from their root store that didn’t meet the requirements. This seems to have caught some CAs by surprise. Some of them were subsequently able to avoid the removal by submitting missing audits, for example the Czech company PostSignum (which is the Czech postal service company).
• A research team presented a new way to choose the parameters for elliptic curves. The Million Dollar Curve bases their parameters on randomness chosen by the data from international lotteries. This proposal reflects on the debates about how the parameters of elliptic curves can be chosen in a way that shows that the designer of a curve had not used intentionally bad parameters. Curve25519, which has recently been standardized by the IETF’s CFRG, chose a different path: Instead of creating supposedly trustworthy randomness, the designers of Curve25519 tried to be rigorous in a way that the choice of design criteria leaves only one possible curve choice.
• A research paper by Nicolas Courtois investigates the complexity of the discrete logarithm problem in binary elliptic curves.
• We reported about the plans for a man-in-the-middle attack on Kazakhstan’s citizens in the December newsletter. The Kazakh root certificate authority has now submitted their root certificate to Mozilla for inclusion into the certificate store of Firefox. This has led to a longer discussion on a Mozilla mailing list. Currently it seems that the certificate submission doesn’t comply with the requirements of Mozilla’s root program membership, so it is unlikely to be added, independent of the discussion about the potential use as a man-in-the-middle certificate.
• Adrienne Porter Felt from Google’s Chrome security team presented research about certificate warnings in browsers at the Real World Crypto conference. By far the largest reason for warnings were wrong clock configurations on devices.
• Two incidents have brought Let’s Encrypt into the news. TrendMicro reported that certificates from Let’s Encrypt have been used for malvertising. CertSimple reported that Let’s Encrypt issued certificates for google.com.mg and google.com.im, neither owned by Google. In both cases it can be argued that Let’s Encrypt is not at fault and the criticism stems from a wrong understanding of the meaning of domain validated certificates. Domain validation only means that a certificate authority is required to verify that a certificate requester has control over a domain, in both incidents this was the case.
• Microsoft announced that they fixed a bug in the TLS session resumption that could cause a downgrade to a less secure TLS version.
• A carry propagation bug in the Go TLS library can in certain circumstances leak a private RSA key. Carry propagation bugs are relatively common errors in bignum libraries. The reason this bug is especially severe is the fact that Go uses the chinese remainder theorem to speed up signature creations and a calculation error in this method can lead to a catastrophic attack leaking the private key to an attacker. On 64 bit systems this bug only occurs in rare circumstances, but on 32 bit systems it is a significant risk. Florian Weimer from Red Hat wrote about this issue in a research paper published back in September 2015.
• Alex Moneger has built a TLS stack on top of scapy which is intended to be used for testing TLS attacks. He presented this at Shmoocon.
• The debate about state-mandated backdoors in crypto products is ongoing:
  • France rejected a proposal to mandate backdoors
  • The state of New York is currently discussing a similar law that would forbid selling smartphones with strong cryptography and
  • The government of the Netherlands has openly opposed state-mandated backdoors at least currently.
  • An open letter by a large number of civil society groups to politicians worldwide demands from them to reject all plans to ban secure cryptography or mandate backdoors. Surprisingly the very real risks of backdoors that came to light both in the Juniper case (see above) and in the FREAK and Logjam attacks rarely play a role in this debate.
• An improvement on the BREACH attack was presented at the Real World Crypto conference. BREACH uses the HTTP compression to give an attacker information about transmitted content. More details will be presented at the Black Hat Asia conference in March.
• The author of this letter [Hanno Böck] reported two bugs in the elliptic curve multiplication code of Nettle, the cryptographic library used by GnuTLS. The Nettle developer published a release candidate for the upcoming version 3.2 which contains fixes for these issues.
• New elliptic curves have been standardized by the IETF in RFC 7748. After a long debate about the best way to define rigorous curves, this RFC specifies Curve25519 and Curve448 as well as a corresponding key exchange protocol.
• David Benjamin announced that the Chrome developers plan to implement and ship the X25519 algorithm soon. X25519 is a key exchange algorithm based on Dan Bernstein’s Curve25519. The specification for the use of this curve in TLS is still a draft, but Benjamin doesn’t expect it to change significantly before it is published as an RFC.
• Researchers from ENS Paris and the Royal Holloway University London published a paper that improves attacks on the RC4 stream cipher. In the past years many improvements on attacks on the RC4 algorithm have been published and browsers are removing support for it.
• OpenSSL announced a security update that will be released on January 28th. It will include fixes for two security issues, one high severity issue affecting version 1.0.2 and one low severity issue affecting all versions.
• Amazon Web Services now offer a Certificate Manager that allows the creation and use of TLS certificates for web services hosted there. The Certificate Manager is available at no extra cost, so this is an important step in making HTTPS available to more users. Surprisingly, Amazon’s own main web page still isn’t using HTTPS by default.