What the QWAC? An EV Certificate all over again(scotthelme.co.uk)
scotthelme.co.uk
What the QWAC? An EV Certificate all over again
https://scotthelme.co.uk/what-the-qwac/
89 comments
> The EU absolutely has an interest in preventing a US (or Chinese or whatever) entity from falsely certifying an EU site.
EU is varied with all kinds of interests and geopolitical orientations.
For example Hungary. Should we let Hungary certify an EU site?
EU is varied with all kinds of interests and geopolitical orientations.
For example Hungary. Should we let Hungary certify an EU site?
Hungary, Spain and Cyprus are voting for breaking end-to-end encryption.
Hungary is run by now already authorian Orban. Spain has a history of spying their political opponents with Pegasus spyware. Yes, we definitely want to give this guys any authority to tap any of our wire traffic.
https://www.wired.com/story/europe-break-encryption-leaked-d...
Hungary is run by now already authorian Orban. Spain has a history of spying their political opponents with Pegasus spyware. Yes, we definitely want to give this guys any authority to tap any of our wire traffic.
https://www.wired.com/story/europe-break-encryption-leaked-d...
That's not at all what I said. The EU has a government, and I don't think anyone particularly disputes which government is the EU government. (I suppose one might argue that .tw is a bit different, but that's a whole different discussion, and somehow the DNS root servers know what to return for SOA and NS queries for tw.)
I'm saying that I think it really would be reasonable for the EU to require that browser follow a specified mechanism to restrict which certificates are valid for .eu. And it would be reasonable for Hungary to use the same mechanism to restrict .hu. So browsers would only accept a certificate for a .hu domain if it was signed according to standard PKIX and CA/B Forum rules and had whatever standardized attestation was required from .hu.
I'm saying that I think it really would be reasonable for the EU to require that browser follow a specified mechanism to restrict which certificates are valid for .eu. And it would be reasonable for Hungary to use the same mechanism to restrict .hu. So browsers would only accept a certificate for a .hu domain if it was signed according to standard PKIX and CA/B Forum rules and had whatever standardized attestation was required from .hu.
If it were that Only *.hu could be signed by a Hungarian-approved CA, then that would be one thing.
However the proposed legislation does not, apparently, say this.
However the proposed legislation does not, apparently, say this.
your comment seems to be making the implication that government-mandated roots will be restricted to their own CCTLD. is this true, or will Chrome and firefox be forced to ship a CA that allows Hungary to sign certs for whatever .com they want to?
They will not be restricted to their own ccTLD, and browsers will in fact be forced to ship a CA that allows Hungary to sign certs for whatever .com they want to.
> DNSSEC is massively problematic.
Everyone has all of these problems with DNSSEC but no solutions. What's the better alternative? We need a way to verify hostname lookups.
DNSSEC does what it says on the tin. DIYing DNSSEC is a pain in the ass, but in 2023 I think the overlap of folks who self host DNS and aren't capable of setting up DNSSEC is quite small.
I personally think we missed a great opportunity with DANE to decentralize a lot of things, but DNSSEC FUD got in the way.
Everyone has all of these problems with DNSSEC but no solutions. What's the better alternative? We need a way to verify hostname lookups.
DNSSEC does what it says on the tin. DIYing DNSSEC is a pain in the ass, but in 2023 I think the overlap of folks who self host DNS and aren't capable of setting up DNSSEC is quite small.
I personally think we missed a great opportunity with DANE to decentralize a lot of things, but DNSSEC FUD got in the way.
You ever have a debate about "defense in depth" versus "multiple single points of failure"? That's the DNSSEC dilemma (or one of them at least). People think they're getting a "decentralized" system. But there are few systems on the Internet more centralized than the DNS, which is tree structured, and which by design delegates authority to world governments.
Appeals to DNSSEC as a decentralization method tend to assume that (a) there are TLDs that are both accessible and reasonably insulated from governmental privacy interference (this is trickier than it looks; .IO, for instance, is squarely within the jurisdiction of the world's most unhinged signals intelligence agency), and that (b) moving established properties to those new TLDs has a reasonable cost, which it virtually never does.
Appeals to DNSSEC as a decentralization method tend to assume that (a) there are TLDs that are both accessible and reasonably insulated from governmental privacy interference (this is trickier than it looks; .IO, for instance, is squarely within the jurisdiction of the world's most unhinged signals intelligence agency), and that (b) moving established properties to those new TLDs has a reasonable cost, which it virtually never does.
Using any web service requires implicitly trusting the government (in the sense of the entity that can give orders that men with guns will follow; not necessarily the party currently in power, in the case of places that have checks and balances) of wherever it's hosted. Not being also obliged to trust 170-odd other governmental and nongovernmental entities would be a step up (I know certificate transparency helps with this to a certain extent, but being a root CA is still a privileged status; really I should be able to use a .foo domain without putting any trust in entities outside foo)
It is simply not true that using any service on the Internet requires you to trust the government. I do appreciate the clarity with which we can associate that idea with DNSSEC advocacy, though. "30 years of Internet privacy research have shown: we should just give up and let governments run the show, they're going to anyways".
Unfortunately, the IETF has categorically rejected that argument:
https://datatracker.ietf.org/doc/html/rfc7624
Unfortunately, the IETF has categorically rejected that argument:
https://datatracker.ietf.org/doc/html/rfc7624
It's not that I want to trust governments more. I want to get away from the "flat list of 170+ root certificates" model because I want to trust a bunch of governments (not least that of the US) less!
Is your argument with the RFC that content exfiltration is always more costly than active network attacks? Obviously all else being equal that's true, but it's an overly simplistic model when multiple countries come into play - for a government, an active network attack against a foreign power is much more costly than any king of attack, even content exfiltration, against a company within your country.
Is your argument with the RFC that content exfiltration is always more costly than active network attacks? Obviously all else being equal that's true, but it's an overly simplistic model when multiple countries come into play - for a government, an active network attack against a foreign power is much more costly than any king of attack, even content exfiltration, against a company within your country.
> assume ... there are TLDs that are both accessible and reasonably insulated from governmental privacy interference
Would be nice if the root servers delegated some TLDs to various experimental projects like blockchain-based name systems and OpenNIC and such (i.e. making domains under those TLDs resolvable for everyone).
Would be nice if the root servers delegated some TLDs to various experimental projects like blockchain-based name systems and OpenNIC and such (i.e. making domains under those TLDs resolvable for everyone).
DNSCurve solves the issues of securing the channel (solves privacy, not authenticity like DNSSEC attempted), unfortunately it wasn't standardized and didn't get wide adoption.
It's never going to get wide adoption now that DoH has become a de facto standard.
The place where DoH is common is the place with no network effect. Anyone can use anything from DoH to DNSCurve to OpenVPN to secure the path between the client and the recursive DNS server, and can do so regardless of what anybody else uses for that.
The thing we're still missing is something to secure the path between the recursive and authoritative nameservers, which is the thing DNSCurve is actually better at and is also not the thing DoH is commonly used for. Moreover, "adoption" is basically code in this context. You could have widespread adoption of DNSCurve just by adding support for it to the handful of open source DNS servers in widespread use.
The thing we're still missing is something to secure the path between the recursive and authoritative nameservers, which is the thing DNSCurve is actually better at and is also not the thing DoH is commonly used for. Moreover, "adoption" is basically code in this context. You could have widespread adoption of DNSCurve just by adding support for it to the handful of open source DNS servers in widespread use.
DNSCurve does make some requirements around the naming of DNS servers, as the name is used to provide the keys. Making:
(example is from: https://dnscurve.org/out-install.html)
uz5xgm1kx1zj8xsh51zp315k0rw7dcsgyxqh2sl7g8tjg25ltcvhyw.nytimes.com.
(example is from: https://dnscurve.org/out-install.html)
This is basically irrelevant, normal people don't interact with the names of authoritative DNS servers.
Operations people frequently pick based on ergonomics. The bad ergonomics and having to learn new tools is a frequently cited reason why IPv6 is seeing lesser adoption.
> Everyone has all of these problems with DNSSEC but no solutions. What's the better alternative? We need a way to verify hostname lookups.
They do offer solutions, which typically involve joining their proprietary, centralized, commercial walled gardens.
They do offer solutions, which typically involve joining their proprietary, centralized, commercial walled gardens.
DoT and DoH seem like better alternatives, these days. At least for the “authenticated delivery of DNS records” bit.
My understanding is that if DNSSEC were to break nothing would really happen to the public Internet, indicating that it’s not really a load-bearing component.
My understanding is that if DNSSEC were to break nothing would really happen to the public Internet, indicating that it’s not really a load-bearing component.
DNSSEC would have prevented the recent TLS MITM attack https://news.ycombinator.com/item?id=37955264
The security of DV certificates is shaky without DNSSEC.
The security of DV certificates is shaky without DNSSEC.
That TLS MITM attack was government-initiated, and governments control the DNSSEC roots. But either way: you can't say your system is load bearing because if it was actually deployed it would bear load. It has to actually bear the load, not just in theory but in practice. The root DNSSEC keys could land on Pastebin tonight and almost nobody would need to be paged.
Authenticated DANE or CAA would have prevented it.
FWIW, there is absolutely no reason that authentication for CAA requests needs to have high bandwidth or low latency or even that it would need to be part of the DNS protocol itself or of any sort of query that ordinary clients do. And the web could tolerate a day-long CAA outage with the only obvious side effect being an inability to issue new certificates.
Heck, a signed CAA attestation valid for 24 hours that was generated, for each domain that uses it, at most once per day, would allow quite a bit of ability to ride through an outage.
FWIW, there is absolutely no reason that authentication for CAA requests needs to have high bandwidth or low latency or even that it would need to be part of the DNS protocol itself or of any sort of query that ordinary clients do. And the web could tolerate a day-long CAA outage with the only obvious side effect being an inability to issue new certificates.
Heck, a signed CAA attestation valid for 24 hours that was generated, for each domain that uses it, at most once per day, would allow quite a bit of ability to ride through an outage.
What's the enforcement mechanism for including the root certs? As far as I know, there is no web browser that is sold for money. That means that if you're Apple or Google, you can spin off a company that has no presence in the EU and ship whatever root certificates you want, and it's not like you lose out on revenue. You probably dispel a lot of antitrust concerns as well.
At the end of the day, what certs you trust is a personal decision. It's not a democracy; there is no need for an entire country to agree on which certificates are trusted and mandate that by law. Pick the ones who you trust, and your choice need not affect my choice. (Most of us delegate to browser vendors, OS vendors, or our employer, of course, but that is a choice. Don't like Apple's set of root certs? Delete the ones you don't trust, or use Firefox, or use Chrome.)
At the end of the day, what certs you trust is a personal decision. It's not a democracy; there is no need for an entire country to agree on which certificates are trusted and mandate that by law. Pick the ones who you trust, and your choice need not affect my choice. (Most of us delegate to browser vendors, OS vendors, or our employer, of course, but that is a choice. Don't like Apple's set of root certs? Delete the ones you don't trust, or use Firefox, or use Chrome.)
The actual enforcement mechanism is the root store programs, i.e. the browsers ultimately decide. The CA/Browser forum is supposed to be a cooperative way for CAs and Browsers to agree technical standards but on the CA side this self regulation doesn't always work.
Perhaps the best "big name" distrusted CA would be Symantec: https://blog.mozilla.org/security/2018/03/12/distrust-symant...
Others include WoSign and StartCom.
The problem with eIDAS is that browsers can no longer police these CAs, as they are legally mandated to carry them. There needs to be a mechanism whereby such a CA can be distrusted, doubly so if it is issuing "qualified" certificates (if it cannot get the basics right it should not attest to someone's legal identity).
On the flip side to this there is nothing stopping Europe distributing additional roots that install themselves in browsers. I work in finance and we operate several closed CAs. Our clients install our CAs all the time. It just would not be on by default nor pop up the EV bit.
But that does not stop the digital wallet software (the motivation for this) peering into the certificate itself and making sure it is a qualified certificate.
Perhaps the best "big name" distrusted CA would be Symantec: https://blog.mozilla.org/security/2018/03/12/distrust-symant...
Others include WoSign and StartCom.
The problem with eIDAS is that browsers can no longer police these CAs, as they are legally mandated to carry them. There needs to be a mechanism whereby such a CA can be distrusted, doubly so if it is issuing "qualified" certificates (if it cannot get the basics right it should not attest to someone's legal identity).
On the flip side to this there is nothing stopping Europe distributing additional roots that install themselves in browsers. I work in finance and we operate several closed CAs. Our clients install our CAs all the time. It just would not be on by default nor pop up the EV bit.
But that does not stop the digital wallet software (the motivation for this) peering into the certificate itself and making sure it is a qualified certificate.
> At the end of the day, what certs you trust is a personal decision. It's not a democracy; there is no need for an entire country to agree on which certificates are trusted and mandate that by law. Pick the ones who you trust, and your choice need not affect my choice. (Most of us delegate to browser vendors, OS vendors, or our employer, of course, but that is a choice. Don't like Apple's set of root certs? Delete the ones you don't trust, or use Firefox, or use Chrome.)
This isn't entirely true. Let's disregard for a moment the spy agency's wet dream that this law introduces (likely fully intentionally). The more benign intent of this law is to prevent foreign entities from the EU (Mozilla, Google, Apple) from having the final say on whether two kinds of EU organizations (site operators and root CA operators) can successfully reach their clients.
Of course you in your capacity as a consumer don't care whether I trust the same root CAs as I do. But a site operator very much cares whether all of their target audience trusts their site, and by extension the root CA that they are paying, and would like for their government to guarantee this trust.
The theoretical problem that this law is theoretically intended to protect from is browser vendors imposing hostile requirements on certificates which cost EU companies money and/or access to clients. It's a form of protectionism, ultimately.
Of course, the law is clearly being influenced by EU members' security agencies as well, who would love to have the ability to issue fake certificates for any site on the internet. With this new law, they would only need to infiltrate/coerce/fool their local root CA and local auditors, and they'd get free reign over encryption everywhere in the EU at least.
This isn't entirely true. Let's disregard for a moment the spy agency's wet dream that this law introduces (likely fully intentionally). The more benign intent of this law is to prevent foreign entities from the EU (Mozilla, Google, Apple) from having the final say on whether two kinds of EU organizations (site operators and root CA operators) can successfully reach their clients.
Of course you in your capacity as a consumer don't care whether I trust the same root CAs as I do. But a site operator very much cares whether all of their target audience trusts their site, and by extension the root CA that they are paying, and would like for their government to guarantee this trust.
The theoretical problem that this law is theoretically intended to protect from is browser vendors imposing hostile requirements on certificates which cost EU companies money and/or access to clients. It's a form of protectionism, ultimately.
Of course, the law is clearly being influenced by EU members' security agencies as well, who would love to have the ability to issue fake certificates for any site on the internet. With this new law, they would only need to infiltrate/coerce/fool their local root CA and local auditors, and they'd get free reign over encryption everywhere in the EU at least.
If this was truly about protectionism, they would mandate CA transparency reports. This is unilaterally a law written to spoof certs to websites EU spy agencies would love to get their hands on.
I don't even trust my own country's spy agencies to not spy on me without cause, how could I ever trust, say, Hungary's?
I don't even trust my own country's spy agencies to not spy on me without cause, how could I ever trust, say, Hungary's?
This over-shot may have the opposite effect though. I think the browser vendors will have more trouble limiting plugins that monitor certificates and perhaps build a p2p transparency report of sorts. Right now the default CA's include the federal post offices, etc, of all sorts of seedy countries.
Spinning Chrome off and keeping enough daylight between Google and the new entity to have any hope of it meaning anything legally-speaking, would likely require Google to stop pushing Chrome like a heavily-indebted crack dealer on all their other properties. They'd probably rather just ship the certs.
It's not only browsers though. The OS has a root store which is used by other non-browser apps. I also want my email program not to be susceptible to government MitM attacks. And whatever else I'm running. Apple and Windows could be compelled to limit the degree to which that store is mutable or even visible.
More and more it looks like Linux on the desktop is the only option.
More and more it looks like Linux on the desktop is the only option.
I would assume coercing the OS providers (MS/Apple/Google) who do sell a system with a browser for money into shipping the backdoored browser would be enough of a win for them. Not a lot of people change their browser, even when it was stupid old Internet explorer...
If this was actually true, Chrome would not have anywhere near the market share it has.
I never said it was the majority, but if you look at the numbers there's a chunkable size of population that don't change (and it's been higher than the Mozilla market share for many years now), that number is getting bigger now that Edge is not immediately terrible anymore (I know several people who used Chrome and now stick to Edge). Plus we have a history of people keeping the default browser around just in case since gov websites were always optimized for weird setups like "Internet Explorer running Java applets".
I feel like "Edge only exists so I can download Chrome" is a meme that many, many people outside the software engineering field relate to. Go post it to Reddit, instant 100k upvotes every time ;)
> That means that if you're Apple or Google, you can spin off a company that has no presence in the EU and ship whatever root certificates you want, and it's not like you lose out on revenue.
If such a solution would work Microsoft would have done it in it's famous browser monopoly suit
If such a solution would work Microsoft would have done it in it's famous browser monopoly suit
I mean, isn't that the solution the government wanted? It was about bundling and interfering with other products the user had installed. An "arm's length" is all that they would have needed to do.
So how's about the browsers/root-programme operators simply stop bundling a root store?
Instead, they could hive-off their root programme into an independent operation. Make it possible for the user to choose which root store they want. Does EIDAS mandate that browsers must provide a root store?
I occasionally pick over my root store(s) looking for government-run root-certs for governments I don't need to trust. But the names of those root certs aren't transparent; you have to research each one before you can safely distrust it.
Most government-run roots are only needed by citizens of that country; e.g. countries that issue government electronic ID that you need for things like voting (which isn't that common). So I'd choose a minimal root store, and then perhaps add back groups of certs, based on what my specific needs were. This could be managed through a slick UI.
It would be extra cool if browser manufacturers could restrict government-issued CAs to attesting subdomains of their CC-TLD. It's nuts that (e.g.) the Turkish and Hungarian governments can attest any domain they want.
Instead, they could hive-off their root programme into an independent operation. Make it possible for the user to choose which root store they want. Does EIDAS mandate that browsers must provide a root store?
I occasionally pick over my root store(s) looking for government-run root-certs for governments I don't need to trust. But the names of those root certs aren't transparent; you have to research each one before you can safely distrust it.
Most government-run roots are only needed by citizens of that country; e.g. countries that issue government electronic ID that you need for things like voting (which isn't that common). So I'd choose a minimal root store, and then perhaps add back groups of certs, based on what my specific needs were. This could be managed through a slick UI.
It would be extra cool if browser manufacturers could restrict government-issued CAs to attesting subdomains of their CC-TLD. It's nuts that (e.g.) the Turkish and Hungarian governments can attest any domain they want.
If it doesn't exist already, surely this would be demand for this as a browser extension in the event that article 45 passes.
Yeah, I've never tried to write a browser extension. I'd foul it up; but I'd be glad to help if anyone else wants to have a go. And it is needed now; there's no need to wait until this proposal goes through.
The other side of the coin is that you'd then get a community of root-block lists (and root-add lists), like AdBlock lists.
The other side of the coin is that you'd then get a community of root-block lists (and root-add lists), like AdBlock lists.
Why don't the browsers make the trusted CA root set a choice? Have a radio button selector between the "EU sanctioned", "Browser safe-default", and user selectable? Make radio button panel really easy to find and update.
The EU seems to really hate not having control over things, so they will just mandate having some hard-coded certs, that are present regardless of choice. It's like a pathological thing in Europe, and the recent legislation coming from there seems very inspired by the great firewall.
It's like they gave up on trying to actually innovate or grow a tech industry (composed of more than the odd successful euro tech corporation) after years of trying and now they are just banking on their market size to push more and more ridiculous legislation.
I can't wait for that to backfire, or for corporations to not bother anymore (imo the GPDR is the only good thing that came out of this non stop spree of legislation, and that's almost half a decade old now).
At least with China, whatever they do or restrict usually only affects their own home grown tech industry. The funny thing is that if the US gov seriously pushed for something similar to the recent laws (chatcontrol, client side scanning, the weird copyright laws, the "fake news" thing, etc), Europeans would call it fascism or typical American thirdworldism (which is extremely ironic regardless of context).
It's like they gave up on trying to actually innovate or grow a tech industry (composed of more than the odd successful euro tech corporation) after years of trying and now they are just banking on their market size to push more and more ridiculous legislation.
I can't wait for that to backfire, or for corporations to not bother anymore (imo the GPDR is the only good thing that came out of this non stop spree of legislation, and that's almost half a decade old now).
At least with China, whatever they do or restrict usually only affects their own home grown tech industry. The funny thing is that if the US gov seriously pushed for something similar to the recent laws (chatcontrol, client side scanning, the weird copyright laws, the "fake news" thing, etc), Europeans would call it fascism or typical American thirdworldism (which is extremely ironic regardless of context).
> and the recent legislation coming from there seems very inspired by the great firewall.
https://www.europarl.europa.eu/RegData/etudes/STUD/2020/6487...
https://www.europarl.europa.eu/RegData/etudes/STUD/2020/6487...
One of the biggest reasons “the EU” can’t seem to home grow a tech industry is fragmentation - each member state has its own bizarre tax rules, and it’s extremely tedious/difficult, even today, to do cross border employment.
A company based in Ireland for example, has a really hard time employing someone in Germany, without spinning up a “local branch” in Germany, and thus having to comply with German tax rules as well.
Rules around contractors vary wildly and don’t simplify matters much.
The “solution” is to accept the overheads of a company like Remote or similar who act as an employer of record, but that’s a bodge.
No member state has any real incentive to simplify cross border employment/business rules, so it drags everyone down.
It gets even worse for startups when rules around equity, etc, vary wildly country to country - some countries have extremely hostile tax rules around equity that may never be realized.
A company based in Ireland for example, has a really hard time employing someone in Germany, without spinning up a “local branch” in Germany, and thus having to comply with German tax rules as well.
Rules around contractors vary wildly and don’t simplify matters much.
The “solution” is to accept the overheads of a company like Remote or similar who act as an employer of record, but that’s a bodge.
No member state has any real incentive to simplify cross border employment/business rules, so it drags everyone down.
It gets even worse for startups when rules around equity, etc, vary wildly country to country - some countries have extremely hostile tax rules around equity that may never be realized.
> imo the GPDR is the only good thing that came out of this non stop spree of legislation, and that's almost half a decade old now
What do you think of the Digital Markets and Digital Services Acts?
What do you think of the Digital Markets and Digital Services Acts?
This is also the same reason why calling upon European citizens to see the negatives of the law and voice their concerns about it isn’t gonna work.
Agree partly the GDPR though, since it requires disclosure about how collected data is gonna be used.
Agree partly the GDPR though, since it requires disclosure about how collected data is gonna be used.
What happens when you selected "Browser safe-default" but your bank's website presents an EU certificate? Sure, you can probably add a "trust only for this site" option, but soon enough users are going to get used to this and will blindly click that button every time the warning shows up, which kills the whole point.
Parent's suggestion is to accept the eIDAS certs only within the EU.
The regulation should be changed such that the QWAC is only ever used to verify during an eIDAS transaction.
The most practical way to achieve that is to legislate for a new API in the browser and implement this in the application layer. That will take some time to implement, however eIDAS itself will also take some time to implement.
This would involve the browsers implementing a new eIDAS-only CA store within their browsers. Which is very easy to do as it's new and the API is regulated thus fixed.
The verification flow would work by exchanging attributes (i.e. browser sends crypto-random message to server, server signs it, browser verifies). It adds work to the audit of eIDAS solutions (implementers will f** it up en masse as most of the involved parties are hopelessly bad) but it's better than the alternatives.
The most practical way to achieve that is to legislate for a new API in the browser and implement this in the application layer. That will take some time to implement, however eIDAS itself will also take some time to implement.
This would involve the browsers implementing a new eIDAS-only CA store within their browsers. Which is very easy to do as it's new and the API is regulated thus fixed.
The verification flow would work by exchanging attributes (i.e. browser sends crypto-random message to server, server signs it, browser verifies). It adds work to the audit of eIDAS solutions (implementers will f** it up en masse as most of the involved parties are hopelessly bad) but it's better than the alternatives.
The browsers in fact proposed an alternative that decoupled eIDAS's real-world-identity verification from TLS connection verification, but the EU rejected it.
Could you please link to the document in question for reference?
Are we reading the same comment? The one I'm reading only mentions having a "radio button selector" with no reference to making it geo specific. Regardless, even if it were geo specific, then what? I guess it's fine for american users, but what about all the EU users that might be getting MITMed?
If the law mandates a MITM capability, and users in the EU don’t consider it important enough to oppose said law, there isn’t really a choice and the region scoped certs may be the only choice moving forward.
There will be a fork of Firefox in that case.
Right? I came here to look for potential remedies when this goes through. Forking browsers sounds like a good solution. Or am I missing something?
Outside of the EU, browser vendors will continue to ship browsers without eIDAS CAs, so just VPN into a non-EU country to download your browsers.
But you'll probably have to keep an EU version on hand in order to access EU gov sites, EU banks, and likely EU businesses if/when the EU government decides to force businesses to use eIDAS certs for their sites.
But you'll probably have to keep an EU version on hand in order to access EU gov sites, EU banks, and likely EU businesses if/when the EU government decides to force businesses to use eIDAS certs for their sites.
Related ongoing thread:
Article 45 of eIDAS 2.0 will roll back web security by 12 years - https://news.ycombinator.com/item?id=38181114 - Nov 2023 (77 comments)
Also: (others?)
Joint statement of scientists and NGOs on the EU’s proposed eIDAS reform - https://news.ycombinator.com/item?id=38126997 - Nov 2023 (63 comments)
Last Chance to fix eIDAS: Secret EU law threatens Internet security - https://news.ycombinator.com/item?id=38109494 - Nov 2023 (299 comments)
EFF about EU: EIDAS 2.0 Sets a Dangerous Precedent for Web Security - https://news.ycombinator.com/item?id=33966364 - Dec 2022 (44 comments)
EU legislation eIDAS article 45.2 may force inclusion of insecure QWAC root CAs - https://news.ycombinator.com/item?id=32093891 - July 2022 (36 comments)
Mozilla and the EFF publish letter about the danger of Article 45.2 - https://news.ycombinator.com/item?id=30549119 - March 2022 (13 comments)
Article 45 of eIDAS 2.0 will roll back web security by 12 years - https://news.ycombinator.com/item?id=38181114 - Nov 2023 (77 comments)
Also: (others?)
Joint statement of scientists and NGOs on the EU’s proposed eIDAS reform - https://news.ycombinator.com/item?id=38126997 - Nov 2023 (63 comments)
Last Chance to fix eIDAS: Secret EU law threatens Internet security - https://news.ycombinator.com/item?id=38109494 - Nov 2023 (299 comments)
EFF about EU: EIDAS 2.0 Sets a Dangerous Precedent for Web Security - https://news.ycombinator.com/item?id=33966364 - Dec 2022 (44 comments)
EU legislation eIDAS article 45.2 may force inclusion of insecure QWAC root CAs - https://news.ycombinator.com/item?id=32093891 - July 2022 (36 comments)
Mozilla and the EFF publish letter about the danger of Article 45.2 - https://news.ycombinator.com/item?id=30549119 - March 2022 (13 comments)
It's strictly worse because at least a rogue/incompetent CA can be distrusted, as the legislation intentionally makes distrusting one of these CAs difficult/impossible
I wonder whether site operators could mitigate this by using SPF-like DNS records to say which cert authorities their site uses. It's of course possible for a sophisticated attacker to try to interfere with such a workaround but:
1) The DNS ecosystem is messy with OS, browser and cached records. This makes it very annoying and slow for attackers to target anything but individual users.
2) Browser vendors, if needed, could verify such DNS records in an EU free connection for most sites.
3) Scanners could compare DNS records to results in EU based browser requests and alert the public.
4) Sites with greater concern could additionally post information about which certs their site uses in other public locations like HTML meta tags, public databases, or even centralised locations like search consoles & app stores.
This isn't as elegant as the current system of certificate transparency, but meaningfully raises the costs of MITM'ing connections in an environment where eIDAS is enforced.
1) The DNS ecosystem is messy with OS, browser and cached records. This makes it very annoying and slow for attackers to target anything but individual users.
2) Browser vendors, if needed, could verify such DNS records in an EU free connection for most sites.
3) Scanners could compare DNS records to results in EU based browser requests and alert the public.
4) Sites with greater concern could additionally post information about which certs their site uses in other public locations like HTML meta tags, public databases, or even centralised locations like search consoles & app stores.
This isn't as elegant as the current system of certificate transparency, but meaningfully raises the costs of MITM'ing connections in an environment where eIDAS is enforced.
This sounds a lot like CAA records! https://datatracker.ietf.org/doc/html/rfc6844
Nice! thanks for the reference
Can't individuals (on their local systems) just blacklist those root CAs independently of the browsers? I can do that today to trust and distrust any certificate out there. Problem solved right?
> Can't individuals (on their local systems) just blacklist those root CAs independently of the browsers?
The problem (for me at least) is deciding which of the 200-odd roots I want to distrust. If a root has a name that I can't decipher because it's in foreign, that's easy. But most roots have cryptic names, and there's no standard way of finding out who operates a given root, who audits it, or who that root is allowed to issue certs for.
Perhaps there's a market for an open-source root-store editor, that annotates each root with a plain-language description, including stuff like how many certs it has issued, and how many frauds and cock-ups it's been responsible for.
The problem (for me at least) is deciding which of the 200-odd roots I want to distrust. If a root has a name that I can't decipher because it's in foreign, that's easy. But most roots have cryptic names, and there's no standard way of finding out who operates a given root, who audits it, or who that root is allowed to issue certs for.
Perhaps there's a market for an open-source root-store editor, that annotates each root with a plain-language description, including stuff like how many certs it has issued, and how many frauds and cock-ups it's been responsible for.
Most people never change defaults, this is for mass surveillance and repression. Its not about some specific activists, for those they hire foreign private security firms and they are using 0-days anyway.
What would this mean for let’s encrypt free certificates ? Would their root CA still be recognized in the EU?
It would be, but so would any of the EU state controlled ones, even if that's not what you use for your domain.
The main problem isn't that it puts any limits on what you can use as a CA but rather that it mandates some of what everyone must trust as one, even if that trust isn't earned (or maintained).
The main problem isn't that it puts any limits on what you can use as a CA but rather that it mandates some of what everyone must trust as one, even if that trust isn't earned (or maintained).
I understand better now, thanks!
Browsers could simply make QWACs distinguishable from all other certs. Make sure to show qwac next to the lock. Will the EU say hide the qwac?
Replace the padlock with a duck icon!
[deleted]
The simple solution to this is to promise that any browser instances outside the EU will label these certificates as invalid with very big red scary warnings (maybe mumbling something about risk of state-sponsored attacks). The CAs trying to push those certificates will then quickly lose interest in pushing this regulation...
Within the EU, this can also be solved: Pop up a dialog with the certificate, showing "This web site uses a special kind of certificate that <browsername> is by law required to accept. <issuing authority> from <country> claims that this web site has the following identity <claim>. Such certificates are typically used by (explain whatever the intended use case of these certificates is supposed to be). If you do not expect this web site to use such a special certificate, this may be a government-sponsored attack. The below text will help any technical people investigate. <base64 of the certificate> [ ] do not show again for this certificate and site".
That fulfills both the letter and the spirit of the law while making it very unlikely that these certificates can be used maliciously (and if they were, would make it extremely likely that signed evidence of that would quickly show up). Optionally, allow site operators of major sites to indicate that they will never use such certificates.
Within the EU, this can also be solved: Pop up a dialog with the certificate, showing "This web site uses a special kind of certificate that <browsername> is by law required to accept. <issuing authority> from <country> claims that this web site has the following identity <claim>. Such certificates are typically used by (explain whatever the intended use case of these certificates is supposed to be). If you do not expect this web site to use such a special certificate, this may be a government-sponsored attack. The below text will help any technical people investigate. <base64 of the certificate> [ ] do not show again for this certificate and site".
That fulfills both the letter and the spirit of the law while making it very unlikely that these certificates can be used maliciously (and if they were, would make it extremely likely that signed evidence of that would quickly show up). Optionally, allow site operators of major sites to indicate that they will never use such certificates.
[deleted]
For other confused people, "EV" here is an Extended Validation certificate, and this has nothing to do with Electric Vehicles.
The author's previous blog post is basically mandatory reading if you want to make any sense of this one:
https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck...
The author's previous blog post is basically mandatory reading if you want to make any sense of this one:
https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck...
[deleted]
He leaked excerpts from the text but not the full document. I would really like to read the actual full text document. The fact that the European commission keeps the draft legislation secret is concerning.
Is this the typical process for all EU regulation?
Is this the typical process for all EU regulation?
The processes are relatively transparent and regularly being reported upon [0][1], though working drafts are not generally public. Most of what is being criticized now is already contained in the 2021 proposal [2]. In reaction to earlier criticisms, provisions were added to the current draft to allow browser vendors to take measures in case of security concerns regarding QWACs, see paragraphs 2–4 in https://news.ycombinator.com/item?id=38183994. The whole thing is not a secret conspiracy, and legislators are generally well-intentioned (for whatever that’s worth).
[0] https://www.europarl.europa.eu/legislative-train/spotlight-J...
[1] https://www.europarl.europa.eu/RegData/etudes/ATAG/2023/7392...
[2] https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=COM%3A20...
[0] https://www.europarl.europa.eu/legislative-train/spotlight-J...
[1] https://www.europarl.europa.eu/RegData/etudes/ATAG/2023/7392...
[2] https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=COM%3A20...
I believe the legislators are generally well-intentioned, but that is worth nothing.
Laws and regulations should be judged by what they will do. In this case, they will make security worse, witg no adquate compensatory advantage, so it should be rejected.
Laws and regulations should be judged by what they will do. In this case, they will make security worse, witg no adquate compensatory advantage, so it should be rejected.
> I would really like to read the actual full text document.
I think they are not releasing the full text to protect their source in case the text was steganographically marked.
I think they are not releasing the full text to protect their source in case the text was steganographically marked.
[deleted]
The secret text of Article 45:
> I have access to the near-final text of the regulation, which is not yet public, but was leaked to me by a confidential source.
‘qualified certificate for website authentication’ means a certificate for website authentication, which is issued by a qualified trust service provider and meets the requirements laid down in Annex IV; Evaluation of compliance with those requirements shall be carried out in accordance with the standards and the specifications referred to in paragraph 3.
Qualified certificates for website authentication issued in accordance with paragraph 1 shall be recognised by web-browsers. Web-browsers shall ensure that the identity data attested in the certificate and additional attested attributes are displayed in a user-friendly manner. Web-browsers shall ensure support and interoperability with qualified certificates for website authentication referred to in paragraph 1
Qualified certificates for website authentication shall not be subject to any mandatory requirements other than the requirements laid down in paragraph 1.
1. Web-browsers shall not take any measures contrary to their obligations set out in Art 45, notably the requirement to recognise Qualified Certificates for Web Authentication, and to display the identity data provided in a user friendly manner.
2. By way of derogation to paragraph 1 and only in case of substantiated concerns related to breaches of security or loss of integrity of an identified certificate or set of certificates, web-browsers may take precautionary measures in relation to that certificate or set of certificates
3. Where measures are taken, web-browsers shall notify their concerns in writing without undue delay, jointly with a description of the measures taken to mitigate those concerns, to the Commission, the competent supervisory authority, the entity to whom the certificate was issued and to the qualified trust service provider that issued that certificate or set of certificates. Upon receipt of such a notification, the competent supervisory authority shall issue an acknowledgement of receipt to the web-browser in question.
4. The competent supervisory authority shall consider the issues raised in the notification in accordance with Article 17(3)(c). When the outcome of that investigation does not result in the withdrawal of the qualified status of the certificate(s), the supervisory authority shall inform the web-browser accordingly and request it to put an end to the precautionary measures referred to in paragraph 2.
There is also recital text which I did not copy.
> I have access to the near-final text of the regulation, which is not yet public, but was leaked to me by a confidential source.
‘qualified certificate for website authentication’ means a certificate for website authentication, which is issued by a qualified trust service provider and meets the requirements laid down in Annex IV; Evaluation of compliance with those requirements shall be carried out in accordance with the standards and the specifications referred to in paragraph 3.
Qualified certificates for website authentication issued in accordance with paragraph 1 shall be recognised by web-browsers. Web-browsers shall ensure that the identity data attested in the certificate and additional attested attributes are displayed in a user-friendly manner. Web-browsers shall ensure support and interoperability with qualified certificates for website authentication referred to in paragraph 1
Qualified certificates for website authentication shall not be subject to any mandatory requirements other than the requirements laid down in paragraph 1.
1. Web-browsers shall not take any measures contrary to their obligations set out in Art 45, notably the requirement to recognise Qualified Certificates for Web Authentication, and to display the identity data provided in a user friendly manner.
2. By way of derogation to paragraph 1 and only in case of substantiated concerns related to breaches of security or loss of integrity of an identified certificate or set of certificates, web-browsers may take precautionary measures in relation to that certificate or set of certificates
3. Where measures are taken, web-browsers shall notify their concerns in writing without undue delay, jointly with a description of the measures taken to mitigate those concerns, to the Commission, the competent supervisory authority, the entity to whom the certificate was issued and to the qualified trust service provider that issued that certificate or set of certificates. Upon receipt of such a notification, the competent supervisory authority shall issue an acknowledgement of receipt to the web-browser in question.
4. The competent supervisory authority shall consider the issues raised in the notification in accordance with Article 17(3)(c). When the outcome of that investigation does not result in the withdrawal of the qualified status of the certificate(s), the supervisory authority shall inform the web-browser accordingly and request it to put an end to the precautionary measures referred to in paragraph 2.
There is also recital text which I did not copy.
[deleted]
Url changed from https://twitter.com/Scott_Helme/status/1721905520788086836, which points to this.
It's pretty funny to me when people defend PKI as something good and nice, especially while criticising EV.
As it stands, PKI is EXACTLY good for spying, MITM etc attacks.
I so wish that a) governments would become their own CAs, this would finally allow us to have actually reliable and secure government level communications and b) tofu would be the standard when communicating with anything on the internet.
PKI is CIAs wet dream, and it's infuriating how people just skip right over that. I actually think it's highly likely that certificate pinning was actually killed because it allowed tofu and basically removed all need for outside control.
As it stands, PKI is EXACTLY good for spying, MITM etc attacks.
I so wish that a) governments would become their own CAs, this would finally allow us to have actually reliable and secure government level communications and b) tofu would be the standard when communicating with anything on the internet.
PKI is CIAs wet dream, and it's infuriating how people just skip right over that. I actually think it's highly likely that certificate pinning was actually killed because it allowed tofu and basically removed all need for outside control.
Can you explain how exactly you believe a government can exploit the PKI to MITM traffic to, say, google.com? Especially how they could do so in a way that wouldn't have been much easier if they (a) could force a browser to trust an insecure CA or (b) intercept my initial communication if they know I'm doing TOFU?
I recommend that you, for example, look into the very recent attack on the Russian Jabber service that was talked about here a lot a couple of weeks back.
Companies, doesn't even have to be the CA themselves, are very easy to coerce into doing the governments bidding, and it doesn't even have to be the entire company, just one person is enough, it's just a change in law that most outside of IT circles support, and it's already law in many, many places.
Like it or not, country level domains are already under the control of their respective country.
And PKI is enabling this coercion, it simply wouldn't be possible if we didn't place trust on these third parties, and place our trust in them all the time, that's a 3 months maximum wait.
As for "bootstrapping" trust, your first connection is always going to be about trust unless you have a side channel to provide you trust (basics of encrypted communications), so trusted CAs are in no way special here, I would much prefer if this trust was provided by say Debian, as it provides the software I'm running. I even much more trust a first connection validity vouched for by an actual government, especially say from Finland than I would trust one vouched for by just some random company.
As for tofu, you do realise attacking it requires capturing and changing ALL traffic, forever, to be effective, as as even though SSH doesn't do it, it's super easy to add forward secrecy to it with a signature update mechanism.
And once you have tofu, you are set. If you can compromise that channel you can also compromise PKI.
PKI is strictly worse than TOFU.
Random company CAs are strictly worse than governments themselves vouching for connections.
PKI is CIAs wet dream.
Companies, doesn't even have to be the CA themselves, are very easy to coerce into doing the governments bidding, and it doesn't even have to be the entire company, just one person is enough, it's just a change in law that most outside of IT circles support, and it's already law in many, many places.
Like it or not, country level domains are already under the control of their respective country.
And PKI is enabling this coercion, it simply wouldn't be possible if we didn't place trust on these third parties, and place our trust in them all the time, that's a 3 months maximum wait.
As for "bootstrapping" trust, your first connection is always going to be about trust unless you have a side channel to provide you trust (basics of encrypted communications), so trusted CAs are in no way special here, I would much prefer if this trust was provided by say Debian, as it provides the software I'm running. I even much more trust a first connection validity vouched for by an actual government, especially say from Finland than I would trust one vouched for by just some random company.
As for tofu, you do realise attacking it requires capturing and changing ALL traffic, forever, to be effective, as as even though SSH doesn't do it, it's super easy to add forward secrecy to it with a signature update mechanism.
And once you have tofu, you are set. If you can compromise that channel you can also compromise PKI.
PKI is strictly worse than TOFU.
Random company CAs are strictly worse than governments themselves vouching for connections.
PKI is CIAs wet dream.
> At the top of my list of concerns is that browser and client vendors (Root Store Operators) will have a legal obligation to add Government mandated Root Certificate Authorities to their Root Stores, bypassing existing approval mechanisms.
> Yep, you read that right. Government mandated Root Certificate Authorities...
> I could end this blog post right here because anyone reading this will understand the significance of such a statement, and just how much of a catastrophically bad idea that is, but it gets worse.
At the end of the day, (other than the EV-like “additional attested attributes”, which have been tried and were not a success), this makes quite a bit of sense: the EU is the authority as to the mapping from foobar.eu to whatever logically lives there. Norway is the authority mapping foobar.no. The US likewise controls .us, etc. So, if the EU says that foobar.eu maps to some public key, who is Google or Mozilla or Apple to question it?
Of course, all of this is ignoring massive technical issues. DNSSEC really does map domain names to attributes (but not individual names!) in a verifiable manner, and DANE can extend it to HTTPS, but DNSSEC is massively problematic. And the CA / WebPKI system is a baroque mess that is, finally, sort of under control. And the actual leaked text of the proposal does not respect any of what got the CA system under control.
I can imagine a situation in which the EU (through its qualified agents) could attest, cryptographically, which CT or its equivalent, that a domain name in .eu maps to a given certificate, and browsers should accept that. Except this is pointless — browsers already accept the equivalent of this.
IMO it would be more valuable for the EU to do the converse: require that browsers not accept a .eu certificate without attenuation from the EU. Raise the bar, don’t lower it! The EU absolutely has an interest in preventing a US (or Chinese or whatever) entity from falsely certifying an EU site.