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.

Mozilla no longer trusts WoSign and StartCOM

The certificate authority WoSign came under fire for various security incidents. Gervase Markham from Mozilla started the debate with an email to Mozilla’s security policy mailing list. Someone was able to generate a certificate for github.io by controlling a subdomain. For some time it was possible to generate certificates by controlling unprivileged port numbers.

In a third incident it was possible to generate SHA-1-signed certificates, which happened through the certificate issuance system from StartCom, indicating that the two companies share parts of their infrastructure. It later turned out that Wosign had backdated several certificates in order to circumvent the SHA-1 ban starting January this year.

During the debate several further issues came up and a former employee of StartCom claimed that WoSign is now the sole owner of StartCom. This was later confirmed by investigations from Mozilla.

Mozilla now proposes that new certificates from WoSign and StartCOM should no longer be trusted in their browser. They could reapply for browser inclusion in a year under certain conditions. Existing certificates would still be trusted. This would theoretically allow WoSign to create backdated certificates, however Mozilla announced that if they saw any evidence of this they would immediately distrust all Wosign/StartCOM certificates.

Comodo issued certificate for top level domains sb and tc

Comodo issued a certificate for the top level domain sb to a user who owns the domain www.sb. Top level domains are not supposed to have TLS certificates. This was due to a bug where control over the www subdomain indicated ownership of the upper domain.

According to an incident report sent to Mozilla’s policy mailing list, Comodo had known about this bug for several weeks. A certificate for the top level domain tc had already been issued due to the same bug. "Since 'www.tc' and 'tc' both belong to the same entity, we took the view that the cert had not been misissued and that an incident report was not warranted. We also took the view that this flaw did not require an urgent hotfix”, Comodo wrote in the incident report.

It seems that Comodo had issued similar certificates in the past for other top level domains. The certificate transparency logs contain a certificate for re that expired in 2015.

OpenSSL Security Update

OpenSSL released fixes for several security bugs. The most severe bug affected the OCSP handling and allowed crashing affected servers. The bug was discovered by the company Qihoo 360. They even created a logo for it!

Shortly after that security update OpenSSL released another security advisory. Two of the bug fixes had introduced other security bugs. In OpenSSL 1.1.0 a use after free bug was introduced.

Chrome stricter on enforcing HTTPS from January 2017

For quite some time Google had been announcing that in the future Chrome would mark HTTP connections as insecure. However until recently this was an announcement without any date attached to it. Now Google got a bit more precise about when it will implement the first steps.

In January 2017 the new Chrome version will mark as insecure those sites that are unencrypted and have a form with a password or credit card field in them.

Short news

