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 wish that Apple would produce a document stating in English the logic of these certificates.

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

Even more recently I have had trouble buying books at Amazon. This page already illustrated the problem. On my Mac, with most certs marked as distrusted, I get a fairly standard 404 ‘page not found’ response with html including “<img src="https://images-na.ssl-images-amazon.com …”. The certificate for the main page is good and trusted because the browser identified the cert for me and I have chosen to trust it, but the box at the top comes from some alternate Amazon server with another certificate that is not trusted by my computer. In this case neither Chrome nor Safari consults me about trusting this alternate certificate and the only clue is that the place where the box should appear, holds an image for a broken gif. Neither Safari (Webkit) nor Chrome report errors to the log. If I paste the above https URL into the address bar of Firefox I get a secure SSL connection and then Firefox will show me the distrusted cert chain for that session. The root CA is “COMODO CA Limited”.

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

There is a design issue at this point and some disagreement on proper browser behavior in such cases. Such disagreement may bear on the absence of diagnostics for it is not clear to whom the diagnostic should go. Amazon’s computer at www.amazon.com delegates delivery of icons to Amazon’s alternate server at images-na.ssl-images-amazon.com . Having different domain names, different certs are required and someone must decide which certs to trust, if anyone is ever required to decide whether to trust a cert. I am counting on being in contact with the authentic www.amazon.com and am confident because I trust its cert. I would know nothing of the alternate server images-na.ssl-images-amazon.com but for reverse engineering the html. The browser user should not need to know, let alone trust, the alternate server. www.amazon.com is, however, relying on the authenticity of the alternate server in order that the labels on the depicted buttons be correct. I rely on www.amazon.com which relies on the alternate server; The integrity of these icons should in Amazon’s purview, not mine. Why should the browser consult me about the authenticity of the alternate server?

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:

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

The switch to 10.9 was smooth. Apple is pushing a new app called “Maps” and installs it in the Dock. It connects to an Apple server via https. Unlike Safari it does not know how to consult you on trusting site certificates. It puts up a blank screen and remains incomunicative. Apple’s Console utility shows two entries 4 sec after launch. The first is:
13/11/24 8:25:15.423 AM com.apple.geod[16784]: NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9807)
and the 2nd is much longer and ends with a very long https URL to the site gspa35-ssl.ls.apple.com . Using the whole URL in Safari causes Safari to consult with you about the untrusted cert. You may choose to trust that cert or one of the certs in the cert chain. I chose to trust the cert of the site whereafter the Maps app seems to work. That also caused Safari to download a file called config into my Downloads folder. I deleted it.

Preferred Solution