The European Commission is a legislative body in the European Union with regulatory authority over digital technology. The EC’s eIDAS Article 45, a proposed regulation, would deliberately weaken areas of internet security that the industry has carefully evolved and hardened for over 25 years. The Article would effectively grant the 27 EU governments vastly expanded surveillance powers over internet use.
The rule would require all internet browsers to trust an additional root certificate from an agency (or a regulated entity) from each of the national governments of each one of the EU member states. For the non-technical readers, I will explain what a root certificate is, how internet trust has evolved, and what Article 45 does to this. And then I will highlight some of the commentary from the tech community on this matter.
The next section of this article will explain how the trust infrastructure of the internet works. This background is necessary in order to understand how radical the proposed Article is. The explanation is intended to be accessible to a non-technical reader.
The regulation in question addresses internet security. Here, “internet” means, largely, browsers visiting web sites. Internet security consists of many distinct aspects. Article 45 intends to modify public key infrastructure (PKI), a part of internet security since the mid-90s. PKI has been at first adopted, and then improved over a 25-year period, to give users and publishers the following assurances:
- Privacy of the conversation between the browser and the website. Browsers and web sites converse over the internet, is a network of networks operated by Internet Service Providers, and tier 1 carriers; or cellular carriers if the device is mobile. The network itself is not inherently safe nor trustworthy. Your nosy home ISP, a traveler in the airport lounge where you are waiting for your flight, or a data vendor looking to sell leads to advertisers might want to spy on you. Without any protection, a bad actor could view confidential data such as a password, credit card balance, or health information.
- Guarantee that you view the page exactly the way the web site sent it to you. When you view a web page, could it have been tampered with between the publisher and your browser? A censor might want to remove content that they don’t want you to see. Content labeled as “misinformation” was widely suppressed during covid hysteria. A hacker who had stolen your credit card might want to remove evidence of their fraudulent charges.
- Guarantee that the website you see is really the one in the browser’s location bar. When you connect to a bank how do you know that you are seeing the web site of that bank, not a fake version that looks identical? You check the location bar in your browser. Could your browser be tricked into showing you a fake website that appears identical to the real one? How does your browser know—for sure—that it is connected to the correct site?
In the early days of the internet, none of these assurances existed. In 2010, a browser plugin available in the add-on store enabled the user to participate in someone else’s Facebook group chat in a cafe hotspot. Now, thanks to PKI, you can be pretty sure of these things.
These security features are protected with a system based on digital certificates. Digital certificates are a form of ID—the internet version of a drivers’ license. When a browser connects to a site, the site presents a certificate to the browser. The certificate contains a cryptographic key. The browser and the website work together with a series of cryptographic calculations to set up secure communication.
Together, the browser and the website provide the three security guarantees:
- Privacy, by encrypting the conversation
- Cryptographic digital signatures, to ensure that the content is not modified in flight.
- Verification of the publisher through the chain of trust provided by PKI, that I will explain in more detail below.
A good identity should be difficult to counterfeit. In the ancient world, a wax casting of a seal served this purpose. Identities for humans have relied on biometrics. Your face is one of the oldest forms. In the non-digital world, when you need to access an age-restricted setting, such as ordering an alcoholic beverage, you will be asked for a photo ID. Another biometric from before the digital era was to match your fresh pen-and-ink signature against your original signature on the back of your ID. As these older types of biometrics become easier to counterfeit, human identity verification has adapted. Now, it is common for a bank to send you a validation code on your mobile. The app requires you to pass a biometric identity check on your mobile phone to view the code such as face recognition or your fingerprint.
In addition to a biometric, the second factor that makes an ID trustworthy is the issuer. IDs that are widely accepted depend on the ability of the issuer to verify that the person applying for an ID is who they say they are. Most of the more widely accepted forms of ID are issued by government agencies, such as the Department of Motor Vehicles. If the issuing agency has reliable means to track who and where its subjects are, such as tax payments, employment records, or the use of water utility services, then there is a good chance the agency can verify that the person named on the ID is that person.
In the online world, governments have, for the most part, not involved themselves in identity verification. Certificates are issued by private sector firms known as certificate authorities (CAs). While certificates used to be quite expensive, fees have come down considerably to the point where some are free. The best known CAs are Verisign, DigiCert and GoDaddy. Ryan Hurst shows the seven major CAs (ISRG, DigiCert, Sectigo, Google, GoDaddy, Microsoft, and IdenTrust) issue 99% of all certificates.
The browser will accept a certificate as proof of identity only if the name field on the certificate matches the domain name, which the browser shows in the location bar. Even if the names match, does that prove that a certificate saying “apple.com” belongs to the consumer electronics business known as Apple, Inc.? No. Identity systems are not bulletproof. Underage drinkers can get fake IDs. Like human IDs, digital certificates can also be fake, or invalid for other reasons. A software engineer using free open source tools can create a digital certificate named “apple.com” with a few Linux commands.
The PKI system relies on CAs to issue any certificate only to the owner of the web site. The workflow to acquire a certificate goes like this:
- The publisher of a website applies to their preferred CA for a certificate, for a domain.
- The CA verifies that the certificate request comes from the actual owner of that site. How does the CA establish this? The CA demands that the entity making the request publish a specific piece of content on a specific URL. The ability to do this proves that the entity has control over the website.
- Once the website has proven ownership of the domain, the CA appends a cryptographic digital signature to the certificate usings its own private cryptographic key. The signature identifies the CA as the issuer.
- The signed certificate is conveyed to the person or entity making the request.
- The publisher installs their certificate on their website, so it may be presented to browsers.
Cryptographic digital signatures are “ a mathematical scheme for verifying the authenticity of digital messages or documents.” They are not the same thing as the online document signing provided by DocuSign and similar vendors. If the signature could be forged, then the certificates would not be trustworthy. Over time the size of the cryptographic keys has increased with the aim of making forgery more difficult. Cryptography researchers believe that current signatures, in practical terms, are impossible to forge. Another vulnerability is when CA has its secret keys stolen. The thief could then produce valid signatures of that CA.
Once the certificate has been installed, then it is used during the set-up of a web conversation. The Register explains how that goes:
If the certificate was issued by a known good CA, and all the details are correct, then the site is trusted, and the browser will try to establish a secure, encrypted connection with the website so that your activity with the site isn’t visible to an eavesdropper on the network. If the cert was issued by a non-trusted CA, or the certificate doesn’t match the website’s address, or some details are wrong, the browser will reject the website out of a concern that it’s not connecting to the actual website the user wants, and may be talking to an impersonator.
We can trust the browser because the browser trusts the website. The browser trusts the website because the certificate was issued by a “known good” CA. But what is a “known good CA?” Most browsers rely on the CAs provided by the operating system. The list of trustworthy CAs is decided by device and software vendors. The major computer and device vendors—MicroSoft, Apple, Android phone manufacturers, and the open source Linux distributors—preload the operating system on their devices with a set of root certificates. These certificates identify the CAs they have vetted and consider to be reliable. This collection of root certificates is called the “trust store.” To take an example close to me, the Windows PC that I am using to write this piece has 70 root certificates in its Trusted Root Certificate Store. Apple’s support site lists all of the roots trusted by the Sierra version of MacOS.
How do the computer and phone vendors decide which CAs are trustworthy? They have audit and compliance programs to evaluate the quality of CAs. Only the ones that pass are included. See for example, the Chrome browser (which provides its own trust store rather than using the one on the device). The EFF (which describes itself as “the leading nonprofit organization defending civil liberties in the digital world”) explains:
Browsers operate “root programs” to monitor the security and trustworthiness of CAs they trust. Those root programs impose a number of requirements varying from “how must key material be secured” to “how must validation of domain name control be performed” to “what algorithms must be used for certificate signing.”
After a CA has been accepted by a vendor, the vendor continues to monitor it. Vendors will remove CAs from the trust store should the CA fail to uphold the necessary security standards. Certificate authorities can, and do, go rogue, or fail for other reasons. The Register reports:
Certificates and the CAs that issue them are not always trustworthy and browser makers over the years have removed CA root certificates from CAs based in Turkey, France, China, Kazakhstan, and elsewhere when the issuing entity or an associated party was found to be intercepting web traffic.
In 2022, researcher Ian Carroll reported Security concerns with the e-Tugra certificate authority. Carroll “found a number of alarming issues that worry me as to the security practices inside their company,” such as weak credentials. Carroll’s reports were verified by the major software vendors. As a result, e-Tugra was removed from their trusted certificate stores.
The Timeline of Certificate Authority Failures tells of other such incidents.
There are still some known holes in PKI as it currently exists. Because one particular issue is important to an understanding of eIDAS Article 45, I will explain that next. A CA’s trust is not scoped to those websites that conduct their business with that CA. A browser will accept a certificate from any trusted CA for any website. There is nothing preventing the CA from issuing a website to a bad actor that was not requested by the owner of the site. Such a certificate would be fraudulent in the legal sense because of who it was issued to. But the contents of the certificate would be technically valid from the browser’s viewpoint.
If there was a way to associate each website with its preferred CA, then any certificate for that site from any other CA would be immediately recognized as fraudulent. Certificate pinning is another standard that takes a step in this direction. But how would that association be published and how would that publisher be trusted?
At each layer of this process, the technical solution relies on an external source of trust. But how is that trust established? By relying on an even more trusted source on the next higher plane? This question illustrates the “turtles, all the way down” nature of the problem. PKI does have a turtle at the bottom: the reputation, visibility, and transparency of the security industry and its customers. Trust is built at this level through constant monitoring, open standards, the software developers, and the CAs.
Fraudulent certificates have been issued. In 2013, ArsTechnica reported French agency caught minting SSL certificates impersonating Google:
In 2011…security researchers spotted a bogus certificate for Google.com that gave attackers the ability to impersonate the website’s mail service and other offerings. The counterfeit certificate was minted after attackers pierced the security of Netherlands-based DigiNotar and gained control of its certificate-issuing systems.
The secure sockets layer (SSL) credentials were digitally signed by a valid certificate authority…In fact, the certificates were unauthorized duplicates that were issued in violation of rules established by browser manufacturers and certificate authority services.
Fraudulent certificate issuance can happen. A rogue CA issue one, but they won’t get far. The bad certificate will be detected. The bad CA will fail compliance programs and be removed from trust stores. Without acceptance, the CA will go out of business. Certificate Transparency, a more recent standard, enables more rapid detection of fraudulent certificates.
Why would a CA go rogue? What advantage can the bad guy gain from an unauthorized certificate? With the certificate alone, not much, even when signed by a trusted CA. But if the bad guy can team up with an ISP, or or otherwise access the network that the browser uses, the certificate gives the bad actor the ability to break all of PKI’s security guarantees.
The hacker could mount a man-in-the-middle attack (MITM) on the conversation. The attacker could insert himself in between the browser and the real website. In this scenario, the user would be talking directly to the attacker, and the attacker would relay the contents back and forth with the real website. The attacker would present the fraudulent certificate to the browser. Because it was signed by a trusted CA, the browser would accept it. The attacker could view and even modify what either party sent before the other side received it.
Now we come to the European Union’s sinister eIDAS, Article 45. This proposed regulation requires all browsers to trust a basket of certificates from CAs designated by the EU. Twenty-seven to be exact: one for each member nation. These certificates are to be called Qualified Website Authentication Certificates. The acronym “QWAC” has an unfortunate homophone to quackery—or perhaps the EC is trolling us.
The QWACs would be issued either by either government agencies, or what Michael Rectenwald calls governmentalities; “corporations and companies and other adjuncts of the state who are otherwise called ‘private,’ but really are operating as state apparatuses, in that they’re enforcing state narratives and dictates.”
This scheme would bring EU member governments one step closer to the point where they could man-in-the-middle attack against their own citizens. They would also need to access the networks. Governments are in a position to do that. If the ISP is run as a state-owned enterprise, then they would already have it. If ISPs are private firms, then local authorities could use police powers to gain access.
One point which has not been emphasized in the public conversation is that a browsers in any of the 27 EU member nations would be required to accept every single QWAC, one from each l EU member. This means that a browser in, for example, Spain, would have to trust a QWAC from entities in Croatia, Finland, and Austria. The Spanish user visiting an Austrian website would have to transit over Austrian portions of the internet. The issues raised above would all apply across countries within the EU.
The Register, in a piece titled “Bad eIDAS: Europe ready to intercept, spy on your encrypted HTTPS connections” explains one way this might work:
…that government can ask its friendly CA for a copy of [the QWAC] certificate so that the government can impersonate the website – or ask for some other certificate browsers will trust and accept for the site. Thus, using a man-in-the-middle attack, that government can intercept and decrypt the encrypted HTTPS traffic between the website and its users, allowing the regime to monitor exactly what people are doing with that site at any time.
Having penetrated the shield of encryption, monitoring could include saving users’ passwords, and then using them at another time to access citizens’ email accounts. In addition to monitoring, governments could modify content inline. For example, they could remove the narratives they want to censor. They could attach annoying nanny state fact checks and content warnings to dissenting opinions.
As things currently stand, CAs must maintain the trust of the browser community. Browsers currently warn the user if a site presents an expired or otherwise untrusted certificate. Under Article 45, warnings or the ejection of trust abusers would be forbidden. Not only are browsers mandated to trust the QWACs, but Article 45 prohibits browsers from showing a warning that a certificate signed by a QWAC.
Last Chance for eIDAS (a website displaying the Mozilla logo) advocates against Article 45:
Any EU member state has the ability to designate cryptographic keys for distribution in web browsers and browsers are forbidden from revoking trust in these keys without government permission.
…There is no independent check or balance on the decisions made by member states with respect to the keys they authorize and the use they put them to. This is particularly troubling given that adherence to the rule of law has not been uniform across all member states, with documented instances of coercion by secret police for political purposes.
Article 45 also bans security checks on EU web certificates unless expressly permitted by regulation when establishing encrypted web traffic connections. Instead of specifying a set of minimum security measures which must be enforced as a baseline, it effectively specifies an upper bound on the security measures which cannot be improved upon without the permission of ETSI. This runs counter to well established global norms where new cybersecurity technologies are developed and deployed in response to fast moving developments in technology.
Most of us rely on our vendors to curate the list of trusted CAs. However, as a user, you may add or remove certificates as you please on your own devices. Microsoft Windows has a tool to do this. On Linux, the root certificates are files located in a single directory. A CA may be untrusted simply by deleting the file. Will this also be forbidden? Steve Gibson, noted security pundit, columnist, and host of the long-running Security Now podcast asks:
But the EU is stating that browsers will be required to honor these new, unproven and untested certificate authorities and thus any certificates they issue, without exception and without recourse. Does that mean that my instance of Firefox will be legally bound to refuse my attempt to remove those certificates?
Gibson notes that some corporations implement similar surveillance of their employees within their own private network. Whatever your opinion about those working conditions, some industries have legitimate audit and compliance reasons to track and record what their employees are doing with company resources. But, as Gibson continues:
The trouble is that the EU and its member nations are very different from the employees of a private organization. Any time an employee doesn’t want to be spied upon, they can use their own smartphone to circumvent their employer’s network. And of course an employer’s private network is just that, a private network. The EU wants to do this for the entire public Internet from which there would be no escape.
Now we have established the radical nature of this proposal. It is time to ask, what reasons does the EC offer to motivate this change? The EC says that identity verification under PKI is not adequate. And that these changes are needed to improve it.
Is there any truth to the EC’s claims? Current PKI in most cases only requires the request to prove control of the website. While that is something, it does not guarantee, for example, that the web property “apple.com” is owned by the consumer electronics company known as Apple Inc, headquartered in Cupertino, California. A malicious user might obtain a valid certificate for a domain similar name to that of a well-known business. The valid certificate could be used in an attack that relied on some users not looking hard enough to notice that the name does not quite match. This happened to payment processor Stripe.
For publishers who would like to prove to the world that they are truly the same corporate entity, some CAs have offered Extended Validation (EV) Certificates. The “extended” part consists of additional validations against the business itself, such as the business address, a working phone number, a business license or incorporation, and other attributes typical of a going concern. EVs are listed at a higher price point because they require more work by the CA.
Browsers used to show highlighted visual feedback for an EV, such as a different color or a more sturdy lock icon. In recent years, EVs have not been particularly popular in the marketplace. They have mostly died off. Many browsers no longer show the differential feedback.
In spite of the weaknesses that still exist, PKI has improved markedly over time. As flaws have become understood, they have been addressed. Cryptographic algorithms have been strengthened, governance has improved, and vulnerabilities have been blocked. Governance by a consensus of industry players has worked quite well. The system will continue to evolve, both technologically and institutionally. Other than meddling by regulators, there is no reason to expect otherwise.
We have learned from the lackluster history of EVs that the marketplace does not care so much about corporate identity verification. However, if internet users did want that, it would not require breaking existing PKI to give it to them. Some small tweaks to existing workflows would suffice. Some commenters have proposed modifying the TLS handshake; the website would present one additional certificate. The primary certificate would work as it does now. The secondary certificate, signed by a QWAC, would implement the additional identity standards that the EC says it wants.
The EC’s purported reasons for eIDAS are simply not credible. Not only are the reasons given implausible, the EC does not even bother with the usual sanctimonious whining about how we must sacrifice important freedoms in the name of safety because we face the grave threat of [pick one] human trafficking, child safety, money laundering, tax evasion, or (my personal favorite) climate change. There is no denying that the EU is gaslighting us.
If the EC is not honest about their true motives, then what are they after? Gibson sees a nefarious intent:
And there’s only one possible reason for them wanting [to enforce browsers to trust QWACs], which is to allow for on-the-fly Internet web traffic interception, exactly as happens inside of corporations. And that’s acknowledged.
(What Gibson means by “web traffic interception” is the MITM attack described above.)
Other commentary has highlighted the sinister implications for free speech and political protest. Ryan Hurst in a long-form essay makes a slippery slope argument:
When a liberal democracy establishes this kind of control over technology on the web, despite its consequences, it lays the groundwork for more authoritarian governments to follow suit with impunity.
Mozilla, quoted in techdirt (with no link to the original), says more or less the same:
…forcing browsers to automatically trust government-backed certificate authorities is a key tactic used by authoritarian regimes, and these actors would be emboldened by the legitimising effect of the EU’s actions…
Gibson makes a similar observation:
And then there’s the very real specter of what other doors this opens: If the EU shows the rest of the world that it can successfully dictate the terms of trust for the independent web browsers used by its citizens, what other countries will follow with similar laws? Now everyone gets to simply require that their own country’s certificates get added. This takes us in exactly the wrong direction.
This proposed Article 45 is an attack on user privacy in the EU nations. If adopted, it would be a massive setback not only in internet security, but in the evolved system of governance. I agree with Steve Gibson that:
What’s completely unclear, and what I haven’t encountered anywhere, is an explanation of the authority by which the EU imagines it’s able to dictate the design of other organization’s software. Because that’s what this comes down to.
Response to the proposed Article 45 has been massively negative. The EFF in “Article 45 Will Roll Back Web Security by 12 Years” writes, “This is a catastrophe for the privacy of everyone who uses the internet, but particularly for those who use the internet in the EU.”
The eIDAS effort is a four-alarm fire for the security community. Mozilla—maker of the open source Firefox web browser—posted an Industry Joint Statement opposing it. The statement is signed by an all-star roster of internet infrastructure companies including Mozilla itself, Cloudflare, Fastly, and the Linux Foundation.
From the the open letter mentioned above:
After reading the near-final text, we are deeply concerned by the proposed text for Article 45. The current proposal radically expands the ability of governments to surveil both their own citizens and residents across the EU by providing them with the technical means to intercept encrypted web traffic, as well as undermining the existing oversight mechanisms relied on by European citizens.
Where does this go? The regulation has been proposed for some time. A final decision was scheduled for November 2023. Web searches show no new information on this topic since that time.
In these past few years, outright censorship in all its forms has increased. During the COVID lunacy, government and industry partnered to create a censorship-industrial complex to more efficiently promote false narratives and suppress dissidents. In these past few years, skeptics and independent voices have fought back, in courts, and by creating viewpoint-neutral platforms.
While censorship of speech continues to be a great danger, the rights of writers and journalists are better protected than many other rights. In the United States, the First Amendment has an explicit protection of speech and the freedom to criticize the government. Courts may be of the opinion that any rights or freedoms not protected by highly specific statutory language is fair game. This may be the reason that the resistance has had more success on speech than other efforts to stop other abuses of power such as quarantines and population lockdowns.
Rather than a well-defended foe, governments are shifting their attacks to other layers of the internet infrastructure. These services, such as domain registration, DNS, certificates, payment processors, hosting, and app stores consist largely of private marketplace transactions. These services are much less well protected than speech because there is, for the most part, no right for anyone to purchase a specific service from a particular business. And the more technical services such as DNS and PKI are less well understood by the public than web publishing.
The PKI system is particularly vulnerable to attack because it works by reputation and consensus. There is no single authority that rules the entire system. The players must earn a reputation through transparency, compliance, and honest reporting of failures. And that makes it vulnerable to this type of disruptive attack. If EU PKI falls to the regulators, I expect other countries to follow. Not only is PKI at risk. Once proven that other layers of the stack can be attacked by regulators, they will be targeted as well.