Shortening the Let's Encrypt chain of trust
letsencrypt.org
letsencrypt.org
I really want to shout out the LE team for how they handled this. Back in 2019 I was one of the loud people urging to you to reconsider. You massively overshot my wildest hopes on this issue - I never expected you to delay this switch for 4 1/2 years. That's incredible. Thank you for showing this level of care for the TLS ecosystem.
I use it and forget Let's Encrypt is so critical to my website.
The biggest concern is old Android devives. By "old", I mean devices using a version of Android from the Obama administration. Android 7.1 is the oldest version that will work, and it was released on October 4th, 2016.
At this point, roughly 6.1% of Android devices are running a version of Android that will be impacted by this change. It's likely that most of these devices are in relatively low-income countries, so depending on your audience this may be much lower or much higher. (If your primary audience isn't in a developing country, it's likely much higher.)
This change will affect you at some point after February 8th, 2024. (Specifically, you'll be affected the first time your LE cert renews after that point. If you're using one of the common clients, it will be up to 60 days after that point.) If you want, you can configure your client to support legacy devices longer, but only up to June 6th, 2024. After then, if you truly need to support very, very old Android devices, you would need to switch from Let's Encrypt to a different (possibly paid) CA.
Only you know for sure if you need to support these very old devices. Most web sites don't.
I’d be nice if this community weren’t so quick to defend planned obsolescence, especially at a 2-3 year pace.
Theres really no reason that can't be done, it's not like phones have the amount of variety as PCs and MS and Linux have both managed to handle some much older hardware.
I don't believe android apps are locked to HTTPS as a rule, though obviously a lot of them likely don't have fallbacks.
Don't get me wrong, I really don't like the whole 'disposable hardware' culture, but you can't deny there has been a huge leap in tech over the last ~7 years.
It works perfectly fine for her, it runs the two apps that she uses: Camera and WhatsApp. And the price was reasonable, only half of her weekly pension. There’s no way she could afford an iPhone 14, that’s a whole month’s income.
She doesn’t know the specs of her phone, or care.
EDIT: However, I don't suspect that iOS15 will be supported for much longer, iOS14 last update was back in Oct 2021.
Not to be too salty but that cake must have tasted worse than the video looked terrible.
About a year ago a friend of mine complimented me on a new phone, until I told him that it's my old LG, I just stopped using the case. He seemed annoyed after that. Must be because I got funny looks and giggles years back when I said I'll never buy a phone without a replaceable battery.
My laptops are both 2015 MacBook Pros.
I’m sure there’s plenty of use cases where the gains are valuable. If you’re a photographer, developer, gamer, or web browser without an Adblocker, I’m sure it’s immense. For me personally, the gains are questionable.
I have an iPad mini that's only a year or two older than that and software upgrades aren't supported, nor are there many (any?) apps available for that version of iOS
Same with my mid-2014 13" MBP. While my M1 MBP is a lot faster for things like building complex C++ code bases, for stuff like web browsing the old Intel Mac doesn't feel much different.
Compared to the incredible hardware progress between 1995 and 2005 (where a 2x increase per year was quite normal) it definitely feels like we're on a plateau since around 2010.
iPhone 7 is still a perfectly usable device but bricked now.. Stuck in iOS.
Iphone 7 got an iOS update to 15.7.7 in 2023 and its truststore contains the ISRG Root X1 certificate: https://support.apple.com/en-gb/HT212773 I am unsure which apps you cannot install but a quick look in the app store indicates that Zoom, LinkedIn, Notability, 1Password, Disney+ and Netflix all support iOS 15.7. And in my anecdotal experience I could find no app with a minimum OS requirement greater than 15.7. As far as I can tell you need to go back to iPhone 4S to find an iphone which does not support the LetsEncrypt root certificate. That device is only 11 years old, so still worse than your Android device. And I do not think there is a workaround by using a different browser like for Android.
Or they should if they are web facing. For security reasons at least.
Something like this is needed for mobile phones, and probably other electronics as well.
This "huge" difference is only at the top. If anything, the software has gotten worse... my parents hate the "new" gestures... if they didn't give the option for the old bottom row buttons it would be doubly worse.
There are many low cost Android devices about whos processing power hasn’t really improved much over the same timespan
And although iPhones have got much better it’s worth remembering how much their price has increased too (SE excepted)
For all the talk this “disposable hardware” and “planned obsolescence” issue is much more a problem on Android.
It's planned obsolescence, plain and simple. It's just surprising how frequently they obsolete things now. I fully expect them to "train" all the good little consumers out there to replace their phones every year lest most of the web stop working on them.
There is a difference between "planned obsolescence" and "not wanting to spend a disproportionate amount of development time making sure old devices work".
If 6% of Android users globally are on an ancient OS version, how many man-hours would it be sensible for my to spend testing that our systems work for them? How many of those 6% are likely to be paying customers for us?
Where could we source enough Android devices with pre-7.1 OS versions? How much time and money would that cost?
Most people don't care about having the latest specs, they want the latest features. If new features only ship to devices that are < 2 years old (like Android updates), older devices will quickly become obsolete. The hardware is still fine - I'm writing this on an almost exact 7 year old OnePlus 3 running a barely year old version of Android and the vast majority of things perform perfectly fine. Even the camera is perfectly fine even for modern standards now that I've switched to a modern camera app by tricking it into thinking my phone is a Pixel.
If we stop making old devices obsolete, dealing with old devices will be a lot easier.
> If 6% of Android users globally are on an ancient OS version, how many man-hours would it be sensible for my to spend testing that our systems work for them? How many of those 6% are likely to be paying customers for us?
From a purely financial point of view, I agree. But it stills sucks for the 6% and indirectly this is one of the reasons for electronic waste.
In a way there is a long tail of consumers with smaller incomes and living in countries with weak currencies that benefit from computer hardware and software and services that are developed targeting wealthier consumers but still have to deal with the fact they aren't really the target market.
If so, I hope they're covering both hardware and software and configs.
That certs eventually expire is obvious to me now that someone raised the issue. But I wouldn't have foreseen the problem on my own. So I imagine policy makers will need to be informed too.
Yes, there is legislation for this that mandates a number of OS updates and security updates. I'm hoping Android manufacturers will stop shovelling new SKUs and concentrate on a few they can actually keep up to date.
It is cheap Android handsets stuck on Android 6 Marshmallow or worse that never have received an OS upgrade.
Still works.
Phones from 2016 are ancient and you can buy newer phones dirt cheap. The Samsung A series costs almost nothing, same with all the cheap Redmi phones and Oppo and whatnot.
Throwing away a phone whose hardware may be perfectly working, but its manufacturer decided to be too cheap to use anything but walled-garden components, feels like an utter waste of resources.
(By walled-garden components, I mean chips whose suppliers make it difficult or impossible to develop an open-source driver.)
But good luck using it
https://www.intel.com/content/www/us/en/products/sku/75203/i...
Like, if I find a knife from 150 years ago, it still cuts cheese. Sure - it isn't the most modern tech, but it still does the job it was made for. Even though cheese recipes have changed, they are still compatible with an old knife.
Yet a phone in 150 years will be 100% useless. Not only useless because other things have moved on, or because the hardware has degraded, but useless by design because root certificates expire.
We shouldn't be putting anything into consumer electronics with an expiry date.
Lets try something appreciably more complex and do an equivalently tricky task. Lets use an 1873 steam train to travel from London to Derby.
We run into more or less the same problem. Functionally, this can work, you'll have to buy the coal from somewhere and hire tankers to move the water where it's needed since there is no longer provision for that- but much harder you'll need to secure an extraordinary amount of special case paperwork to make this happen, because obviously your 1873 steam train isn't authorized to use this route, you will need to retro-fit safety equipment that an 1873 steam train was never designed to work with, and you will need to re-train people to operate it.
Don't worry though, you have preserved the important part - your 150 year old train is still ludicrously unsafe compared to its modern equivalent like the phone. Relatively minor impacts will turn the passenger compartments into kindling, with passengers still inside, because they're basically just a wooden box resting on a simple metal platform, not a monocoque design and even after fitting mandatory safety equipment the train can't effectively stop anywhere close to fast as modern trains if things go wrong.
The tricky part about PKI and signed TLS certificates has little to do with the encryption and a lot to do with networks of trusted parties. People die and are born, relationships evolve, and so these networks are inherently dynamic.
Certificate expiration is a feature by design, and it's included for a reason.
So you wouldn't have half the consumer electronics we have because nobody would be able to afford them.
We should be making consumer electronics with reasonable life expectancies. 150 years in the future I don't want to use something from 150 years ago that "still works", I want something that is new with more capabilities, that is cheaper, that does the thing better. Why create undestructible phones that will last 150 years when nobody other than vintage collectors will want them after ~10 years due to other problems with material degradation, fashion etc.
The optimal point is to not create discardable things, but it's also realising that if you're making something forever you're going to use up way more resources and people will still stop using those devices for other reasons, so you just created more waste.
Too short life = too much waste due to replacement needs.
Too long life = too many wasted resources per-device which will be abandoned for other reasons.
In 150 years you could as well not have anything new on par with the currently available devices.
Even if that computer had up-to-date certificates, basically nothing about it would be compatible with the modern internet. It's not just a question of of "expiry dates", it's that you cannot make any forward progress if you have to maintain backwards compatibility forever.
Internet protocols, file formats, hardware standards... all these things need to be able to change over time. Hell, with the old phone example, your biggest problem with a sufficiently old phone is whether it can even connect to the network - I recently tried using a retro Nokia as a backup phone, but realised that the SIM card I'd put in it was for a network which didn't offer 2G coverage. Phone couldn't even make calls or send texts because it wasn't 3G compatible.
Solutions will come and go. Hell, what's stopping someone from building an on-device VPN that does the SSL translation itself?
Well, not exactly web browsing, but somewhat using API... yes :) https://www.dialup.net/wingpt/tls.html
Not that it would be necessary
Should be noted that the new design (Android 14) is to allow certificate updates to be separate from operating system updates. Not sure if this is done via a standardized API or something proprietary, so the problem of servers going down forever might remain.
Because the root issue is just that — no root certificate in the system.
https://www.urbandictionary.com/define.php?term=spicy+pillow
TIL!
In addition to LE, there’s other CAs like sectigo, digicert, and Google Trust Services that support it. A few are listed here: https://www.acmeisuptime.com/#CA-Software
Also in practice, Google's policies strongly resemble Mozilla's. Mozilla's root programme is overseen by mozilla.dev.security.policy, a public group. So, to some extent the answer to "Who governs that list?" is you do, much as (if you live in a democracy) it's your fault that your government is terrible. You could work hard to improve things. But, you probably won't.
It was 50% when they announced the plan initially. :-|
If so, what would make them suggest such a plan in the first place?
* https://en.wikipedia.org/wiki/Android_Nougat
To attain coverage of 95% of iOS devices, you have to support iOS 14 which dates back to September 2020 (~3 years ago):
* https://iosref.com/ios-usage
* https://en.wikipedia.org/wiki/IOS_14
Even for 'only' 90% coverage, it's 8.1 (2017) versus iOS 15 (2021).
Seems like Apple is doing a better job of convincing / allowing folks to move to a more recent version of their operating system.
Apple isn't selling $10 phones in developing countries. If you compare phones at the same price points from major manufacturers/carriers the difference won't be nearly as drastic.
- support lifetimes are better than before (now at 4 years by standard).
- but they don’t match up well with versions, eg the S8 support ended earlier this year running an android major version from 2018 (four and a half years earlier), the S9 will[2] stop later this year with a major version that will be four years old, the S10 stops next year with a major version that will be 3 years old.
That’s just what is available rather than what actually runs on existing devices.
For comparison, everything from the iPhone 8 onwards (released nearly 6 years ago) can run the latest OS version, much of it does, and some older hardware still gets the occasional security update.
My understanding of the android ecosystem is that pixel phones are much more likely to be updated than iPhones, though they’re at a lower price point which is why I didn’t look into them.
[1] https://en.wikipedia.org/wiki/Samsung_Galaxy_S_series
[2] I may be misreading the table here. It could be that the column is ‘current latest version’ and might change before the EOL date.
I don't remember the specifics, but I migrated to iOS after being appalled at how quickly my Pixel phone was losing OS updates, including security updates. IIRC, it was due to lose updates after it was less than three years old.
At least now now with Google's own chips (Pixel 6+) the guarantee is 5 years of security updates but still only 3 of Android version updates.
At the very least, marketing and packaging for units sold as new near the end of the security lifecycle should have a disclosure like: “We will try to keep this phone secure until [EOL DATE]. Beyond that date, use of this phone may leave you vulnerable to cyberattacks.” Honestly, that would be a great disclaimer to make a legal requirement for all phones, or even all connected devices for which the concept even makes sense.
(Disclosure: I used to work for Google over 8 years ago. But I never had any involvement with Android in any way, other than trying some versions of Android before they were released outside of Google and maybe giving some feedback internally. I’m certainly not speaking for anyone but myself here.)
Which means that after an initial period of half a year of "production is still slow, you have to wait" and another half year of "we maybe start selling this to Europe now", for the device I've bought today, updates will last a mere 2 years.
Its security theatre.
The only thing I got in the last year was a gps firmware update. Security patch level is still April 1, 2021 so really it's been out of support for over 2 years now.
It's a shame because apart from this huge incompetence from Samsung it's the best phone I've ever had. The latest S23 is far inferior in terms of features. No notification led, no 3,5mm jack, lower resolution display than S8, cameras sticking out of the case, much heavier, no 3D glass, no heart sensor, no pressure sensitive screen. Oh and it's double the price I paid for the S8.
The few things where the S23 is better (CPU speed and photo quality) happen to be things I don't care about. But I do care about security updates.
Only the other day, I got a message from Slack telling me their client won't support Android 9 any more, even though, like most apps, I still use the same features I always did.
Groan!
They claim they don't do that, and it's 3rd party apps. Perhaps, but it's apps they force onto users with their update process.
I imagine I'm not the only one blocking updates to avoid ads.
Plus, Apple users simply don't care about switching their phones, if Apple says they HAVE TO, they will.
Alternatively: Apple lowers battery drain to reduce the odds of your phone crashing:
* https://techcrunch.com/2017/12/20/apple-addresses-why-people...
* https://en.wikipedia.org/wiki/Batterygate
The main problem with Apple's actions were: not being transparent about what they were doing (and why), and not giving users a choice (toggle) on whether they preferred speed or longevity.
Samsung could definitely both reduce the unnecessarily large number of SKUs, and better unify their software stack so they could update for 5 years all of their phones.
It's crazy how we went from PCs having the right abstractions, where you can easily keep a 10 year old PC updated, to this awful Android situation.
Expecting continued multi-year support from manufacturers and carriers is impossible at this range when the sole focus is on driving down the price and nothing else.
But I know Samsung has the money and manpower to drastically improve the situation, yet they don't care.
With the right abstractions, they would only have a single version of "Samsung OS", like you only have a single version of Windows/Ubuntu. And all devices within reason would be able to immediately update to the latest version of Samsung OS, like PCs can.
And say in your example Samsung does get its shit together and spends a ton of money to upgrade every phone in the world...that's still ~25-30% of the Android population. What about the rest?
As a user, I don't really appreciate all the menus moving around, just because some designer in california needs a promotion.
Unfortunately, currently, updating a device might mean making it useless.
My hammer can do this but I have never had a smartphone that achieved it.
Sorry, but that's just not how developing for mobile SoCs work, and, regardless, Samsung ships Qualcomm chipsets in many of their phones. Once the latest version of "Samsung OS" needs a kernel version beyond what Qualcomm is willing to provide binary blobs for on a particular chipset, that's it for updates to phones that use that chipset.
And sure, maybe they could keep "Samsung OS" limping along on an older kernel, with some missing or broken functionality, but that costs time and money. It's not unreasonable for Samsung to not want to spend it.
Please stop considering US+Canada == "most western countries". Xiaomi and Oppo are big brands, quite popular in Europe (especially Southern Europe), and FFS Oppo are one of the major sponsors of the Champions League, one of the biggest and most popular football competitions in the world.
Never heard of vivo. The other 2 are well known phone brands in italy.
This makes no sense whatsoever. West Bengal has the same carriers and bands as the rest of the country.
Neither does a 1:5 scale model of Big Ben, but Kolkata has that too.
I'm sure there's a knob I can tweak somewhere that makes it work, but a Xiaomi handset is like $20 so I never bothered.
I feel like TPM and some modern OSes and software requiring it would like a word in that regard. :(
But yes, it feels like PCs are generally more open to both updates and running different OSes instead of smartphones getting turned into e-waste because of the more closed ecosystem (drivers, bootloaders, support).
Samsung is garbage tier and on my list of Never Buy.
They have big marketing campaigns and their phones at max brightness with a cool default wallpaper. The crapware is annoying and the performance is average at best.
I feel its my duty to warn people about Samsung.
Even comparing like-for-like on flagship products, the androids perform poorly when it comes to Long Term Support.
Much simpler than that: Apple doesn't allow third parties to make iPhones, while Google allows third parties to make Android phones. Devices don't get updated because manufacturers stop providing updates for them.
Apple is doing a better job with operating system updates. On June 21, Apple released a bunch of iOS updates including iOS 15.7.7 [1] for devices going back to the iPhone 6s which was released September 2015--nearly 8 years ago.
There's no reason why the large Android OEMs couldn't do the same if they wanted to.
And that's with 81% of iPhone bought in the last 4 years running a version of iOS 16 [2] five months ago. When iOS 17 is available to be installed in two months, over 90% the installed base will be running iOS 16.
[1]: https://support.apple.com/en-us/HT213811
[2]: https://www.macrumors.com/2023/02/16/ios-16-adoption-stats-f...
Wrong, there's a big reason: Qualcomm. Newer Android releases often bump the minimum required version of the Linux kernel. If Qualcomm stops supporting a particular chipset, they won't give you new binary blobs (part of what's known as a "board support package" or BSP) for the new minimum kernel version, so you can't update.
Google managed to negotiate with Qualcomm to get them to support old chipsets for longer, but it still falls far short of what Apple does. And now Google is making their own chips for Pixel phones and are doing 5 years of security updates (though still only 3 for major OS updates, boo).
And really, it just boils down to a shitty planned-obsolescence business decision. Apple knows that they will have enough people to buy (either first-time or upgrade) their newest shiny iPhone come release time every year, even if they continue to support 8-year old phones. Google doesn't have that confidence, so they don't put as much effort into upgrades for older devices. And that's Google, who makes fairly high-end phones; the makers of low-end devices know their users are price-sensitive and won't upgrade phones unless they have to.
So it's really two things: one is that they don't want to, and there's no market or regulatory force that pushes them to. And the other is that they truly are limited in how far they can support upgrades, much more limited than Apple is, since Apple controls the entire hardware and software stack.
Having said all that, do understand that I don't endorse or like the current situation here. My Pixel 4 stopped getting security updates (technically last fall, but Google pushed out a roll-up update a few months ago), and I'm frankly not ready to upgrade. The hardware is fine, the software is snappy, and it does everything I want it to. The Pixel 7a is probably my next best bet, but it is yet again a physically larger phone, and I hate that. But this is the situation, and these are the reasons for it.
I'm not convinced. Apple controls the iPhone market and can do this, but no Android manufacturer controls the Android market. A brand that deliberately reduces its own devices' lifespan can't trust that its consumers will buy another device from the same brand. I think it's just a matter of not offering support being cheaper than some plan to reduced lifespan leading to new purchases.
As far as I understand price sensitive users will stop using apps that don't support their device instead of upgrading. (Or will try to roll back the update of said apps.) Providing base security updates wouldn't change this logic.
This is the biggest reason Google is pushing for there being one version of the Android kernel, across all vendors: to make updates always possible.
Samsung and Google can do 5 years of support because of Exynos/Tensor, and Samsung basically spends the money to support older Qualcomm devices themselves.
https://www.qualcomm.com/news/releases/2020/12/qualcomm-and-...
Open source isn't the differentiator, IMO. OEM fuckwittery is. Just as Dell can junk up this $3,000 laptop with shitty drivers and shell extensions that are markedly worse than what Windows offers natively, so could other Windows OEMs.
The major difference here I think is that until the recent era, MS wasn't competing with those OEMs so they had little reason to try to one-up MS and every reason to leverage MS for as much of the update infra as possible. For the last 5-10 years, with the Surface line, Microsoft has been increasingly encroaching on the top OEM user base and some are fighting back by trying to outdo MS (and failing).
But I don't think anyone is putting the right blame here on Android. It's not the OEMs not serving enough software updates, it's that in many parts of the world, a 10 year old device can still connect to the network and the carriers are OK with that. That device, even it it was from Apple, would not be getting updates that late in its lifetime but large swaths of the world aren't so fucking hung up on phones as jewelry that they update every year, or even every two, or even every 5. Those ancient Android phones in Bangladesh, they're working just fine for their users and even Apple wouldn't be serving them any better with software updates.
Android being open source isn’t the problem.
However with Android, companies sell 100s of millions of devices to consumers that are more concerned about price point than updates. There just doesn't seem to be the incentive for OEMs to care about it, if the majority of consumers refused to buy devices based on old OS versions or ones that didn't get updates, those devices wouldn't get made.
Curl's ca bundle page says the mozilla bundle is about 200KB uncompressed, and my Android says the Chrome App is 25 MB, so a 1% increase in app size seems reasonable to keep things current.
Certainly, other apps might also want updated CAs, too, but do they need all of them, or only the CAs they might actually use?
This is covered in TFA:
> …especially as Android releases version 14, which has the ability to update its trust store without a full OS update.
IMHO, Google really should work on reducing the OS to the minimum needed, and make it possible for apps to share dependencies. If App A and App B use the same X, it doesn't really need to be downloaded and stored twice. For X including CA bundles, libraries, etc. Then you push play store publishers to update libraries and what not to what is commonly installed.
Google really has very little say if some random low-end manufacturer doesn't feel like updating their customers. Sure, they can try to require that they provide updates for a certain amount of time in order to get and keep their Android certification, but at some point they'll just give up and ditch Android entirely.
And on top of that, Qualcomm just won't provide updated kernels and blobs for their older chipsets after a while. Google has managed to negotiate them up from their pathetic 18 months that it used to be, but Qualcomm still doen't have to play ball any further if they don't want to. And Google's making their own chipsets now, so they care a little bit less about that problem.
Not saying it's great, but that's just how it is. Android's model basically means it's just going to be that way. Apple's means they get more control over such things.
For me, it is the improved cameras.
Look down market even slightly and the cameras on today's upper and middle mid-range or the those on a two or three year old hero phone poll exceptionally well with users today. Sensors, lens packs, and OIS are good enough and cheap enough for even very low light situations and everything else is software (or perhaps some new hardware as we get more ruin like "A.I." enhancements like portrait mode -- God damn if I have to see another photo with that exaggerated depth of field I'm gonna kick something, but even those effects don't need this years model as the hardware and software for that have filtered out over the last 7 years.
I think we're really at the end for the "I need (or even want) the new phone for a better camera." (note Samsung and others marketing moves to streaming and astrophotography as "normal" photos that most people care about are simply good enough.)
Perhaps something more computationally challenging like live deep fake video and things like that will drive sales going forward and that's "camera" sure (but also that AI chip) but photography, pictures, IMO, has reached a plateau and nothing exciting has happened enough yet in video to replace "outrageously better pictures" as as a that now fading upgrade cycle driver.
I think battery (and weight considerations) could be drivers in the near future. Fast charging, IMO, has been a bigger driver of revenue for phone makers than cameras for the last few years and I suspect we'll see marketing and user demand shifting to "does your phone run for a week without bending your spine" or "does your phone charge in under a minute" something like that becoming a focus in 3-5 years and cameras falling down to compete with things like cover glass which has also plateaued and mostly fallen off the users radar.
Apple's rumored battery and size bump and the EU's move to consumer replaceable batteries is a perfect storm for super fast charging, even at destructive levels, then OEM or 7-11 sales of replacement batteries. I imagine we'll also see optimizations in the rest of the hardware and software stack become a focus for that magical week of battery that's probably not a decade away.
Photography, like cover glass, is bound by some pretty daunting constraints of physics and I think we've hit "good as it's gonna get" or "good enough" or some combination of those for a while and so phone makers need something new to drive their annual or biannual upgrade cycles.
Apple hopes VR will be big and replace a lot of phone and pc use cases, perhaps the way the iPhone and iPad did so much of that 15 years ago, but I don't see that happening for another decade or three (I've used various head mounted VR kits since 1993; it's not happening any time soon.)
Android is too fragmented to say what that ecosystem is betting on over the next 5 years or so, but I'm gonna wager it's battery and screen followed by performance, camera, and then storage, durability and IP rating and all those other "a few small but big spending segments care enough to keep improving" features.
I would be more concerned about security updates though. What percentage of ios and android have all security updates released say t-7 days before applied?
I do think they could and should be more aggressive with security updates. Both by releasing/messaging those separately from other kinds of point releases (improving but not great), and by notifying sooner/more frequently. It definitely irks me when I find out about a critical security patch over a week after it was available, and that the security content is a secondary link with no immediate conveyance of its urgency. And they should also make it a lot more obvious how to go find out if an update is even available in the first place.
Even today(?)’s rapid response, I had to read about it on some site and then remember the incantation to go look to see if the update was available. Of course it was, so I tapped download and install. After waiting a while, I switched to another thing. When I came back, it was downloaded and ready and waiting for another affirmative to do the thing I already requested. I should not need to do any of this when I have automatic updates on.
Normies usually have their updates set to automatic, so they get the updates a soon as they're out.
I count over 9 security updates for iOS 16 [1] as of July 10th, with the rest of the year to go. I feel like as soon as any type of update is released by Apple, I'm inundated with the news from many websites, RSS feeds and the PGP-signed email from Apple with the news [2] [3].
[1]: https://support.apple.com/en-us/HT201222
[2]: security-announce@lists.apple.com
I have my iPhone and iPad both set to automatic updates, as are some others in the family. I have noticed several times when my iPad will get an update and then a couple weeks later I'll be on another family member's iPad and notice it still hasn't done the update yet.
[1]: https://support.apple.com/guide/mac-help/set-up-content-cach...
A few features I’ve found particularly impactful in recent updates, which do feel like they require a deeper change than just an app are:
- translate button on selected text (and the translation works sufficiently well)
- OCR + selection of text in images, automatic OCR and indexing of text in photos
- oftentimes if you select something in some units, you can select the text and see a conversion to other units (though it is a bit fussy about what it accepts, e.g. it doesn’t like 5’, 5’1, 5’2”, 5lb 3oz, but it is ok with 5lb, $1, 1$, or USD 1)
- The translate button has been in Android for ages but it's using the standard context menu API. Not many apps use it and very few users care, but it's there. Very useful for sending a bit of text over KDE connect!
- OCR + text selection was brought to my phone by a Google Pixel Launcher update. I didn't even notice it until I accidentally selected text from the task switcher.
- I have no idea why OCR is not in Photos yet, I guess the Lens button is good enough for Google, which has worked for years now.
- I guess I don't have unit conversion built into my phone? I could probably install an app that does it from the context menu but I can't say I care. That's what Google Assistant is built into Android for.
None of these features require an operating system update on Android. They're often released around/after a new major Android release, but that's just Google's release schedule. Apple could probably apply these updates through the app store as well if they bothered, but they prefer collecting updates for a year and releasing the as new features all at once.
Other than a smallish group if tech enthusiasts and people who consider phones fashion, I argue that most are perfectly happy with their 2020 iPhone or 2018 Android phone. They are clearly not replacing them as fast as the industry expects, so may a small fee for updates, so you avoid having to replace the phone would be acceptable.
Want to use a modern web engine but your customers are running a seven year old OS? No problem, the webview updates come AUTOMATICALLY. Want to integrate with Google's new nearby share mechanism? It's already present on the same devices. Google's cloud API changed as part of a recent Android update? No matter, every API feature has already been working on every outdated phone since before you even know there was going to be a problem.
You do end up with annoying clutter supporting all of these devices because of API/permission changes, but it's all quite easy to deal with if you just stuff the compat code away behind an abstraction.
Not having old phones on your platform is a failure, not a success. Old Android phones still work okay. Apple isn't giving away free new phones - there is no right to repair.
Yes it's called planned obsolescence and nature ain't thanking them.
> The new cross-sign will be somewhat novel because it extends beyond the expiration of DST Root CA X3. This solution works because Android intentionally does not enforce the expiration dates of certificates used as trust anchors. [1]
Trust anchors work really differently than other certificates in practice, which can be surprising [2].
[1] https://letsencrypt.org/2020/12/21/extending-android-compati...
IIRC one of the bigger problems was that older versions of OpenSSL did check root anchor expiration. But that wasn't all - at my then-employer we had a brief outage on some of our systems because Ubuntu had to patch something (I don't recall what) to deal with this, and they only released the patch a few days before the expiration. We had to mass-rebuild all our Docker images to fix the issue.
This workaround was so wild and unprecedented that I assume the cost difference vs. getting cross-sig from an unexpired (and widely compatible) root was massive for them to use it. There must have been a huge amount of testing involved. The fact that it went as smoothly as it did (mostly, but not completely) was impressive.
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 time_check = cert.issue_time
6 return NOT_EXPIRED
With code signing certificates it does work the way I assumed TLS work. Timestamped code signed with an expired root certificate is still valid as long as the root certificate was valid at the time of the timestamp.
Let's hope so. But the last DST cross-sign expiration wasn't a non-event. IIRC, GnuTLS failed to correctly path-build after the expiration (AFAICT, it would only build a path to the expired cert, see that it was expired, and then abort, ignoring all other possible paths); worse, GnuTLS is the TLS library used by apt (when using HTTPS, which isn't the default, but my security team wanted all packages vendored and served securely — which … sensible, but yeah. An outage was the cost). (This was fixed in Bullseye, I think? Which was literally like a mere week or so before, by sheer luck.) Azure also had multiple outages caused by or surrounding that expiration.
Or am I missing something?
All I know is that apt (through GnuTLS) stopped being able to install, and it was a massive headache. We upgraded to Bullseye (where apt seemed to not have whatever bug ailed it) at that time, and that fixed things.
One would think the Authority Key ID info would be the only thing that could define a path up the tree. There's also an option in ACME to get "alternate" chains, and I forget which chain was the alternate at the time. (I feel like it might have been the non-DST one, b/c the DST one was being preferred to get compatibility w/ Android, who would not realize the cross had expired, or something. But I also didn't learn about alternate chains in ACME until the expiration forced me to out of necessity.)
(I'm not sure how rigorous path building is, but the general state of TLS tooling leads me to believe it's a giant ball of yarn. Even since then, I have seen a bizarre apparent path to the expired DST root get built, although the circumstance in which I saw it afterwards was contrived, and involved a vendor (Hashicorp) adding a leaf (i.e., non-CA) cert to the list of CA certs, and doing it in such a way that leaves OpenSSL's internal structures in that dir corrupt. OpenSSL, in that situation, somehow, found the DST cert once again. Removing the leaf cert form the store caused the validation to succeed, but … OpenSSL's docs are not really clear about how you can or cannot screw about with its on-disk data. I call such shenanigans UB, and you reap what you sow, but I couldn't convince them of that. We lived with the issues that bug caused until it was apparently fixed in a later version.)
The constant churn of protocol deprecations, certificate expirations, rotations, etc. is like planned obsolescence on steroids.
BGP and us-east-1 fair :D
I think this is a very different definition of brittle than the original poster meant
Facebook doesn't count, as it was limited to their network.
> either need to open-source everything
That'd be problematic, as in many cases the vendor doesn't even have the full source code (think: all of the embedded chips that run their own RTOS), let alone the legal right of relicensing it. Another thing is build reproducibility, the ability to actually flash/install the code, etc. It would be desirable to have all that, but it's far from simple.
> allow everyone who ever bought one to return it for a full refund.
Regardless of the actual physical condition of the item? I would say something like a trade-in program, where you get a % of the original value depending on overall condition. But then it gets tricky as it's difficult to write into law, what "good condition" does actually mean. What if the device has two screens, but only one is broken? What about components that tend to wear out or break during normal use (batteries, straps, hinges)?
But having that process in place could also actually help us recycle more stuff.
Also, consider the smaller companies, that don't have the resources to effectively give you a 10-year warranty on their product. That'd just get the bigger corps even more entrenched (while they figure out the "legitimate interest cookie" equivalent of still screwing you over).
I consider making closed-source more legally difficult to be an additional benefit, not a downside.
> Regardless of the actual physical condition of the item?
Yes. The idea is that it'd be better for things to continue to be safely usable rather than to have to become e-waste, so if the manufacturer chooses the option that requires the latter, the deal should be as one-sided as possible against them.
> Also, consider the smaller companies, that don't have the resources to effectively give you a 10-year warranty on their product.
Software updates are a lot cheaper than full warranties, and if they make all of their stuff open-source then there'd be nothing else they have to do at all.
Then perhaps start with a copyright reform, otherwise I think you're trying to "solve" too many problems all at once.
> so if the manufacturer chooses the option that requires the latter, the deal should be as one-sided as possible against them.
Meaning only the already wealthy companies can afford to take the risk. You're further empowering the rich.
Firstly, the obvious, laws are local not global. Your proposed law would need to be ratified by 200 odd governments. This seems unlikely (Not least in the US which perfers not to ratify international laws). Given that China is least likely to care, and given that most really cheap phones originate there, I'm not sure your proposed law will work there.
So, to summarise, suggesting global laws, while not necessarily wrong, is as fruitless as suggesting that we use magic pixie dust to solve the problem. Both have exactly the same liklihood of being adopted.
Plus, given that the proposed law dictates -future- behaviour I'm not sure who, how or where an affected person (one who only has money for an ultra cheap phone they haven't updated in 7 years) would get relief from.
> Space Cadet Pinball was not originally written by Microsoft, but was rather obtained via licensing from a company then-known as Cinematronics. This means that there are restrictions on what can be done with the program, as spelled out by the license agreement.
https://devblogs.microsoft.com/oldnewthing/20181221-00/?p=10...
The change would be you can’t ship software like this… I would say that is a net positive.
Free software centers around the user. Everything else is a means to that end. Open source centers around the authors. This is fundamentally misguided.
I couldn’t give two [deleted] about authors and what they want.
This is cold comfort, of course (though: the post-ACME world of short-lived certs has better DX than the nightmare world of long-lived Verisign certs), but it's worth noting that any alternative to TLS would face similar problems.
It would be nice to have a centralized push-based solution or something. I dunno, hard problem.
I suspect that protocol churn will settle down now. TLS 1.2 was introduced in 2008 and still considered ok, so its hardly that new now. Lots of people looking carefully hopefully means most of the issues have been flushed out.
IMO, you could argue what Let's Encrypt does is basically DANE so why not just support it, but there may be use cases where DANE isn't appropriate. I don't see why perfect has to be the enemy of good though, let folks use DANE if they want.
HTTP over tcpcrypt AKA TCP-ENO?
https://www.rfc-editor.org/rfc/rfc8547.html and https://www.rfc-editor.org/rfc/rfc8548.html
Unlike HTTPS/TLS, it doesn't provide protection against active attacks, but at least prevents passive ones. So it couldn't be used for https:// URLs, but would be a security improvement for http:// ones. And no certificates to manage
E.g. you could try to randomly record both ends of a TCP connection and then compare them out-of-band to see if someone in between tampered with the contents. (Although my late former colleague was working on a tool to do that and it turns out that there's a lot of noise and complexity to contend with in trying to make it practical, e.g. because of packet loss, retransmission, fragmentation, and changes like NAT by middleboxes that consider themselves benign.)
Random example of a passive communications interception attacker:
https://en.wikipedia.org/wiki/RAF_Menwith_Hill#/media/File:M...
Another example:
https://en.wikipedia.org/wiki/Orion_(satellite)#/media/File:...
There are lots more where those came from!
I think a lot of stuff on local LANs is still HTTP-only because trying to do TLS for local devices – even with LetsEncrypt – is a pain. Not impossible – you can't get a TLS certificate for 192.168.12.34, but you can create a public DNS entry pointing to that and then use a DNS-01 challenge to get a certificate for it. But that's enough work that heaps of people don't do it.
It also makes local LAN reliant connectivity reliant on public DNS – since you can't do https://192.168.12.34 you have to do https://device-12-34.example.com, if your Internet connection is down you might not be able to resolve device-12-34.example.com even though the device is up and accessible on your local network. Adding a local DNS server will fix that – but now that's another thing you need to make it all work.
Whereas if we had opportunistic encryption for http://, that would make local LAN passive attacks a lot harder. Yes it wouldn't stop against local LAN active attacks, but security against passive but not active attacks is still better than no security against either.
You wouldn't even have to expose the private network to the outside world. It could still be firewalled off.
Say if your prefix is 2a09:1337:8888:aa::/56 and your private prefix is 2a09:1337:8888:aaff::/64, just make sure that the router redirects all traffic from outside to the /64 to a box that listens for connections so a certificate can be issued. Of course you'd also need to be able to reach the said box from boxes within the private network (for .well_known cert requests), but it's trivial. No BGP required. Simple HTTP challenge.
At the same time: how do you foresee this interoperating securely with TLS? My first intuition is, without something even stronger than HSTS, that this would open up additional downgrade attacks against HTTPS: an attacker could do a normal HTTP downgrade and then present a TCP-ENO session that they control the key for. That's perhaps no worse than the downgrade itself, but I could see it being a source of user confusion if browsers choose to present this kind of scheme as "secure" in the UI.
The obvious solution to that problem is - don’t show it in the UI by default.
For sophisticated users, have a config setting they can turn on which will show some kind of icon (not the padlock, a different one). For unsophisticated users, make it invisible.
Invisible protection against passive attacks is still better than no protection against passive attacks. But passive-vs-active is beyond the understanding of non-technical users, so for them keep it invisible.
I agree that perfect can be the enemy of good, but i also think its important to do things that stop actual attacks. Things that make attacks just mildly more difficult are pointless since the attacks are going to be scripted anyways.
How do you distinguish between a host you have seen before that has a mismatched key vs a totally new host which you have never seen before.
I guess it depends on how you are discovering these resources in the first place, but traditional answers like IP address are much less workable on the local network.
Does that imply they are paying millions or something for the cross-sign?
In that same year, their total expenses were $5.1M - so that expense would make up almost 10% of their budget.
[0]: https://beta.candid.org/profile/9328188?keyword=46-3344200&a...
We are sincerely glad to have them as partners, and grateful for their contributions to helping get Let's Encrypt going. We could not have done what we did without them. Running a publicly trusted CA is not easy, and cross-signing others involves work and liability, particularly if the entity asking for a cross-sign is an upstart with a strange plan and little to no experience running a CA.
Imagine if a CA cross-signed some new, upstart CA to get them browser compatibility (like IdenTrust did for LE), and then the new upstart went rogue and started issuing phony certs for google.com, wikipedia.org, etc. on behalf of [insert totalitarian nation here] state security. Those certs would chain up to the cross-signer's root, and they're responsible for it. They could face removal from root programs if they were reckless about cross-signatures.
So if a root CA wants to cross-sign a new CA, they need to make sure that the new CA follows the same policies and gets the same audits as a root CA, because their ability to break things will be basically equivalent to a root CA.
Honestly, <$500k for all the admin work on this sounds reasonable to me. It probably took a huge portion of several people's time throughout the year.
> In addition, dropping the cross-sign will reduce the number of certificate bytes sent in a TLS handshake by over 40%
A company like RapidSSL or GoDaddy would never have cross-signed Let's Encrypt, unless they offered "buy our whole CA business" money.
But selling DV certs wasn't IdenTrust's business model, so they were happy to provide a cross-signature for (according to some speculation elsewhere in this thread) less than six figures. And because of how TLS root certs work, a cross-sig from IdenTrust was just as useful to LE as a cross-sig from one of the ultra-profitable CA's.
It seems IdenTrust has not been killed off.
1 IdenTrust 48.5% 53.6%
2 DigiCert Group 13.1% 14.5%
3 Sectigo (Comodo Cybersecurity) 12.1% 13.4%
4 GlobalSign 6.1% 6.7%
5 Let's Encrypt 5.8% 6.4%
6 GoDaddy Group 4.8% 5.3%
Not at all. Major cert authorities are all selling to businesses, and that will continue to be the case. Letsencrypt's users are almost all in the personal/hobbyist space.
From a technical point of view there is no reason a business cannot use Let's Encrypt. The certificates provide exactly the same security. There is really no difference in the encryption you need for a "personal/hobbyist" site or a business site.
Yeah, CAs still successfully convince some businesses to pay a premium, because they don't understand how TLS works. That mostly works because in "business terms" the price is still low.
That may have been true in the early days of Let's encrypt. But today, if you're using any of a number of newer hosting options (Netlify, Vercel, Fly.io, etc.) you're probably using a let's encrypt certificate.
Older/more staid companies will mostly still be using certs from Digisign et al., but there's little reason for new companies to pay for that.
How so?
> Netlify, Vercel, Fly, etc.
For the default URLs generated when you deploy an app, sure, but companies using them commercially are all bringing their own domains (with their own certs).
When LE came out they already had multi-year certificates, so they just used those. At the time many were convinced to switch from DV to EV [1] certificates. Since then the (alleged) benefits of EV certificates have vanished. [2]
Thus the argument to spend budget money on thing-we-can-get-for-free is very thin. Sure, there are some die-hards, but since they are literally wasting money they become fewer either each passing day.
[1] DV = Domain Verified which is what LE issues. EV is Extended Verification and costs several hundred $.
[2] Off the top of your head name 3 domins you visit that use an EV certificate. You can't because you can't tell if they do or not. And since no-one cared when you -could- tell, no-one complained when bring able to tell went away.
[3] LAN certificates was the last "hurdle" and that's been automated away as well. So now those spending money on CAs are just using up their budget, and not getting something for it.
My employer isn't a heavy user of LetsEncrypt, as AWS's certificate issuance is more straightforward to use when we're already using AWS for pretty much everything. But we still have a few hundred LE certificates that are in active use.
I only noticed this a few weeks ago, apparently ubiquiti users were also affected.
It was kind of an eye-opener that you could potentially brick a whole fleet of sold products by a cert expiring. In this case it was no real problem as other providers had certs with valid root certs.
That leaves other browser's such as Samsung's one which probably has the most usage, no idea if they bundle root CAs or not.
[1]: https://www.google.com/search?q=number+of+android+users
[2]: https://www.theverge.com/2023/6/16/23763340/google-domains-s...
Are they using public cloud?
"If you see a sudden drop in visits from Android, it is likely because you have a significant population of users on Android 7.0 or earlier. We encourage you to provide the same advice to them as we provided above."
Good luck doing that.
If you want to continue serving your clients, you can still pay for a certificate from an authority trusted by your outdated clients. If you want to continue serving the old clients for free, ask them to use another free browser that will allow them to do so.