Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s Encrypt comes up with workaround for abandonware Android devices

arstechnica.com

Post reply on HN
Print view View original

71–80 of 132 posts

Re: Let’s Encrypt comes up with workaround for abandonware Android devices

#71

Post by gene91 »

quesera wrote: post #62
move-on-by wrote: post #60

Earlier quoted context omitted.

I just got some combo smoke and carbon monoxide detectors that say replace every 7 years, so perhaps 8 years isn’t that bad?

Received wisdom: Don't buy combination smoke & CO detectors. Smoke rises, so detectors are best placed on or near the ceiling. CO sinks, so detectors are best placed a few feet above the ground. Considering the importance of early notification of either condition, these requirements appear irreconcilable.

That's a myth according to this article [1] from a well known US brand of alarms.

[1] https://support.firstalert.com/s/article/Where-to-install-CO...

Re: Let’s Encrypt comes up with workaround for abandonware Android devices

#72

Post by M277 »

1-6 wrote: post #67
dade_ wrote: post #64

Android tablets are probably part of the problem. I still use my Sony Z3 Compact tablet. It is thin, waterproof, supports a SIM and SD card. I have never found a good replacement, though I'd like to. I mostly use it for reading ebooks and Pocket and RSS feeds so it handles the tasks well, but no upgrades, eventually it will need a new battery and now I see root certs are built in guaranteed obsolescence (like on the…

Glad you've stated this because going forward, software generally gets deprecated more often than maintained (I'm sure there are a few rare cases). Our hardware is very intertwined with software, so we toss out perfectly good hardware because it isn't running the latest firmware. Can manufacturers allow late-stage open source rom conversions on smart devices and allow the community to keep supporting legacy systems?

Yup. My father has an old Galaxy Note 3 Neo (Dual Sim edition). That particular model never got any updates at all, so it was stuck on the release Android 4.3.

While it's old, it actually fulfills all his needs very well and he has little need for a newer phone... but he can't get new apps, because all of them require at least Android 5.0 (regular Note 3 / Note 3 Neo Single Sim got the update to 5, but not the dual sim). And the applications that are already on the device (Google stuff) actually no longer gets updates, and occasionally pops up "This version is too old! You have to update!" warnings that he can do nothing about..

Re: Let’s Encrypt comes up with workaround for abandonware Android devices

#73

Post by toast0 »

I would be concerned that chaining to an expired root is going to cause some certificate verifyers to flag the chain as invalid. Similar to when the Sectigo/AddTrust root expired recently (but perhaps that was an issue because the cross-signed certificate expired).

