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:
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.
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.
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.
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:
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.
13/11/24 8:25:15.423 AM com.apple.geod: 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.