[HN Gopher] Apple memory holed its broken promise for an OCSP op...
___________________________________________________________________
Apple memory holed its broken promise for an OCSP opt-out
Author : latexr
Score : 169 points
Date : 2024-08-07 18:50 UTC (4 hours ago)
(HTM) web link (lapcatsoftware.com)
(TXT) w3m dump (lapcatsoftware.com)
| cyberpunk wrote:
| How does one go about creating a little snitch rule to prevent
| these connections?
| jiripospisil wrote:
| Paste the following on the All Rules view
| https://gist.github.com/jiripospisil/e8e0aeef0f83b76c9d8db08...
|
| (Posting a link because HN formatting breaks the format).
| lapcat wrote:
| That's obsolete. macOS now uses ocsp2.apple.com.
|
| The process is "trustd".
| jiripospisil wrote:
| Thanks. Does that depend on macOS version? Better to block
| both I guess.
| lapcat wrote:
| > Does that depend on macOS version?
|
| Yes, though I couldn't say offhand when exactly it
| changed.
| phi0 wrote:
| I've checked my DNS logs and there hasn't been a single
| hit against ocsp.apple.com over the last year, but around
| 20-30 hits for ocsp2.apple.com per day per device.
| (iphone, macMini, macbook)
|
| Just blocking ocsp2.apple.com is probably fine if you're
| running anything recent-ish.
| JBiserkov wrote:
| Block ocsp3.apple.com while you're at it.
|
| And ocsp4. And 5. Block them all!
| Wowfunhappy wrote:
| Does Little Snitch support regex? Perhaps it should be
| `ocsp\d*\\.apple\\.com`
| FireBeyond wrote:
| Well, let's not forget the little dance Apple did to make their
| programs and the system be able to bypass packet filters like
| Little Snitch...
|
| ... and then claim it was necessary for "updates and upgrades".
| Not sure why TextEdit.app needed a kernel network extension for
| "updates and upgrades".
|
| They also denied it was possible until it was provably
| demonstrated that they did.
|
| I like Apple stuff, everything I use is Apple. But too many see
| them as infallible or go to the whataboutism for missteps like
| these.
| keleftheriou wrote:
| Shameful behavior by Apple.
| saagarjha wrote:
| It's really quite unfortunate how much of Apple software is
| designed around "privacy is when you trust Apple" :/
| flarex wrote:
| Not really they are moving into homomorphic encryption where
| the entire query and processing is encrypted and Apple has no
| knowledge of the what you actually requested.
| walterbell wrote:
| Following through on a public privacy promise does not
| require R&D.
| TimSchumann wrote:
| I was unaware there exists a fully homomorphic encryption
| scheme that has the right trade offs between security and
| computational effort to make this economically viable for
| even moderate to small workloads.
|
| I've always thought it was either far too time or far too
| space intensive to be practical.
|
| Do you have sources on this, either from Apple or academic
| papers of the scheme they're planning on using?
| timenova wrote:
| They posted about this recently [0][1]. They are using
| Homomorphic Encryption in iOS 18 for Live Caller ID
| Lookups.
|
| [0] https://www.swift.org/blog/announcing-swift-
| homomorphic-encr...
|
| [1] https://news.ycombinator.com/item?id=41111129
| rpdillon wrote:
| I've posted about this above a little after you did.
| Reading the article, I'm unable to determine whether or
| not this has any practical utility outside of niche
| applications or if it has the potential to be broadly
| useful. Has anyone reviewed the SDK that can render an
| opinion?
| flarex wrote:
| Homomorphic encryption is broadly useful and in fact
| should be ubiquitous for remote computation that leaks
| private data (not to comment specifically on Apple's
| implementation). They did open source it though, which
| gives you an idea that they want others to follow.
| rpdillon wrote:
| Completely unclear how much they're moving into homomorphic
| encryption. The only resource I'm available to find about it
| is an announcement from 30 July saying that they can now do
| caller ID lookup using homomorphic encryption and they've
| announced an SDK that developers can use to leverage it. But
| the announcement is so vague that it's entirely unclear how
| much this can actually be used for practical workloads. And,
| the idea that they're going to go all in on homomorphic
| encryption is speculative based on what Apple has revealed so
| far.
|
| That's notable, as we're discussing a case where Apple said
| they would do something, and then not only didn't do it, but
| went out of their way to pretend that they never said they
| would.
| flarex wrote:
| I'm not aware of any other company of Apple's size (or
| anywhere approaching) that have been as committed to
| privacy tech. Of course they are not perfect and sometimes
| get it wrong but they constantly release new technologies
| that are furthering our privacy. Who else does it better?
| 7jjjjjjj wrote:
| These companies shouldn't be graded on a curve. Everyone
| knows Microsoft is crap for privacy. But Apple has their
| reality distortion field, and it's important to show
| people that their privacy promises are BS.
| makeitdouble wrote:
| It comes down to what you identify as privacy. Apple is
| commited to not give your data to any other company and
| keep it protected in their ecosystem. They'll sell access
| to you for ads, but only exposing your cohort to the
| advertiser.
|
| From that lens, Google is also commited to never give
| your personal data (think Gmail content, Maps behaviour,
| pins etc) to other companies and keep it all in their
| ecosystem, for themselves only. Your data is their key
| advantage, the base of the ad empire, and they won't let
| another company run away with it.
|
| If we call Apple privacy focused, Google also fits the
| bill, the question just falls down on whether we see
| Apple or Google as part of our intimate circle, within
| our private life. I assume you do for Apple but not for
| Google.
| csande17 wrote:
| Also, the homomorphic encryption is a requirement for
| _third-party_ caller ID providers, not Apple themselves.
| Apple 's first-party "Contact Photos" caller ID feature
| operates primarily on the "trust Apple" security model
| AFAIK.
| Spivak wrote:
| Honestly I can imagine the preference being axed when OSCP _is_
| the macOS antivirus and I 'm pretty sure I know what the first
| thing any malicious software is gonna do if it's able to be
| turned off.
|
| macOS preferences aren't magically locked away from the rest of
| system, regular users can change their own user preferences, and
| root can change system preferences. An antivirus has to still
| work against an attacker who has root. It's why you can't block
| certain apps/domains from the firewall as well.
|
| You could put the preference in recovery mode along with
| disabling SIP and I think that would accomplish everyone's goals.
| lapcat wrote:
| > OSCP _is_ the macOS antivirus
|
| It's not. There are multiple layers of security, including
| notarization and XProtect.
|
| > I'm pretty sure I know what the first thing any malicious
| software is gonna do.
|
| What?
|
| > macOS preferences aren't magically locked away from the rest
| of system, regular users can change their own user preferences,
| and root can change system preferences. An antivirus has to
| still work against an attacker who has root.
|
| You sound confused about admin vs. root. Anyway, if you have a
| local attacker running on your Mac, then it's already too late
| for OCSP.
| Spivak wrote:
| Those aren't so much layers as the different parts, and OSCP
| is how notarization actually provides security, the developer
| cert is what's being checked to run the app.
|
| This scheme isn't really designed to prevent attacks so to
| speak, it's to stop the malicious software on everyone's
| system all at once. You can say _theoretically_ it 's too
| late because the software is already doing what it's doing
| and you should consider the machine compromised. But the
| rubber meets the road for regular users who aren't going to
| wipe their machines in response to malware and so this lets
| you purge it.
|
| I don't think I'm confused about admin vs root. I'm talking
| about the System Administrator user, The oops I ran malware
| with sudo user, uid 0, the user who is only constrained by
| the kernel via SIP. But yeah, admin is the more common use-
| case for regular users and I'm not sure the point you're
| making, malware can get admin and if you put the preference
| somewhere changeable by admin then welp. You could put the
| preference in recovery mode same as SIP, I think that would
| be fine.
| lapcat wrote:
| > Those aren't so much layers as the different parts
|
| Mkay.
|
| > OSCP is how notarization actually works, that's what's
| being checked to validate the notarization.
|
| No, you are misinformed. OCSP is checked by the trustd
| process on ocsp2.apple.com, whereas notarization is checked
| by the syspolicyd process on api.apple-cloudkit.com.
|
| OCSP is simply checking whether the Developer ID
| certificate has been revoked. Notarization, on the other
| hand, requires uploading a build to Apple and receiving a
| special notarization ticket. The notarization ticket is
| either "stapled" to the app or downloaded from Apple when
| the app is first launched.
| Spivak wrote:
| > Mkay
|
| Well they're not. What would you call it? Windows
| Defender and Microsoft's code signing requirement aren't
| super related. You could purge discovered malware with a
| signature/scan but that's not impossible to get around.
|
| I'm not sure I really grok the difference from a security
| perspective when the main thing with notarization is
| ensuring it's signed with your developer cert.
|
| I guess the Venn diagram isn't technically a circle but
| is it not that the actual security of notarization is
| provided by OSCP? I suppose I could have phrased that bit
| better.
|
| Is there a case where a hypothetical notarization process
| that excludes that bit provides any real security?
| Because Apple "scanning it for malware" isn't going to be
| that different from Xprotect.
|
| I'm really not sure what I did to get such an, idk
| hostile? response.
| lapcat wrote:
| > the main thing with notarization is ensuring it's
| signed with your developer cert.
|
| It's not the main thing.
|
| > is it not that the actual security of notarization is
| provided by OSCP?
|
| No.
|
| I tried to explain the difference in my previous reply,
| but I'm not going to sit here and write an entire essay
| on the subject (though I could). The information is out
| there, for example on developer.apple.com. Or even on my
| own website. Inform yourself, or at least stop spouting
| falsehoods.
| Vegenoid wrote:
| > is it not that the actual security of notarization is
| provided by OSCP?
|
| The security of notarization is provided by Apple's
| signature over the hashes of the executables in the app
| [0]. The hashes and signature are put into a "ticket".
| This ticket is stored on Apple's servers, and can also be
| "stapled" to the app. Gatekeeper (one of the macOS
| security systems) will prefer to fetch the ticket from
| Apple if possible, and fall back to the stapled ticket if
| available. Notarization is meant to guarantee that the
| code was sent to Apple and checked for malicious code.
|
| OCSP checks that the Apple Developer ID certificate used
| to sign the app hasn't been revoked.
|
| They are two separate checks done by the Gatekeeper
| system, which is meant to ensure that only trusted
| software runs on macOS. I believe it makes sense to call
| the OCSP check part of the Gatekeeper system, but this
| may be incorrect.
|
| [0]:
| https://forums.developer.apple.com/forums/thread/710738
| hansvm wrote:
| Can you get around that nonsense by turning off wireless radios
| before launching apps?
| minkles wrote:
| Ok I understand the technical considerations here. But really
| what is the risk surface for me here as a dumb end user who uses
| apps from the store and a few things off homebrew and not a lot
| else? I mean I've got a large pile of Apple crap sitting here. Is
| this even remotely worrisome enough to shift it and move to
| something else? The CSAM thing probably was. This? I don't know.
|
| (I could probably do everything I need to do on Linux - I just
| don't want to)
| IndySun wrote:
| What are Apple up to? Very long term?
___________________________________________________________________
(page generated 2024-08-07 23:00 UTC)