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.

OpenSSL security update and the trouble with non-safe primes

OpenSSL published a security advisory and updates. One high severity bug was fixed in the 1.0.2 branch of OpenSSL affecting the Diffie-Hellman key exchange (CVE-2016-0701).

In the Diffie-Hellman key exchange, the calculations need a large prime as a parameter. The prime is part of the Diffie-Hellman parameters of a server. The primes usually used for this are called safe primes. They have the property that for a prime p there is another prime (p-1)/2. This other prime is called Sophie Germain prime.

OpenSSL 1.0.2 does not use safe primes by default; instead it uses primes of another form that were specified in RFC 5114. In combination with another property of OpenSSL this becomes a security problem: OpenSSL had the ability to cache and re-use ephemeral keys for several connections. Most common server applications like Apache and Nginx disable this key caching, but it was enabled by default.

OpenSSL 1.0.2f introduces an additional check that prevents attacks against this issue. Also, the caching of ephemeral keys in Diffie-Hellman key exchanges has been disabled and cannot be enabled any more. The Elliptic Curve Diffie-Hellman key exchanges have a similar ephemeral key caching property. This is independent of this vulnerability, but it may lead to security risks in other situations.

A second vulnerability (CVE-2015-3197) with low severity was also fixed: If SSLv2 cipher suites were disabled on a server, but the SSLv2 protocol was still enabled, the server would still allow connections with the disabled cipher suites.

NIST wants to standardize Post-Quantum Cryptography

The US National Institute of Standards and Technology (NIST) published a report on the state of Post-Quantum Cryptography. Quantum computers threaten the security of almost all cryptographic protocols in use today.

The biggest announcement in the report is that NIST plans to start a standardization process for post-quantum cryptography. NIST plans to publish preliminary evaluation criteria during 2016 that should be finalized by the end of the year. After that NIST will accept proposals for quantum-resistant algorithms.

The problem with existing post-quantum algorithms is that they are usually either not very well researched, or not very practical for production use. Last year an EU-funded research project led by Tanja Lange published preliminary recommendations for post-quantum cryptography.

Powerful features require HTTPS

Newer versions of the Chrome browser disallow certain features if they are not in a secure context. A web page is a secure context if it is delivered over HTTPS. In case it’s embedded as a frame or an iframe, the top web page also must be delivered over HTTPS.

Chrome has already disabled the possibility to access certain media features like the microphone or the camera in insecure contexts. Access to the geolocation API over insecure contexts will be forbidden in Chrome 50.

This move was not without controversy. On the Chromium security mailing list the owner of a company that provides microphone-based services embedded via Iframes complained that many users don’t see the need to move to HTTPS. However, given that access to a microphone might allow secret listening to sensitive conversations it seems sensible to restrict the access to secure websites.

These changes are implementing the Secure Contexts standard that was published by the W3C. Firefox also plans to implement this standard.

The risk of TLS interception

Researchers from the Concordia University in Montreal, Canada, published a paper analyzing the security of so-called TLS interception solutions. They found a large number of security problems.

Many software products install a root certificate into the browser in order to be able to inspect or manipulate traffic. This can happen through a locally installed proxy or a network device. Technically this is a Man-in-the-Middle attack. The researchers analyzed various antivirus and parental control applications.

Four applications (CYBERsitter, KinderGate, PC Pandora and G DATA) allowed attackers to trivially attack them, because they simply accepted all certificates presented to them. Several less severe problems were found in the other analyzed applications.The authors came to the conclusion that “all the analyzed products in some way weaken TLS security on their host”.

German IT magazine c’t also analyzed antivirus applications doing TLS interception and found that the ESET NOT32 antivirus software had a similar problem and didn’t properly verify certificates, thus allowing attackers to forge HTTPS websites.

TLS interception products have often been the source of security vulnerabilities in the past. The most prominent example was the Superfish adware that came preinstalled on Lenovo laptops. The author of this newsletter [Hanno Böck] also analyzed a number of such products in the past and found various security issues (1, 2, 3, 4).

TRON workshop looks at TLS 1.3

On February 21st the Internet Society held a workshop with the title “TLS 1.3 Ready Or Not? (TRON)”. Several cryptographers analyzed the current draft version of TLS 1.3 and presented their findings. All papers are linked to from the workshop’s program web page.

Research presented at the workshop has already caused a discussion on the TLS mailing list about the removal of client authentication in zero-round-trip (0-RTT) connections. A paper by researchers from the Ruhr University Bochum about Bleichenbacher attacks against QUIC and TLS 1.3 was awarded best contribution to the workshop. We wrote about that research in our December newsletter.

Short News

