GRC's web server can obtain and display the “fingerprint” of any HTTPS-capable public web server's secure connection certificate. Simply enter the domain name of the server you wish to fingerprint, then press Enter or click the “Fingerprint Site” button:

https://

Google and Apple are different: Some visitors are being confused by Google's and Apple's certificate fingerprints which change and may not match.  Please see the “What can go wrong with this test?” section at the bottom of this page for an explanation of the complexities.

The Internet is a cooperative PUBLIC DATA NETWORK. Its data traffic flows around the globe freely, transported by an incredible variety of intermediate carriers. These carriers cooperate because they need each other equally: “I'll carry your traffic if you'll carry mine.” And the system works. But with all of this traffic zipping around all over the place, in full public view, how do we KNOW that we are really connected to our bank, our medical records database, or any other public or private website? Websites are (obviously) easy to create, so copying a popular website and redirecting traffic there would not be difficult. And, unfortunately, the world has no shortage of people who would like to do that.

The original un-secured HTTP web connections never attempted to authenticate or encrypt their connections. Users who knew enough to wonder and worry could only hope that they were actually interacting with the website they intended. And that was fine back when the Internet was just a curiosity. But the Internet has grown into a resource where people conduct business, place orders, exchange stock, refer to their medical histories, perform their banking, and everything else—very much as they do in the physical world. For the “cyber versions” of these activities to be feasible, users expect, need, and must have security and privacy.

The “S” added to the end of the “HTTP” means SECURE.

(Or at least it was supposed to.)

The presence of the unbroken key or the lock icon on the web browser once meant that the connection between the user and the remote web server was authenticated, secured, encrypted . . . and not susceptible to any form of eavesdropping by any third party. Unfortunately, that is no longer always true.

To enhance their users' security and privacy, an ever increasing number of web sites are switching from traditional “HTTP” to the more secure “HTTPS” connections—like THIS web page. This type of secured connection is known as SSL or TLS (“Secure Sockets Layer” and “Transport Layer Security”) two names for the same thing. What's significant is that the data sent back and forth over any HTTPS/SSL/TLS connection is encrypted by technology no one knows how to break. Really, no one. It's truly secure.

