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.

A planned EU regulation about so-called Qualified Website Authentication Certificates (QWACs) is causing concerns among security researchers and browser vendors. The QWACs concept has existed for several years, but has not gained much traction.

Today most certificates are so-called Domain Validation (DV) certificates and bind the identity of a host name—like www.google.com—to a cryptographic key. The idea of QWACs is to have further information—most notably, a company name—in a certificate.

QWACs share a very similar concept with Extended Validation (EV) certificates. As most of our readers probably know, in the past, browser vendors used to display a green bar containing a company name in front of a URL for a site using an EV certificate.

But in 2019, the major browser vendors decided to no longer show the green bar and thus no longer give EV certificates any special treatment in the user interface. This was the result of intense discussions around the value of EVs. Most notably, the notion of EV certificates providing any higher security assurance relies on the expectation that users will notice the green bar and will not, for example, enter their credentials on a web page that does not show it. But it has been shown that users usually don’t notice that difference. A research paper published at the 2019 USENIX conference based on user experiments came to the following conclusion: “We find that most metrics of user behavior are unaffected by its removal, providing evidence that the EV indicator adds little value in its current form.”

Further evidence of the limited usefulness of EV indicators came from natural experiments; that is, major sites like Facebook and Twitter have sometimes used EV certificates, and then stopped using them. The change was not widely noted by users, indicating that the idea that EV certificates can prevent phishing does not seem plausible. Some security professionals went as far as arguing that EV certificates provide less security, as their issuance cannot be automated.

Another point of criticism was that people often don’t know the company names of the services they interact with and that company names are not unique. The latter was demonstrated by Ian Carroll, who was able to register an EV certificate for Stripe—but not for the well-known payment provider. It was simply for another company by the same name that he registered himself.

Despite all this controversy around EV certificates, the planned EU regulation, which is an update of the European Identity Framework, could impose requirements on browsers to give QWACs special treatment very similar to EV certificates. Thus the first major point of criticism is that QWACs are simply trying to revive a concept that was widely considered flawed and obsolete by the TLS community. Scott Helme discusses that point in detail in a blog post.

But there is an even more concerning aspect of the QWACs proposal: the certificate authorities that would issue these certificates would be decided by the EU member states, and browsers would be forced to accept those, even if they don’t comply with existing security rules. The EU keeps a list of Trust Service Providers (TSPs) that are eligible for QWACs.

Mozilla writes in a position paper that “the security practices for TSPs that issue QWACs are tangibly weaker than Mozilla’s own Root Program policies.” In 2019, Mozilla had already provided a list of concerns and incidents tied to the security vetting of these Trust Service Providers.

Thus, if implemented, these plans could mean that browsers would be forced to give special treatment to TLS certificates that have been issued by entities held to a lower standard than the other certificate authorities.

We asked the European Commission’s press office for a comment about these concerns, but the office hasn’t replied as of the publication of this newsletter.

Update 28 Feb 2022

We originally mentioned Camerfirma as an example of a CA still trusted for QWACs that was distrusted by browsers. In fact, while Camerfirma is still listed in the Trusted Service Providers list, its status for issuing QWACs has been withdrawn. We apologize for this mistake and have removed the misleading paragraph.

Update 3 Mar 2022

On 3 March 2022 a group of well-known cryptography and TLS researchers addressed the issue in an open letter organized by Mozilla. They warn that the proposal would have the effect of “dramatically weakening web security”.

Short News

• OpenSSL fixed a carry propagation vulnerability (CVE-2021-4160) that affects code on the MIPS platform. Fixes are in versions 1.1.1m and 3.0.1.
• A post to the always interesting blog from Soatok discusses hybrid cryptography in regards to post-quantum algorithms and the use of RSA in a modern environment.
• Domingo Martin created a web page that illustrates the steps of the SHA256 hashing algorithm.
• Mozilla NSS released version 3.75. Most changes affect the implementation of Encrypted ClientHello (ECH).
• Jason Donenfeld continues major work on the Linux random number generator. Entropy extraction now uses the BLAKE2s algorithm and includes some performance improvements. A proposed change could unify /dev/random and /dev/urandom and no longer provide any randomness before the devices are seeded. This is a major change. LWN has an article discussing the details.
• Amazon implemented a QUIC library in Rust called s2n-quic.
• An attack on a cryptocurrency company apparently seems to have involved issuing a TLS certificate via BGP hijacking. This is a well-known weakness of TLS certificate ecosystems. For example, we mentioned a research paper on this topic in a newsletter back in 2018. But this is one of the first instances in which such an attack has been documented in the wild. There has been some follow-up discussion on how to mitigate or prevent such attacks. Possible mitigations include RPKI, CAA with DNSSEC, and possibly account binding or requiring CAs to have multiple verification points.
• Hybrid Public Key Encryption has been standardized as RFC 9180. Benjamin Lipp, one of the coauthors, discusses the technical background of the security analysis in a blog post. Franziskus Kiefer gives an overview of the technology in a blog post.
• Peter Gutmann has written an RFC draft with example cryptographic keys to be used in, for example, software test suites. This was triggered by certificates using OpenSSL example keys, as discovered by the author of this newsletter.
• Chrome has announced a major policy update regarding the use of Certificate Transparency. New certificates are no longer required to provide one SCT by a Google-owned CT log, and certificates with a lifetime of over 180 days will have to provide three SCTs in the future. The update will be implemented in Chrome version 100.
• A draft for an RFC proposes a mechanism for how browsers could indicate to a site that it should not send intermediate certificates. This could reduce the handshake size, which would be particularly valuable for future post-quantum algorithms that come with larger signature sizes.
• Cloudflare has published a series of blog posts around post-quantum cryptography, discussing many of the challenges of implementing TLS with quantum-safe algorithms.
• A research paper published to the Cryptology ePrint Archive shows a new attack against Rainbow, one of the signature schemes in the post-quantum cryptography competition.
• The German cartel office has closed a case around a complaint by a CA against Google. It involved three topics: Google’s removal of special treatment of EV certificates; the distrust of certificate authorities by Google, such as Symantec and Camerfirma; and the reduction of certificate lifetimes. The complaining certificate authority apparently saw these as indications of abuse of a monopoly position. The cartel office indicated that while it followed some of the reasoning by the complaining CA, an obligation for Google could only be based on legal requirements. It specifically mentions the proposed QWACs regulation (see main news item).

Interesting Jobs

Here are some interesting jobs we've come across in the last month:

• Senior Software Engineer (TLS, PKI and Crypto) - Microsoft
• IT Expert, Security Infrastructure - Finanz Informatik (Germany)
• IT Compliance Expert - Finanz Informatik (Germany)

If you know of similar jobs that our readers might be interested in, for example cryptography, TLS, or PKI, let us know and we may add them to future newsletters.