"In summary, we strongly warn against the currently proposed trilogue agreement, as it fails to properly respect the right to privacy of citizens and secure online communications; without establishing proper safeguards as outlined above, it instead substantially increases the potential for harm."
The Open Source Security Foundation (OpenSSF) has co-signed the Industry Joint Statement on Article 45 in the EU’s eIDAS Regulation, indicating that "Those provisions are likely to weaken the security of the Internet as a whole":
https://openssf.org/blog/2023/11/02/openssf-co-signs-industr...
Good morning. It has actually been happening all around the world, not just in the EU. Given how governments encroached on crypto and ad tech and social tech and in the last 10 years, the writing is on the wall for end-to-end encryption next. They have to know ALL your communications:
I wrote a summary of the countries in the world that have already undermined it, banned it or on the way to banning it:
The pushback against ad tech - or more precisely tracking tech - is hardly the same thing. One of the EU's moves will greatly improve privacy, another one will harm it.
A world is possible where we have end-to-end encryption AND a ban on profiling people online without their consent.
Sure, and a world is possible when we have other types of tech, too. For example we can have zero-knowledge proofs to access online sites and prove we’re over 18. But the UK government has already passed a law requiring all websites to KYC their members with a passport. And Utah recently passed a law also protecting children on social sites and I asked their politicians directly how they will enforce it — a likely candidate will be requiring ID from everyone.
But the governments when all is said and done don’t care about your privacy.
I'm no fan of the existing system of CA - in 2023 we should have certificate pinning for sites with mechanism for checking which certificate hashes are valid for which site (via a distributed ledger or via browser vendors etc).
However this amendment is disgusting.
I was one of the many experts reviewing previous drafts; the timing and content of these changes are absolutely an attempt by security services to break security on the web.
We're already all used to running ad/script block on our clients so accept a certain level of breakage. It's just a part of the cost of using the web that some sites are crap (youtube being the big one nowadays) but in the end we just "route around them" (they die).
> We're already all used to running ad/script block on our clients so accept a certain level of breakage.
The "we" reading this post? Yeah, probably.
The internet population as a whole? Absolutely not, nowhere close.
I've been using Adblock or its descendants since the original Firefox extension where downloadable filter lists were a separate addon, and every time I have to browse a mainstream web site when using a "normal" person's computer it blows my mind how bad the experience is with all kinds of extra iframes I never normally see full of ads moving around, modals, etc. without even getting in to video content.
Normal people don't troubleshoot things like we do, if it doesn't work they try to do the same thing over and over again until they get bored or annoyed and then either move on or call one of us to "fix it".
Exactly. Besides, why should a grandma lose online banking access because some IT guy (or gal, I'm not judging) fat-fingered a certificate revocation in production and now the site is broken?
>in the end we just "route around them" (they die)
My comment was about the perspective of the website owner, not the website user. The website owner certainly doesn't want to be routed around and have the website die. So the website owner will avoid HPKP.
Interesting - I know DNSSEC (great solution) but haven't seen DANE. From a quick glance it looks like an obvious solution which should be implemented by the browser vendors and top sites.
DNSSEC is a great concept with a rather convoluted design that's based on limitations of computers in the 90s. It's obviously better to have DNSSEC than not to, but I wouldn't call it a "great solution".
Case in point: the DNS client never actually validates the DNSSEC signatures, the DNS server the client uses is supposed to do that, and then simply sets a flag that says "I validated this". Perfect for recursive DNS resolvers running on localhost, but terrible for security when applied as designed.
Another example: Firefox currently has encrypted client hello enables to encrypt the SNI information and help combat traffic analysis, but only if you enable DoH to ensure that the necessary DNS records are correct. Once again, Mozilla didn't trust DNSSEC to work right and opted to trust DoH servers on their word.
In truth, DNSSEC isn't widely used, at least not internationally. Some TLDs have high DNSSEC usages, often because their registrar advocates for securing DNS, but with companies like Amazon failing to produce DNSSEC software that doesn't cause massive outages and TLDs like .nz going down for a day because of bad policies and management, many people don't bother.
It's a shame, really, because DANE would've fixed so many problems. I attribute its failure mostly to the design decisions the people behind DNSSEC made when they released the protocol.
> It's a shame, really, because DANE would've fixed so many problems.
It would basically make services like Let's Encrypt unnecessary and would move us close to a world where email encryption and validation works by default.
It would take us to a world where the only CA you can and have to trust is the TLD operators and their nation. Where transparency is mostly an afterthought and violators can't be forced to do anything.
> The proposed eIDAS revision gives Member States the possibility of inserting root certificates at will [..]
That should've been a clear problem when architecting this system for anyone that knows how PKI works. Control and transparency around CAs (especially roots) is extremely important for web security.
Did they not consider issuing citizens with WebAuthn certificates, or working with browser vendors to support using client certificates (since they'd only need to be trusted by the server, not the client)?
Knowing the EU is behind this, I wouldn't be surprised if the people making decisions about this are even aware of any technology beyond Windows XP.
The funny thing is that several European governments have actually operated certificate authorities of their own, and they worked just fine.
It's so stupid, because the rest of the eIDAS is a pretty good idea.
From what I can tell, this stupid addendum is the result of the certificate authority industry, which were mad that nobody trusts EV certificates anymore (because they never added the security they promised in the first place).
WebAuthn uses private keys in the secure enclave. It won’t be affected.
To be clear: EU here is backdooring https encryption which protects most communication, not signing. While also moving to ban end-to-end encryption (Spain leading the way).
If this goes through without change the browser vendors should implement an UX which allows the user to disable these root certificates; ideally within different contexts.
I also hope that our community produces tools to allow the cert stack on our OSes to be purged of these certificates.
Then they’ll ban that UX. Just like US banned the ability to disclose how much taxes you pay for airline tickets
EDIT: for clarification, they banned disclosing it in initial communications like emails. They can do same for browsers. Apple also successfully banned apps from disclosing links to buying stuff online etc.
I can still see taxes and fees when I'm booking a flight. I just checked on delta.com . I can see the total taxes and fees, and the breakdown of what they are and how much each one is. I'm in the US.
Well, if Spirit Airlines is in fact being ingenuous, then they're -at best- one of the good guys demonstrating Why We Can't Have Nice Things.
What happens is that -in some countries I've visited- people can legally advertise a particular sticker price, and then when you actually go to pay, you pay a very different amount. That threw me for a loop the first time I encountered it. I felt they were being tremendously dishonest.
Where I live, you are totally permitted and encouraged to also provide an itemized price breakdown, but the sticker price is what I'm paying you at the end of the day. No surprises for the consumer.
> for clarification, they banned disclosing it in initial communications like emails
please give a source for that. That's the spin some airlines gave it, but as far as I understood the new requirement was to list the full price including taxes and fees in advertisements. This could be seen as hiding the fees and taxes, but the Airlines are still allowed to list fees and taxes.
In Europe, listing the full price is mandated for all industries as far as I know. Feels bad as a customer to not know what you will have to pay upfront, like it is in most industries in the US. But it also feels weird to me that this ruling was only applied to the air travel industry.
How much tax there is to pay is not my problem as a consumer. The only thing that matters is how much it will cost me to get the thing. Everything one must pay, including all fees and taxes should be included. Listing these will only cause unnecessary confusion and is often done in a deceptive manner.
It has nothing to do with adding root certificates to browsers. These are consumer protection laws against deceptive advertising. It may be surprising to Americans but in most of Europe, thanks to such laws, the price you see is usually the exact price you are paying. No taxes, fees or tips, it is all included, which I think is better for everyone.
We already have that option. At least on desktop OSes. On mobile it's hard, especially on Android it's no longer possible to add root CAs in the system store without rooting, ever since Android 7.
I believe on iOS you can do it with an MDM profile.
I would say it's not speaking against the intel agencies. The intelligence community protects us from many threats (terrorists, foreign organized crime, etc.). However, they are human, and make mistakes in the name of self-preservation, zeal for their mission, and in some cases greed.
The intel agencies of different countries act as checks and balances against each other, to some degree. In some countries there are enough different intel agencies that they act as checks and balances against each other.
However, the voice of the public is a great additional check on their behavior, especially when amplified by mainstream media and social media. Our elected officials want to be re-elected. Many will change their tune if they feel there is enough outcry that it might affect their poll numbers. And this is the only legal way to effect change in many countries.
speaking to emphasize layered representation, not the future-value of a single vote or wave of voters...
Those representatives in a position to affect the arc of the actions here, especially those who work in the civilian sphere regularly, need all manner of support now.
Making porn sites KYC is likely something that the public wants.
There have been numerous cases of nude pics of minors ending up on "amateur" porn sites.
It would be nice if browsers can require that certificates be co-signed by multiple, mutually distrusting root CAs, such as a hypothetical EU CA whose certificates are only trusted if also signed by an OSSF-backed root CA.
Thank god they're fixing this. Can't wait for Java to also pick up third party certificates. Every time I install my personal CA certificate I need to go through every application and do the special certificate dance (in the case of Electron, modifying the launch arguments) because every application is opinionated about what certificates it should trust for some stupid reason.
Every OS has an API for this, why should I need to go into the special super secret debug settings to tell an application "trust the system you're running on and use the damn API already".
As I commented there, you've misunderstood this change.
There's a difference between certificates distributed with the OS and certificates added to the OS by a user. Right now Firefox ignores both.
This change ONLY picks up the certificates added to the OS by a user. Firefox will continue to ignore the certificates included with the OS store by default.
Literally in the bugzilla entry is stated either by user or administrator so either you misunderstood or you need to raise this directly to the bug for correction
EDIT: for clarity, something I should have done from the beginning, I checked the affected code, they clearly remove warnings around security.enterprise_roots.enabled preference and enable it by default. This is the preference that was added back in the day to control if the browser will allow root certificates added to the OS no matter the source (user or system context) and now they change it to true by default. I think this provides more clarity but feel free to search the affected code for references that indicate that only part of the root certificate store is trusted
Late so don't if you will see this, but from the very beginning, the security.enterprise_roots.enabled preference always stated it applied to certificates added, not those included by default, eg [0]. System vs User context is still different from baked-in vs added. On macOS for example the System keychain contains certificates added that are then accessible by all users and can only be added by an Administrator, and the separate System Roots keychain holds the root certificates (151 on the Mac I'm sitting in front of) that Apple ships with the OS. Firefox reading from both the "login" and "System" keychains doesn't mean reading from "System Roots". The suggested release notes for the bug report you linked reinforces this [1] (capitalization emphasis added):
>[Suggested wording]: By default, Firefox will now use TLS trust anchors (e.g., certificates) ADDED to the operating system by the user or an administrator. This works on Windows, macOS, and Android, and it can be turned off in the "Privacy & Security" section of Firefox settings, under "Certificates".
If you think all of these descriptions have been wrong all along from the code, that'd definitely be worth bringing up on Bugzilla. Personally I'm happy to have it enabled by default vs always needing to remember to do so if it's working as described. I think support for one's own CAs should be encouraged even the overall UX around running your own CA is mediocre right now.
>"Mozilla has added an Enterprise Roots preference to Firefox as a solution to the problem. This preference can be used to import any root certificate authorities (CAs) that have been added to the operating system, to resolve your TLS connection error. You can determine if a website is relying on an imported root certificate by clicking the Site Information icon in the address bar."
Https always had problems with the long list of mysterious root certificates. Maybe this is the push needed to do something about it, e.g. :
* Warn when a new root is user for the first time.
* Warn when a site changes its root cert.
* Warn when a root cert is used for DNS names that shouldnt belong to it, e.g. wrong tld.
In a broader context, the question who you trust when will become more and more important. E.g. deepfakes might push us all to digitally sign their real messages. I don't think the current root certificate systems can survive the deluge of mistrust generated by AI.
Wow. Does the EU intend on basically killing their economies? Online commerce is a huge deal and would be heavily impacted if people didn't trust their connections.
Well, for now most people do trust the states and don't know the implications of this. The EU could have just as well modified e-commerce and other pages before everything was encrypted.
I also don't know how certificate pinning is impacted by this (which would mean that simply creating another cert from a EU root cert would at the very least be noticable)
Why would people worry? We already have mobile phones, televisions, cars, etc., continuously monitoring and sending private information about ourselves and our relatives to external parties that we may don't even know about. This -if comes to be true- would just mean that more parties could have access to our data. But who cares once we are already giving it for free?
Isn’t there a way to do away with CA and do it on the block chain?
BUT to be clear the governments shouldn’t be compromising the security of their own people and organisations in the first place. We can’t technology our way out of this behaviour!
This would be really easy to detect. Just look at the certificate chain.
It would be trivial to make a plugin to warn the user of this, at which point they know they're under surveillance which would be worse than just doing human surveillance IMO.
Almost nothing coming out of the EU that touches encryption makes sense these days, even when viewed from their own perspective. It's like they are desperate to get any kind of crypto regulation into the door before some deadline and consequences be damned.
I say this with the upmost request to their politicians, but their politicians have no clue what they're doing. They clearly don't understand how any of this works. None of what they propose can solve the issues they claim they want to solve. Not this, not client-side scanning, nothing. I genuinely wonder who's "advising" them on this stuff and what their true motives are.
It's sad to see the EU like this but nothing lasts forever. I feel sad for the next generations. They'll be the ones to bare the full brunt of these misguided regulations.
Could we work around this by moving encryption to the application/website layer with client certificates? Please let me know if you see any reason this wouldn't work.
You still have a bootstrapping problem. How do we establish what application-layer signatures are valid when a member state can forge a certificate for any origin at the transport-layer?
Ideally through hardware keys, but I see how that's hard to adopt. It's not entirely unrealistic though in the context of Play Store/App Store for the first download of an app from Google/Apple servers to be protected in transport by hardware keys.
Do the web browsers & operating systems face the same bootstrapping problem at the moment? At some point they must get their first certificate without using a certificate protected connection?
Edit - in the context of service which exists pre regulation, the client certificate could also be derived from the user's existing login credentials.
Of course they face that problem. It's a subset of the more general bootstrapping problem for a computer. So far, it mostly works as long as we can trust the hardware and we assume that the stack as we have it now is trustworthy.
As soon as you download and install an OS via an MITMed connection, it's over.
By using pre-shared keys instead of public key encryption. I'm not suggesting that is a practical solution for day-to-day use; I am saying this is how LE will be evaded, if this law should come to pass. So in effect, only criminals will have encryption.
The Open Source Security Foundation (OpenSSF) has co-signed the Industry Joint Statement on Article 45 in the EU’s eIDAS Regulation, indicating that "Those provisions are likely to weaken the security of the Internet as a whole": https://openssf.org/blog/2023/11/02/openssf-co-signs-industr...