If you support older systems, you really need to try to separate out clients to different hostnames (and sometimes different IPs, it they don't have good SNI support), so that you can provide each segment with the certificate chain it needs. Trust root issues are a lot harder than the sha1 deprecation, because at least there's a fairly well used TLS option exchanged for key support (it doesn't exactly mean support for keys in certificates, but it worked pretty well). There is a TLS option to provide trusted CA information, but it has zero mainstream use (and it doesn't seem terribly usable anyway, sending all your trusted root CAs is too much data, a digest/id would be much more reasonable).

Thankfully, browsers usually have forgiving verifiers, but if you support applications, libraries for certificate verification are all over the place; and if you support 3rd party clients good luck. x.509 is too big a spec to want to bundle it with an app, but you can bundle in trusted roots if you're targetting a sane platform.

Re: Let’s Encrypt comes up with workaround for abandonware Android devices

#74

Post by AnssiH »

toast0 wrote: post #73

I would be concerned that chaining to an expired root is going to cause some certificate verifyers to flag the chain as invalid. Similar to when the Sectigo/AddTrust root expired recently (but perhaps that was an issue because the cross-signed certificate expired). If you support older systems, you really need to try to separate out clients to different hostnames (and sometimes different IPs, it they don't have good…

Yes, e.g. some old OpenSSL and GnuTLS versions will fail due to this, but it was considered a lesser issue than failing on old Android versions (by default): https://community.letsencrypt.org/t/questions-re-extending-a...

They will probably post details more prominently about that later.

You can also still offer a chain that works with old OpenSSL and GnuTLS but not with old Android if you prefer that.

Re: Let’s Encrypt comes up with workaround for abandonware Android devices

#75

Post by anonymousiam »

Seems like there would be other serious problems with running an OS that hasn't been updated in four+ years. I'm not going to bother with a survey, but if memory serves, there have been at least a half dozen serious exploits revealed among different SSL libraries, bluetooth stacks, and WiFi.

Maybe letting the certificates expire would have actually helped to secure the IoT.

Re: Let’s Encrypt comes up with workaround for abandonware Android devices

#76

Post by heyoni »

anonymousiam wrote: post #75

Seems like there would be other serious problems with running an OS that hasn't been updated in four+ years. I'm not going to bother with a survey, but if memory serves, there have been at least a half dozen serious exploits revealed among different SSL libraries, bluetooth stacks, and WiFi. Maybe letting the certificates expire would have actually helped to secure the IoT.

But if your device is just some thermostat behind a NAT firewall talking to one server, what’s the risk if it isn’t opening up ports or accepting unsolicited connections?

Re: Let’s Encrypt comes up with workaround for abandonware Android devices

#77

Post by stqism »

mschuster91 wrote: post #66
Jonnax wrote: post #33

Earlier quoted context omitted.

Generally these devices use the ancient kernel that they shipped with with the current userland. This is because the device drivers are compiled for that kernel version with no open source alternative. So whilst it might be running a newer version of Android. It isn't like installing Ubuntu 20.04 on a 10 year old laptop.

Honestly, Google should require as part of the Play Store certification that vendors ship their goddamn drivers in a quality that is acceptable to upstream Linux, or at least get them to staging quality.

The situation exists entirely because Google created it, they designed a HAL (hardware abstraction layer) with the intention of letting device manufacturers design devices while skirting GPLv2 requirements.

https://source.android.com/devices/architecture

Re: Let’s Encrypt comes up with workaround for abandonware Android devices

#78

Post by viraptor »

krupan wrote: post #6
usr1106 wrote: post #3

I have always wondered a bit what is the purpose of expiration dates. For certificates or GPG keys alike. Once they expire it often enough creates some problems. Either because renewal has just been forgotten or because there are some technical issues, like in the Let's Encrypt / Android case. If you have a security incident you can't wait for the expiration date anyway, you need to revoke. And hopefully users have a…

I had a co-worker who was pushing for certs that were only valid for a day, or for hours or even minutes. It would solve the whole problem of revocation.

Openstack Anchor aimed for that. No problem with revocation if your certificates last a day, are fully automated, and issuing is validated by network https://wiki.openstack.org/wiki/Security/Projects/Anchor

Re: Let’s Encrypt comes up with workaround for abandonware Android devices

#79

Post by edoceo »

jefftk wrote: post #70

Original Source, from Let's Encrypt: https://letsencrypt.org/2020/12/21/extending-android-compati... "IdenTrust has agreed to issue a 3-year cross-sign for our ISRG Root X1 from their DST Root CA X3. 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…

This "Android intentionally does not enforce the expiration dates of certificates used as trust anchors" - seems like another issue. And now LE is basically building features on an implementation flaw?

Re: Let’s Encrypt comes up with workaround for abandonware Android devices

#80

Post by thayne »

8organicbits wrote: post #19
usr1106 wrote: post #3

I have always wondered a bit what is the purpose of expiration dates. For certificates or GPG keys alike. Once they expire it often enough creates some problems. Either because renewal has just been forgotten or because there are some technical issues, like in the Let's Encrypt / Android case. If you have a security incident you can't wait for the expiration date anyway, you need to revoke. And hopefully users have a…

I agree with the sentiment that cert expiry is a frequent cause of outages. I think short lived certs and automated cert management are a better fix versus certs that never expire (for that issue). If you don't have an expiry then you'd need to keep certificate revocations around forever, so your CRL grows without bound. Currently the certificate revocation list can remove expired certificates as clients won't use th…

> There's also lots of clients that don't check CRL

This is in part due to the difficulty of doing so. On linux at least there is generally not a central location for CRLs, or anything to keep them up to date. Each application is responsible for maintinging CRLs it cares about itself. And then there is the fact that a full set of CRLs is pretty big. OCSP fixes some of that, at the cost of more latency during the TLS handshake. OCSP stapling is probably the best existing solution, but I don't think it is widespread enough that you can rely on it yet.

Post reply on HN