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.

Certificate Transparency for all new certificates

Google developer Ryan Sleevi announced that starting with October 2017 the Chrome browser will require that all new HTTPS certificates get logged in the Certificate Transparency system. Certificate Transparency is a system of public logs of certificates. The idea is to bring transparency into the certificate system and make it much harder to abuse certificates.

In the past Certificate Transparency was already helpful in uncovering numerous instances of wrong certificate issuances. Most notable was an incident in 2015 with the certificate authority Symantec (see our past newsletter on the incident).

Up until now Google only required Extended Validation certificates to be logged. In practice, however, most certificates were already logged. Now Google is taking the next step and requires logging of all certificates.

Backdoors in primes

Three research papers lately looked into the possibility of backdoored parameters for the Diffie-Hellman key exchange. A research team was able to construct a 1024 bit prime number that contains a secret backdoor. This research was based on very old attacks from the 90s.

Two research papers ([1], [2]) investigate suspicious Diffie-Hellman parameters in the wild, several of which allow compromising the security of TLS connections. In light of this recent research questions were raised about RFC 5114, which specifies prime numbers for Diffie-Hellman, but doesn’t explain their origin.

Earlier this year David Wong already investigated the possibility to backdoor Diffie-Hellman parameters if a composite number is used instead of a prime.

OCR vulnerability in Comodo’s certificate issuance process

The certificate authority Comodo recently had to report a security vulnerability in their domain validation process. Some top level domain authorities provide the whois data only with a picture of the email address. Comodo used an OCR text recognition software to extract these email addresses. However, the text recognition could result in errors. Thus, it was sometimes possible to receive the domain validation emails by registering a similar looking domain. Two security researchers discovered this and the German news magazine heise.de reported about it.

This is the third security issue in Comodo’s domain validation process in the past months. As we reported in this newsletter last month, due to an error Comodo issued certificates for various top level domains. In our August newsletter we reported that the domain validation emails from Comodo had a script injection flaw.

Apple and Mozilla mistrust WoSign/StartCOM

We wrote in the last month’s issue about the incidents involving the certificate authority WoSign, who misissued certificates in various instances and backdated certificates in a deception attempt. Mozilla has now decided to finally distrust all WoSign certificates, as well as the certificates from StartCom, as they are now owned by WoSign. Earlier this month Apple announced that they will do the same.

WoSign is now owned by the company Qihoo 360. This has caused some debates about the 360 secure browser developed by that company. It allows connections to sites despite certificate validation errors. In light of these issues Mozilla developer Gervase Markham created a list summarizing the behaviour of various browsers in different cases of certificate validation issues.

Short News

• Dutch government entities using email servers now have to implement STARTTLS and DANE for their SMTP servers.
• Vincent Lynch takes a look at TLS certificates used by servers within North Korea.
• An article by the author of this Newsletter for Linux Weekly News and a blog post by Mozilla developer Tim Taubert discuss the issue of TLS Version Intolerance. The TLS working group has recently decided to adopt a new extension-based version negotiation mechanism for TLS 1.3 to avoid the problem of version intolerance.
• Cloudflare now offers dedicated certificate to its customers. Normally Cloudflare groups several domains in one certificate.
• Researchers from the company Cryptosense tested keys from TLS and SSH servers for shared RSA moduli. If two RSA keys have a shared modulus, then an attacker can use this to factorize the keys. One can search for shared moduli at scale with a so-called Batch-GCD algorithm. This was first done in 2012 by two research teams - Arjen Lenstra et al and Nadia Heninger et al.
• Gentoo Linux has removed the SPI certificate and disabled the CAcert.org certificate by default in its ca-certificates package. The SPI certificate was used by Debian Linux for their own infrastructure in the past and CAcert.org is a community-based certificate authority that never managed to gain widespread acceptance.
• Let’s Encrypt introduced support for International Domain Names (IDN).
• Craig Young from Tripwire found several vulnerabilities in MatrixSSL via Fuzzing. An older vulnerability in MatrixSSL discovered by the author of this newsletter still hasn’t been fixed.
• Filippo Valsorda from Cloudflare explains the use of nonce values in TLS.
• Libtomcrypt was vulnerable to a Bleichenbacher signature forgery attack. This was already fixed in 2014, but it wasn’t widely backported back then. Debian published a security advisory about the vulnerability.
• According to statistics from Mozilla, more than 50 percent of page loads from Firefox now use HTTPS.
• Google has strict requirements for the Certificate Transparency logs that are accepted by the Chrome browser. Now one of Google’s own, Aviator log, failed to comply with these requirements and was unable to add certificates to its log in an acceptable speed. The reason was that a large amount of certificates were added to the log in a short time.
• Mozilla announced how they will further proceed with the deprecation of SHA-1-signatures in Firefox.
• The Domain neverssl.com pledges to stay available over insecure HTTP in order to provide a default URL for Wifi captive portals.
• A research paper presented at CCS 2016 formally investigates the security properties of transparency systems like Certificate Transparency and Bitcoin.
• Juraj Somorovsky released a new version of TLS Attacker with a test for the Lucky Thirteen attack.
• An analysis of an older security bug in OpenSSL found by the author of this newsletter via fuzzing led to an improvement of LibFuzzer. Originally this bug was found with the tool American Fuzzy Lop. Although LibFuzzer uses similar strategies it was unable to find this bug in the same way.
• Draft 17 and Draft 18 of TLS 1.3 have been published.
• Google Chrome will soon stop supporting some variants of ECDSA encryptions, including CBC-modes and signatures using SHA1 or SHA512.
• NSS 3.26.2 has been released. It fixes a bug with MD5 signatures.
• Mozilla plans to support the draft version of TLS 1.3 with Firefox 52. Chrome plans to do the same, however no date or version has been announced for that.
• Pornhub announced that they will support HTTPS soon, according to an article in the Washington Post.
• A research paper presents a new method to compress keys for the Supersingular Isogeny Diffie-Hellman key exchange.
• The web hosting provider Squarespace now issues certificates for their customer webpages with Let’s Encrypt.
• The Wordpress hosting service wpengine now supports HTTPS via Let’s Encrypt.
• Researchers from Qihoo 360 reported a denial of service security vulnerability in OpenSSL named SSL Death Alert.
• Newer Chrome versions automatically redirect HTTPS requests to the www version of a domain if the certificate is only valid for that.
• OpenSSL announced that it will soon release version 1.1.1 with support for TLS 1.3.
• Dan Kaminsky published the tool jfe (Jump to Full Encryption) that tries to automatically deploy TLS for all services running on a server.
• Apple’s SecureTransport (used in OS X and iOS) doesn’t validate certificates before checking the OCSP server. This allows an attacker to create a bogus certificate with many OCSP URLs causing unneeded traffic.