Checking certificate fingerprints

  • SpinRite v6.1 is Released!
    Guest:
    That's right. SpinRite v6.1 is finished and released. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.
  • Announcing “BootAble” – GRC's New Boot-Testing Freeware
    Please see the BootAble page at GRC for the whole story.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


ldmia

Member
Oct 1, 2021
14
4
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.
 
Last edited:
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.
 
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 :)
 
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.
 
I'm finding that there are often different fingerprints for the login page and a payment page e.g.

Code:
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.
 
Last edited:
In case anyone is wondering how the fingerprint fetch is done, this is for Linux:

Bash:
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).
 
Last edited:
You might want to tell that to Steve. It's his webpage that was inspiration for using SHA1.
 
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.