Checking certificate fingerprints

[ldmia]

Recently I decided to start checking HTTPS certificate fingerprints when I'm on public Wifi. I have a long list of domains for which I obtain the certificate fingerprints and then compare against my "gold standard" set of fingerprints, which I obtained when my network connection was solely through tethering with my phone, which uses the T-mobile network. Some of the domains on my list are subdomains for logging into sites, or making payments, which an attacker might find attractive.

I started on this certificate checking crusade because my web browsers had begun to complain when I was on public Wifi about suspicious certificates on pretty basic websites like Reddit and Craigslist. Initially I checked to see if the same certificate warnings appeared while I was tethering with my phone and they did not, and then I checked whether the certificate warnings appeared while I was on Wifi but using TOR, and they did not. Thus something was sketchy with that Wifi. Certainly a VPN would be advisable, but I decided to see what fingerprint comparisons show.

Now that I am checking certificate fingerprints, I currently see that most are the same between my T-mobile set and those obtained when I'm on the public Wifi. There are a few discrepancies but nothing too alarming-- at the moment. The most suspicious discrepancy is developer.android.com's certificate, from which a person might download software although at the moment the download link provided over Wifi points to what I assume is a randomly chosen server r1---sn-a5meknek.gvt1.com, which traceroute suggests is actually Google.

I assume the intention of having this kind of randomly chosen server is for network efficiency and not preventing MITM, because if a MITM attacker used a regular expression to intercept all gvt1.com subdomains, she could handle all of those subdomains and send an infected executable to the user, e.g. AndroidStudio.exe modified by Sketchy Telcom Inc.

 

[Ralph]

I've also found an occasional mismatch between GRC and a site's certificate. If you haven't already check GRC again. I've had certificates expire so they don't match my list, but upon rechecking the certificate had merely been renewed generating a new fingerprint. If that is not the case you have run into the same thing I have. That is GRC does not match the site, the BIG question (to which I don't have an answer) is how to determine if it is a true mismatch or does the site have multiple certificates.

 

[EdwinG]

Now that I am checking certificate fingerprints, I currently see that most are the same between my T-mobile set and those obtained when I'm on the public Wifi. There are a few discrepancies but nothing too alarming-- at the moment. The most suspicious discrepancy is developer.android.com's certificate, from which a person might download software although at the moment the download link provided over Wifi points to what I assume is a randomly chosen server r1---sn-a5meknek.gvt1.com, which traceroute suggests is actually Google.

I assume the intention of having this kind of randomly chosen server is for network efficiency and not preventing MITM, because if a MITM attacker used a regular expression to intercept all gvt1.com subdomains, she could handle all of those subdomains and send an infected executable to the user, e.g. AndroidStudio.exe modified by Sketchy Telcom Inc.

This little fact could be also as simple as a CDN host being chosen rather than another, because of network proximity, performance or load.

The fact the fingerprint is different also means that the associated private key is different, which can be good; it means they didn't move the private key on their network. This statement assumes that the destination host is the intended host

 

[Ralph]

A very good point. I forgot that on a site or 2 the home page and login page had different fingerprints. I haven't had to update my fingerprint list in a while, but you jogged my memory. I did add the additional fingerprints for the login page to my list, probably why I haven't had to update the list in a while. I do recall the one site that gave me concern over a mismatch was Coinbase.com -a cryptocurrency exchange I use. I started a thread because of that site, but never did get a way to determine if the mismatch from the certificate and GRC was due to multiple certificates or a 'hijacked' site. A few people here were nice enough to check the certificate as well. From different parts of the country they were getting the same mismatch I was. Eventually I just added the 'mismatch' to my fingerprint list and haven't had any mismatches since. Over time I just settled on the assumption all was OK, but I must say I was very uneasy moving money to that site for a while. Nothing bad has happened so I assume everything is OK, but there must be some way to verify a mismatch other that use the site then wait and see if anything goes wrong. I use 2 factor authentication for important sites as an extra precaution.

 

[ldmia]

I'm finding that there are often different fingerprints for the login page and a payment page e.g.

pay.usps.com AE:32:8F:F3:71:41:5B:31:B6:D8:56:9E:EB:49:57:98:1F:C9:EF:03
poboxes.usps.com 7F:13:43:BD:73:38:23:15:81:A8:54:11:C3:13:F4:95:12:81:96:1F
usps.com 6D:78:55:1B:65:2F:36:E4:9E:E0:AE:B4:B9:BA:2B:D8:C1:E6:9E:FB

I'm also seeing some curious timeouts that require that I redo the fingerprint fetch e.g.
these timed out among others:

www.annualcreditreport.com = akamaiedge
login.blockchain.com = cloudflare

The ones that time out seem to have sensitive content of one kind or another.

Too bad there isn't some sort of fingerprint blockchain that I could periodically download, where every new certificate is published and a consensus of servers verifies that each fingerprint in a new block is a real one and not a fake.

 

[ldmia]

In case anyone is wondering how the fingerprint fetch is done, this is for Linux:

function fingerprint {
        if [[ "$1" == "" ]]; then
                echo "Usage: fingerprint domain [port]"
                return
        fi
        port=$2
        if [[ "$2" == "" ]]; then
                port=443
        fi
        CERT=/tmp/.cert
        rm -f $CERT
        let tries=0
        while [ ! -s $CERT ]; do
                openssl s_client -connect $1:$port < /dev/null 2>/dev/null > $CERT
                if [ ! -s $CERT ]; then
                        echo DID NOT GET CERT, TRYING AGAIN
                        let tries=1+$tries
                        if [[ $tries == 10 ]]; then
                                echo TRIED 10 TIMES
                                return
                        fi
                fi
        done
        cat $CERT | openssl x509 -fingerprint -noout -in /dev/stdin | sed "s/SHA1 Fingerprint=//"
}

I'm kind of curious as to why openssl x509 can't process the cert for mail.comcast.net port 995 (pop3s).

 

[PHolder]

You really should not be basing any decisions on the SHA1 fingerprint. It is deprecated for removal in the future.

A further update on SHA-1 certificates in Chrome

 

[ldmia]

You might want to tell that to Steve. It's his webpage that was inspiration for using SHA1.

 

[PHolder]

tell that to Steve

Most of the content on Steve's site is dated. Other than SQRL content, and the Security Now updates, there hasn't been anything new posted on his site in probably a decade. The status of SHA1 has changed in the mean time.

 

[Ralph]

I took at the Chromium page link above. "Since this policy is intended only to allow additional time to complete the migration away from SHA-1, it will eventually be removed in the first Chrome release after January 1st 2019". A quick search pulled up a number of stories but all a few years old. I guess I'll try asking Steve since it doesn't seem as if anyone has an answer. I use fingerprinting on some sites and in ALMOST every case I get a match, it's the almost that I am concerned about.