CertWatch is a Firefox add-on that helps you control how digital certificates are used when you visit secure websites. While there exist tools that help control how, for example, scripts like Javascript are executed (NoScript addon), there has not been a tool for digital certificates.
The closest Firefox addon to the functionality of CertWatch is Certificate Patrol, which keeps track of website certificates and notifies when a revisited website has a different website certificate. CertWatch collects more information than Certificate Patrol and keeps track of root, intermediate and website certificates, plus visit details.
Once you install CertWatch and restart Firefox, CertWatch will take up to 30 seconds to parse all root certificates that your Firefox comes with. Every secure website that you visit is vouched for by some root certificate that pre-exists in Firefox. Your Firefox has about 150 of those root certificates, and you can traditionally view them in Edit»Preferences»Advanced»Encryption»View Certificates»Authorities.
This is Firefox 4 (beta1) with a new profile. Both Firefox 4 and Firefox 3.6.8 (as found in Ubuntu 10.04) come with 149 root certificates. If you have more than 149, then you accepted yourself extra root certificates which are fully enabled and can vouch for secure websites. As you browse, your Firefox collects intermediate certificates (I plan to explain all these in future posts at certwatch.simos.info). These are added to Firefox without user interaction, as long as the respective root certificate is in Firefox as well.
These are the preferences, accessible from Tools » CertWatch Preferences. When you visit a secure website, there is a process where the website certificate is vouched by the root certificate that Firefox already knows. Between the website and root certificates there could be intermediate certificates, creating what is called a certificate chain.
What the preferences do is specify when you should get a notification while you visit a secure website. The default preferences say that for the certificate chain of a secure website, show the certificate details if any of the website, intermediate or root certificates are encountered for the first time.
Let’s visit https://addons.mozilla.org/ with CertWatch installed.
Each tab correspond to a certificate. All these three certificates are the certificate chain that verifies the secure website https://addons.mozilla.org/. The numbers at the tab names indicate how many times CertWatch encountered these certificates. It’s the first time, so they all show 1. The black star ★ indicates whether the CertWatch Preferences apply for each certificate. Since the preferences indicate first time only, then all tabs get a star.
From the list of root certificates, only a handful of them will be ever used during your browsing and with CertWatch you now have the facility to figure out which ones are actually being used. At this stage I would consider this as the first most important use of CertWatch; keeping track on how many times certificates are used. If you encounter a new certificate when you visit a revisited website, then this is something to investigate.
CertWatch keeps its copy of certificates in an SQLite database in your Firefox profile. For Linux, the path is ~/.mozilla/firefox/YOURPROFILENAME/CertWatchDB3.sqlite. You can read the database with any SQLite client such as the Firefox Addon SQLite Manager or sqlitebrowser (Packaged in Debian and Ubuntu as sqlitebrowser). In the SQLite database you can view the root/intermediate certificate table, the website certificate table, and the website visits table. In all cases the full certificate is stored in case you want to contribute to the EFF SSL Observatory.
CertWatch is developed on Ubuntu Linux 10.04, with Eclipse 3.6 (Helios) and the JSDT environment.
Install the latest version of CertWatch, which is available from the addons.mozilla.org (AMO) CertWatch page.
Follow the progress of CertWatch at the https://certwatch.simos.info/ CertWatch blog.
Here are some secure websites for testing, https://www.google.com/, https://www.paypal.com/, https://www.facebook.com/, https://twitter.com/
I have a question:
– I visit a site A with a certificate signed by CA1. I approve the certificate chain.
– I visit a site B with a certificate signed by CA2. I approve the certificate chain.
– If I visit the site A again, and that its certification chain has changed and uses CA2, will I get a warning ?
In other words: CertWatch show me certificates I have not yet approved, but will it inform me of changes in certificate chains for a particular website ?
@sebsauvage: CertWatch is made of two components; the collection /storage of certificate data for the secure websites you visit, and the reporting to the user (based on the historic data) whether a secure connection needs attention.
The collection/storage of certificate data is quite complete; I cannot think of any data that is not stored in the SQLite database.
For the part of the reporting, this is where CertWatch will be growing in the following months. What I expect is to have cases like the one you describe above and create code that checks for this type of issue.
At the moment, a user would need to manually figure this one out. Suppose that the GMail certificate chain changes from the Verisign root certificate to certification authority CA_rogue (and CA_rogue is actually used by other certificate chains so you do not get a strange “first time with this root certificate” message). In this case, the website certificate would have to be different in order to match CA_rogue. Therefore, when you connect once more to GMail and see some new GMail website certificate, you can check the certificate chain to verify whether it is still GMail » Thawte » Verisign (that’s the current certificate chain) or the root certificate changed.
Thanks for the answer.
Hi,
the functionality of your addon sounds very promising, thanks for making it available. Unfortunately it causes a LOT of disk activity every time I visit an SSL encrypted website. I guess that this is due to the addon accessing the CertWatchDB3.sqlite file, although it is only 416K on my system. If there was a way to make these database reads and writes less aggressive I’d appreciate it a lot. I also wouldn’t mind if this meant that some of the recent updates to the database got lost in case of a system crash (I’m thinking of delayed write access), after all the information stored in the database (visit count etc.) doesn’t seem to be that important.
I’m running Iceweasel 3.6.9 on a Debian testing with CertWatch 1.0. If you need debug information in order to find out what exactly is causing the disk activity I’ll be happy to be of assistance.
@Philipp Hartwig: Thanks for the feedback.
Indeed, the default behaviour of the addon is to count the times that a certificate is used, whether it is a root certificate, an intermediate or the website certificate.
I did not investigate yet whether SQLite has an option to cache read/write requests. This is something I’ld like to do.
An alternative would be to have an option to count the visits up to the, let’s say, fifth time and then consider that the certificate was accessed many times.
In any case, as more checks are added to CertWatch (such as ‘check if certificate path has changed’ or ‘check if THAT certificate was used’ or ‘notify if new web certificate is used’), then it requires to have a proper caching mechanism.
I would like to look into this in more detail. I’ll have time in October.
If you would like to try out with the source code, tell me. I maintain a git repository and I’ll be happy to make it public if it helps to enhance to the addon. I use Eclipse + Javascript environment (JSDT) for the development and it’s fun!
Unfortunately I’m neither a developer nor do I have any experience with SQLite. I’m afraid it is therefore very unlikely that I’ll be able to contribute anything to the addon. Still I’d find it interesting to follow the development (at least passively) by looking at the Git repository and I’m convinced that the addon would only profit from making the repository publicly available.
I’ve had a little look at the disc activity. I’ve tried moving CertWatchDB3.sqlite to a tmpfs (i.e. into RAM) and only placing a symlink to it in my firefox folder. Surprisingly I still got a lot of disk activity whenever I visited an encrypted site.
This is what I found in syslog (after enabling block_dump):
xulrunner-stub(3019): dirtied inode 12238931 (CertWatchDB3.sqlite) on sda5
xulrunner-stub(3019): dirtied inode 12238911 (CertWatchDB3.sqlite-journal) on sda5
xulrunner-stub(3019): dirtied inode 12238911 (CertWatchDB3.sqlite-journal) on sda5
xulrunner-stub(3019): dirtied inode 12238911 (CertWatchDB3.sqlite-journal) on sda5
xulrunner-stub(3019): dirtied inode 12238911 (CertWatchDB3.sqlite-journal) on sda5
xulrunner-stub(3019): dirtied inode 12238911 (CertWatchDB3.sqlite-journal) on sda5
xulrunner-stub(3019): dirtied inode 12238911 (CertWatchDB3.sqlite-journal) on sda5
xulrunner-stub(3019): dirtied inode 12238911 (CertWatchDB3.sqlite-journal) on sda5
So sqlite creates a lot of journal files in the firefox directory. The discussion under [1] is interesting as it seems to indicate a way to move all the journal and other temp files into memory. Maybe this would be an option for CertWatch?
[1] http://www.mail-archive.com/sqlite-users@sqlite.org/msg37362.html
Hello,
I have now moved my complete Firefox profile into RAM (see [1]) as Firefox 4 triggers way too much disk activity for my taste (also with CertWatch disabled). So the problem is gone for me and as it doesn’t seem to annoy anyone else you should probably just ignore it. 🙂
But on a different topic: Today I did some playing around with SSL certificates and to my surprise I found that CertWatch did not alert me when the certificate for a previously visited site changed from one valid certificate to another. I always thought that this was more or less the purpose of CertWatch!? It is the purpose of Certificate Patrol after all and I thought CertWatch was supposed to be an enriched version of CertPatrol? Am I mistaken or is this a bug?
More details: I created a CA and two certificates for 127.0.0.1 that I signed with the CA. I imported the CA into Firefox. I started a simple HTTPS server on 127.0.0.1 using the first certificate. CertWatch would show me the unknown certificate when browsing 127.0.0.1. I stopped the HTTPS server and restarted it using the second certificate. But on browsing 127.0.0.1 in Firefox again, CertWatch would not do anything. CertPatrol on the other hand would warn me that the certificate of a previously visitied site changed for no apparent reason.
I’d be grateful if you could comment on this.
[1] https://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs
As stated in the post this addons seems like an improved version of certpatrol. That is why I would like to have a warning feature which is the essential part of certpatrol to help against mitm attacks. I assume it is a common issue for firefox user having an overloaded set of addons.
Please, make it wokring for firefox 4, thanks !
I’ve noticed an error in CertWatch’s reporting. When I receive a pop-up telling me about a new certificate, the URL specified is the the URL of the currently focused tab, not necessarily the tab where the certificate is being used.
I’m using CertWatch 1.1 on Firefox 3.6.16.
First of all I would like to thank you for the very useful addon. Then let me draw your attention to the strange CertWatch behavior in my system (currently W7/FF7.0.1). It looks like that: I have a lot of open tabs (about 70) scattered over several groups. One tab is open on our corporate https page (with self-signed CA), and others on various http and https sites. After I restart FF it restores my last active tab set (actually through the TabMix’ session manager) and during this massive restoration/reloading CertWatch issues certificate warning saying that a (random, sometimes even just http) site uses that corporate certificate with self-signed CA. I.e. it mess the site and the certificate. There is the screenshot: http://imageshack.us/photo/my-images/269/certwatch.png/
I confirm the issue raised by Max above. In CertWatch window, “Website URL” seems to show the URL, visible in the currently open tab (?). Certificate can come from another tab, so the displayed URL is wrong.
Another issue: CertWatch window is modal: impossible to do anything in the browser (e.g. change the tab) when it is open. I take this as a bug, not as a feature 🙂
Otherwise, a great add-on, and thanks Simos for this work!
Hello Simos, it just occurred to me that CertWatch would be even more useful with Thunderbird than with Firefox because Thunderbird, as far as I can see, doesn’t show you any indication that the connections it makes are protected by SSL/TLS, so a notice of certificates being used would be a great improvement already. Would it be possible to port CertWatch over? Difficult? I’m willing to help, I never developed extensions for Firefox/Tunderbird but I can certainly learn to.
Thanks