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

91–100 of 132 posts

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

#91

Post by supertrope »

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.

So like Kerberos?

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

#92

Post by segfaultbuserr »

spockz wrote: post #83
segfaultbuserr wrote: post #40

Earlier quoted context omitted.

It's also important to see that the SSL/TLS system does not allow you to revoke a certificate with 100% certainty, the revocation mechanism is flawed - it's often practically impossible to reliably revoke a certificate after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability. * CRL is a list of revoked certificates, it must be downloaded an…

I see a lot of discussion about server certificates. But does there exist ocsp stapling for clients at all?

No, I don't think so. According to RFC 6066, Section 8 "Certificate Status Request" (a.k.a OCSP Stapling)...

> In order to indicate their desire to receive certificate status information, clients MAY include an extension of type "status_request" in the (extended) client hello. Servers that receive a client hello containing the "status_request" extension MAY return a suitable certificate status response to the client along with their certificate.

And in a TLS handshake, the procedure is ClientHello, ServerHello, Server Certificate, CertificateRequest, Client Certificate. But "Certificate Status Request" is only specified in ClientHello, not CertificateRequest, so it's not possible for a server to request OCSP status from the client.

Hence, OCSP Stapling strictly a service provided to the clients, not vice versa - unfortunately, reliable revocation of client certificate is a still a problem. But I guess it's much easier to blacklist the offended client certificates on your own server, perhaps still problematic in a big organization, but certainly easier than blacklisting every leaked certificate on the Internet.

Disclamer: I don't have any experience on managing systems that use client verification. I did my best to RTMF and fact-check myself, but corrections are welcomed.

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

#93

Post by rini17 »

move-on-by wrote: post #60
pyb wrote: post #47

"The new cross-sign will expire in early 2024, and hopefully versions of Android from 2016 and earlier will be dead by then." Hard disagree. In this day and age, a device or OS that is merely 8 years old should be able to function! Is the issue limited to Lets Encrypt? If so its usage should be discouraged.

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

What, phones are dangerous to rely on after 7 years?

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

#94

Post by schoen »

Causality1 wrote: post #42
vbezhenar wrote: post #16

Earlier quoted context omitted.

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

I know the concept is offensive to us who love optimization and efficiency, but would it actually be impractical, though? A root certificate is a couple of kilobytes. How much space would you need to store every single certificate in history for the next hundred years?

Let's Encrypt alone has issued about 1.5 billion certificates in five years of operation; just storing those in DER form with no indexing or other metadata would occupy more than a terabyte of storage. (This is also not counting CT precertificates, which are duplicative of the final certificates in their meaningful content but contain different signature data.)

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

#95

Post by bawolff »

thayne wrote: post #80
8organicbits wrote: post #19

Earlier quoted context omitted.

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…

OCSP stapling always felt a little hacky to me. It feels like just having super short lived certificates but with extra steps. Why not just have super short lived certificates instesd?

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

#96

Post by Laforet »

reaperhulk wrote: post #57
anfilt wrote: post #53

Earlier quoted context omitted.

For root certs probably not too much space, but for all certs.... That depends on the number of certs issued, and more people and things are using TLS and such so it probably be more than just linear growth. 100 Years seems a bit extreme just even look back 20 years for the terms of hardware and such. Also think about how much common MD5 was then and SHA1, both of which are broken for a lot use cases.

A good example of how rapidly a CRL can grow in size is Apple's WWDRCA CRL. Current size: 224MB despite only containing revocations back to Feb 2020. http://developer.apple.com/certificationauthority/wwdrca.crl

I chuckled a bit when I clicked on your link and got a browser warning that crl cannot be downloaded securely over http.

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

#97

Post by google234123 »

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…

Shame on everyone for not sticking with their Apple 2s.

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

#98

Post by sverhagen »

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…

That was a great clarification, but wouldn't those admins also possibly have put far out expiration dates, to make things "easier" on them.

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

#99

Post by sciurus »

thayne wrote: post #80
8organicbits wrote: post #19

Earlier quoted context omitted.

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…

If you haven't seen it already, check out https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...

(Disclaimer: I work for Mozilla and have helped with the rollout of this)

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

#100

Post by AlphaSite »

sverhagen wrote: post #98
8organicbits wrote: post #19

Earlier quoted context omitted.

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…

That was a great clarification, but wouldn't those admins also possibly have put far out expiration dates, to make things "easier" on them.

I think most browsers typically enforce a maximum duration.
Post reply on HN