X.509 Certificates on the Mac

An exercise in paranoia by
distrusting all the root certificates

I record here some findings from playing with the SSL certificate logic as implemented on Mac OS 10.6.7 . These should be called conjectures rather than findings, but the conjectures are compatible with what:

• I observe,
• seems possible,
• is popularly thought of as desirable,
• is according to commonly supposed crypto rules,
• is conformant with X.509 certificate rhetoric.

There is a system wide collection of certs consulted by Safari and Chrome but not Firefox with a record of which certs the user has chosen to trust for what purposes. For a browser to render a page whose URL begins “https” it attempts to establish an SSL encrypted connection for the indicated page. The server ships a ‘cert chain’ to the browser. The top member of the chain is presumably already known and recognized by the browser, most likely shipped with the browser or OS. Each other member of the chain has presumably been signed by the cert above. The bottom cert presumably has a copy of the domain name portion of the URL. The browser is supposed to check all of these presumptions. This cert logic is intended to ensure that the material displayed by the browser was indeed delivered by the site whose name is the same of the domain name in the URL. This is done be establishing symmetric encryption and authentication keys between the browser and web site.

There is a utility called ‘Keychain Access’ from Apple that comes with the OS which accesses these 509 certs and the computer user’s stated degree of trust of each of these certs. A few weeks ago, after reading of the Stuxnet virus and soon thereafter the Comodo fiasco, I marked almost all of the certs that came with the machine as untrusted. This initially and correctly leads to numerous work flow interruptions as I am asked about unstrusted SSL sites. I instruct the system to trust the certs of CAs that I have actually heard of and also self signed certs at least the first time I encounter them. For other CAs I may choose to trust the cert from a particular site rather than its root cert. The browser (or Keychain Access as its deputy) shows me the cert chain and I can choose to trust any cert on that chain whereupon subsequent trips to that site will proceed without interruption. I often choose to trust the bottom certificate for SSL connections but not for 509 logic. This way my bank account is not at risk of malfeasance by staff at some SSL site. Even if a site whose cert X I have chosen to trust generates and signs a bogus cert for my bank, the attack will fail for when X is included in the cert chain the browser should note that I have chosen not to trust X for cert signing. I have not invested the time to test if browsers do this tet correctly, but the UI in the Keychain app leads to that impression.

By far the largest time cost of distrusting the root certs was Keychain Access asking me to enter my admin's password for each of the hundreds of root certs that I disabled. This design is questionable for enabling such a cert is dangerous, disabling one is not! In a parallel task of distrusting groups of certs held by Firefox, it was efficient to distrust batches.

Chrome does not offer me an opportunity to mark a cert as trusted as does Safari. Neither does it identify the distrusted cert nor the cert by which it was signed.

Safari, on the other hand, will not continue after notifying me of an untrusted cert, even after I select “Continue” in the notification window.

Firefox problems:
Menu Bar > Firefox > Preferences > Advanced > Encryption > View Certificates > Authorities > Comodo > [turn down triangle] > AAA Certificate Services > Export > Save as ‘X.509 (DER)’.
This action indeed places a binary file on my disk. In the same ‘Certificate Manager’ window I click ‘delete or distrust’ and the cert disappears from the list. I close ‘Certificate Manager’ window and go back to the ‘Advanced’ window which is still open and proceed with
Encryption > View Certificates > Authorities > Comodo >
again and ‘AAA Certificate Services’ is back. This is clearly confusing. ‘Edit Trust … ’ shows it to be distrusted, as I wanted.

Secondary URLs

In the following I include in the html of this page the link from the referenced page above to an icon from the alternate server of secure icons at Amazon. It is rendered as a broken image on my paranoid Mac with Safari or Chrome which use Apple’s central cert collection. (Now, 2011 Oct it is good.) I presume that no new SSL protected TCP circuit can be created due to the distrusted cert for the alternate server. The public library computer, which presumably trusts the cert for Amazon’s alternate server, shows the icon properly when viewing this page. Firefox shows the correct icon probably due to its own collection of certs, not as many of which I have marked as distrusted.

Misgivings on 509 Design

If the page at www.amazon.com were to refer to its image server with a YURL which includes a secure hash of the cert at images-na.ssl-images-amazon.com, (or better a finger print of the cert’s public key) then this dilemma would disappear. Alas browsers do not understand YURLs yet. There is another near solution which should be discussed. If Amazon were to acquire a certificate able to create subsidiary certificates, then I could choose to trust the former certificate. There are these drawbacks, however:

• Amazon would acquire the ability to spoof certs for my bank unless the semantics of 509 certificates were changed to limit the ‘common name’ to Amazon sub domains.
• In this scheme Amazon would be unable to delegate to servers outside of Amazon.

Code Signing

It has more recently come to my attention that code signing also relies on these certs. In this case failure is silent and the cause is difficult to diagnose. See this.

Mac OS 10.9

13/11/24 8:25:15.423 AM com.apple.geod[16784]: NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9807)

Preferred Solution