jay/certwatch

CertWatch monitors the use of digital certificates in Firefox when you visit secure websites.

certwatch's Issues

Should development versions auto-update?

Should development versions auto-update? I'd have to set updateURL in the manifest. What would I set it to? Here or the AMO page?

Security - Dialog data can be overridden

Make a bookmark folder. Add two websites:
https://www.wikipedia.org/
https://www.facebook.com/
Exit Firefox, Temporarily rename cert8.db and CertWatchDB3.sqlite, Start Firefox.
Middle-click on the bookmark folder to open the websites in separate tabs. CertWatch will give a warning for Wikipedia but the contents of the dialog (ie the certificates) will quickly be replaced by Facebook's.

This happens because dialogs are monolithic and the reporting is done concurrently instead of consecutively.

CertWatch records data while private browsing

Data is recorded by CertWatch while private browsing. What should be recorded, if anything? The user's URL history is recorded in the database and that shouldn't be.

Warn of new intermediate and root CAs

If a new intermediate is found when evaluating a website's certificate chain then the user could be warned that the new intermediate was just found and added to the db (and also added by Firefox to its db).

If a new root is found when examining a website's certificate chain then the user is already warned, but it's confusing. Here is the message shown to the user.
FIXME: Got a new unknown *root* certificate which is not stored in my CertWatchDB. What to do?

The root cert is not added to CertWatch's db until the browser is restarted.

Refer to
https://github.com/jay/CertWatch/blob/69a357dafa9cb705ff8b7dd782c4a756fa649cd6/chrome/content/overlay.js#L661-687

I think timesAccessed should be 1 in both cases and there should be some type of integrated warning in the dialog instead of that message box. Maybe a change in color (orange is good) and/or something integrated like "please review this chain carefully, a new intermediate/root was just added."

When would an unknown root be found during a browser session? After I add a root manually (Tools > Options > Advanced > Certificates > View Certificates > Authorities > Import) I've seen that message but not otherwise. Does Mozilla update its master list of root and intermediate CAs during a browser session?

Security - Better handle CAs silently added to Firefox

A page may use one certificate (checked by CertWatch) but have resources on other HTTPS websites. Those websites' intermediate certificates will be added to Firefox's certificate database silently if they aren't there already. When Firefox is restarted CertWatch will warn for each:

Probably due to a browser update, the following new root certificate was found installed in Firefox

To reproduce:

• Close all tabs and exit Firefox
• Rename cert8.db and CertWatchDB3.sqlite in the profile directory
• Start Firefox
• Go to PayPal.com. It has a resource https://ads.bluelithium.com/pixel?id=2041741&t=2

The chain for that is
DigiCert High Assurance EV Root CA
DigiCert High Assurance CA-3 <--- will be added to Firefox db
ad.yieldmanager.com (ads.bluelithium.com)

• Restart Firefox

After a restart there will be a message from CertWatch that DigiCert High Assurance CA-3 was found due to a browser update.

_

Scenario 2:

• Set homepage to https://encrypted.google.com and on startup show homepage
• Close all tabs and exit Firefox
• Rename cert8.db and CertWatchDB3.sqlite in the profile directory
• Start Firefox
• Observe and warning about Google root cert found due to browser update

Website visits aren't removed when the user clears Firefox history

Firefox has an option to remove history (CTRL+SHIFT+INSERT) but executing a history remove has no bearing on the website history in the CertWatch database.

Website URL may be incorrect

The website URL found by CertWatch may be incorrect under certain circumstances like session restore or several tabs loading simultaneously. The issue is noted in the source, and there are reports in the comments section of the CertWatch author's website. Here's one:

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: (url broken)

I observed the behavior as well, but I don't know the cause.

Dialogs shown before startup may pop under other windows

Observed on Windows 7 SP1 x64 in FF24.

When Firefox is started with CertWatch for the first time a first time use dialog appears. The dialog may not be visible because it's under the windows of other applications. This seems to be very rare and I can't reproduce it.

Because the CertWatch dialogs are blocking this can lead to the user thinking Firefox didn't start when it did and is waiting for the user to confirm the CertWatch dialog.

Firefox window may resize to a tiny window if CertWatch dialog appears on startup

Observed on Windows 7 SP1 x64 in FF24.

Edit: This may have something to do with my 'Restart Firefox' extension. If I exit Firefox manually and then start it manually, I can't reproduce.

Steps to reproduce:

• Set homepage to https://encrypted.google.com and on startup show homepage
• Close all tabs and exit Firefox
• Rename cert8.db and CertWatchDB3.sqlite in the profile directory
• Start Firefox
• Observe and confirm warning about Google root cert found due to browser update
• Restart Firefox
• Observe FF window is resized to a tiny size in upper left hand corner
• Observe CertWatch dialog at same time saying first time certs used

Disambiguate root, intermediate and their revoked certificates

Right now there is one table, certificatesRoot, in the db that stores all of root, intermediate and their revoked. To identify the different types accurately why not separate them or add some identifier? Right now if an intermediate cert is observed in use its parent's hash is stored with it. Although that does make it possible if that circumstance has occurred to identify an intermediate cert in the database, it's really lacking.

I can't distinguish via sql query between a root CA and this revoked one for example:
login.yahoo.com / Google Ltd. (80:96:2A:E4:D6:C5:B4:42:89:4E:95:A1:3E:4A:69:9E:07:D6:94:CF).

Why use dbUpdateStringCertificatesIntermediate?

chrome/content/sqlite-statements.js @ 116-119 shows the dbUpdateStringCertificatesIntermediate query used to update an intermediate certificate does not accept a dateFirstUsed parameter. Why not? Given the current db structure why is this query any different from dbUpdateStringCertificatesRootWeb, and why not consolidate? Root CAs are in the same table with Intermediate CAs. Maybe the author had had a different plan?

To fix a bug where intermediate certificates did not have a dateFirstUsed stored I had to use dbUpdateCertsRootWeb --created from dbUpdateStringCertificatesRootWeb-- since it accepts that parameter.

Opt-out from recording website visits

There should be an option for disabling website visits so that the specific URL a user visits (table visitsWebsite) isn't recorded in the database, but the website certificate info (table certificatesWebsite) still is.

Or maybe an option to record only the domain name and not the full URL?

Recording website visits is essentially a shadow history and I think that's too intrusive by default. I don't know how many users realize that the URLs they visit are always being recorded (I didn't!).

Related:
Website visits aren't removed when the user clears Firefox history
CertWatch records data while private browsing

Predictable OCSP request on first run

Versions affected: CertWatch v1.2.0-pre and earlier on Firefox 24 ESR, 28a, others.

The first time CertWatch runs it populates its database and during that procedure Firefox makes an OCSP request to ocsp.pki.gva.es re Root CA Generalitat Valenciana.

From Wireshark:

Hypertext Transfer Protocol
    POST / HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): POST / HTTP/1.1\r\n]
            [POST / HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: POST
        Request URI: /
        Request Version: HTTP/1.1
    Host: ocsp.pki.gva.es\r\n
    User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0\r\n
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
    Accept-Language: en-US,en;q=0.5\r\n
    Accept-Encoding: gzip, deflate\r\n
    Content-Length: 103\r\n
        [Content length: 103]
    Content-Type: application/ocsp-request\r\n
    Connection: keep-alive\r\n
    \r\n
    [Full request URI: http://ocsp.pki.gva.es/]
    [HTTP request 1/1]
Online Certificate Status Protocol
    tbsRequest
        requestList: 1 item
            Request
                reqCert
                    hashAlgorithm (SHA-1)
                        Algorithm Id: 1.3.14.3.2.26 (SHA-1)
                    issuerNameHash: 3b94c52379217f03b1361591b457a08dc1c42318
                    issuerKeyHash: 7b35d340d21c781966ef741028dc3e4fb27804fc
                    serialNumber: 994436456
        requestExtensions: 1 item
            Extension
                Id: 1.3.6.1.5.5.7.48.1.4 (id-pkix-ocsp-response)
                AcceptableResponses: 1 item
                    AcceptableResponses item: 1.3.6.1.5.5.7.48.1.1 (id-pkix-ocsp-basic)

I don't know why this is happening that Firefox makes an outgoing OCSP request to this address and if this address why no others. The request could fingerprint that the user is using CertWatch and is likely undesirable for TOR, although it's probably undesirable to use OCSP over TOR anyway.

A workaround for this issue is to disable OCSP temporarily for the first run:
user_pref("security.OCSP.enabled", 0);

Certificate opt-out

Allow for ignore if particular certificate is in the chain. For example I'd like to do this with Fiddler's root certificate so that when I have Fiddler enabled for HTTPS monitoring, CertWatch won't record any data or warn me.