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

81–90 of 132 posts

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

#81

Post by schoen »

edoceo wrote: post #79
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?

I agree with you conceptually, but it seems like everyone wants this and nobody doesn't want it, so as the lawyers sometimes say, "no harm, no foul".

In particular, the users of the Android devices want to continue to be able to access sites protected with Let's Encrypt, the site operators want to continue to allow this, Let's Encrypt wants to continue to allow this, and the auditors and root program operators decided that they don't consider it improper either.

You're right to describe it as an implementation flaw -- among other things, it removes the lever that root programs normally have to ensure continued compliance by CAs.

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

#82

Post by thayne »

_jal wrote: post #5
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…

Things are moving in the other direction. Browser vendors have forced certificates used for browsers to a max life of 398 days. There are multiple reasons, but you seem focused on the certificate management side. One advantage of doing things more frequently is they are forced to become more routine or automated. So shorter expirations should actually make expiration failures less likely over time. Of course the tran…

That lifetime is for domain certificates. CA certificates, which is what matters for the Let's Encrypt issue have much longer lifetimes, like 10 years.

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

#83

Post by spockz »

segfaultbuserr wrote: post #40
necheffa wrote: post #7

Earlier quoted context omitted.

In order to revoke a certificate, you first must at least suspect it has been compromised. An expiration date can help limit the impact of compromises you don't suspect.

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?

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

#84

Post by anonymousiam »

heyoni wrote: post #76
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?

If it uses WiFi, it might just provide a foothold for an intruder to your protected network.

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

#85

Post by stjohnswarts »

schoen wrote: post #81
edoceo wrote: post #79

Earlier quoted context omitted.

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?

I agree with you conceptually, but it seems like everyone wants this and nobody doesn't want it, so as the lawyers sometimes say, "no harm, no foul". In particular, the users of the Android devices want to continue to be able to access sites protected with Let's Encrypt, the site operators want to continue to allow this, Let's Encrypt wants to continue to allow this, and the auditors and root program operators decide…

Thanks for the explanation. Sometime pragmatism has to overcome idealism/semantics to keep things moving.

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

#87

Post by stjohnswarts »

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.

However lots of corner cases end up being weak points to be hacked if not properly accounted for

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

#88

Post by stjohnswarts »

M277 wrote: post #72
1-6 wrote: post #67

Earlier quoted context omitted.

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

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

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

#89

Post by quesera »

gene91 wrote: post #71
quesera wrote: post #62

Earlier quoted context omitted.

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...

Thank you for the correction!

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

#90

Post by michalhosna »

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.

How many devices are running iOS8 or older vs 7.1.1 or older?

iOS8 released 2014. Newest iPhone that is stuck on iOS8 or older is iPhone 4 from 2010.

Android 7.1.1 released 2016, many devices without any upgrade provided. There are Android phones from 2016 + 2017 that are stuck at 7.1.

Apple devices does not have the same problem.

(Android upgrade paths are super sad, you almost have to buy new phone every year to stay updated)

Post reply on HN