How Kaspersky makes you vulnerable to the FREAK attack and other ways Antivirus software lowers your

Discussion in 'other anti-virus software' started by Gein, Apr 26, 2015.

  1. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
  2. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    I don't see how that will impact (cert-based) AV SSL MITMing on the client. It appears that all three Cloudflare options:
    1. Flexible SSL - front-end over TLS, back-end unencrypted
    2. Full SSL - front-end over TLS, back-end over TLS
    3. Full SSL (Strict) - front-end over TLS, back-end over TLS (validated)
    utilize the same front-end over TLS mechanism that relies upon the normal browser certificate checks (which AV, gateway devices, debugging proxies, etc work around via root CA cert installation). The only difference in the Cloudflare options appears to be in how Cloudflare<->OriginServer communication is handled.
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I assume AV and other self-signed trusted root certs. will fail this test:

    In strict mode, CloudFlare validates the certificate chain on the back-end using its own list of trusted certificate authorities.
     
  4. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    That's just CloudFlare checking cert/chain when its server is communicating with the OriginServer, right? Which could, for example, help CloudFlare to protect the server<->server communication from a MITM including one being done by AV software that is installed on the CloudFlare server itself. Is that what you mean?
     
  5. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I am interpreting Full SSL to mean that the source connection cert pining chain is being validated using a trusted root store located on their servers. They are retrieving web site cert chain against what the source connection presented using their own root store.

    Full SSL (Strict) makes sure that CloudFlare validates the certificate chain presented by the web server.

    CloudFlare’s list is more exclusive than the ones used by the popular browsers. By trusting a smaller and more exclusive list of certificate authorities, we protect our customers against MitM attacks using certificates signed by rogue or compromised certificate authorities.

    Strict SSL.png
     
    Last edited: May 3, 2015
  6. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    I am unable to interpret and apply that in a way that would prevent a MITM of the WebBrowser<->CloudflareServer connection. We aren't talking about scenarios where the WebBrowser is required to present its own cert to the CloudflareServer, so we don't even have that to help out. Perhaps someone else can/will step in and help resolve the disagreement. In the mean time...

    Notice where the "monitoring failed here" is located on that diagram. It is between CloudFlare and the OriginServer.

    In addition to that location, a MITM could also be located somewhere between the user's device and CloudFlare. Plus, one could also be present within the user's device. We don't see those positions. Not even the ISP<->CloudFlare link on their diagram (which does have a lock to reflect TLS) changes.

    Note, also, the description... "front-end over TLS, back-end over TLS (validated)". Two TLS connections, only the back end one has the (validated) qualifier. I believe that is the correct way to factor in the comma. Which translates to:
    1. Front-end over TLS. Validated by user's WebBrowser using WebBrowser cert data.
    2. Back-end over TLS. Validated by CloudFlare software using CloudFlare cert data (which is more restrictive than what some web browsers use).
     
    Last edited: May 3, 2015
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    This article pretty much covers everything why SSL scanning should not be performed: https://www.cert.org/blogs/certcc/post.cfm?EntryID=221

    Note that 58 products are listed here that can perform SSL scanning and have issues. Surprisingly they didn't include Avast. Can it be assumed Avast has got it right?
     
  8. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    If my memory serves me correctly, Avast was one of the earlier AV's to add SSL scanning. Their Web Shield module has been around for a number of years now as well. So I assume you are correct, Avast has probably got it right and takes that portion of their program seriously.
     
  9. RejZoR

    RejZoR Lurker

    Joined:
    May 31, 2004
    Posts:
    6,426
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Close but not 100%. You can read Vik's responses to detail questions here: https://www.wilderssecurity.com/thre...s-ssl-hijackers-with-root-certs.373772/page-3https://www.wilderssecurity.com/thre...s-ssl-hijackers-with-root-certs.373772/page-3
     
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Here's a thought. From what I can determine, all these retail AV's that scan SSL traffic appear to be violating U.S. privacy laws. Guess it's time to blow the whistle on them to the Feds:

    It (SSL protocol scanner) must be able to whitelist or filter certain data that must be kept encrypted, such as patient information protected by HIPAA.
    Ref: http://www.sans.org/reading-room/whitepapers/analyst/finding-hidden-threats-decrypting-ssl-34840

    For non-U.S. residents, this refers to the health information confidentiality law commonly referred to as HIPAA. And the financial penalties are substantial.

    I also suspect that similar privacy laws exist in other countries?

    Now Eset has SSL protocol scanning turned off by default. So it can be argued that a user enabling it violated his own privacy. Whether that would stand up in a U.S. federal court remains to be determined. There are a lot of "hungry" lawyers in the U.S. though ........................................... And court and legal fees in the U.S. in cases like this start at 6 figures and rapidly increase.
     
    Last edited: May 6, 2015
  12. xxJackxx

    xxJackxx Registered Member

    Joined:
    Oct 23, 2008
    Posts:
    8,627
    Location:
    USA
    Maybe the Feds asked them to do it so they could get in through it...
     
  13. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    It is also illegal in the U.S. to decrypt PCI i.e. credit card payment data.

    And from what I can determine, it is illegal in many European countries to decrypt any type of SSL encrypted data.
     
  14. hawki

    hawki Registered Member

    Joined:
    Dec 17, 2008
    Posts:
    6,065
    Location:
    DC Metro Area
    Is this thread on the Kaspersky forum relevant to this issue -- and does it indicate a fix is coming?

    OP complains that when going to a banking site an error is reported that "Certificate verification service is not available". The next post says it's a known bug with Safe Money and a fix is coming in mid may.

    http://forum.kaspersky.com/index.php?showtopic=322435
     
  15. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Appears to be more of a bug in Kapersky itself: http://forum.kaspersky.com/lofiversion/index.php/t320945.html . Just search the web and you will notice many postings about issues with the Safe Money feature.
     
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I also question if these AV's are performing SSL certificate pinning checking correctly.

    Can't comment on Avast or Kapersky, but I do have Eset Smart Security 8 installed and have tested the SSL protocol scanning feature extensively.

    For starters, when you verify a SSL web page's site pinning, you will observe that the web site cert. is directly pinned to the Eset self-signed root cert.. No intermediate CA cert. is shown. Well, that's interesting and in itself not all that bad; assuming that Eset had previously verified the entire cert. pinned path?

    Next I observed that when a site is excluded from scanning in Eset, only the web site and intermediate CA cert. is stored. I found that a bit odd for a couple of reasons. First, there was no reason to store the intermediate CA cert. if all SSL checking for that web site was to be bypassed; the web site cert. would be sufficient. This implies that Eset is still performing the cert. pinning validation for the site; just not unencrypting the data. Ok, that is good. However, why store the intermediate CA cert. and not the root CA cert. for that web site or better yet, both the intermediate and root CA cert.? The associated root CA cert. is the most important one for determining any man-in-the-middle activity.

    Bottom line - I am suspicious that the cert. pinning being performed is only for the intermediate CA and not the root CA?
     
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Thought I would add this element to the discussion that the vendors in question might not have considered. What about the performance impact on your PC on decrypting all that SSL traffic; more so in light of the move to 2048 bit cyphers?

    https://www.nsslabs.com/news/press-...-causes-significant-performance-problems-next

    -EDIT- Hum ....... Maybe this isn't that big of a deal after all. Appears anything served up by Google isn't being scanned at all; at least as far as Kapersky goes and I assume the other vendors also:eek:_O

    For quicker loading of web pages and data exchange via encrypted connections some web servers (for example Google) use the SPDY protocol instead of HTTP. If an encrypted connection is established using the SPDY protocol, then the data received from the web server are not scanned with the heuristic analysis. In this case possibly infected programs can be downloaded to the user’s computer.

    And ........ Google will be phasing out SPDY starting early next year in favor of ALPN aka the SSL version of HTTP/2.

    So .......... things that should be scanned, aren't being scanned and things that shouldn't be scanned, are being scanned. Great solution these AV vendors have come up with.:isay:
     
    Last edited: May 15, 2015
  18. xxJackxx

    xxJackxx Registered Member

    Joined:
    Oct 23, 2008
    Posts:
    8,627
    Location:
    USA
    Despite these issues I have reinstalled Kaspersky based on the lesser of evils vs. some other products. I expect the real world likelihood of this is low, and it doesn't delete my files with false positives like some other products do. I expect now that this has been exposed it will be addressed rather quickly (by quickly I mean weeks or months, not days).
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.