Cryptography works. At least until sufficiently powerful quantum computers arrive, TLS reliably ensures confidentiality between your browser and the server. No one else can snoop on the data transmitted via that connection.
But are you connected to the right server? Without some kind of authentication, any adversary in the middle (such as your ISP) could impersonate the real server.
That is where certificates come in. They are issued by neutral certificate authorities (CAs) that check the identity. It works something like this:
- I, the server operator, create a private key on that server. I use that key to create a certificate request which asks the CA to give me a certificate. This request also contains the domain names for which the key shall be used.
- The CA performs identity checks.
- The CA issues me the certificate. I install it on my server. Now, when browsers create a TLS connection I can tell them: here’s my public key you can use to check my identity, and here’s a certificate that shows that this is a valid key for this domain name!
- The browser will validate the certificate and see if the domain name matches one of the names in the certificate.
What kind of checks are done depends on the CA. I’ve obtained certificates by appearing in person at a counter, showing my government ID, and filling out a form. Nowadays more common is the ACME protocol which enables automated certificate issuance. With ACME, the CA connects to the server from multiple network locations (making interception unlikely) and checks if the server provides a certain authentication token.
To know which certificates are valid, browsers must know which CAs are trusted. Browser makers and CAs have come together to create an evolving standard of minimum requirements that CAs must fulfill to be eligible for inclusion in the browser’s default trust store. If a CA violates this (for example by creating certificates that can be used for government traffic interception, or by creating a certificate without announcing it in a public transparency list), then future browser versions will remove them, making all their certificates worthless.
eIDAS 2 has the effect of circumventing all of this. There is to be a government-controlled CA (already high-risk) that has its own verification rules set by legislation (does not meet industry standard rules). And browsers would be legally forced to include the eIDAS CAs as “trusted”.
This puts browsers in a tough spot because they’ve resisted these kinds of requests from authoritarian regimes in the past. But now the world’s largest trade bloc is asking. Browsers can comply or leave the EU market, or maybe provide a less secure EU edition? Awakens uncomfortable memories around the failed US attempts at cryptography export control (cryptography is considered a munition, like hand grenades or ballistic missiles).
It is plausible that the EU is doing this with good intentions: having a digital identity scheme is useful, it makes sense for identity to be government-controlled (like passports), and such a scheme will only see success if it sees industry adoption. The EU has also seen that hoping for voluntary industry adoption doesn’t generally work, e.g. see the USB-C mandate.
wdx@feddit.de 7 months ago
There can be an infinite amount of certificates for a single domain.
When you setup a connection to a website you basically get a response back that has been signed with a certificate.
Your Browser / OS has a list of certification authorities that it deems trustworthy.
So when you get the response the browser checks if the certificate was issued by a trusted CA.
Now, if the EU forces browsers to trust their CA they can facilitate a man-in-the-middle attack.
In this instance they will intercept the TLS Handshake and give you back a response that was signed by their certificate. Your Browser deems the certificate valid and sets up a secure tunnel to the EUs Server.
From then on they can forward packets between you and the real website while being able to read everything in cleartext