• Mozilla fixed a miscalculation bug that the author of this newsletter [Hanno Böck] reported in the NSS library which could have security implications (CVE-2016-1938). Under certain conditions the division function (mp_div) and the exponentiation/modulo function (mp_exptmod) produced wrong results. This was fixed in Firefox 44 and in NSS 3.21.
• Kenneth White points out on Twitter that a major change has happened in the code for the upcoming OpenSSL version 1.1: The FIPS-validated code has been removed. FIPS is a validation system for cryptographic code and is required in some environments. In the past it was possible to compile OpenSSL in a way that was FIPS compliant. However the FIPS code has often been described as painful to maintain. It is currently unclear whether the final OpenSSL 1.1 will be FIPS compatible.
• The tool socat included hardcoded Diffie-Hellman parameters where the “prime” parameter was not a prime. It is unclear how this happened. The parameters were introduced by a patch from a Zhigang Wang, who worked for Oracle at that time. Ars Technica covered the issue and was unable to get a comment from Wang.
• The XMSS signature scheme could soon become an RFC. According to Andreas Hüsing the current draft is almost finished. XMSS is a hash-based signature scheme that is believed to be resistant to quantum computer attacks. However it is a stateful signature scheme, which makes it often impractical to use. A stateless hash-based signature scheme called SPHINCS has been developed in part by the same authors.
• The file sharing website Pirate Bay added a new feature to stream movies with the software Torrents Time. However this software had some security issues. It would open a web server on a local port and stream movies over an HTTPS connection. This means that the private keys of the used certificates were shipped with the software. The private keys were published and revoked by the responsible certificate authorities.
• Google developer David Benjamin published a tool to decode DER/ASN.1 structures to readable ASCII text and to re-encode them from the same format. The tools are written in Go.
• The hosting company Linode used Ubuntu images with a preconfigured SSH key that was the same on all servers. This was reported by the German IT news web page heise. A similar incident happened last year at the German hosting company Hetzner.
• The developers of Chrome announced that the browser will stop supporting the deprecated SPDY and NPN protocols in May. SPDY was the predecessor of HTTP2 and NPN was the mechanism to negotiate SPDY/HTTP2. NPN has been replaced by ALPN. The NPN deprecation had already been done last year, but it was reverted, because many servers still don’t support ALPN. We wrote about that in our November newsletter.
• A research team at Tel Aviv University successfully conducted a sidechannel attack against elliptic curve encryption in GnuPG and the Libgcrypt library. They measured the electromagnetic waves coming from a laptop. Libgcrypt 1.6.5 has implemented countermeasures to this attack.
• CAA records allow a domain owner to specify via DNS records which certificate authorities are allowed to issue certificates for that domain. Benny Baumann has collected some statistics about the use of CAA records. Among the Alexa Top 1 Million there are only 17 domains using CAA records.
• Downgrade attacks are a recurring problem in cryptographic protocols. A team of researchers did a formal analysis of downgrade attacks and ways to prevent them in configurable cryptographic protocols.
• Key Pinning is seen as a good way to mitigate the problem of malicious certificate authorities. However, the only widely supported standard for this is HTTP Public Key Pinning (HPKP, specified in RFC 7469), which is only available for HTTPS. A new draft proposes a generic pinning mechanism for TLS. This new mechanism is called TLS Server Identity Pinning. Unlike HPKP it doesn’t pin the key itself, it creates a pinning ticket that acts as a second authentication factor on subsequent connections.
• Gmail introduced a new UI that will mark mails that have not been delivered over STARTTLS. Mails that arrived at the Google mail servers over an unencrypted SMTP connection will be marked with a broken, red lock icon.
• In the Firefox bug tracker a proposal was discussed to restrict all insecure cookies to one browser session. However, based on the telemetry data collected by Firefox this proposal looked impractical: More than 90% of all cookies don’t have the secure flag set. Even on HTTPS-only web pages a large number of cookies come without the secure flag.
• Peter Bowen from Amazon developed the tool certlint to check for several common errors in X.509 certificates. The source code is available on Github and the tool has been integrated into the crt.sh service, a web interface that provides access to the Certificate Transparency logs. Certlint identified several hundred errors and several thousand warnings in valid certificates.
• The website Meduza reports that the Kremlin plans to create a Russian state-operated certificate authority. Meduza refers to an article on the Russian web page Kommersant as their source.
• Chrome developer Lucas Garron gives an overview of the state of the HSTS preload list in Chrome. Website owners who want their webpages to be only accessible over HTTPS can add their webpage to this preload list. It is maintained by Google, but other browsers use the same data. There has been an exponential growth of the number of sites and in the long term the size of the list may become a problem. Chrome discusses various methods to shrink the list. Also, currently there is no automatic mechanism to remove stale entries from the list.
• Chrome may soon remove the remaining support for insecure TLS downgrades. These downgrades were implemented because some faulty TLS server implementations would not properly establish a connection if one tried to connect with a newer TLS version. These downgrades have caused various usability and security issues in the past, most notably the POODLE attack. Firefox already disabled these fallbacks in 2014. A workaround called SCSV can prevent these fallbacks from happening, but if they are disabled, SCSV is no longer necessary.
• Starting January 2016, according to the CA/Browser Forum’s Baseline Requirements, it is no longer allowed to issue certificates signed with the old SHA-1 algorithm. However, several such certificates issued this year have been reported on a Mozilla mailing list (1, 2).
• An IETF draft document written by Google developer Mike West proposes to change the way browsers handle secure cookies. It is currently possible for an unencrypted HTTP connection to set and overwrite cookies that have the secure flag set. This behavior is often unexpected for web developers. The secure flag in a cookie indicates that it should only be sent over encrypted HTTPS connections.