For example, if you use private "e2echat.com" it can still use safe certs and be safe, the risk is only that "governmentchat.com" will use bad certs, which was already a risk.
This is still very bad.
Yes, potentially, but it isn't "another kind of chat control".
It is similar to how Chrome displays a warning when you visit some sites. You can visit the site anyway, but you get a warning since Google thinks it is bad.
Mozilla has proposed text[1] that would make clear that the requirement is only to display identity information, but this text has not been adopted.
[1] https://securityriskahead.eu/wp-content/uploads/2023/09/Mozi...
Accepting certificates from a given issuer does not give them the issuer the right to impersonate others
(Still bad but would at least protect connections from ever talking to e2echats servers)
In the general case, any CA can sign any website certificate. So all those new government CAs can sign all the man-in-the-middle certificates they like, and browsers are obliged to accept them. Nothing the website can do about that.
There are ways to pin certain CAs via DNSSEC and TLSA resource records in DNS. But browsers ignore those, and even if they didn't, the same EU proposal also specifies government DNS manipulation.
So the gist is: EIDAS must die.
And if the site can see your data assume the government can see it as well, they can get it with a warrant.
A warrant will maybe warn the site and the user that something is going on.
A man-in-the-middle attack without a warrant delivered to either party is more likely to go undetected.
Updating others javascript as a proxy isn't "easily".
Also if the government goes all this way to tell each internet provider to spy on people, why do you think they couldn't tell certificate authorities to spy on people? It is the same level. I wouldn't be surprised if many CA's in USA already does this.
And the way to spy on people via a certificate authority is exactly as described, you get a CA that signs your man-in-the-middle certificate for a website you do not own. Then you MitM that traffic using that certificate, while still getting a green "lock" icon.
With current WebCA certificates, certificate transparency does help a little to detect such MitM certificates, and some CAs have actually been caught red-handed. There are processes to punish or remove such CAs. However, this law would also prevent such actions, thus making it impossible to prevent any future malfeasant CAs.
About an example MitM certificate case and removal, see the DigiNotar case: https://blog.mozilla.org/security/2011/08/29/fraudulent-goog...
For more about how certificate transparency works see http://nil.lcs.mit.edu/6.824/2020/papers/ct-faq.txt
If this means users gets more power over what CAs to trust then that is a good thing.
And depending on how that law will be interpreted by courts, manually distrusting might be considered illegal.
It is just a display change, all the law says is:
"For those purposes web-browsers shall ensure that the identity data provided using any of the methods is displayed in a user friendly manner."
I don't see how adding a warning icon or block icon instead of the lock hurts would be banned. To me it seems like so much here is based on baseless assumptions.
I would also urge you to refrain from using terminology such as "baseless assumptions" when your own assumptions are so easily refuted by directly reading the text of the proposal.
Do you really think your average user is going to go into the browser and manually distrust root CAs? We have learned again and again that good security is "secure by default", not "secure after arcane configuration".
The weakness is only if someone controls your internet connection and can use a compromised certification process to trick you into thinking you are at "e2e.com" when you are on another site, and in those cases the only difference from now is that your browser will display "secure" instead of "invalid cert". There is no other difference.
So to orchestrate an attack they would need to build an webbapp that is sufficient similar for you not to notice, take over your internet connection and break the certification process.
That will be (or already is) done at ISP level. It will probably be fully automated, where they just put a court order number into a form, and it automatically just catches all your traffic in gear that's installed at the ISP.
Also, MITMs are a thing and getting the EIDAS certs in the root store will show that the certs in question are trusted, which is all that really matters because there is no way for users to know what certificates were actually installed by the website owner.
TLDR: If you are worried about security you can always install a plugin to get back the old behavior. This just says that browsers should be able to trust them, not that you have to configure your browser to trust them.
The moment people learn that the US government could control a CA and your internet provider to spy on you maybe that will change. But as is people think it is too much work for governments to bother with it.
I'd call that bs, CA level attacks are very unlikely to be detected, so we know little about their prevalence.
(you edited your comment to add... that it requires you to control the targets internet connection?? And "the moment people learn that thenUS government could control (a CA) and your internet provider to spy on you maybe that will change With tls becoming ubiquitous they're now indispensable
It originally was
* I'd call that bs, CA level attacks are very unlikely to be detected, so we know little about their prevalence.
With tls becoming ubiquitous they're now indispensable*
Oh that's SUCH as an insignificant difference!!!
> So to orchestrate an attack they would need to build an webbapp that is sufficient similar for you not to notice, take over your internet connection and break the certification process.
You can simply relay the requests to the original site/"webapp", no need to build one similar
Doesn't work if the app encrypts messages locally, so end to end encryption is still valid with this.
The only way around this would be a "real" app.