Apple + Security & Privacy

When you surf the web, you trust certain web sites where you provide confidential information, such as credit card numbers, or where you access and send e-mail. Certain applications that connect to remote servers also depend on this type of trust. A broad system based on the SSL (Secure Sockets Layer) protocol ensures that when you visit a web site, such as Apple.com, Amazon.com or Google’s Gmail, that the site is indeed what it pretends to be. For example, if you go to Apple’s MobileMe web site, you will see indications such as these in your browser:

At the left of the image above you see Apple Inc. written in green; this is proof that Apple’s digital certificate has been recognized by the Safari web browser. At the right of the image is a padlock icon, which shows that SSL is being used, and that data is sent and received in encrypted form. (Note that not all sites will display a name in green, as above, but all SSL sites will show a padlock in the browser title bar.)

So far so good.

There are a limited number of companies authorized, and recognized, who issue such certificates. One of these, Comodo, was recently hacked, and certain individuals were able to buy nine digital certificates for major web sites, including mail.google.com, login.yahoo.com, login.skype.com and addons.mozilla.org. This means that the malicious users who obtained these certificates will be able to set up web sites that can spoof users who check for the visual signs of trust shown above. They may be able to use these for phishing attacks as well; when you click on a link, and go to a site, if you see these signs indicating security, you’re likely to trust them.

In addition, this goes beyond just web usage. The same system is used when you log into Gmail using an e-mail program, or when you log into Skype via their application. When using public wifi networks, it’s possible that a man-in-the-middle attack may be able to spoof local DNS resources and lead you to a booby-trapped server.

The domains affected are as follows:

• login.live.com
• mail.google.com
• www.google.com
• login.yahoo.com
• login.skype.com
• addons.mozilla.org

Microsoft’s Security Advisory about this issue gives more information about the problem. As they point out:

Comodo has revoked these certificates, and they are listed in Comodo’s current Certificate Revocation List (CRL). In addition, browsers which have enabled the Online Certificate Status Protocol (OCSP) will interactively validate these certificates and block them from being used.

Comodo also discusses the incident in this blog post.

The latest version of Firefox 4, just released this week, includes a fix to spot these fraudulent certificates. Google’s Chrome web browser was also updated for this last week.

Safari, however, doesn’t directly use the CRL or OCSP systems mentioned above; settings to activate this feature are found in Keychain Access. To do this, open Keychain Access; it is in the Utilities Folder in the Applications folder on a Mac. Choose Keychain Access > Preferences, then click on the Certificates tab. Set the first two options, for OCSP and CRL, to Best Attempt, and leave priority set to OCSP. This will tell Safari, or any other program that uses the built-in certificates on Mac OS X, to check these servers before accepting any SSL certificate on a web site. This may, however, slow down access to some sites. So it’s best to not have these settings on all the time.

For now, it’s good to turn these settings on to ensure that your Mac is protected. This affects not just Safari, but Mac OS X in general; certificate validation is a system-wide API. However, not all applications use this system, so we cannot guarantee that this will resolve the problem entirely.