| HN Mirror

gallexme 964 days ago

Wouldn't a client certificate from e2echat protect that kind of attack ? Since even when a man in the middle offers u a server cert u accept, the e2echat servers can't validate the client certificate from you anymore

(Still bad but would at least protect connections from ever talking to e2echats servers)

Filligree 964 days ago

Nobody uses client certs.

> This is still very bad.

Yes, potentially, but it isn't "another kind of chat control".

It's another side of the efforts of going around encryption, chat controls deals with communication services, this one with browsers

But this doesn't force browsers and sites to use weak encryption. It is very different.

This forces browsers to accept all the CAs approved by the EU states, and you can be certain that some of them will be used for decrypting (and if needed modifying) the traffic

And then you can just tell the browser to not trust those CAs and you are safe. This is nothing like "chat control". This only lets the government spy on people who don't care if the government spies on them.

no_time 964 days ago

Luckily, I never said anything like this anywhere.

raverbashing 964 days ago

Yes, I agree. The crying wolf is too much sometimes.

Accepting certificates from a given issuer does not give them the issuer the right to impersonate others

All root CAs can issue certificates for any site (except those with CAA records etc.)

There is no way for e2echat.com to make sure that the client will insist on a certain safe CA. Sure, in case e2echat.com controls all clients this would be possible, but this is a rare case.

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.

You still wont be able to break the end to end encryption of a site. You can only intercept traffic that the server can read, you can't intercept traffic that are encrypted end to end.

And if the site can see your data assume the government can see it as well, they can get it with a warrant.

Website-based end-to-end encryption isn't usually. In most cases, the "e2e-encrypting" website will deliver the Javascript that does the "e2e-encryption", which can easily be manipulated to provide a copy of all messages to some convenient third location.

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.

> which can easily be manipulated to provide a copy of all messages to some convenient third location.

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.

It is "easily", because current commercially available "firewall" appliances include that kind of capabilities. Just a few clicks, install a CA certificate, add a logging endpoint, done. Certain regulated industries like finance and medicine are required to use those. All chats are instantly intercepted and logged.

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

Maybe browsers shouldn't hardcode those things? If they let you blacklist CAs you could do that yourself or via a plugin. There is nothing preventing browsers from implementing that, and have a one click button "don't trust compromised CAs". Could even had that during install as a toggle, would satisfy every legal requirement.

If this means users gets more power over what CAs to trust then that is a good thing.

Oh yeah if encryption is broken only for browsers no big deal right

Governments still can't see your requests to servers under normal circumstances with this law.

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.

calgoo 964 days ago

"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"

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.

It is only undetectable if the site actually uses the vulnerable certificates. Otherwise you can see that the government is spying on you since the browser tells you what certificate it got (Telling you what certificate was used is a part of eIDAS). There is no way the government will replace certificates like that on an automated basis, it is too easy for people to notice and make a big deal about.

supriyo-biswas 964 days ago

If a nonprofit like Let’s Encrypt can perform automated certificate renewal with a few API calls, so can the government.

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.

That has nothing to do with this, I don't think you understand this vulnerability. You can see which certificate authority issued the cert, so you can see if the suddenly the site started using a vulnerable cert provider and thus know that it is compromised. Note that the same attack is possible right now, the only difference is how your browser displays it, you can just install a plugin to get back the original behavior if you want. So this in no way prevents you from secure browsing.

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.

There's probably at most one person every ten millions who uses add-ons displaying each connection's certificate authority; and even them will likely not notice anything if it's only done to them occasionally (not to mention that absolutely no one checks the connections used to download third-party stuff, to my knowledge).

Yes, because CA level attacks are basically nonexistent and not a very big deal since they require you to control the targets internet connection.

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.

> the only difference from now is that your browser will display "secure" instead of "invalid cert". There is no other difference.

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

> 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.

We're talking about normal browsing, not webapps performing their encryption

Webapps are also vulnerable because the Javascript can be manipulated in a MitM attack.

The only way around this would be a "real" app.