Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
19028 Views 49 Replies Latest reply: Mar 22, 2012 12:02 AM by Hayton RSS Go to original post 1 2 3 4 5 Previous Next
  • Apprentice 144 posts since
    Mar 30, 2010
    Currently Being Moderated
    40. Mar 19, 2012 12:39 PM (in response to revealdion)
    Re: netguard blocks risky connectio´n

    The high risk warning for 194.7.155.82 got removed.

    Best regards,

    Peter

  • Hayton Volunteer Moderator 4,599 posts since
    Sep 27, 2010
    Currently Being Moderated
    41. Mar 19, 2012 1:55 PM (in response to x-pmeyer)
    Re: netguard blocks risky connectio´n

    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.

     

    Edit -

      IP address no longer Red but not yet Green according to SiteAdvisor, so Google searches show it as unrated.

     

    194.7.155.82 - McAfee SiteAdvisor Software – Website Safety Ratings and Secure Search.png

     

    Message was edited by: Hayton on 19/03/12 18:55:32 GMT

    Volunteer Moderator  Leeds, UK
    No PM's please
  • Hayton Volunteer Moderator 4,599 posts since
    Sep 27, 2010
    Currently Being Moderated
    43. Mar 19, 2012 2:50 PM (in response to revealdion)
    Re: netguard blocks risky connectio´n

    The connection no longer needs to be blocked, I guess. As I've never had to deal with this situation I can't say what action you need to take. Peacekeeper knows more about Netguard than I do, I'll wait for him to come online.


    Volunteer Moderator  Leeds, UK
    No PM's please
  • Peacekeeper Volunteer Moderator 21,365 posts since
    Nov 23, 2002
    Currently Being Moderated
    44. Mar 19, 2012 2:52 PM (in response to Hayton)
    Re: netguard blocks risky connectio´n

    I do?  I just removed the block I feel it will not do that automatically.


    Tony
    Volunteer Moderator
    Mcafee Total Protection 7.0 beta, Windows 8 64bit
    No Unrequested PMs please
    Do you have an idea for improving McAfee products? Please share it in the new Ideas community space!  NOTE: You must register an account first.

  • Peacekeeper Volunteer Moderator 21,365 posts since
    Nov 23, 2002
    Currently Being Moderated
    46. Mar 20, 2012 5:23 AM (in response to revealdion)
    Re: netguard blocks risky connectio´n

    Good I learnt sometime today as well. netguard auto removes blocks


    Tony
    Volunteer Moderator
    Mcafee Total Protection 7.0 beta, Windows 8 64bit
    No Unrequested PMs please
    Do you have an idea for improving McAfee products? Please share it in the new Ideas community space!  NOTE: You must register an account first.

  • Hayton Volunteer Moderator 4,599 posts since
    Sep 27, 2010
    Currently Being Moderated
    47. Mar 21, 2012 11:16 AM (in response to Peacekeeper)
    Re: netguard blocks risky connectio´n

    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.


    Volunteer Moderator  Leeds, UK
    No PM's please
  • Jaheira Apprentice 152 posts since
    Mar 19, 2010
    Currently Being Moderated
    48. Mar 21, 2012 4:53 PM (in response to Hayton)
    Re: netguard blocks risky connectio´n

    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.

     

    on 21/03/12 16:53:42 CDT
  • Hayton Volunteer Moderator 4,599 posts since
    Sep 27, 2010
    Currently Being Moderated
    49. Mar 22, 2012 12:14 AM (in response to Jaheira)
    Re: netguard blocks risky connectio´n

    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.)

    Options - Under the Bonnet.png

     

    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).

    Firefox Certificate handling.JPG

     

    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:

    image

    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:

     

     

    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.

    http://en.wikipedia.org/wiki/Certificate_Revocation_List

    http://en.wikipedia.org/wiki/OCSP_stapling

     

    http://nakedsecurity.sophos.com/2011/03/24/fraudulent-certificates-issued-by-com odo-is-it-time-to-rethink-who-we-trust/

     

    http://www.pcworld.com/article/249525/google_chrome_will_no_longer_check_for_rev oked_ssl_certificates_online.html

     

    http://www.pcworld.com/businesscenter/article/250218/the_decision_to_strip_onlin e_certificate_revocation_checks_from_chrome_is_misguided_symantec_says.html

     

    http://www.darkreading.com/authentication/167901072/security/news/232601983/solv ing-the-ssl-certificate-revocation-checking-shortfall.html

     

    http://www.symantec.com/connect/blogs/stripping-ocsp-chrome-will-not-improve-bro wser-security

     

    http://blogs.msdn.com/b/ieinternals/archive/2011/04/07/enabling-certificate-revo cation-check-failure-warnings-in-internet-explorer.aspx

     

    http://technet.microsoft.com/en-us/library/ee619754(WS.10).aspx

     

    Message was edited by: Hayton (to fix typos) on 22/03/12 05:14:56 GMT

    Volunteer Moderator  Leeds, UK
    No PM's please
1 2 3 4 5 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points