←back to thread

2603 points mattsolle | 1 comments | | HN request time: 0s | source
Show context
elmo2you ◴[] No.25076037[source]
Sincerely and without any intention to troll or be sarcastic: I'm puzzled that people are willing buy a computer/OS where (apparently) software can/will fail to launch if some central company server goes down. Maybe I'm just getting this wrong, because I can honestly not quite wrap my head around this. This is such a big no-go, from a systems design point of view.

Even beyond unintentional glitches at Apple, just imagine what this could mean when traffic to this infra is disrupted intentionally (e.g. to any "unfavorable" country). That sounds like a really serious cyber attack vector to me. Equally dangerous if infra inside the USA gets compromised, if that is going to make Apple computers effectively inoperable. Not sure how Apple will shield itself from legal liability in such an event, if things are intentionally designed this way. I seriously doubt that a cleverly crafted TOS/EULA will do it, for the damage might easily go way beyond to just users in this case.

Again, maybe (and in fact: hopefully) I'm just getting this all wrong. If not, I might know a country or two where this could even warrant a full ban on the sale of Apple computers, if there is no local/national instance of this (apparently crucial) infrastructure operating in that country itself, merely on the argument of national security (and in this case a very valid one, for a change).

All in all, this appears to be a design fuck-up of monumental proportions. One that might very well deserve to have serious legal ramifications for Apple.

replies(35): >>25076070 #>>25076108 #>>25076117 #>>25076130 #>>25076131 #>>25076194 #>>25076232 #>>25076348 #>>25076377 #>>25076414 #>>25076421 #>>25076460 #>>25076514 #>>25076630 #>>25076635 #>>25076649 #>>25076707 #>>25076786 #>>25076858 #>>25076908 #>>25076965 #>>25077109 #>>25077171 #>>25077401 #>>25077488 #>>25077655 #>>25077729 #>>25077764 #>>25077960 #>>25078164 #>>25078511 #>>25078513 #>>25079215 #>>25080127 #>>25108729 #
alwillis ◴[] No.25076635[source]
Welcome to 2020.

Because we can't have nice things, Apple has to check that apps are signed with a current certificate for safety and security reasons. OCSP tells the client if the certificate has been revoked or not.

Try opening a non-https web page; you'll get a bunch of ominous warnings from all major browsers.

Browser certificates need to be OSCP signed for the browser to trust them. You can't even get a new cert if the issuer’s OCSP server goes down, which does happen on occasion.

There are so many dependencies to ensure we're not running malware infected apps that sometimes things break.

Let’s not get carried away; every major tech company has had some version of this happen at one time or another.

FWIW, I haven't experienced any issues with my iMac running Big Sur running Apple or 3rd party apps all day.

replies(1): >>25076771 #
jiggawatts ◴[] No.25076771[source]
This used to be true, but neither Chrome nor Firefox actually check CRLs or OCSP that much. They'll accept OCSP-stapling, but that's about it.

This is a very serious concern for Enterprise PKI systems: revoking certificates is now virtually impossible. CRLs and OCSP do practically nothing.

Google especially has unilaterally decided that Enterprise PKI systems don't matter. They have established a new "standard" called Certificate Transparency, which they use to make CRLSets that they publish as Chrome updates.

Which is fine I suppose for public CAs, but utterly useless on internal-use private CAs on local networks, especially those with lots of BYOD or guest/partner systems. Think universities or hospitals.

Google has become a juggernaut with more control over computing in general (not even just the Internet!) than all of the world governments put together.

They're getting truly terrifying.

replies(4): >>25076906 #>>25076924 #>>25076961 #>>25087203 #
1. iso1631 ◴[] No.25087203[source]
It's a shame you're being downvoted as you're right, CRLs and OCSP do practically nothing _for webbrowsers_

OSCP is flawed because you can block the connection, meaning

1) Your browswer has to accept it (thus an attacker feeding you the bad certificate can bypass OSCP)

2) Your browswer blocks completely (thus DOSsing all connections), and people use another browser

CRLs don't scale - you can't keep a cached list of every revoked cert globally.

However I pull down the CRLs for my internal CA every few hours onto my internal https sites, which rely on a client presenting a valid certificate to connect. If that doesn't get pulled down, I get a warning about it in the monitoring system. When a client with a client certificate connects, I check against my local cache of the CRL, and if it's been revoked, it can't connect.

What problem do you have on your private CA internal network that CRLs fix but browsers don't? Are you that concerned that your server certificates get compromised? You should be working to massively reduce the time those certificate are valid.