Mac users listen up! Enable certificate checking

Are you using lack of firewall support as an excuse to avoid IPv6?

My dog ate god's plan

Mac users listen up! Enable certificate checking

Friday, 01 April 2011

I hope you've all heard of the events leading to certificate authority Comodo incorrectly issuing SSL server certificates for some high profile web sites. This is disconcerting news, compounded by an announcement yesterday from hacker Ich Sun who claims to have breached a second CA.

Please revoke DigiNotar CA trust too!

If there is a silver lining, Comodo's provided details of the incident, including the affected domain names and serial numbers here. These certificates have been revoked, so users and applications that check certificate revocation status will not be affected by the bogus certificates.

My colleague Craig Watkins at Transcend, Inc. points out that not everyone has revocation enabled and provided a detailed explanation of how Mac OS users can enable this defense on a private mailing list. His explanation and testing is well documented and timely, so I invited him to post it here.

What follows is fully attributed to Craig Watkins. I take no credit except for having the good sense to keep company with really competent people and recognizing an opportunity to share this competence with you:-)

Google, Microsoft, and Mozilla have patched their browsers (by 23 March) to add these specific certs to a blacklist that will never be trusted. So far Apple has not done this, but that's OK if
everything is working fine with certificate status checking.

The complication is that OCSP and CRL checking is disabled by default in Mac OS (except for Extended Validation "EV" certificates). You should turn it on. While I don't see a
a big risk to most of us from the Comodo issue, in general it is a very good idea to enable this checking. To do this on Mac OS 10.6:

- Open Applications -> Utilities -> Keychain Access
- Under Keychain Access menu, select Preferences...
- Select the Certificates tab
- Set "Online Certificate Status Protocol (OCSP)" to
"Best Attempt"
- Set "Certificate Revocation List (CRL)" to "Best Attempt"
- Set "Priority" to "OCSP"

You can now lock the login keychain and close Keychain Access.

This will effect your Safari and Chrome browsers because they use the keychain. Firefox has its own certificate store, and it should already be configured to use OCSP by default. For Firefox,

- Under the Firefox menu, select Preferences...
- Select the Advanced tab
- Select the Encryption sub-tab
- Click the (Validation) button
- Verify that "Use the Online Certificate Status Protocol" is checked
- Verify that "Validate a certificate if it specifies an OCSP server" is selected
- Leave "When an OCSP server connection fails, treat the certificate as
invalid" unchecked
(That's consistent with the "Best Attempt" setting in Keychain Access)

To see what it looks like when you visit a site with a revoked certificate, visit
https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html

Your browser should not allow you to go to this site and should report that the certificate is revoked. You'll notice a stern warning from Firefox, a really stern warning from Chrome, and a quite wimpy warning from Safari. You should get this warning from Safari and Chrome regardless
of your Keychain Access settings because this site uses one of those EV certificates that I mentioned above. These certificates have added validation requirements and Mac OS will always attempt an OCSP validation so that your browser can show you that "extra-green SSL bar."

The only downside to this extra checking is possibly a slight delay to perform the request the first time you go to a web site and when the cache expires. This should be less overhead than downloading a small image, so I'm not worrying about it.

Thanks Craig!

Posted at 12:12 PM in MacOS, Stop Think Connect, Web/Tech | Permalink | Comments (7)

Spotlight Posts

Widespread Issues with Domain Registration Accountability Have a COVID Nexus
My Interisle partners and colleague Greg Aaron have published a detailed study that measures the effectiveness and impact of ICANN's registration data access policies and procedures. This study reveals widespread problems with access to and the reliability of domain name registration data systems (WHOIS). These failures have real-life security implications, which are being seen in the current wave of cybercrime accompanying the COVID-19 pandemic. In our Press Release I make the comment that, “The COVID-19 pandemic has led to a recent explosion of cybercrime, with thousands of new domain names using terms like ‘covid’ or ‘corona’ being used to perpetrate...
Report: Criminal Abuse of Domain Names, Bulk Registration and Contact Information Access
My Interisle Consulting Group colleague, Dr. Colin Strutt and I have published a report, Criminal Abuse of Domain Names: Bulk Registration and Contact Information Access http://interisle.net/criminaldomainabuse.html In this report, we study "bulk registration misuse" by criminal actors. Bulk registrations refers to the practice of rapidly acquiring domain names, using these in an attack, and abandoning them as if they were throw-away ("burner") phones. These domains are a critical resource for cyber criminals. We use reputation block list (RBL) data to reveal how the use of bulk registrations, coupled with the crippling of registration data access by the ICANN Temp Spec...
Facts & Figures: Whois Policy Changes Impair Blocklisting Defenses
Two independently conducted studies demonstrate that the onset of masking Whois contact data has had the direct, corresponding, and ongoing effect of reducing the number of blocklisted domains, dramatically undermining the efficiency of this and other security countermeasures.
Conservative abuse reporting throws new TLD program under the bus
ICANN has released a January 2019 domain abuse report generated from the Domain Abuse Activity Repor...
APWG and M3AAWG Survey Finds ICANN WHOIS Changes Impede Cyber Investigations
The Anti-Phishing Working Group (APWG) and the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) have collaborated to conduct a survey of cyber investigators and anti-abuse service providers to understand how ICANN’s Temporary Specification for gTLD Registration Data has affected their access and usage of domain name registration information and their ability to mitigate abuse. I served as Principal Investigator for APWG and M3AAWG for this project. I received strong subject matter expertise support from both working groups. From our analysis of 327 survey responses we find that the changes to WHOIS access following ICANN’s implementation of the Temp Spec...

