Standing on our own two feet
letsencrypt.org
letsencrypt.org
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.
Perhaps they saw the writing on the walls and wanted to boost their standing in the post LetsEncrypt world.
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.
So this is perhaps why there is no EV or OV differentiation. Who cares? Of what use is an EV cert, if no one even checks the name. Or further, knows if the bank (for example) uses that CA?
I think in such a context, 'green' and 'no-green' is just non-helpful to validate anything. Sadly, 1 person out of 1000? actually care about encryption, or even know what SSL is. Maybe only 1 out of 10000 know about EV.
Sometimes I just become sad, when I think of the lack of general knowledge about fairly important things.
So it would be prohibited to issue leaf certificates with a CN that's a human meaningful name like "Google" or "Hacker News" because that violates PKIX.
It doesn't matter anyway, the only enforcement that really matters for HTTPS is the mechanical enforcement by the user agent, because there are way too many HTTPS transactions for the human to realistically assess the certificate shown for each transaction and decide if it's OK.
Validating human-readable names, be that of individuals or corporations, would be opening a can of worms. Domain validation is already decidedly non-trivial.
It just should work for them, and the browser should enforce it. I think the tech world is biased to think consumers are more technically inclined due to the people they are around. I do not work in computer tech. No-one I work with, all of whom have some form of an engineering degree unrelated to computers, could tell you the difference or care less.
But maybe Mozilla & Google, were aware of it being used like that and thought that EV certs were not reliable enough to be used as a signal of trustworthiness?
TLDR: yes, but some companies wants another company to manage their certs.
> Also, sometimes people need to access documents and emails from home computers and the company may use some devices on which it isn't possible to install the CA
That’s a plus as far most security professionals are concerned
That's not how certificates work. The CA doesn't have your private key. They could theoretically sign a fake certificate with your hostname but that risk is still present if you use a private CA and is mitigated by certificate transparency
Regarding CT I’m not aware of any clients other than browsers actually enforcing that.
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...
Its not like the OS can actually withstand the app though, looking at a years out-of-date OS with thousands of accumulated known bugs.
Maybe a single confirmation box "would you like to add this ca" would work.
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.
(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.
https://android.googlesource.com/platform/libcore/+/android-...
I'm not sure whether that particular root is being used for their Go SSL product. If so, Buypass might be a good alternative to migrate to.
From what I read though, they do require an E-Mail address, so you've got to keep that in mind.
I realize that is a tough message to get out to users and site owners are going to be in the cross-fire, but it seems better to try to work for solidarity in pointing fingers at the right direction and the right direction certainly isn't Let's Encrypt.
https://scotthelme.co.uk/impending-doom-root-ca-expiring-leg...
Previous HN discussion on that article: https://news.ycombinator.com/item?id=23455463
But this is not up to Let's Encrypt to solve. They market themselves to build products for the mass market instead of small niches of the market, say, everyone who buys a new phone every year. But then they also have to treat their product like a mass market product, and if Android users still use older versions of the OS, then Let's Encrypt should adopt for that.
What is unique about Let's Encrypt, is they may have a harder time getting cross-signed by a CA that will still have a valid root cert on these devices for a significant amount of time, because, as has been pointed out in other comments, Let's Encrypt is disrupting the CA industry.
even without having to click through security warnings, the web is horribly broken on old android devices. the overlap of sites using letsencrypt and sites that care about people using android <5 has got to be vanishingly small. this isn't going to cause a move away from letsencrypt.
Microsoft Edge still gets updates on Android 4.4 KitKat
On an Android 4.4 device, you should probably skip the system root store and the system libraries, and if you're already doing it for those phones, you might as well do it for all the phones.
In the context of this thread (aka older Android devices), they aren’t truly separate concerns. You really need to do both. My point is that doing both is relatively straightforward, but doing the root store part is fairly easy to do it in a mediocre way and be brittle / insecure.
It was really short-sighted of Google to make the system cert bundle something that can't be updated without a full OS update. There should be an OTA mechanism that allows it to be updated through the Play Store or through some other means that isn't reliant upon lazy device manufacturers.
Thanks G!
You cannot gatekeep with such sweeping statements. People have old phones for lots of reasons. Others will have to serve those people for lots of other reasons.
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.
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.
I'd also argue that even if someone uses Play Store services, but doesn't pay a penny, they're still a "customer" in a looser sense of the word. They're engaging in the market-place, likely using free apps subsidized by advertising. Even if you want to argue that they're the product instead of the client (and I'd be inclined to agree), they're still revenue-generating users.
That is a lie and you know it. Google updates the OS, but they are also directly responsible for many products they sold themselves with their brand. And those have as much updates as any other company, well maybe one or two more.
I happen to have two devices bought directly from google. One is stuck on android 2.3 and another on 4.0, both full of security holes, not updated because "it would be too slow" when in reality i can't even install replicant et al because google never worked with the component providers to offer compatible binary blobs for the hardware.
Yeah, android itself is opensource (mostly because it is built on top of GPLed linux code so they do not have an option) but 99% of what makes your phone run is a proprietary binary-only code provided by the likes of Qualcomm etc. And why phone manufacturers, google included, use the options with closed source binary blobs? To save $5 or so from the BOM cost in production.
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 ;) )
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
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.
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.
I'd absolutely agree that this is a design error though: We'll be better off when Android is dead and gone as a platform.
The same applies to unlocked phones. The service provider has 0 control over what I am running on that phone, and they don't control the updates (the OEM does), but as long as the baseband firmware complies with established standards, the phone will work. This was mandated by law some years back in the US and I am certain it's been the case in the EU for longer.
What you seem to be referring to is telco customized phones (subsidized ones), and in those cases you'd be correct.
This one-third of Android devices only yields 5% of traffic? Interesting.
So yeah, 5% of traffic makes sense.
For stylesheets, I'm not certain how you're disabling them. Depending on how you do it, they may or may not get downloaded. The most common ways of disabling them result in them not being downloaded.
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).
Also, while the article focuses on the Android, my first thought was about all those outdated CentOS/Debian/etc boxes/VMs/containers that silently curl something from a cron job or such and that will all of a sudden stop working. So I expect a lot of infrastructure breakages.
Android 6 is 2015. root and intermediates CA have a 10 and 5 year lifespan. I am afraid you might not be able to find something that work on old phones and new phones.
Even if you do find an older CA vendor that has an ancient CA and is willing to sign (you will be forced into an enterprise contract that will take months to negotiate), it's going to be retired anytime soon and break everywhere.
Last but not least. Old phones are stuck on old versions of SSL/TLS, they're not able to connect to recent websites irrelevant of the certificates. Your site is probably no exception and cut the old protocols a long time ago.
https://www.stoutner.com/lets-encrypt-isrg-root-x1-and-priva...
/me runs
Although I agree fully on the sketchiness part, installing the root is a fix.
ISRG Root X1 expires in 2035. Not one of these problematic Android devices will be online anymore.
They appear to have added it back with a big warning screen similar to what they do for VPNs and stuff telling users it could compromise them, which is reasonable. It was a pain you couldn't before.
Generally speaking, the way that new competitors enter a given market is with low-cost options that are often inferior to established players. Then, as those entrants expand upmarket by offering better and improved products, the existing/established players abandon parts of their downmarket products to the new entrants. This cycle repeats until there's nowhere left for the established players to go. At that point, these upstarts can often replace the existing players and become the dominant ones.
I'm not sure if the above was a deliberate strategic move on the part of IdenTrust or not, but in cross-signing the Let's Encrypt certificate, it effectively killed off the potential for new players in the low-cost TLS/SSL certificate market because there's no margin in $0. [Citation needed] Further, because the purpose of Let's Encrypt is to serve the base level of the market [1] with no apparent desire (as per the parent organization which is effectively a non-profit/public-benefit organization) to expand upmarket. This move would appear to solidify (whether intentional or not) the position of larger players who cater to larger customers while keeping any potential newer players from disrupting the space.
Aside: I love Let's Encrypt and have about a dozen or so certificates issued through them that I am in charge of. They're awesome and kudos to their team for what they've been able to accomplish. When they first offered certificates, the 90-day validity period felt very restrictive. Now it feels great because the certificates are automatically rotated every 60 days per various automation tools and painful certificate renewals are very much a thing of the past for me.
An active MITM is a relatively more exotic threat than a passive observer. In the days when certificates cost money, there was a legitimate argument that you shouldn't need the whole elaborate active-MITM defense just to get protection against passive snooping. But now that you can get both for free... just use Let's Encrypt.
Browser security warnings imply https > http > self signed https. The correct order of should be https > self signed https > http.
If you're writing an HTML 4.0 web page that's no issue. If you were building a video chat, or you were going to add geolocation to your "Where's my closest store?" page or you want to send Notifications, or you've got a framework that needs Service Workers, those APIs are Secure Context only and won't exist.
The general rule of thumb is, if you could polyfill it, then it's available even without Secure Context, otherwise you need Secure Context to get the new feature. Some older features are being retrospectively given this treatment.
Without encryption we know the NSA takes the approach of just bulk collecting everything they can to filter after the fact.
So rather than an assigned agent trying to discern what Public Enemy #1 Lammy is up to right now, and painstakingly concluding you have probably just read a Wikipedia article about Jaffa cakes, if you don't have encryption what happens is that the automation notes "Lammy looked at http://en.wikipedia.org/wiki/Jaffa_Cakes" as you click and it goes into the vast heap of stuff snooped that second even though you aren't under any suspicion and it's probably irrelevant.
This bulk surveillance is an unjustified attack on everybody's privacy.
It’s the second or third tier nation state actors that you can really make a difference with.
I do TLS only for my stuff however.
Really don't think you're grasping this and lack an understanding of packet routing.
Please type:
traceroute apache.org
Apache will happily serve you an insecure connection, they are the 80th top site on the internet. This type of stuff should be called out by technologists and it's incredibly disappointing when its handwaved away.
I did run into some random 503s occasionally, but that was pretty soon after it was launched. Maybe just a few teething issues.
Seconding regecks' comment.
We're gradually making ZeroSSL a default CA for Caddy.
(I am currently implementing multi-CA support into Caddy and CertMagic, so that Caddy will be able to use both Let's Encrypt and ZeroSSL for redundancy. It's the first server to support this!)
This is a good thing for the ecosystem.
As in, replacing LE as the default, or supplementing it? (And if the former, why?)
- https://letsencrypt.org/docs/staging-environment/ - https://caddyserver.com/docs/automatic-https#testing
For more help, please ask on our forums! I don't use Google Cloud but it is more likely that somebody there does: https://caddy.community -- otherwise, time to roll up your sleeves and get to work, forge the answer for others, I suppose!
But those markets don't have the legal power against Google or Samsung.
And markets that would have the legal power, don't care about unnecessary electronic waste ruining the planet.
(Sent from Android 4.1 without Playstore.)
If it is "just" bluetooth, that may be fine. When networking (wifi/GSM) or the screen stops working, it probably is not.
I've done a fair bit of upgrades of ancient android phones to CyanogenMod, LineageOs and even an accidental Ubuntu Touch. Fairly common that things like the camera or bluetooth stop working (partly), but for many owners of old phones, that is certainly a trade to make. "I never use Bluetooth, what could you use it for?", "Oh, but then I'll just use this jack-cable for my sonos").
What I'm trying to say: yes: updates require SoC vendors to help, or at least stay out of the way. But no, that does not mean one cannot ever update at all.
(Obviously IdenTrust is under no obligation to do so, but since they've done this much, it's not a stretch to hope they'd do more, even if they want to charge for it.)
Perhaps somebody has a list of what's in the trust store for various historical Android builds, I do not.
But I think you can assume that the team at Let's Encrypt have considered any options that might work and decided that either they wouldn't make enough difference to be worthwhile or have asked and been told it isn't possible or would be too expensive to make sense.
Good judgment.
still the 33% of the devices is a quite a large number to consider.
It’s a pity - there’s no essential reason why old phones with new batteries should get worse over time. But software kills them in so many ways.
Natively? Windows 7, assuming you have installed all updates before January. Microsoft can update the roots as they please (and historically issued updates up unto Windows 2000, so root updates are a demonstrable solved problem).
BSDs and Linuxes: (Usually) Uses Mozilla's trust list. Also updates separately from system updates, so unless you stick somehow with unsupported systems you already have this (and can be manually included into the trusted roots if you insist on using that outdated version).
macOS: bundled with the system updates (see caveat with Firefox independently managing roots). Here, I don't know what version is the oldest one with ISRG root certs.
As far as marketshare goes iOS 13 and 12 make up 94% of devices [2]. So I am guessing its an insignificant amount of actual users.
I don't even control the certificate provisioning process. We use Heroku and Webflow. This is frustrating.
I imagine the cross cert cost a bunch of money, and they may not have the money to do that again.