hoakley August 12, 2021 Macs, Technology

Is Apple keeping its promises over online OCSP certificate checks?

Cast your mind back to Thursday 12 November last year (2020, in case time still seems out of joint). Let me remind you of what occurred on that day to millions of Macs around the world.

It happened to be the day that Big Sur was released to the public, unusually not in its first version 11.0, but as 11.0.1. That coincided with two prominent Apple server failures: those intended to deliver Big Sur inauspiciously hit a problem, delaying its release for many, and ocsp.apple.com went down for several hours.

At the time, few knew of the significance of ocsp.apple.com, and the great majority of us were blissfully ignorant of OCSP too. But that second and greater misfortune which struck Apple and even more millions of Mac users that day stopped apps dead in their tracks, their users unable to launch the software on which they rely.

It wasn’t until the following day that a full explanation was provided, not by Apple, but by Jeff Johnson, one of the most knowledgeable and experienced Mac developers on the planet. His account led a general call for urgent action.

Apple responded swiftly, announcing on Monday 16 November – immediately following the weekend in which there had been intense public discussion – that it would address the issues raised. Not only that, but its undertakings were published explicitly here, stating: “to further protect privacy, we have stopped logging IP addresses associated with Developer ID certificate checks, and we will ensure that any collected IP addresses are removed from logs.” It additionally promised that would make the following changes over the coming year (from 16 November 2020):

“a new encrypted protocol for Developer ID certificate revocation checks”;
“strong protections against server failure”;
“a new preference for users to opt out of these security protections”.

With less than three months to go to the end of that year, I can’t discover any further announcements from Apple that anything has changed, and by the end of November last year the trail runs cold. Apple revised that support article on 30 March 2021, but doesn’t appear to have altered anything of substance concerning its OCSP checks.

Of Apple’s four promises, removal of IP addresses from the OCSP servers should have happened immediately, and there appear to have been no further server outages, making it plausible that the service is now more robust.

Apple has made no announcement regarding the more difficult problem of introducing an encrypted protocol to protect revocation checks. This is more difficult than it might sound because the obvious answer of using TLS would introduce a circular dependency on being able to check the TLS certificate, which is the reason for many OCSP checks being performed over HTTP rather than HTTPS. I’m not aware that Apple has solved this conundrum and introduced the encryption that it promised last November.

It’s the fourth promise which should be most obvious. I can see no change in Big Sur which provides a means for users to opt out of OCSP revocation checks. Perhaps Apple intended to introduce this in Monterey, but there’s no mention in the full list of its features, nor can I see any reference to it in release or other notes, nor comments by those currently testing betas. As far as I can tell, the Security & Privacy pane, where such a control would be expected to appear, makes no mention.

I think it’s time for Apple to provide an update on its progress in implementing the changes which it so publicly announced on 16 November 2020.

In the meantime, if you do want to ensure that your Mac doesn’t perform OCSP checks, I’ve compiled my recommendations here.

6Comments

Add yours

1

F30 on August 12, 2021 at 8:04 am

It is generally possible to perform OCSP queries over HTTPS/TLS. As you write, this is problematic when trying to validate for the certificate from that TLS connection itself. However, macOS does not do OCSP for regular TLS anyway. For the code signing certificates, OCSP validation should not be an issue.

LikeLiked by 1 person
- 2
  
  hoakley on August 12, 2021 at 10:14 pm
  
  Thank you.
  I don’t think this would be regular TLS, would it though? To meet Apple’s intention, surely the certificate used for the TLS connection should be properly checked, or how could it be secure and encrypted?
  Howard.
  
  LikeLike
  - 3
    
    F30 on August 13, 2021 at 2:34 pm
    
    That will depend on what you mean by “properly checked”: Basically, there are two ways to check for certificate revocation: CRLs and OCSP.
    
    With CRLs, CAs usually publish a list of revoked certificates. Everybody who wants to validate certificates has to regularly download these lists. They get longer and longer over time, even though technologies like delta CRLs do exist in theory. We can see how the approach won’t scale for the global web PKI with hundreds of CAs and millions of clients. This story might be different if you’re running a private PKI, e.g. as a company issuing user certificates to your employees. (Or an OS vendor issuing code signing certificates to developers, for that matter.)
    
    With OCSP, a server run by the CA gets asked whether the certificate is still valid every time the certificate gets used. Apart from privacy issues, you now rely on that server being available (which was Apple’s original problem). Also, performing OCSP for every TLS connection does introduce additional latency.
    
    Therefore, neither (classic) CRLs nor OCSP play a huge role for the public web PKI these days. Firefox and Internet Explorer appear to be the only browsers still doing OCSP by default, but even they default to a fail-safe mode where a missing OCSP response will count as valid. (This opens the door for man-in-the-middle attacks.) OCSP stapling would solve the issues, but it has not gained wide adoption so far.
    
    As of now, most browsers and operating systems resort to some implementation of a single, aggregated CRL delivered by the browser/OS vendor. In Chrome, this is called CRLSets; Mozilla has OneCRL. Apple appears to be doing something similar, but information on it is sparse. (Might be an interesting topic for you to dig into.) All of these have to make some compromises, as they realistically cannot contain all revoked certificates. Mozilla is experimenting with a new technology called CRLite to overcome that.
    
    For Apple to keep its promise, I can see multiple ways: OCSP is an HTTP-based protocol that can work over HTTPS with TLS. We should view this TLS connection independently of its payload, the OCSP query for a code signing certificate. For the connection, you may or may not apply all the considerations from above about public web PKI revocation. Not performing additional OCSP checks makes it about as secure as any other TLS connection, which you also rely on for other sensitive connections as well. Furthermore, the payload will still be signed at the OCSP level.
    
    However, that approach will not protect against server failures. Also, Apple would still see the apps launched by users, even though a third party snooping on the network would not. To work around that, they might route the traffic over their new Private Relay service. But if I were Apple, I’d probably go with a CRL-like approach and have clients regularly download (delta) lists of revoked certificates. As they control the single PKI used for code signing, that should be feasible.
    
    LikeLiked by 1 person
    - 4
      
      hoakley on August 13, 2021 at 6:41 pm
      
      Thank you. That’s very informative.
      macOS used to use a CRL-based system, but I think Apple believed that this propagated far too slowly, leaving users exposed to known malware for days or even weeks. It also relied entirely on every Mac downloading the latest CRL or its delta, which again didn’t prove at all reliable.
      I don’t think the major concern is with Apple knowing which certificate is being checked – and that doesn’t necessarily reveal which app is being run, except for certificates which are only used to sign a single product – but the ease of man-in-the-middle attack, for example by a hostile government. This might, for instance, reveal which Mac users are using specific comms products and when.
      Howard.
      
      LikeLike
    - 5
      
      hoakley on August 13, 2021 at 7:37 pm
      
      It’s also worth pointing out that the current system of OCSP checks doesn’t rely on the OCSP server being available. macOS falls back to not performing the check when it can’t contact the service. Otherwise it would only be possible to launch such apps when you have an Internet connection.
      The problem here, as I understand it, was that the server was responding, but failed to answer the queries it was getting. That too is simple to address – first, in ensuring that the server either answers or doesn’t respond at all, and second by ensuring a timeout in macOS waiting for an answer to a query. Although the second introduces a vulnerability, I don’t think in this case it would affect overall security.
      Howard.
      
      LikeLike
6

Michael Tsai - Blog - Apple Server Outage Makes Mac Apps Hang on Launch on August 13, 2021 at 6:22 pm

[…] Update (2021-08-13): Howard Oakley: […]

LikeLike

·Comments are closed.

Share this:

Like this:

Related