Comments

You can follow this conversation by subscribing to the comment feed for this post.

via Twitter, Christopher Soghoian
(RT by ioerror)

"Each time your browser validates a SSL cert via OCSP protocol, it queries the Cert Authority. If logged, the CA knows where you are surfing."

Posted by: name | Sunday, 17 April 2011 at 09:14 PM

Be warned that enabling this setting reduced my App Store app to a crawl.

------------------------- NOTE -----------------

There's a discussion thread about this problem.

http://discussions.apple.com/thread.jspa?messageID=13327545

From the thread:

"Switching off certificate checks did solve the problem. However the discussion in that thread suggests that this fix subverts security."

Posted by: James French | Monday, 04 April 2011 at 01:48 PM

Folks may also want to check out the 'Perspectives' extension for Firefox (CA mismatch detection)

http://www.networknotary.org/firefox.html

as well as recent initiatives by Google such as their 'Cert Catalog' (not meant to be a replacement for OCSP/CRL)

http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html

Lots of work ahead to improve PKI infrastructure. In the meantime we don our tfh's.

Posted by: Geoff | Monday, 04 April 2011 at 01:08 PM

When I enable this option in Keychain Access, App Store becomes unusably slow. Every page change takes 10 or more seconds. Is that "normal" or is it just happening to me?

@tempelorg

------------------------- NOTE -----------------

There's a discussion thread about this problem.

http://discussions.apple.com/thread.jspa?messageID=13327545

From the thread:

"Switching off certificate checks did solve the problem. However the discussion in that thread suggests that this fix subverts security."

Posted by: Tempelorg | Monday, 04 April 2011 at 12:07 PM

Hi Dave Z,

I downloaded Opera to confirm this. It seems that Opera uses the certificate validation settings as set in the Certificates pane of Keychain access. I gathered this from Help-> search -> "certificate revocation" returns "Changing the validation settings for certificates". I didn't see any explicit method to modify certificate validation in an Opera preference. Is this what you meant in your comment?

Posted by: The Security Skeptic | Monday, 04 April 2011 at 10:52 AM

Verify your Comment

Previewing your Comment

Posted by: |

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:

Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

The Security Skeptic

The Security Skeptic blogs about all matters related to Internet Security, from domain names (DNS), firewalls and network security to phishing, malware and social engineering.