• The iTunes Podcast service now allows feeds over HTTPS. However, for reasons that are not clear, Apple only accepts a very small list of certificate authorities for this and none of the free certificate authorities are among them.
• The tool sslyze can find configuration errors and vulnerabilities in TLS server configurations. The development had been stalled for a while, but several new versions have been released recently.
• The company bitfire published cert4android, a library to handle certificates on android systems, under the GPLv3 license.
• The malware exploiting the Trident vulnerabilities on Apple’s iOS used a self-signed certificate that has some unusual properties.
• A vulnerability in the validation of OCSP responses has been found in GnuTLS. It is fixed in the versions 3.4.15 and 3.5.4.
• An analysis of cryptography based on supersingular isogenies has identified several potential attacks. Countermeasures are possible, but have high performance costs. Supersingular isogenies over elliptic curves are considered as one option to build post-quantum cryptosystems.
• PGP keyservers can be accessed with a TLS-protected connection through the HKPS protocol. PGP keyservers are usually accessed with a DNS round robin, therefore all of them need a certificate valid for the same domain name. This doesn’t fit into the classical model of certificate authorities, so PGP keyservers have their own certificate authority and use certificates issued by it. This was explained by Kristian Fiskerstrand during the OpenPGP.conf in Cologne.
• Dennis Detering has identified a Bleichenbacher vulnerability in the RSA encryption operation of jwcrypto, a JSON encryption library. Although such vulnerabilities are very common, the JSON Web Encryption (JWE) standard uses the old PKCS #1 1.5 RSA encryption and not the newer and more robust OAEP mode.
• Apple announced deprecation plans for RC4 and SSL version 3. However, there have been reports that these changes have not yet been implemented as announced.
• The company SEC Consult released an update on an analysis of shared keys in embedded devices. The problem is apparently growing - compared to a previous analysis done in November 2015, the number of affected devices grew by 40 percent. One certificate that was used in 49,000 devices from Aruba/Alcatel-Lucent was actually signed by a real certificate authority and Aruba at first refused to revoke it.
• Oracle has updated the roadmap for future crypto support in Java.
• Alexander Færøy published an implementation of SPHINCS in Erlang. SPHINCS is a hash-based post-quantum signature scheme.
• OpenSSL will soon disable insecure downloads over FTP and recommends that everyone uses HTTPS for downloads.
• A Bleichenbacher RSA signature forgery vulnerability was discovered and fixed in libtomcrypt. An old bug in the Mozilla bug tracker indicates that this had been known for many years, but libtomcrypt hadn’t reacted.
• Samsung and Sony created FIPS-validated versions of BoringSSL.
• Xt_sslpin is a module for iptables that allows filtering of network traffic based on TLS certificate pins.
• Apple will use HTTPS to deliver updates for iOS 10.
• Michael Horowitz investigates the TLS settings for various Apple domains. He criticizes Apple for not using forward secrecy for several important services involving Apple ID.
• SSLMate explains why the Chrome browser shows a warning for some extended validation certificates issued by Symantec. Symantec used a redaction feature of the Certificate Transparency system that allows masking parts of the domain name. Some banks seem to have bought such redacted domains. However, the redaction feature is not finalized and Google had some major reservations about it in its current form.
• The code hosting webpage Savannah, the main code repository for the GNU project, is not using HTTPS by default. It also doesn’t provide any option to check out Git repositories over a secure channel. This was pointed out by the author of this newsletter. The Free Software Foundation has guidelines for ethical code hosting which require to “support HTTPS properly and securely”. Despite the problems with Savannah it is currently still listed on the GNU webpage as the only code hosting repository with an A rating.
• Connections to sites using Cloudflare can now use the draft version of TLS 1.3. In a detailed blog post and a talk Cloudflare developer Filippo Valsorda explained the major changes in TLS 1.3.
• Cloudflare will enable Opportunistic Encryption for HTTP connections. This allows upgrading HTTP connections to use TLS without having to switch to real HTTPS with regards to mixed content. This led to a longer debate on twitter where Google developer Ryan Sleevi was very critical of Opportunistic Encryption.
• By rewriting references to HTTP resources that are also available over HTTPS, Cloudflare is trying to make a full switch to HTTPS easier. Ingvar Stepanyan explains the technical details in a blog post.
• The OpenSSL module for Ruby had a GCM nonce reuse bugs. If the GCM cipher is used with the same nonce value and key for multiple encryption, this compromises the security of this cipher mode. The author of this newsletter and other researchers had previously published a paper about this issue.
• Let’s Encrypt published an overview of their financial costs.
• Several TLS features rely on an accurate system time. However, the time is usually set through NTP, which is an insecure protocol. This has enabled attacks in the past, for example against HSTS. Google developer Adam Langley has now published the new time setting protocol roughtime that relies on multiple time sources and creates cryptographic proofs if one of those sources misbehaves.
• Vincent Lynch gives an overview of the changes in the certificate root store of Mac OS Sierra and iOS 10.
• Dingo is a DNS server using Google’s DNS-over-HTTPS service. This offers a way to encrypt DNS queries. It’s written in Go and licensed under the GPL version 3.
• Markus Vervier and Jean-Philippe Aumasson discovered two integer overflows in the Android Signal code. One of them allows attaching partially attacker-controlled content to transferred files by exploiting properties of the CBC mode. Signal 3.19.0 fixes these bugs.
• David Wong published a document summarizing various mistakes that can happen when validating X.509 certificates.
• Windows 10 seems to contain an undocumented certificate pinning feature that has system-wide pins for certain high-value Microsoft domains.
• Firefox 49 changed the password storage’s behavior regarding HTTPS. If a password is saved for an HTTP version of a webpage, Firefox will now also use it if the webpage switches to HTTPS.
• Google developer David Benjamin published a draft for GREASE (Generate Random Extensions And Sustain Extensibility). It’s a mechanism designed to spot faulty TLS implementations and improve the ecosystem’s quality. The idea is to reserve unused values for cipher suites, extensions and other features that can randomly be sent in order to make sure that TLS implementations ignore values they don’t support.
• The version negotiation mechanism will probably be redesigned to use an extension based on a proposal by Google developer David Benjamin. This is in response to continuing problems with version intolerance, which we covered in detail in July Newsletter. With this change the GREASE mechanism can also be used for the version negotiation.
• A representative from BITS, part of the industry group Financial Services Roundtable (FSR), has raised concerns about the removal of the RSA key exchange in TLS 1.3. This would make it harder for financial companies to monitor encrypted connections. However the request was rejected by many members of the TLS working group. The RSA handshake was removed in the early stages of TLS 1.3, because it doesn’t provide forward secrecy and it is vulnerable to Bleichenbacher attacks.
• The German IT news webpage Heise now supports HTTPS.
• Several people have debated the risks and problems associated with HTTP Public Key Pinning (HPKP) lately. A talk at Def Con had introduced the idea of malicious uses of HPKP, most notably one scenario called RansomPKP. Scott Helme blogged about this and Ivan Ristić asked whether HPKP is dead.