In the early days of the Internet, the encryption provided by HTTPS connections was difficult and time consuming to establish, so these “expensive” connections were usually reserved for logging into a site (to protect the user's name and password) or when submitting very sensitive information, such as private credit card numbers and purchasing data. Since HTTPS connections were once used sparingly, anyone wishing to monitor, watch, record and log the actions of users on the Internet could do so easily, simply by eavesdropping on the data moving through the wires. But as technology has advanced, the cost of employing unbreakable encryption for all connections has become feasible. So today more and more websites are switching to always using encrypted HTTPS connections.

This has been great for Internet users, who expect and want their use of the Internet to remain personal and private. But employers, educational institutions, and others have become unhappy that their traditional network traffic monitoring and filtering is increasingly blinded by the growing use of HTTPS connection encryption. (The United States FBI refers to this as the “Going Dark Problem” since they, too, are able to see less and less of what's going on. For them, the Internet is “going dark” all around them.)

Private institutions—corporations, schools, and other organizations—have responded to this “loss of visibility” into every detail of their employees' and students' Internet usage by deploying new technology known as “HTTPS Proxy Appliances”. These devices circumvent our most basic assumption and guarantee of Internet browser privacy and security.

Internet providers, public and private, cannot control what they cannot see . . . so they insist upon seeing everything.

Study the following statement very carefully until you're sure you understand what it is saying. It is the key:

Web browsers trust the identity assertion made by a remote web site when that site presents a certification of its identity that has been signed by a higher authority that the browser already trusts.

Many years ago, the people at Netscape who developed the first popular web browser, invented a solution to both the need for Internet privacy (encryption) and security (authentication). Their concept was elegant and simple and has endured to this day: A third party who we trust has assured us that our encrypted traffic is going only to the website we intend. Here how that works:

There are entities known as "Certificate Authorities" (CA) to whom web sites prove their identity in the real physical world using incorporation documentation, Dun & Bradstreet records, their publicly known telephone numbers, and so forth. When a web site has proven its identity with sufficient certainty, the Certificate Authority (CA) will put its reputation on the line by digitally signing the site's security certificate which contains an assertion of its identity.

When an Internet browser establishes a secure connection with a remote site, that site must provide that signed certificate for the web browser's inspection. The web browser already contains a (long) list of all the trusted and reputable certificate authorities that exist in the world. So the browser is able to verify the authenticity of the certificate provided by the web site by verifying that it was properly digitally signed by one of the many certificate authorities it trusts to sign website identity certificates.

Any corporation, educational institution, or other Internet connectivity provider who wishes to monitor every Internet action of its employees, students or users—every private user ID & password of every social networking or banking site they visit, their medical records, all “secure” eMail . . . EVERYTHING—simply arranges to add one additional “Pseudo Certificate Authority” to their users' browsers or computers. It's that simple.

Here's a 2013 real-world example: Nokia caught secretly decrypting mobile browser traffic: ZDNet reports security researcher Gaurang Pandya's discovery that the “secure” HTTPS traffic from his web browser was being decrypted by Nokia's servers. (See the link.) Nokia's reason is valid: Encrypted data appears as pseudo-random noise and cannot be compressed. But they did this secretly and there's no way to disable it.  Opera's Mini browser does the same thing for the same reason, but makes it optional and explains it clearly. And while Nokia says they would never pry, the fact is that since they CAN, in the USA they could be compelled to do so.

For example, suppose that “Bendover Industries” installs a commercially available “SSL Proxy” (also known as an HTTPS or TLS Proxy). Then, as part of prepping computers for use inside their network, Bendover's IT department simply adds one additional “trusted” Certificate Authority to each computer. That's all it takes.

Now, whenever anyone inside Bendover's network makes a “secure” connection to any remote public web site—their bank, Google Mail, Facebook, anything—that connection is intercepted by Bendover's SSL Proxy appliance before it leaves the building. On-the-fly, the SSL Proxy Appliance creates a fraudulent “spoofed” web server certificate in order to impersonate the intended remote web site, and it signs that fraudulent certificate itself using the signature of the also-fraudulent Certificate Authority that was previously planted inside the user's browser or computer.

Because the impersonation is perfect, neither the browser nor the user can readily detect that they do not have a securely encrypted direct connection to the remote web site. Their browser shows every facet of a standard secured SSL connection—all the locks and pretty colors and everything we have been trained to look for and check for are present . . .

And it's all a lie.

Instead of connecting to the remote web server, the browser is “securely” connected only to the local Proxy Appliance which is decrypting, inspecting, and logging all of the material sent from the browser. It inspects all content to determine whether it abides by whatever arbitrary policies the local network is enforcing. It's users have NO privacy and NO security. Or perhaps it just silently logs & records everything for possible future need. Either way, it has obtained full access to everything the user enters into their web browser.

Never to be left (far) behind, this dialog box presented by Microsoft's “Forefront Threat Management Gateway” shows the options offered for “HTTPS Inspection.” Note the warning near the bottom. They know this is slimy behavior:

Once the SSL Proxy Appliance has decrypted, inspected and judged the user's content, it establishes a second secure connection to the remote web server—this time impersonating the user. Assuming that the user's request and data meet with the network's policies, or perhaps after having all been logged, the data is re-encrypted through the second connection to the remote web site . . . just as if nothing had happened.

No.  But it CAN be reliably detected because it is NOT POSSIBLE to COMPLETELY spoof ANY security certificate!

Anyone examining an SSL certificate (like this page or your web browser) can create a “cryptographic hash” or “digest” of the certificate's contents. Cryptographic hashes are complex mathematical algorithms which carefully process every single bit of what they “digest.” They have the amazingly property that if even one bit inside the certificate is changed, an average of half of the fingerprint's hash bits will change in response! In other words, when such a cryptographic hash is used to “fingerprint” a certificate any change, no matter how small, will result in a COMPLETELY different fingerprint.

Fingerprints offer incredibly sensitive and strong detection of anything changed anywhere in a security certificate. Certificate fingerprints were originally based upon the “MD5” (Message Digest 5) hashing algorithm. But over time researchers found MD5 to be a bit weak in some special cases which might have been exploitable. So the entire industry (and this web site) has switched over to using the newer, stronger and even more secure “SHA1” (Secure Hashing Algorithm 1) hashing algorithm.

All SSL-intercepting Proxy Appliances MUST provide a fraudulent spoofed certificate containing a public key for which it has the matching private key, and that private key cannot be the same as the actual remote server's because private keys are a closely held secret and no one knows any server's private key.

This means that no matter how much any SSL Proxy Appliance might want to duplicate a remote server's certificate . . . it cannot.  It is impossible.  And the certificate's fingerprint, which can be easily viewed through any web browser's user-interface, completely gives away the lie:

The remote server's REAL certificate and the SSL Appliance's FAKED certificate MUST HAVE AND WILL HAVE radically different fingerprints.  They will not be remotely similar.

YOUR web browser's Internet connection MAY be intercepted by your employer, school, church, ISP or whatever organization is providing the Internet connection. But GRC's connection is NOT being intercepted by anyone. We use the “Tier 1” provider “Level 3” to connect directly to the Internet Backbone with no third-party between us and any remote website. So, with this page, WE can obtain any website's authentic HTTPS fingerprint to show you what it SHOULD BE.

THIS PAGE will only allow itself to be delivered from GRC over a secure and encrypted SSL connection. So your web browser will show SOME SSL certificate fingerprint . . . but will it be GRC's authentic fingerprint, shown here?:

73:15:EE:7D:F9:72:37:C4:2C:B8:3C:BD:4E:FD:43:FF:36:9D:C2:42

The fingerprint of GRC's authentic security certificate

 . . . or will it be the necessarily different fingerprint of a fraudulent SSL interception certificate that was created for the deliberate purpose of attempting to fool you and your web browser?

If you are currently—right now—viewing this page from within ANY network that is intercepting and spoofing SSL connections (the dialog box above clearly shows that Microsoft offers this “feature”), and if THIS specific connection was intercepted, the fingerprint of GRC's authentic SSL security certificate shown above will NOT match the fingerprint shown by your web browser. And the same is true for any websites your local network may be secretly intercepting.

The SHA1 fingerprint hash displayed by web browsers usually (but not always) use UPPERCASE “hexadecimal” formatting, and usually (but not always) separate each pair of characters with a colon. That's why this web page chose that most common display format. If your browser uses lowercase and/or uses spaces instead of colons, those are just display choices and do not affect the fingerprint contents. So the following two fingerprints are IDENTICAL: (So it is always safe to ignore the alphabetic case and colons.)

Each web browser is a bit different, but here's where to (currently) find the certificate fingerprints in the more popular web browsers. (And you can probably figure this out for any others.)

• Right-click somewhere on the page.
• Select “Properties” at the bottom of the pop-up menu.
• Click the “Certificates” button on the Properties page.
• Verify that the “Issued to” name exactly matches what this GRC page shows.
• Click the “Details” tab to change views.
• Set the “Show” selector to “<All>” if it isn't already.
• Scroll down to the end of the list to “Thumbprint” (which is what Windows calls it).
• Click on the “Thumbprint” item to select it and show the full thumbprint in the window.

• Click on the padlock at the far left end of the URL address bar.
• Select the “Connection” tab.
• Click on “Certificate Information”.
• Verify that the “Issued to” name exactly matches what this GRC page shows.
• Click the “Details” tab to change views.
• Set the “Show” selector to “<All>” if it isn't already.
• Scroll down to the end of the list to “Thumbprint” (which is what Windows calls it).
• Click on the “Thumbprint” item to select it and show the full thumbprint in the window.

• Click on the padlock at the far left end of the URL address bar.
• Click the More “Information...” button.
• Click the “Security” icon/tab at the top of the “Page Info” dialog.
• Click “View Certificate”.
• Verify that the certificate's name under “Common Name (CN)” exactly matches what this GRC page shows.
• The SHA1 fingerprint is shown under “Fingerprints”.

• Click the [https padlock] icon at the far left end of the URL address bar.
• Click “Show Certificate”.
• Click the arrow to expand the “Details”
• Verify that the certificate's “Common Name” exactly matches the name shown on the GRC page.
• Scroll to the bottom to view the certificate's SHA1 Fingerprint.

The ONLY WAY the SHA1 fingerprints can match, is if the certificate GRC just now
obtained DIRECTLY from the remote web server is IDENTICAL to the certificate
YOUR web browser also just obtained DIRECTLY from the remote web server.

But IF this SSL page was intercepted, its certificate fingerprint will HAVE TO BE DIFFERENT since authentic SSL certificates are impossible to perfectly duplicate.

While researching ways to help our visitors verify their connection fingerprints, we hit upon one type of certificate which, when properly handled, as they have been in the Firefox and Chrome (and Chromium), but not Internet Explorer . . . CANNOT BE SPOOFED at all!!

This www.GRC.com web site always uses Extended Validation (EV) certificates. So if you are viewing this EV site through a properly-designed web browser, such as Firefox or Chrome (but not Internet Explorer, since Microsoft deliberately allows EV indications to be forged) and you DO see the special EV treatment in the address bar, then you KNOW your connection to US is NOT being intercepted (and also that this page's contents have not been altered!) But if the special EV indication is NOT being displayed . . . then you instantly know that something IS intercepting and spoofing this web site's certificate!

Or to put it another way: If you are using Firefox or Chrome somewhere that never shows any EV certificates, then you ARE using a connection that is being intercepted, and your web browser is being presented with deliberately fraudulent certificates . . . since EV certificates cannot be spoofed!

Note that because extended validation certificates are completely spoof-proof (under Firefox and Chrome) we show the true EV status for every fingerprinted site. This allows you to determine whether any site you select should be showing as EV in your Firefox or Chrome browser.

Please see our The Special Power of Extended Validation Web Site Certificates page for an in-depth discussion of the value and spoofing-resistance of extended validation certificates.

There ARE several things to consider:

Smaller web sites, like this one (GRC) and those others listed above, deploy only one security certificate on one or more web servers (For example, our wonderful certificate provider, DigiCert, specifically allows us to use the same single certificate on as many servers as necessary.)

But companies with a massive and widely distributed web presence, such as Amazon or Google, may deploy many different security certificates across their many globally distributed servers and web sites. Multiple certificates may be easier for them to obtain and manage, and their security is not reduced. But it does mean that not every user of their servers (like you and this GRC page) would necessarily obtain the same security certificate.

This means that a simple comparison of certificate fingerprints could erroneously lead people wishing to test these huge websites to conclude that their connections were being intercepted, when they have simply received a different valid certificate than the one received and shown by this web page.

The best solution is to test smaller sites that are known to be using single certificates, or sites using the completely unspoofable extended validation (EV) certificates with an EV-honoring web browser such as Firefox or Chrome (but not Internet Explorer, which doesn't properly verify EV certificates).

At least two anti-malware products — BitDefender and Kaspersky A/V — operate as local HTTPS intercepting proxies. They obviously do this in order to scan the machine's secured and encrypted inbound web content for anything malicious. But this is quite disturbing because, even though it's for a good purpose, there are other ways to access the content after it has been decrypted and before it reaches the web browser. So this incredibly intrusive and security-breaking approach is not necessary. And this also has very negative side effects, such as breaking the display of all EV (extended validation) web sites. This is really bad. Since you are ALWAYS being intercepted, you can NEVER verify whether it's only once . . . or more. (Note that I can and do vouch for the value of Kaspersky as a terrific security threat research group. But this approach is wrong.) If it is possible to temporarily disable this aspect of their “protection”, then you could perform remote interception testing while the local interception is disabled.

BitDefender Interception Configuration: Under “Settings” / “Privacy Control” you will find an on/off slider “Scan SSL” which can be used to temporarily or permanently enable or disable this single aspect of BitDefender's operation.

Note that since extended validation (EV) certificates cannot be spoofed, any use of these machine-resident connection intercepting systems will disable all extended validation certificate display.

The only criteria for web servers is that they work, not that they necessarily make much sense to users. For example, these are the two DIFFERENT certificates we receive for the wordpress.com domain with, and without, the “www” prefix:

Domain Name Certificate Name Security Certificate's Authentic Fingerprint wordpress.com wordpress.com 52:0E:61:A7:BD:5C:34:6E:64:BC:5C:DC:02:DF:AD:FF:C2:48:21:47

Domain Name Certificate Name Security Certificate's Authentic Fingerprint www.wordpress.com *.wordpress.com 52:0E:61:A7:BD:5C:34:6E:64:BC:5C:DC:02:DF:AD:FF:C2:48:21:47

As you can see, depending upon how we ask for the certificate, with or without the “www” prefix, we receive two entirely different certificates. They have different certificate “Common Names” (Certificate Names) and, of course, radically different fingerprints.

The lesson here is that you MUST be vigilant about comparing the “Certificate Name”, also known as the “Common Name” on the certificate with what this GRC page shows here to be sure you are examining and comparing the SAME certificate. The result of not being careful, would be a “falsely positive” belief that SSL interception was occurring when it is not. And we don't want that.

SSL-intercepting Proxy Appliances are highly configurable. In fact, in many cases the so-called “C-level” executives within a corporation—the CEO, CFO, CIO, CTO, COO, etc.—do not have their own SSL connections intercepted at all! It's only the lowly and less trusted peons who need to be spied upon.

So, theoretically, specific web sites like this one could be excluded from SSL-interception, decryption and logging. Therefore, if THIS SSL Fingerprinting facility at GRC were to become popular, SSL-interception Proxies could make an exception and deliberately not intercept your browser's connections to GRC. Then the GRC fingerprints would match, and visitors would be lead to falsely believe that NO OTHER connections were being intercepted.

IF WE EVER LEARN THAT THIS IS BEING DONE WE WILL IMMEDIATELY UPDATE THIS PAGE.

But that's why this page obtains the fingerprints for many of the top web sites on the Internet . . . they would all need to be bypassed for your web browser to obtain the same fingerprint for them as GRC . . . which seems unlikely to be done. And that's also why we added the “Custom Site Fingerprinting” feature: Only you know which domains you want to verify are NOT being intercepted.

Once SSL Interception is occurring, the page CONTENT being delivered over SSL can no longer be absolutely trusted. Since the pages are already being decrypted and scanned for content, nothing prevents them from also being altered. What that means is, though it is incredibly unlikely, an SSL-intercepting Proxy Appliance could theoretically alter THIS page on the fly, before your web browser receives it. Such an alteration could replace the authentic fingerprints the GRC server has received and forwarded to your web browser with fraudulent fingerprints for the sites being tested. (But there's a solution to that as well.)

IF WE EVER LEARN THAT THIS IS BEING DONE WE WILL IMMEDIATELY UPDATE THIS PAGE.

And remember that since GRC is 100% secured using Extended Validation (EV) certificates, if you are viewing this site through a browser such as Firefox or Chrome, which properly validates EV certificates, and if you are seeing the special green EV display in your browser's address bar for this page, then the connection can not possibly have been intercepted and altered. (See this page for a full discussion of the special anti-spoofing power of extended validation certificates.)

All you need to do is go home (or anywhere that's unlikely to have SSL interception in place) then bring up and print just the first page of this GRC Fingerprints page. Now you'll have a handy hardcopy showing the authentic fingerprints of those top popularity web sites shown at the top when this page is first presented. Bring the printout back to where you're wondering about SSL interception and filtering. Bring up a few of those sites and compare their fingerprints to the handy printout. If they match, you know absolutely that they are NOT being filtered. And if they don't match . . . something fishy may well be going on.

• Send us any feedback, questions, thoughts, ideas, etc., about this HTTPS connection fingerprinting page.
• Michael Horowitz's “Defensive Computing” blog at ComputerWorld has a terrific and even more extensive explanation of this issue. If you're interested in reading more about this, check it out!
• Direct Domain Access: Webmasters who wish to place links on their own sites to allow their visitors to be assured of their connection's privacy, may simply append the string “?domain=domain.name” to the end of this page's URL. So, for example, to directly display the certificate fingerprint for “www.pbs.org”, the URL would be:
  
  https://www.grc.com/fingerprints.htm?domain=www.pbs.org
  (click it and see)
• A WIRED Magazine article discussing a device made by “Packet Forensics” for perpetrating exactly this sort of secretive connection interception.
• A comprehensive White Paper (1.27 mb PDF) which accompanied Jeff Jarmoc's presentation at the Black Hat Europe, March 14, 2012, conference. Jeff's presentation and paper were titled: SSL/TLS Interception Proxies and Transitive Trust.
• A Spanish language explanation of these ideas: Miguel Mollejo, a valued contributor to GRC's public newsgroups, has thoughtfully produced a Spanish language explanation of these ideas.