Looking back at 2021

In 2021, HTTPS was everywhere and use of the TLS 1.3 protocol continued to grow. With this growth, we continue to see the industry evolve − the Certificate Authority Security Council (CASC) was reborn as the PKI Consortium; there are new certificate transparency (CT) policies; a certificate authority (CA) was distrusted, and an Application Layer Protocols Allowing Cross-Protocol Attacks (ALPACA) TLS vulnerability was announced. Let’s look back at the key changes that have progressed us to this point…

HTTPS Everywhere

Last autumn, the Electronic Frontier Foundation, or EFF, announced the deprecation of their HTTPS Everywhere browser extension. This comes as no surprise as the now 10-year-old extension was always expected to become redundant someday. Over the past several years, HTTPS traffic increased to over 90 percent due to browser site security feedback, certificate transparency, and free auto-generated Domain Validated (DV) certificates. Additionally, Chrome and Firefox now default to HTTPS, and since the Chromium project covers the Microsoft Edge, Vivaldi, Brave, and Opera, most browsing traffic is secure. Apple/Safari 15 will switch from HTTP to HTTPS, when HTTPS is available.

TLS/SSL protocol version support

The growth of TLS 1.3 is flattening out, but it has made tremendous progress since the RC release in August 2018. The good news is that SSL 3.0 and TLS 1.0/1.1 are essentially non-existent. And, as the internet grows, most new servers now support TLS 1.3.

TLS/SSL Protocol Version Percentage
SSL 3.0 0.00
TLS 1.0 0.05
TLS 1.1 0.00
TLS 1.2 27.90
TLS 1.3 72.05

From Netcraft survey provided at end of December 2021


CA/Browser Forum

The Server Working Group of the CA/Browser Forum approved some ballots that will impact subscribers and CAs.

Certificate transparency

In February 2021, Google announced their 2021 Chrome certificate transparency (CT) plans, which included removal of the “One Google Log” policy as this will be possible with the deployment of signed certificate timestamp (SCT) auditing in Chrome. It’s worth noting that it does not appear this has happened as the CT policy states “At least one SCT from a Google CT Log that was Qualified, Usable, or ReadOnly at the time of check.” Also included are dynamically updatable CT log lists to Chrome clients, which will bring CT enforcement to Android.

In March, Apple updated their CT policy with three important changes: They defined a day as 86,400 seconds; increased the SCTs required for certificates valid for more than 180 days, and required CT log operator diversity – SCTs must now come from two different entities.

The two different CT policies have created issues where some CAs were not compliant to both policies. The hope is that these policies will align in the future.

Public Key Infrastructure Consortium

The Certificate Authority Security Council (CASC) has faded away but has been reimagined as the PKI Consortium (PKIC). The PKIC has a broader mission: to advance trust in assets and communication for everyone and everything using PKI. The goal is to improve, create, and collaborate on generic, industry, or use-case specific policies, procedures, best practices, standards, and tools. The PKIC already has quite a few diverse members to help advance this mission.

Camerfirma roots distrusted

Due to compliance issues and incident reports, Mozilla collected a list of issues with Camerfirma roots and subordinate CAs. The issues were discussed with the Mozilla security policy group. Through discussion one participant summarized, “This is clearly a portrait of a CA that, like those that came before, paint a pattern of a CA that consistently and regularly fails to meet program requirements, in a way that clearly demonstrates these are systemic and architectural issues.” Google Chrome and Mozilla Firefox have distrusted the Camerfirma roots for TLS.

ALPACA Vulnerability

ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using wildcard certificates or multi-domain TLS certificates. Man-in-the-Middle (MitM) attackers could redirect traffic from one subdomain to another, which would result in a valid TLS session. The result is the authentication of TLS is broken and cross-protocol attacks are possible. The NSA has provided a paper, Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique, to help mitigate the vulnerability.

To 2022 and beyond

With all of these advances made, what will 2022 bring the TLS/SSL ecosystem? The CA/Browser Forum Server Certificate Working Group is working on updating the SSL certificate profiles. This shouldn’t result in many technical changes for most deployments but will limit the options that CAs can provide to certificate subscribers. Below are a few other items that we hope to see more progress on in 2022.

Delegated credentials for TLS

In 2021, we talked about delegated credentials, which have been proposed per delegated credential IETF RFC. The delegated credential mechanism allows a server operator to use the private key from their server to issue a delegated credential. The new credential will have a different private key and a validity period of no greater than seven days. Since the delegated credential is only valid for a short period of time, there is no status protocol required to be checked, that is, no CRL or OCSP response. It will be interesting to see if the RFC gets finalized in 2022.

Exported Authenticators in TLS

Exported Authenticators is a proposed new extension to TLS. It will unlock new authentication possibilities, from TLS connections with multiple certificates attached, to logging in to a website without ever revealing your password. It can allow application layer authentication that’s as strong as the TLS authentication and tie it to the TLS channel. This new TLS mechanism will also allow for peers to provide a proof of ownership of an identity, such as a certificate. The proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer.


The Internet Security Research Group (ISRG) Prossimo project is creating Rustls, which is an alternative to OpenSSL and similar TLS/SSL libraries. The code is written mostly using the Rust programming language, so it is largely memory-safe without sacrificing performance. Rustls is being improved for wider adoption and we hope to see more deployments in the coming years.

There you have it – a brief look at a very active year in the TLS/SSL ecosystem. Find out more about how Entrust can help you manage your TLS/SSL environment here.