Thank you Peter for the status update. Glad to see that it's been sorted out, whatever it was.
The latest info I had (earlier today) from Verizon was that
I have contacted McAfee for this, hopefully they will lower this rating soon.
IP address no longer Red but not yet Green according to SiteAdvisor, so Google searches show it as unrated.
Okay, now all the fuss has died down I'm wondering about a couple of things.
First, as a couple of posters to the thread were saying, did the recent updates to Chrome and Firefox have anything to do with this? (I'm not sure if the Microsoft Patch Tuesday updates also included any updates to Internet Explorer, but I can't see anything about IE in Microsoft's March Security Bulletin). The guy at Verizon was also of the opinion that a browser update might have been the (partial) cause of the Netguard block.
However, I'm not so sure. Netguard blocked access to the IP because TrustedSource had increased its risk rating to High Risk. Why it did that is another question. Someone certainly was submitting Abuse reports for that IP address on the day it went Red, but whether before or after Netguard started blocking it I can't say. I only mention that because I see it as a potential weakness in the system, that one malicious person could possibly trigger a rating change on an IP address (which could have many sites and users on it) by knowing where to submit false reports of, for instance, a server sending spam or attempting to hack into their PC.
I'm also wondering why, since I have Netguard installed as part of my McAfee package, I didn't see this Netguard block? It was only when I attempted to access the server and SiteAdvisor intervened with a Red blocking page that I was quite certain that there really was a problem, and a problem with the server not with Netguard. I've checked all my Netguard settings and they're enabled and activated, so if Windows or my browser had attempted to connect to the server for a CRL check I should have seen the Netguard message. But I didn't.
I can only conclude that the check for revoked certificates was being carried out for sites that I don't go to, or that one browser or another doesn't bother with these checks .... and that may be the case. I recall seeing an article recently about this, which (of course) I didn't bookmark and now can't find.
The whole area of Certificates, their use and misuse, is an interesting one if you want to delve into aspects of computer security. Have a look sometime at all the certificates in your browser store, and try to work out where and how you ended up with half of them.
Does Firefox check for revoked certificates as part of its normal operation? I thought it was given a list of revoked certificates via patches.
IE certainly does check for publisher and server revocation of certificates as part of its normal operation. Although I never use IE, Windows Live Messenger takes all its rules for security from IE settings, so maybe simply running this program will cause checks for revoked certificates for all the connections it makes, most notably for the adverts it attempts to display.
I've been looking into the way browsers implement SSL certificate revocation checking and it's not quite as straightforward as I thought.
First, there are two ways to check for revocation. One is the CRL method :
In the CRL method, the browser downloads a file from the specified URL that contains every certificate which is not yet expired but has been revoked by the CA. This file may be several hundred kilobytes in size and is typically cached on the client computer for several days or more. The CRL file is itself signed by the CA to prevent tampering.
The other is OCSP - Online Certificate Status Protocol.
In the OCSP method, the browser contacts a web service running at the specified URL and asks the service whether a specific certificate has been revoked; again, the response is signed to prevent tampering. The response to the “Is certificate <XXX> revoked” query is typically much smaller than downloading an entire CRL file. If each OCSP request doesn't complete in less than 15 seconds, it times out and fails.
The note about requests timing out is significant -
..it can introduce a significant penalty for certificate authorities who are now required to provide responses to every client of a given certificate in real time. When the certificate is issued to a legitimate high traffic web site, for instance, this can result in enormous volumes of OCSP traffic, all of which serves to indicate that the certificate is valid and can be trusted.
OCSP checking also creates a privacy concern for some users, since it requires the client to contact a third party (albeit a party trusted by the client software) to confirm certificate validity.
At the moment there are heated discussions going on about the default behaviour of browsers in the event of a timeout - a "soft fail". Most of them ignore the recommended action, which is to treat the site as untrusted; they silently allow the connection, The user never knows that the site to which (s)he is "securely" connected has not provided a valid SSL certificate for the connection. In Internet Explorer, for instance,
... if a given certificate specifies a CRL or OCSP URL, but the revocation check cannot be completed (say, because the Certificate Authority’s server is not reachable), Internet Explorer will not notify the user.
There is a variant of OCSP called "OCSP stapling" which aims to overcome some of the above-noted drawbacks :
.. the certificate owner queries the OCSP server themselves at regular intervals, obtaining a signed time-stamped response. When the site's visitors attempt to connect to the site, this response is included ("stapled") with the SSL/TLS Handshake.
OCSP stapling is not yet widely implemented, although Mozilla is funding a project to add support to OpenSSL.
Now to the browsers, and the way they handle checking.
First, Chrome. Google recently - and controversially - announced that it would abandon both methods in future releases of Chrome, and instead would implement its own method of certificate checking. This seems to be part of Google's drive for greater efficiency and reduced page-load times.
"The median time for a successful OCSP check is ~300ms and the mean is nearly a second," Langley said. "This delays page loading and discourages sites from using HTTPS."
After considering the drawbacks, Google decided to remove OCSP checks from future versions of Chrome and replace them with a local list of revoked certificates that can be updated without requiring a browser restart.
(So this might explain why I did not see a warning from Netguard : Chrome wasn't performing any revocation checks. On the other hand, in "Under the Bonnet" ("Under the Hood", perhaps, in the US) there is still an option to check for revoked certificates.)
Next, Firefox. Mozilla shows in detail what protocols are being used and gives the user the option of changing the default settings. It offers the clearest overview of certificates of these three browsers. You can view the Certificate Revocation Lists and examine the list of stored certificates on your system without having to call up the obscure "certmgr.msc" using the Start/Run command. According to Firefox I don't actually have any CRL data; whether this means "none as far as Firefox is concerned" (because it's using OCSP) or not, I'm not sure. Note that there is an option in the 'Certificate Validation' window to allow/disallow treatment of a certificate as invalid if a server connection fails.
The decision by Mozilla to include only OCSP checking is unsafe (see quote below).
Finally, Internet Explorer. The settings for publisher's certificate revocation, server certificate revocation and certificate address mismatch checking are hidden away in the Advanced section of Internet Options, where few people will probably bother to look. The defaults are handled differently in IE8 (and presumably earlier versions of IE, still apparently in use) and IE9 :
Notably, from my VB2010 presentation on digital signature abuse, neither Internet Explorer 8 nor Firefox have certificate revocation options set to safe defaults. Internet Explorer 8 has server certificate revocation checking off by default and Firefox only has Online Certificate Status Protocol (OCSP) revocation enabled. Microsoft has changed the default in Internet Explorer 9 to have server certificate revocation checking enabled by default.
It seems that whether a certificate can be checked for revocation using OCSP depends on how the CA has configured it : the implication would then be that not all revoked certificates can be verified with OCSP. According to Microsoft,
Many certificates are configured to offer information for both revocation mechanisms; Windows XP’s HTTPS stack does not offer support for OCSP, and thus Internet Explorer only supports OCSP on Windows Vista and later.
By default, Windows Vista and later enable revocation checks in both scenarios, while Internet Explorer on Windows XP only enables Authenticode Revocation checking by default because of the performance impact of downloading CRLs for HTTPS connections. If a CA indicates that a server’s HTTPS certificate was revoked, the user is blocked from navigating to a site; no override link is presented to allow the user to ignore the security warning. If a CA indicates that a downloaded binary’s signing certificate was revoked, the program will fail the Authenticode check and will not run.
Microsoft do provide a way of letting you see if a certificate revocation check has failed. This is via a mechanism so little-publicised that I only found out about it when I reached the end of an MSDN IEInternals blog. I reproduce it in its entirety below.
... we recognize that a certain subset of users would still prefer to see warnings when a certificate revocation check did not complete successfully. (One criticism of revocation checking is that most attacks against HTTPS sites require both control of a rogue certificate and control of the DNS, and if the attacker has control of DNS, he may be able to block the client’s network request used to check for revocation.)
To that end, users may set an option (known as a Feature Control Key) to re-enable the warning UI. When a revocation check fails to complete, the lock icon will be replaced with an orange shield icon, like so:
The feature control key is named FEATURE_WARN_ON_SEC_CERT_REV_FAILED, and it is respected by IE7 and later. End-users may enable or disable the warning by running one of the following registry scripts and restarting their browser instances:
- Enable Revocation Check Warning for IExplore.exe
- Undo enabling revocation check warning for IExplore.exe
I apologise for the length of this post; the subject is fascinating, in a nerdy sort of way. I may take all of this material and put it into a blog post, where this sort of length won't annoy people.
Finally, sources and links (for the quoted material above). Quite a lot of them, I'm afraid.