CertWatch 0.8 (released May 14, 2010)

Certificate Watch (CertWatch) is a Firefox extension that helps detect security problems with certificates in secure websites (https://).

I uploaded CertWatch 1.0 to AMO (Addons.Mozilla.Org) and it will take a few days until it gets accepted and becomes available there.

Therefore, let’s see for now what we get with CertWatch 0.8.

Installation

You can install CertWatch 0.8 by visiting the CertWatch AMO web page.

Once you install, select to restart your browser. Note that when you restart your browser, CertWatch performs an analysis of your Firefox’s root certificates and adds them to its own copy, in the file CertWatchDB2.sqlite, in your profile folder. This analysis may take up to 30 seconds (if your computer is slow), therefore be patient.

First use

CertWatch 0.8 - First time use
CertWatch 0.8 - First time use

Once you have installed CertWatch 0.8 and you restart Firefox, you are presented with a dialog similar to the one above. It shows the number of root certificates (includes what we call “intermediate” certificates as well) that have been read from Firefox and saved in CertWatch’s database. In CertWatch we distinguish between root and intermediate certificates. Click OK and you are read to surf.

Preferences

The CertWatch preferences are accessible from Tools » CertWatch Preferences.

CertWatch 0.8 Preferences dialog
CertWatch 0.8 Preferences dialog

When you visit a secure (i.e. https://) website, Firefox verifies whether the website certificate (secure websites come with “certificates”) is vouched by some authority, a Certification Authority (CA). These Certification Authorities are the 177 root certificates we saw earlier. There is a link between a website certificate and a corresponding root certificate in Firefox. In addition, between the website and root certificates there might be more certificates, the intermediate certificates. All these together make a chain.

So, when you visit a secure website, Firefox finds all the elements of the certification chain and verifies that a website is secure.

Once of the principle tasks of CertWatch is to keep track how many times a certificate has been accessed. When you repeatedly visit secure websites, the same certificates are used. So, with these preferences, CertWatch asks you how often to get notifications when certificates are accessed. The default is, when any new certificate is accessed, to show some notification.

In CertWatch 0.8 you can select up to how many times a new certificate (either website or root/intermediate) should be shown, when you visit a secure website.

CertWatch 0.8 - Website certificate
CertWatch 0.8 - Website certificate

This is a website certificate; every secure website has one of those. Issued To are the details of the website according to the certificate. Issued By are the details of the certification authority that vouches for the website certificate. From these details we do not know yet whether this Thawte certificate is a root certificate or whether it’s an intermediate certificate with some other root certificate on top.

Validity shows when the certificate was issued and when it expires. I hope you like the human-readable text next to the dates. Finally, the SHA-1 fingerprint of the certificate is shown. We keep track of the fingerprints in the CertWatch database; it helps to identify if something strange changed in the chain.

Certwatch 0.8 - Intermediate certificate
Certwatch 0.8 - Intermediate certificate

These are the details of the Thawte certificate. It is issued by a Verisign certificate so we know that the Thawte certificate is an intermediate certificate. We will see below whether the Verisign certificate is the root certificate or just an intermediate certificate.

Why does Verisign vouch for a Thawte certificate? Aren’t they different companies? Thawte was a South African company by Mark Shuttleworth (Ubuntu fame, cosmonaut) who sold his company in 1999 to Verisign. Now Thawte is part of Verisign.

You can notice the validity, compared to the validity of the website certificate. The more we move towards the root certificate, the validities become wider (compare two years to ten years for website and intermediate respectively).

Certwatch 0.8 - Root certificate
Certwatch 0.8 - Root certificate

This is the root certificate. The Issued To and Issued By details are the same. In CertWatch 1.0 this detail will be more visual than having to compare strings.

Although this certificate is for Google (I am insinuating quality), it is amazing how old the certificate is. It hails from 1996. The validity span is over 30 years. A piece of information that we do not show yet in CertWatch is the key size; this Verisign certificate from 1996 has a key size of 1024 bits. If you read the security news, you may have noticed complaints about this root certificate. It gets a bit worse; both this Verisign and the Thawte certificates have 1024-bit keys.

Are these two 1024-bit keys compromised? We can only speculate at this time. It will helps us figure out the answer if we can find out, how much harder it is to perform calculations between 1024-bit and 2048-bit RSA keys, and multiply that with the millions that connect to Google and GMail every day. If the computation requirements are not very different between the two, then there is no reason to keep 1024-bit keys.

The new billing.microsoft.com root certificate

If you visit https://billing.microsoft.com/ with Firefox, you will be confronted with an error message that the certificate is invalid. The reason is that the website is vouched by a new root certificate by Microsoft, that Microsoft appears not to have done the proper procedure to contact the Mozilla Foundation and add the root certificate.

Using CertWatch we managed to extract the certificate file (other methods also exist).

Here are the details of this billing.microsoft.com root certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6a:80:24:5c:00:08:00:01:9c:18
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: DC=com, DC=microsoft, DC=corp, DC=redmond,
                                CN=Microsoft Secure Server Authority
        Validity
            Not Before: Jul  9 03:16:55 2010 GMT
            Not After : Jul  9 03:16:55 2011 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft,
                OU=Windows Live Operations, CN=billing.microsoft.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:ab:d7:34:a7:58:eb:89:b8:a0:3c:5a:d4:fb:d5:
                    49:1e:6c:51:79:d0:dc:49:03:3d:11:e8:79:2c:e2:
                    c8:24:e4:d0:a8:45:57:c1:fd:b9:9e:ed:c0:c5:e6:
                    94:ae:96:45:db:ce:14:29:63:34:55:f4:e9:3a:d1:
                    4e:be:45:06:db:ef:f0:95:7d:dd:63:21:81:6e:d6:
                    1f:8a:7d:59:80:83:df:59:a8:a6:6e:b3:82:ea:af:
                    80:43:79:45:45:af:fb:5e:66:83:4d:b2:23:13:ff:
                    bc:67:5d:a5:7b:03:81:e5:24:7f:31:2d:5b:1d:98:
                    ed:c5:53:73:17:2e:7e:c4:cd
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage:
                Digital Signature, Key Encipherment, Data Encipherment
            S/MIME Capabilities:
......0...+....0050...*.H..
..*.H..
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 Subject Key Identifier:
                69:47:71:B7:BA:81:B5:35:50:69:AC:DB:46:18:F2:5F:82:83:9B:D5
            X509v3 Authority Key Identifier:
                keyid:08:42:E3:DB:4E:11:66:F3:B5:08:C5:40:DB:55:7C:33:46:11:83:38

            X509v3 CRL Distribution Points:
                URI:http://mscrl.microsoft.com/pki/mscorp/crl/Microsoft%20Secure%20Server%20Authority(8).crl
                URI:http://crl.microsoft.com/pki/mscorp/crl/Microsoft%20Secure%20Server%20Authority(8).crl
                URI:http://corppki/crl/Microsoft%20Secure%20Server%20Authority(8).crl

            Authority Information Access:
                CA Issuers - URI:http://www.microsoft.com/pki/mscorp/Microsoft%20Secure%20Server%20Authority(8).crt
                CA Issuers - URI:http://corppki/aia/Microsoft%20Secure%20Server%20Authority(8).crt

            1.3.6.1.4.1.311.21.7:
                00.(+.....7.....M..........}...t.O.........c..d...
            1.3.6.1.4.1.311.21.10:
                0.0
..+.......0
..+.......
    Signature Algorithm: sha1WithRSAEncryption
        77:62:04:97:b2:38:c5:90:1e:9f:8d:03:16:bd:79:c9:c9:54:
        cb:f3:94:b4:7a:fa:18:de:95:54:20:1f:3a:bd:72:c2:d9:46:
        d5:af:b9:72:5a:a2:52:5f:42:89:16:b8:60:f7:00:74:19:e8:
        de:23:64:0c:a2:6e:64:7c:22:aa:58:a0:25:59:24:b5:30:54:
        2f:a3:be:db:b7:6d:ce:02:37:37:d8:c0:11:c5:62:d8:81:84:
        cd:c3:e3:15:36:33:56:97:7f:68:d9:ab:d4:ac:5a:9b:f5:99:
        be:52:4d:f1:c4:32:40:0d:ed:27:59:36:75:3c:a5:27:6e:66:
        43:b8:82:56:74:eb:ab:62:5f:5d:96:b8:ba:0d:59:f7:1f:f4:
        8d:e1:ff:88:0d:5d:76:10:3e:90:46:85:5e:f9:a7:13:b8:11:
        e8:39:79:49:c6:5a:04:55:c9:bf:fb:b9:6a:ea:2a:2b:ab:0a:
        97:3b:86:78:5c:2e:28:39:19:c6:29:66:32:a8:60:d8:55:2b:
        71:4c:ff:e1:69:7c:40:a0:6c:86:49:fe:f8:0d:f4:8c:2c:03:
        e2:45:16:fd:0a:72:c1:90:4e:8c:ff:b0:e8:9b:1f:0f:51:f0:
        3e:40:a2:4a:10:70:48:6e:a7:08:8f:59:bc:61:96:1e:85:11:
        ea:db:63:64

The public key in decimal is

120670606144085109719219572194923534474923017051023017296322634692
625135745151055829730471725822826389243527648003600042874496534246
318211937373035306269108919094913609992115753070424083618544501290
818141600949585344863493055281433804504288287861848308627219396986
992979141910834747175772631763346288615015629

If you can factorise this number, then you have broken the certificate.

Apparently this certificate is accepted by recent versions of Internet Explorer and Chrome. With this information at hand, I do not see how these browsers accept the root certificate which is also a website certificate (an oddity). Currently, the only explanation at hand would be that those browsers either have a copy of this root certificate or they use another (unknown to me) cryptographic mechanism to verify the certificate.