Meditations on Crafting Software

The Symptomatic Experience

A computer (Mac OS X, 10.7.2-10.7.5) attempts to connect to a public wireless network which requires them to either accept some license/agreement and (potentially) authenticate before granting access to the Internet (e.g. at a coffee shop, Internet cafe, or university guest network).

The computer joins the wireless network successfully, but fails to load the "login" page.
The browser reports "Establishing secure connection" or the like, but the page fails to load.

Poking around...

If the user attempts to launch Keychain, the application fails to load, hanging (beachballs).
These symptoms occur when using Safari or Chrome (indeed, any browser that uses WebKit),
However, browsers that do not use WebKit (notably, FireFox), seem to work just fine.
The symptoms persist until the machine is rebooted.

The Problem

Stating the situation more precisely...

A computer joins a wireless network that's running a captive portal.

The network is configured to redirect all attempts to get to the web to a login page to authenticate
and because we're authenticating, the redirect is to an https: URL.

As part of the SSL handshake protocol (RFC 6101), the Server provides its certificate to the client. The client "authenticates" the server, in part by ensuring that the certificate has not been revoked.
The captive portal is not configured to pass through OSCP traffic to known Certificate Authority hosts (which is usually implemented in DER encoding over HTTP). When the client attempts to check for a certificate revocation, the Captive Portal returns the redirect instead.

In Mac OS X, there is an error in this mechanism such that the "Login" keychain becomes corrupted.

Not only can this computer not gain access to the Internet, it now has a corrupt keychain.

Solutions

In my research, here are three solutions offered, in descending order of preference/correctness.

Best Solution: Configure Captive Portal to Pass-Through OCSP Traffic

The most complete solution is for the captive portal to allow OSCP to known hosts. And example of this configuration is here: http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/OCSP-captive-portal-issues-apple-laptops-amp-firefox/td-p/82456.

Next Best Solution: Explicitly Trust the Certificate of the Captive Portal

If you do not have the ability to modify the captive network configuration, then individual clients can get passed this problem by explicitly trusting the X.509 cert of the captive portal itself. This would allow the computer to successfully establish an SSL connection to the captive portal and then the user could login.

By doing this, you are assuming that:

you are connecting to the wireless network you are intending to.
you trust that the people running that network are using valid certificates.

(from: http://superuser.com/questions/349740/mac-os-x-lion-10-7-2-update-breaks-ssl/365333#365333)

Step 1: Download the Captive Portal's Certificate

Visit the captive portal page in Firefox
Select Tools > Page Info > Security > View Certificate > Details > Export
Save the certificate to your hard drive with the extension ".crt"

Step 2: Import the Certificate

If you cannot open Keychain Access because your keychain is corrupted, turn off wireless, delete ~/Library/Keychains/login.keychain and /Library/Keychains/System.keychain, and then reboot.

Open Keychain Access.app
Drag the certificate from Finder into a keychain
Double click on the certificate and expand the "Trust" section
Choose "When using this certificate: Always Trust"
Close the popup window

... then try the login again.

Workaround: Turn Off Certificate Revocation

If, for some reason, you don't want to include the captive network's certificate, you can disable certificate revocation. However, doing so comes with significant risk. The whole point of having certificate revocation is to maintain trust. If you just turn this feature off, then you risk trusting certificates that have been compromised.

To do this, you disable OSCP and CRL before you attempt to connect to the network.

You can either do this in the Keychain App:

Preferences > Certificates
Mark both OSCP and CRL to "Off"
Close the Preferences window (important step as these preferences are not saved until you do)

Or you can change the settings from the command line:

$ defaults write com.apple.security.revocation CRLStyle -string "None"$ defaults write com.apple.security.revocation OCSPStyle -string "None"

Once you've completed the login sequence with the captive network, you should re-enable cert revocation checks:

$ defaults write com.apple.security.revocation CRLStyle -string "BestAttempt"$ defaults write com.apple.security.revocation OCSPStyle -string "BestAttempt"

Summary

A rather cryptic set of circumstances results when OCSP fails on Mac OS X (Lion) while attempting to gain access to the Internet from a captive portal: a keychain becomes corrupted and further attempts to access it hang (instead of reporting an error).

The best fix is for the captive portal administrator to poke holes in the firewall to allow for OSCP traffic to well-known hosts. Barring that, the individual computer user can either explicitly download and trust the certificate of the captive portal login; or temporarily disable certificate revocation checking (not advised).