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.

Several events related to certificate reseller Trustico have caused questions to arise about the practice of certificate sellers that generate keys for their users.

Jeremy Rowley from Digicert reported on the Mozilla security policy mailing list that he was asked by Trustico to revoke a large number of former Symantec certificates. Symantec was bought recently by Digicert after browser vendors made plans to distrust existing Symantec certificates. Trustico is a certificate reseller that used to sell Symantec certificates and has switched to Comodo certificates.

Rowley refused to revoke the certificates without signs of a compromise, mentioning that one such sign would be revealing the private keys of those certificates. After that, Trustico provided Rowley with keys for most, but not all, of the certificates he was asked to revoke. Subsequently, the certificates belonging to those private keys were revoked.

As it turned out, Trustico kept a large number of private keys that were used when users bought certificates on its web page. It’s been a common practice of some certificate authorities and resellers to generate keys for their users, though doing so is quite controversial.

It isn’t necessary for a certificate authority to have access to a private key. A safer and established way of creating certificates is that a user generates a private key and a certificate signing request (CSR), but some feel this method is too complicated. Trustico explicitly advertised that they can provide certificates without CSRs.

After these events unfolded, some people checked the Trustico web page for security vulnerabilities, and someone found a trivial script-injection vulnerability that allowed executing commands on the server with root permissions.

Although certificate authorities are required to perform audits and have quite strict rules to follow, there are no such rules for resellers. However, it should be noted that none of these events impacted the security of the ecosystem as such. Resellers like Trustico usually don’t have direct access to certificate-issuance and domain-validation systems and thus cannot issue malicious certificates or compromise keys for anyone but their own customers.

Short News

• TLS 1.3 has been approved by the IETF; a final RFC will probably follow very soon.
• The upcoming finalization of TLS 1.3 has once again started a discussion about intercepting proxies and datacenter visibility. The UK National Cyber Security Centre joined the debate, but with some factually wrong claims, as noted by Adam Langley. In particular, some of the misconceptions about ways to intercept traffic in the previous TLS version, 1.2, were responsible for the deployment issues that delayed TLS 1.3 for several months. The visibility issue was also brought up again at the IETF meeting in London.
• OpenSSL is trying to change its code to the Apache License. They’re now looking for the last contributors that they couldn’t reach yet to get their approval for the license change.
• Facebook introduced a feature that will actively rewrite HTTP links to HTTPS for URLs that either are in the HSTS preload list or set an HSTS header.
• NSS released version 3.36 and replaced its Chacha20 algorithm with a formally verified version from the HACL* project.
• Google explained its final plans to deprecate some Symantec certificates next month and all remaining ones later this year. As we reported last month, there are still many sites that use these certificates that soon will no longer be trusted and that already cause warnings in Firefox Nightly and Chrome Beta versions. Some new data on this topic was provided by the Mozilla TLS Observatory.
• Apple has made some changes to HSTS to try to prevent the abuse of the feature for user tracking.
• Android P will strengthen requirements for TLS traffic in apps, blocking all non-TLS traffic if a developer doesn’t explicitly opt-in for unencrypted traffic.
• An experiment by Mozilla to test DNS over HTTPS caused some controversy. This would mean that DNS queries go to a Mozilla-controlled server over an encrypted channel. From a privacy perspective, this has both upsides and downsides: the traffic itself is encrypted and can’t be read, but a central server—in Mozilla’s case, using Cloudflare—would have access to a lot of user DNS data.
• The ACME specification for automated certificate issuance is in last call and may soon become an IETF RFC.
• The encrypted.google.com subdomain provided an optional way to access the Google search engine via HTTPS. It’s now been deprecated, as the search engine has been accessed via HTTPS by default for a while.
• The author of this newsletter published details about a stack buffer overflow in the WolfSSL library.
• Let’s Encrypt now supports wildcard certificates.
• LibreSSL fixed a vulnerability in certificate validation in version 2.7.1, discovered by Python developer Christian Heimes, who also implemented a workaround in Python itself. It only affected the development version 2.7.0 and the vulnerable code was taken from BoringSSL.
• OpenSSL has fixed two vulnerabilities, a stack exhaustion in the ASN.1 parser and a bug in the HP-UX/RISC assembly code for the CRYPTO_memcmp function.
• Researchers have published a paper analyzing the compliance of certificates in the Certificate Transparency logs with the Baseline Requirements.
• The German Federal Office for Information Security (BSI) has created a study analyzing the crypto libraries LibreSSL, NSS and Botan for a project where they subsequently chose to support the development of Botan. The author of this newsletter was able to get access to that study via the German freedom of information law, but the BSI did not allow making the study public.