OCSP Service using up quite a bit of bandwidth

I suggest this procedure to those having the same problem as the original poster.

Back up all data.

If you have more than one user account, you must be logged in as an administrator to carry out these instructions.

Triple-click anywhere in the line below on this page to select it:

sudo rm -i ~root/Library/Caches/ocspd/Cache.db

Copy the selected text to the Clipboard by pressing the key combination command-C.

Launch the Terminal application in any of the following ways:

☞ Enter the first few letters of its name into a Spotlight search. Select it in the results (it should be at the top.)

☞ In the Finder, select Go ▹ Utilities from the menu bar, or press the key combination shift-command-U. The application is in the folder that opens.

☞ Open LaunchPad. Click Utilities, then Terminal in the icon grid.

Paste into the Terminal window by pressing the key combination command-V. I've tested these instructions only with the Safari web browser. If you use another browser, you may have to press the return key after pasting. You'll be prompted for your login password. Nothing will be displayed when you type it. If you don’t have a login password, you’ll need to set one before you can run the command. You may get a one-time warning to be careful. Confirm. You don't need to post the warning.

If you see a message that your username "is not in the sudoers file," then you're not logged in as an administrator. Log in as one and start over.

You may be prompted to remove a file named exactly "Cache.db" (without the quotes.) Press the Y key and then return to confirm. Press the N key and then return if you get any other response, or just close the Terminal window. You can then quit Terminal.

Do not type anything in the Terminal window, apart from your password. Copy and paste only.

Restart the computer.

Credit for this idea, if it helps, to ASC members Drew Reece and Elrainia.

Cheers,

I have the Little Snitch demo thanks for the screengrab, I couldn't find the place to start a capture or see data amounts 🙂

You can select the urls in snitch's floaty network monitor window & copy to get an overview…

/usr/sbin/ocspd Total: 5.24 kB sent, 35.8 kB received

rapidssl-ocsp.geotrust.com (199.7.59.72), Port http (80), Protocol TCP (6), 5.24 kB sent, 35.8 kB received

ocsp.digicert.com (93.184.220.29), Port http (80), Protocol TCP (6), 1.54 kB sent, 3.94 kB received

clients1.google.com (173.194.34.165), Port http (80), Protocol TCP (6), 1.82 kB sent, 4.72 kB received

svr-sgc-crl.thawte.com (2.22.133.163), Port http (80), Protocol TCP (6), 367 B sent, 29.7 kB received

ocsp.entrust.net (23.74.101.231), Port http (80), Protocol TCP (6), 876 B sent, 6.36 kB received

ocsp.comodoca.com (178.255.83.1), Port http (80), Protocol TCP (6), 1.55 kB sent, 4.29 kB received

crt.comodoca.com (178.255.83.2), Port http (80), Protocol TCP (6), 977 B sent, 201 kB received

ocsp.startssl.com (82.71.193.201), Port http (80), Protocol TCP (6), 912 B sent, 6.17 kB received

Thank you, that helps. I'll see what info I can gather & compare to a clean restore.

@emlynuk, thanks. It's a CRL. Revocation lists are not intended to be downloaded frequently as they can be large, particularly if a CA is compromised and a lot of certificates are added to the list. They're meant to be periodic - say daily - with OCSP making up the difference.

From what I've read to date there are (at least) two possible causes for frequent downloads of the CRL.

One is that a process is explicitly asking fo the CRL to be refreshed.

The other is that the CRL has a very short expiry, so every time a process requests a certificate be checked the CRL is expired and a new one needs to be downloaded.

For info, continuation of graph below. Up to 23:00 is user activity, overlapping the previous graph, but from then on there was only a sys admin logged in (not iCloud linked) with no apps other than Rubbernet running. You can see the same ~40min periodic download happening. Time machine is running hourly backups, but I'm not aware of anything else that's on anything like this schedule.

Just to report back on the ~root/Library/Caches/ocspd/ file deletion experiment....

All was good for about 8 hours with no apps running. Fired up Mail and iTunes and the downloads have started again. 😟

The only thing that I can say with any certainty is that I have a 100% correlation between

storeagent[353]: multibyte ASN1 identifiers are not supported.

log entries and 200Mb/s ocspd downloads.

Apple got back to me via email with the following observations:

"Apple Engineering has received reports of this symptom and are investigating."

and

"I understand this is causing issues about broadband limit usage but until the issue is resolved I would advise you to turn off OCSP and CRL."

Any bets that 10.9.1 is gonna offer a fix for this...

@emlynuk based what you posted I turned CRL checking off in Keychain Access prefs, left OCSP on, and <insert applause?> ocspd downloads for the past few hours have totalled about 20KB. No great news I guess, as others have already suggested turning both off, but the key here is that it looks like we can significantly reduce traffic by only turning CRL off, perhaps remaining security.

I need to test further, to make sure downloads don't start again when other users log in/do something they haven't done yet, and sniff what ocspd doing now, but the fact that it's downloading anything at all points to it making OCSP request for validation of certs rather than downloading a CRL. If that's the case the validation may be working; I have tested https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html in Safari and it correctly identifies this as a revoked certificate. However, it looks like Safari is doing it's own check - there's a connection from Safari Networking to akamai, but no traffic from/to ocspd, when I attempt to load that page.

The safety or otherwise of having CRL checking off, but OCSP on, depends on whether all validation requests will be made via OCSP in the absence of CRL. I'm guessing it may be client process dependent. If anyone's got the time perhaps try:

- set KeyChain Access prefs to: OCSP Best Attempt, CRL Off

- block traffic to the OCSP servers

- try to validate a cert

I'm not sure this is a valid test though, as it's not possible to absolutely require validation (ie. hard fail) as the option is greyed out in KeyChain Access.

I have gone back to my settings (like you asked above) and put OCSP back to Best attempt, and left CRL "Off", and my Mac has been good for close to 12 hours. The only spikes I see on my router traffic logs are from real use by me.

Keep in mind my firewall is still blocking outgoing traffic to 23.0.165.42, .16 and .81.

I'll let you know what happens over the next 24 hours....if it's still good, I will try turning off the firewall rule.

bdiamond18 wrote:

I have gone back to my settings (like you asked above) and put OCSP back to Best attempt, and left CRL "Off", and my Mac has been good for close to 12 hours. The only spikes I see on my router traffic logs are from real use by me.

Similar story here, although only about 8 hours so far (I've got no relevant firewall rules in place).

I could have sworn that I'd tried this combo before and had zero/minimal effect, but clearly I'm wrong on that score or something has changed somewhere else.

Maybe Apple is listening to this thread and made updates on their end? 😮

Apple doesn’t routinely monitor the discussions.

Send Apple feedback. They won't answer, but at least will know there is a problem. If enough people send feedback, it may get the problem solved sooner.

Feedback

I found this on another thread relating to the same problem:

https://discussions.apple.com/thread/5578275?answerId=23984535022#23984535022&ac_cid=tw123456#23984535

My Apple bug ID is: 15529619 which is a duplicate of: 15432402.