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

111–120 of 132 posts

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

#111

Post by Dylan16807 »

DiabloD3 wrote: post #61
progval wrote: post #44

Earlier quoted context omitted.

> but Google cannot force OEMs to continue supporting a phone within a reasonable timeframe Couldn't Google could pressure them to do it, by making this a legal requirement for a Google Play license for their devices?

Could, in the literal sense? Yes. Could they do it without alienating their hardware partners? No. Does Android require the Google Play store or any other Google services or non-AOSP code? No. Many Android devices ship entirely without Google stuff, including no Google Play store. Could they do it even if they didn't care about alienating their hardware partners? Yes, if they also intend on being fined into the groun…

> fined into the ground

Google's gotten away with extremely anticompetitive requirements so far. I can't imagine it would be worse for them to mandate 5 years of software support, something that's very positive for consumers.

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

#112

Post by Dylan16807 »

danmg wrote: post #56
Jonnax wrote: post #36

Earlier quoted context omitted.

Why are you going after Let's Encrypt and not the manufacturers and hardware vendors that abandoned the devices? The source code for the device drivers are not available to be able to update these phones to the latest version of Android. These devices are insecure. Using them is not sane.

You're really going to scrap your car from 2015 because the off-brand android doo-hicky they stuck in it hasn't been updated? Even if you're technically inclined, it's not like installing some community provided roms image on your slightly out-of-date flagship phone. The device likely has some proprietary aspects to it which would render it useless even if you attempted.

Don't scrap the car, but you shouldn't be connecting the doo-hicky to the internet any more.

The manufacturer sold you a part that would break for many purposes after a few years. Be mad at them, and strongly consider replacing it.

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

#113

Post by M277 »

stjohnswarts wrote: post #88
M277 wrote: post #72

Earlier quoted context omitted.

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 s…

Any reason you can't hook him up with lineage OS?

Couldn't find one for the dual sim version. :(

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

#114

Post by fireant »

Dylan16807 wrote: post #110
fireant wrote: post #108

Earlier quoted context omitted.

What's wrong with using JWTs? What you have done should be industry standard and is enabled by the JWK spec. In fact several features of OpenID Connect are built upon signed JWTs from a well-known JWK store.

https://www.howmanydayssinceajwtalgnonevuln.com/ Having such a tempting footgun is a real problem.

The problem I think is that JWT is just a small puzzle piece of a great artwork that is identity and auth. It is overly complex (not without reason) and people don't put in enough effort to learn the whole picture (and it just isn't thought in schools) and just want to use something quickly for their current problem. Which is why they pick JWT and don't understand the host of related technologies - OAuth2, OIDC, JWK, JWE - just to name a few.

I don't see a reason why I would ever want to use auth=none for anything as at that point JWT is just base64 encoded json but I may be too deep in the identity world by now.

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

#115

Post by Semaphor »

forty wrote: post #52
Semaphor wrote: post #49

Earlier quoted context omitted.

Just FYI, the issue is with certificates in general, nothing to do with LE specifically. Dumbed down, the problem is that someone the old device never heard of, is not trustworthy. Of course, an OS should still work after 8 years. But the problem is, that the OS has been abandoned (by the device manufacturer and possibly the community), so it is falling apart. Anything that accesses the internet needs regular mainten…

I think it's a bit LE specific here though, since according to the article, real trust anchors do not expire on android, so it's only because LE is relatively new and was not a bundled CA root at the time, and had to be signed by a CA that was bundled (and this intermediate signature is what expires if I understand correctly)

It’s not, as any new CA would have the same problem.

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

#116

Post by marcosdumay »

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…

Certificate revoking has a completely different level of reliability from the normal certificate management. There are theoretical flaws that can not be fixed.

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

#117

Post by iso947 »

hannob wrote: post #24
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…

> If you have a security incident you can't wait for the expiration date anyway, you need to revoke. And hopefully users have a mechanism to note the revocation in time. This is the key issue. For a long time there was no working revocation mechanism. With a combination of OCSP, OCSP stapling and the muststaple extension you can get there, but this isn't in widespread use yet. Revocation is a difficult problem.

Even then it still relies on knowledge that the certificate has been compromised.

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

#118

Post by t0astbread »

easton wrote: post #46
t0astbread wrote: post #15

Earlier quoted context omitted.

You have to draw the line somewhere. Daily certs would probably increase the load for CAs by a lot. Also, energy consumption for certificate management would increase.

How compute intensive is a CA, anyway? I’d think that a few Raspberry Pi-ish devices would be enough to do it for an entire enterprise (or maybe even one, but fault tolerance).

In general I would assume when you shorten certificate validity from 90-ish days to one the computational resources required for issuance will increase to about 90x of what it was before. So it would be a lot more expensive to run.

Also, unrelated to that argument but I think the most expensive part in a CA is not issuance but rather OCSP since an OCSP query could happen with every TLS connection (although stapling exists to solve that). OCSP would not be affected by a shortening of validity periods.

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

#119

Post by danmg »

Dylan16807 wrote: post #112
danmg wrote: post #56

Earlier quoted context omitted.

You're really going to scrap your car from 2015 because the off-brand android doo-hicky they stuck in it hasn't been updated? Even if you're technically inclined, it's not like installing some community provided roms image on your slightly out-of-date flagship phone. The device likely has some proprietary aspects to it which would render it useless even if you attempted.

Don't scrap the car, but you shouldn't be connecting the doo-hicky to the internet any more. The manufacturer sold you a part that would break for many purposes after a few years. Be mad at them, and strongly consider replacing it.

The part didn't break. Someone who thinks they know better decided to make it not work, and complicated some normal person's life with some security theater.

If a manufacture intentionally made a product they sold you not work, much like how Tesla disables fast charging capriciously, it would be a violation of the Magnuson-Moss Warranty Act.

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

#120

Post by cnst »

xacky wrote: post #86

Apple devices have the same issue. Any device running iOS 8 or lower can’t connect to tls 1.2 sites which is the majority of the internet.

> Apple devices have the same issue.

Let's be real here -- is this a problem with the device, or with site operators?

All the major players that promote TLSv1.2 -- Mozilla, Microsoft, Google -- serve their websites over TLSv1.0 just fine. Because they understand that they have to serve old devices to sell products and make money even from such outdated clients, which are still plentiful by the absolute numbers when it's billions of users that we're talking about.

In fact, most people aren't even aware of this, but www.google.com itself still works without HTTPS at all. This can easily be verified with curl. Looks like www.bing.com is the same in this aspect; because they gotta make the money from every user as well.

But what doesn't work? Wikipedia. Ironically, it's Wikipedia that intentionally engages in planned device obsolescence. Does the read-only access to an encyclopedia editable by anonymous users even require any TLS at all? Really?! And why is noone talking about this?

The worst part is that the overwhelming tech community is doing absolutely nothing about this injustice -- about planned device obsolescence by the likes of Wikipedia. Most of these obsoleted TLSv1.0 devices have very fast CPUs and gigabytes of RAM, and are still perfectly capable of browsing most of the internet, and non-technical people are genuinely unaware about these politics w.r.t. TLSv1.2. There's not a single advocacy group that I'm aware of that advocates for the rights of people who cannot use TLSv1.2. Mozilla SSL Configuration Generator is intentionally giving misleading TLS advice that Mozilla itself doesn't adhere to.

Post reply on HN