Sebcurity on Nostr: # [Article 45 Will Roll Back Web Security by 12 ...
# [Article 45 Will Roll Back Web Security by 12 Years](https://www.eff.org/deeplinks/2023/11/article-45-will-roll-back-web-security-12-years)
DEEPLINKS BLOG
By Jacob Hoffman-Andrews
November 7, 2023
---
The EU is poised to [pass a sweeping new regulation](https://last-chance-for-eidas.org/), eIDAS 2.0. Buried deep in the text is Article 45, which returns us to the dark ages of 2011, when certificate authorities (CAs) could collaborate with governments to spy on encrypted traffic—and get away with it. Article 45 forbids browsers from enforcing modern security requirements on certain CAs without the approval of an EU member government. Which CAs? Specifically the CAs that were appointed by the government, which in some cases will be owned or operated by that selfsame government. That means cryptographic keys under one government’s control could be used to intercept HTTPS communication throughout the EU and beyond.
This is a catastrophe for the privacy of everyone who uses the internet, but particularly for those who use the internet in the EU. Browser makers have not announced their plans yet, but it seems inevitable that they will have to create two versions of their software: one for the EU, with security checks removed, and another for the rest of the world, with security checks intact. We’ve been down this road before, when export controls on cryptography meant browsers were released in two versions: strong cryptography for US users, and weak cryptography for everyone else. It was a fundamentally inequitable situation and the knock-on effects set back web security by decades.
The current text of Article 45 requires that browsers trust CAs appointed by governments, and [prohibits browsers from enforcing any security requirements](https://blog.mozilla.org/netpolicy/files/2023/11/eIDAS-Industry-Letter-updated.pdf) on those CAs beyond what is approved by [ETSI](https://en.wikipedia.org/wiki/ETSI).
In other words, it sets an upper bar on how much security browsers can require of CAs, rather than setting a lower bar. That in turn limits how vigorously browsers can compete with each other on improving security for their users.
This upper bar on security may even ban browsers from enforcing [Certificate Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency), an IETF technical standard that ensures a CA’s issuing history can be examined by the public in order to detect malfeasance. Banning CT enforcement makes it much more likely for government spying to go undetected.
Why is this such a big deal? The role of a CA is to bootstrap encrypted [HTTPS](https://www.eff.org/encrypt-the-web) communication with websites by issuing certificates. The CA’s core responsibility is to match web site names with customers, so that the operator of a website can get a valid certificate for that website, but no one else can. If someone else gets a certificate for that website, they can use it to intercept encrypted communications, meaning they can read private information like emails.
We know HTTPS encryption is a barrier to government spying because of the NSA’s famous “[SSL added and removed here](https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html)” note. We also know that misissued certificates have been used to spy on traffic in the past. For instance, in 2011 [DigiNotar was hacked](https://en.wikipedia.org/wiki/DigiNotar) and the resulting certificates used to intercept emails for people in Iran. In 2015, [CNNIC issued an intermediate certificate](https://slate.com/technology/2016/12/how-the-2011-hack-of-diginotar-changed-the-internets-infrastructure.html) used in intercepting traffic to a variety of websites. Each CA was subsequently [distrusted](https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/).
Distrusting a CA is just one end of a spectrum of technical interventions browsers can take to improve the security of their users. 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.” As one example, certificate security rests critically on the security of the hash algorithm used. The [SHA-1 hash algorithm](https://en.wikipedia.org/wiki/SHA-1), published in 1993, was considered not secure by 2005. NIST disallowed its use in 2013. However, CAs didn't stop using it until 2017, and that only happened because one browser made SHA-1 removal a requirement of its root program. After that, the other browsers followed suit, along with the [CA/Browser Forum](https://cabforum.org/).
The removal of SHA-1 illustrates the backwards security incentives for CAs. A CA serves two audiences: their customers, who get certificates from them, and the rest of the internet, who trusts them to provide security. When it comes time to raise the bar on security, a CA will often hear from their customers that upgrading is difficult and expensive, as it sometimes is. That motivates the CA to drag their feet and keep offering the insecure technology. But the CA’s other audience, the population of global internet users, needs them to continually improve security. That’s why browser root programs need to (and do) require a steadily increasing level of security of CAs. The root programs advocate for the needs of their users so that they can provide a more secure product. The security of a browser’s root program is, in a very real way, a determining factor in the security of the browser itself.
That’s why it’s so disturbing that eIDAS 2.0 is poised to prevent browsers from holding CAs accountable. By all means, raise the bar for CA security, but permanently lowering the bar means less accountability for CAs and less security for internet users everywhere.
The text isn't final yet, but is subject to approval behind closed doors in Brussels on November 8.
DEEPLINKS BLOG
By Jacob Hoffman-Andrews
November 7, 2023
---
The EU is poised to [pass a sweeping new regulation](https://last-chance-for-eidas.org/), eIDAS 2.0. Buried deep in the text is Article 45, which returns us to the dark ages of 2011, when certificate authorities (CAs) could collaborate with governments to spy on encrypted traffic—and get away with it. Article 45 forbids browsers from enforcing modern security requirements on certain CAs without the approval of an EU member government. Which CAs? Specifically the CAs that were appointed by the government, which in some cases will be owned or operated by that selfsame government. That means cryptographic keys under one government’s control could be used to intercept HTTPS communication throughout the EU and beyond.
This is a catastrophe for the privacy of everyone who uses the internet, but particularly for those who use the internet in the EU. Browser makers have not announced their plans yet, but it seems inevitable that they will have to create two versions of their software: one for the EU, with security checks removed, and another for the rest of the world, with security checks intact. We’ve been down this road before, when export controls on cryptography meant browsers were released in two versions: strong cryptography for US users, and weak cryptography for everyone else. It was a fundamentally inequitable situation and the knock-on effects set back web security by decades.
The current text of Article 45 requires that browsers trust CAs appointed by governments, and [prohibits browsers from enforcing any security requirements](https://blog.mozilla.org/netpolicy/files/2023/11/eIDAS-Industry-Letter-updated.pdf) on those CAs beyond what is approved by [ETSI](https://en.wikipedia.org/wiki/ETSI).
In other words, it sets an upper bar on how much security browsers can require of CAs, rather than setting a lower bar. That in turn limits how vigorously browsers can compete with each other on improving security for their users.
This upper bar on security may even ban browsers from enforcing [Certificate Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency), an IETF technical standard that ensures a CA’s issuing history can be examined by the public in order to detect malfeasance. Banning CT enforcement makes it much more likely for government spying to go undetected.
Why is this such a big deal? The role of a CA is to bootstrap encrypted [HTTPS](https://www.eff.org/encrypt-the-web) communication with websites by issuing certificates. The CA’s core responsibility is to match web site names with customers, so that the operator of a website can get a valid certificate for that website, but no one else can. If someone else gets a certificate for that website, they can use it to intercept encrypted communications, meaning they can read private information like emails.
We know HTTPS encryption is a barrier to government spying because of the NSA’s famous “[SSL added and removed here](https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html)” note. We also know that misissued certificates have been used to spy on traffic in the past. For instance, in 2011 [DigiNotar was hacked](https://en.wikipedia.org/wiki/DigiNotar) and the resulting certificates used to intercept emails for people in Iran. In 2015, [CNNIC issued an intermediate certificate](https://slate.com/technology/2016/12/how-the-2011-hack-of-diginotar-changed-the-internets-infrastructure.html) used in intercepting traffic to a variety of websites. Each CA was subsequently [distrusted](https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/).
Distrusting a CA is just one end of a spectrum of technical interventions browsers can take to improve the security of their users. 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.” As one example, certificate security rests critically on the security of the hash algorithm used. The [SHA-1 hash algorithm](https://en.wikipedia.org/wiki/SHA-1), published in 1993, was considered not secure by 2005. NIST disallowed its use in 2013. However, CAs didn't stop using it until 2017, and that only happened because one browser made SHA-1 removal a requirement of its root program. After that, the other browsers followed suit, along with the [CA/Browser Forum](https://cabforum.org/).
The removal of SHA-1 illustrates the backwards security incentives for CAs. A CA serves two audiences: their customers, who get certificates from them, and the rest of the internet, who trusts them to provide security. When it comes time to raise the bar on security, a CA will often hear from their customers that upgrading is difficult and expensive, as it sometimes is. That motivates the CA to drag their feet and keep offering the insecure technology. But the CA’s other audience, the population of global internet users, needs them to continually improve security. That’s why browser root programs need to (and do) require a steadily increasing level of security of CAs. The root programs advocate for the needs of their users so that they can provide a more secure product. The security of a browser’s root program is, in a very real way, a determining factor in the security of the browser itself.
That’s why it’s so disturbing that eIDAS 2.0 is poised to prevent browsers from holding CAs accountable. By all means, raise the bar for CA security, but permanently lowering the bar means less accountability for CAs and less security for internet users everywhere.
The text isn't final yet, but is subject to approval behind closed doors in Brussels on November 8.