Is your employer, school, or Internet provider
eavesdropping on your secure connections?
|523 sets of fingerprints checked per day|
778,788 sets of fingerprints checked for our visitors
Secure browser connections can be intercepted and decrypted
by authorities who spoof the authentic site's certificate. But
the authentic site's fingerprint CANNOT be duplicated!
|Domain Name||Certificate Name||EV||Security Certificate's Authentic Fingerprint|
|Each site's authentic security certificate fingerprint (shown above) was just now obtained by GRC's servers from each target web|
server. If your web browser sees a different fingerprint for the same certificate (carefully verify the Certificate Name is identical) that
forms strong evidence that something is intercepting your web browser's secure connections and is creating fraudulent site certificates.
In addition to the well-known web sites listed above, 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:
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.
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.
|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.
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.
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.
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?:
|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.
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.)
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:
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).
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.
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.
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.
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.
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.)
Gibson Research Corporation is owned and operated by Steve Gibson. The contents
of this page are Copyright (c) 2014 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson