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

11–20 of 132 posts

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

#11

Post by dotancohen »

t0astbread wrote: post #9
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 assume expiration protects against the case where a valid certificate is forgotten and a bad actor gets their hands on it and abuses it without the domain owner noticing. Similar to how some sites enforce session expiration.

That is beginning to appear to be a very corner case. But we didn't know that when the standards were being written.

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

#12

Post by dotancohen »

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.

Is he not aware of OCSP Stapling? It's very much a solved issue, as the same CA authorization can be presented to multiple clients.

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

#13

Post by dotancohen »

intricatedetail wrote: post #10

Not sure why author writes using negative language about the fact that Android cannot be remotely updated? To me that sounds like an agenda to encourage the use of less privacy conscious operating systems. If the OS can be remotely updated, nothing stops bad actor from updating particular phone with a keylogger to bypass any end to end messenger a target is using and so on. Remote update is a great option if it is in…

Let's assume that you are correct. I am now holding a perfectly-fine Samsung Note 3, purchased new in 2013 and has never had a broken screen. To which trusted source can I initiate a remote update?

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

#14

Post by Leherenn »

bonzini wrote: post #4

What about iOS? Which is the oldest version that has the Let's Encrypt certificate?

I don't think it's an issue on iOS, Apple is able and willing to update old devices if needs be. My 5S still receives the odd security update in iOS 12 from time to time (basically when something really big comes up).

If it would make sense, I'm pretty sure Apple could update the first iPhone still. And that would cover every iPhone 1 in existence. Android with its fragmentation makes that pretty much impossible.

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

#15

Post by t0astbread »

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.

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.

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

#16

Post by vbezhenar »

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…

You can remove expired certificates from the list of revoked certificates. Without expiration time that list could grow limitless making it impractical.

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

#17

Post by algesten »

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.

When I've implemented JWT in the past (yes, I know, "don't use JWT"), I've opted for public/private signatures. The public cert I would publish on some URL for all consumers of the JWT to use. The rotation of certs there was a matter of hours. It would hold 3-4 of the last certs (depending on JWT lifetime).

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

#18

Post by t0astbread »

dotancohen wrote: post #11
t0astbread wrote: post #9

Earlier quoted context omitted.

I assume expiration protects against the case where a valid certificate is forgotten and a bad actor gets their hands on it and abuses it without the domain owner noticing. Similar to how some sites enforce session expiration.

That is beginning to appear to be a very corner case. But we didn't know that when the standards were being written.

Maybe because certificates are treated as an ephemeral resource that needs to be managed? If a business had "the certificate" for all its lifetime I imagine it would be easier to forget revocation when it's not needed anymore.

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

#19

Post by 8organicbits »

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 them. There's also lots of clients that don't check CRLs. Those clients would be forever vulnerable to a stolen certificate if we removed expiry.

Imagine if you inherited the infrastructure for a company where the previous admin created certs, lost track of them, and used questionable methods for securing them. I believe you'd struggle to find and revoke every previously issued certificate. The expiry ensures that gets cleaned up, eventually.

I don't have a good solution to the Nokia Symbian problem. I suspect if the device only supports SHA-1 then there are other unpatched security issues. Does anyone know if that's the case? If so, this seems more like a support and patching issue.

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

#20

Post by andylynch »

zelienople wrote: post #8

>Today, your example eight-years-obsolete install base of Android starts with version 4.2, which occupies 0.8 percent of the market. Instead of hoping that the 0.8% will shrink over the next 4 years, Let's Encrypt should understand that the 0.8% are the sane, reasonable people who realize that their Android devices still work fine for their intended purpose and do not have to be mindlessly upgraded because of mass-me…

The issue here is not due to Let's Encrypt, it's due to these devices, like so many others, not being designed to be maintained for the long term.

Solving this problem for 1/3 of Android users is going to help reduce the problem of electrical waste; even if they wear out Let's Encrypt will not be they reason why.

Post reply on HN