> Without IdenTrust, Let’s Encrypt may have never happened and we are grateful to them for their partnership.
What I have never understood is why IdenTrust accepted to cross-sign Let’s Encrypt's root certificate.
With that move, IdenTrust basically broke the CA cartel and helped driving the price of basic certificates to zero. How did they, as a for-profit organization, justify "doing the right thing" when that meant disrupting their own market?
My professor was one of the founders of Let's Encrypt. He said it was basically a game theory problem. Whichever CA defects gets money. The rest get nothing. IdenTrust decided to get that money, because they thought that if they didn't, a different CA would.
Exactly, but the funny thing is that Chrome and Firefox (Desktop at least) are no longer showing the differentiating green lock for those high-end (EV & OV) certs, but the same neutral-looking lock as those Domain-Validated (DV) certs that Let's Encrypt is issuing.
I'm very grateful for IdenTrust for having made that move. I just hope it won't hurt their business too much because of that.
Does anyone in enterprise actually need publicly trusted certificates for documents and email? Seems like it's an inside-the-firewall Exchange server for internal traffic, and a white-label "secure messaging center" portal for external traffic.
They offer a variety of enterprises services and can now capture more of the marginal consumer value relative to competitors still fighting for the cert issuing market.
Yeah they likely got a stash of money for it while the other CAs got nothing. First mover advantage I guess. It's not that they'd have been able to prevent it anyways, as the root stores are not under their control, especially when Let's encrypt is being supported, even started, by the entities which run the root stores (Mozilla, through Firefox, and Google, through Android). Ultimately it's the entities which run and deploy the root stores who have ultimate say on which CA gets to issue certs and which doesn't.
I'd be very surprised if an app without root privileges could install a new root certificate. If an app installed a malicious (or even just a poor quality) certificate, that would be a pretty big compromise to the OS.
What is strange to me though, is that it seems like the OS should have a mechanism to update the root certs independently of the OS itself. Then again, not updating root certs is a way to put an expiration date on a phone, forcing customers to buy more phones...
(3) Chrome is migrating to using it's own store: "Historically, Chrome has integrated with the Root Store provided by the platform on which it is running. Chrome is in the process of transitioning certificate verification to use a common implementation on all platforms where it's under application control, namely Android, Chrome OS, Linux, Windows, and macOS. Apple policies prevent the Chrome Root Store and verifier from being used on Chrome for iOS."
Let’s Encrypt cross-signature with IdenTrust "DST Root X3" is ending on September 1, 2021 but 33.8% of Android devices are running versions under 7.1 which don't trust Let’s Encrypt new root certificate "ISRG Root X1"
Unfortunately, on my Moto G5 Plus (which is not an high-end device), I've found that Firefox on Android is slower than Chrome (specifically the Bromite fork). I think that Firefox may not be a good solution for low-spec or older phones running older Android versions.
Firefox is not a workaround for non-web mobile apps. Lots of them will stop working unless they do cert pinning / have their own CA bundle or simply stop using LE..
The most impressive thing it that Let’s Encrypt are the ones who are trying to fix a problem that should be fixed by phone manufactures and telcos.
I can see why, but I would also have like the phones to “break” so the owners would avoid those brands in the future, and pick one who care enough to push out update.
Still, I can blame Let’s Encrypt, they just want to be the good guys, and the do it so beautifully and transparently.
It probably wouldn't encourage many people to upgrade their phones, though. They would probably just see the website as broken and either click through the warning or abandon it completely
Google sells you a pocket computer with a locked down OS, not for your safety but to control the ability to run ads.
If they cared about user security, they would provide updates, no matter how "slow" (their excuse) the device gets.
If they didn't want full control to show ads (ads are downloaded by the GooglePlayServices, which is pretty much the kernel of all your android experience) then it would be trivial to install other android distributions like replicant.
hence, both a reasonable and google is evil. They want full control and do not care about (your) security updates.
Could Google possibly be able (before were discuss willingness) to push an update to root certificate via Play Services?
I'd like to think that anyone not using Play Services (i.e. Android with no Play) is likely using a custom browser, and would heed a call to switch to Firefox.
The problem with some devices in Africa would be that many people will using older phone often don't have enough data for the big Play updates to succeed.
Teens often buy 10-100MB of data so they can use WhatsApp. (If you're from Southern Africa, and disagree with this, hit me up, you probably need to spend some time in a village ;) )
No play services on an Android phone in the US probably implies willingness to tinker. No play services on an Android phone in China only implies it's an Android phone. In the developing world, it most likely implies a very low cost Android phone of Chinese origin.
Bundling things that need timely updates with the OS with no mechanism to update them individually is a design error. Things like root certificates, time zone databases, leap second information, and even TLS libraries need to be updated on a regular basis. These items should be distributed outside of the general upgrade process, even if the general upgrade process worked (which is clearly not the case). Alternatively, root certs and TLS libraries could be bundled with applications as needed. You could probably have a stable core x.509 library and cipher algorithms bundled with the OS, so that the application level TLS library can be kept small. You still need to get tzdb updates out though.
In an ideal world, large OS vendors could work with carriers to get this small set of updates zero-rated in exchange for making sure they are very small and background downloaded only at times of low network congestion.
In an ideal world carriers wouldn't have a say in what software updates were installed on my phone. Comcast doesn't control the software on the computers it services. Why should Telus control what updates are made available for my phone?
Actually I was surprised that there would be such an easy fix : Switching to Firefox. Which is apparently around 70MB, apparently affordable from what you wrote and definitely worth it if it allows you to unlock a chunk of the internet. So no need for an improbable and costly Play update.
> The remaining 33.8% of Android devices will eventually start getting certificate errors when users visit sites that have a Let’s Encrypt certificate. In our communications with large integrators, we have found that this represents around 1-5% of traffic to their sites.
This one-third of Android devices only yields 5% of traffic? Interesting.
I have a 2010 Android smartphone and it's painfully slow to navigate the modern web, almost unbearable. Browsing news websites is simply not worth my time of waiting for the phone to download and process 22MB of JS, CSS, and graphics. Being on wifi makes no difference; it's the CPU choking to render all that cruft.
That’s a pretty bad assumption. Just because 99% of Polish folks use Android doesn’t mean that 33% of those phones are in the group that doesn’t have the cert. “will” is strong.
More interesting that % of traffic in this case would be unique users. But it's not surprising to me that people using Androids on older devices are using them to access the internet less; they're generally not as nice to use, but also if they were heavily used, they may have worn out by now.
This might also concern you if your app is running on older android devices, and you have a backend that uses letsencrypt certificates, while the app is relying on the system root CAs.
A fix for this could be to add Let's Encrypt's root CA to your app.
> As of January 11, 2021, we’re planning to make a change to our API so that ACME clients will, by default, serve a certificate chain that leads to ISRG Root X1.
Ouch. So anyone who wants to support older devices 3 months from now needs to add `--preferred-chain "DST Root CA X3"` to their certbot command. When that chain is completely retired in September next year, certbot appears to fallback on the default (even with that argument present).
Readit News
What I have never understood is why IdenTrust accepted to cross-sign Let’s Encrypt's root certificate.
With that move, IdenTrust basically broke the CA cartel and helped driving the price of basic certificates to zero. How did they, as a for-profit organization, justify "doing the right thing" when that meant disrupting their own market?
Anyway, kudos to IdenTrust.
I'm very grateful for IdenTrust for having made that move. I just hope it won't hurt their business too much because of that.
They offer a variety of enterprises services and can now capture more of the marginal consumer value relative to competitors still fighting for the cert issuing market.
Perhaps they saw the writing on the walls and wanted to boost their standing in the post LetsEncrypt world.
I wonder whether IdenTrust imagined that a five year cross signed root ca would be too little a timespan to get wide adoption.
Btw... Wouldn't it be possible to just add a new root ca to android? Maybe an app could simplify delivery?
I'd be very surprised if an app without root privileges could install a new root certificate. If an app installed a malicious (or even just a poor quality) certificate, that would be a pretty big compromise to the OS.
What is strange to me though, is that it seems like the OS should have a mechanism to update the root certs independently of the OS itself. Then again, not updating root certs is a way to put an expiration date on a phone, forcing customers to buy more phones...
(1) Firefox already uses its own root store
(2) App developers can include additional roots in addition to the system root store: https://developer.android.com/training/articles/security-con...
(3) Chrome is migrating to using it's own store: "Historically, Chrome has integrated with the Root Store provided by the platform on which it is running. Chrome is in the process of transitioning certificate verification to use a common implementation on all platforms where it's under application control, namely Android, Chrome OS, Linux, Windows, and macOS. Apple policies prevent the Chrome Root Store and verifier from being used on Chrome for iOS."
https://www.chromium.org/Home/chromium-security/root-ca-poli...
For those older devices, the only option is to install the new root certificate.
Anyways, there are billions of Android devices out there. 33% of those is a large number. You can't just tell all of them that they are wrong.
If this happens, people will move away from Let's encrypt in masses. They don't realize yet how self-harming this really is.
I can see why, but I would also have like the phones to “break” so the owners would avoid those brands in the future, and pick one who care enough to push out update.
Still, I can blame Let’s Encrypt, they just want to be the good guys, and the do it so beautifully and transparently.
Thanks G!
Now, here people are suggesting Google should somehow update the old Androids.
Be damned one way or the other.
And both are reasonable and not excluding.
Google sells you a pocket computer with a locked down OS, not for your safety but to control the ability to run ads.
If they cared about user security, they would provide updates, no matter how "slow" (their excuse) the device gets.
If they didn't want full control to show ads (ads are downloaded by the GooglePlayServices, which is pretty much the kernel of all your android experience) then it would be trivial to install other android distributions like replicant.
hence, both a reasonable and google is evil. They want full control and do not care about (your) security updates.
But we need Google to step up because we know that the manufacturers and carriers won't.
I'd like to think that anyone not using Play Services (i.e. Android with no Play) is likely using a custom browser, and would heed a call to switch to Firefox.
The problem with some devices in Africa would be that many people will using older phone often don't have enough data for the big Play updates to succeed.
Teens often buy 10-100MB of data so they can use WhatsApp. (If you're from Southern Africa, and disagree with this, hit me up, you probably need to spend some time in a village ;) )
Bundling things that need timely updates with the OS with no mechanism to update them individually is a design error. Things like root certificates, time zone databases, leap second information, and even TLS libraries need to be updated on a regular basis. These items should be distributed outside of the general upgrade process, even if the general upgrade process worked (which is clearly not the case). Alternatively, root certs and TLS libraries could be bundled with applications as needed. You could probably have a stable core x.509 library and cipher algorithms bundled with the OS, so that the application level TLS library can be kept small. You still need to get tzdb updates out though.
In an ideal world, large OS vendors could work with carriers to get this small set of updates zero-rated in exchange for making sure they are very small and background downloaded only at times of low network congestion.
But those on older versions are screwed. It's really a major fuck-up that Google didn't do this for root certs since the beginning of Android.
Valid for a day: 25MB for $0.32; Valid for a week: 50MB for $0.64; Valid for a month: 100MB for $1.28, 1GB for $6.35
This one-third of Android devices only yields 5% of traffic? Interesting.
So yeah, 5% of traffic makes sense.
A fix for this could be to add Let's Encrypt's root CA to your app.
Ouch. So anyone who wants to support older devices 3 months from now needs to add `--preferred-chain "DST Root CA X3"` to their certbot command. When that chain is completely retired in September next year, certbot appears to fallback on the default (even with that argument present).