Killed by Proxy: Analyzing Client-end TLS Interception Software

Found via TheRegister article:

Killed by Proxy: Analyzing Client-end TLS Interception Software
https://users.encs.concordia.ca/~mmannan/publications/ssl-interception-ndss2016.pdf

Edit: Found an earlier thread by Rasheed187: https://www.wilderssecurity.com/thr...-client-end-tls-interception-software.382679/. Which currently gets me the same PDF created/modified December 19, 2015.

 

Nice find, shows again that it's better not to trust AV's to do HTTPS scanning.

 

This subject coming up again motivated me to start putting together a list of SSL/TLS related test tools. I put a copy on my profile page, if anyone is interested. Edit: Moved to https://www.wilderssecurity.com/threads/ssl-tls-assessment-tools.385788/.

 

@TheWindBringeth Thank you for sharing. I think that this is a critical topic of this day and age and, in particular, we need more eyes and more security researchers analyzing these local/mitm interceptions by third party security software to ensure that there are no glaring holes and that specifications are followed accurately at the very minimum.

 

Nice find on the Symantec checker Didn't know about that one.

 

With this, is it advisable to disable ESET's SSL scanning?
@itman Correct me if I'm wrong, but I think I saw a post of yours stating that ESET's SSL scanning is needed for full network and exploit protection. If it is disabled, then I may not get ESET's full protection.

 

Not all vendors are guilty, emsisoft e.g. doesnt interfere with TLS, but ESET does.

I got a few 2 year nod32 licenses this past week, but I will consider moving to emsisoft for their behaviour blocking and the better https scanning (not just that they avoid proxying but also their malware hostlist).

xhened its a lose-lose choice.

you picking to compromise tls security, or to compromise web page scanning side of eset, content still gets scanned as its cached by the web browser on disk, but some people say that side of scanning is not good enough, in addition any suitable memory exploit scanning should scan if compromise is attempted via browser memory instead of on disk.

Me personally? I keep eset's https scanning disabled.

 

I have went "back and forth" on the issue. I recently discovered some behavior with SSL scanning that I personally found unacceptable and have since turned it off.

What @chrcol is referring to is no security vendor performs SSL scanning 100% properly. Additionally content providers such as Google are constantly revising protocol processing which further complicates and causes issues with existing vendor SSL scanning.

The decision to use SSL scanning has to be made by each individual. Eset's ver.8 at least now automatically excludes EV certificates and some trusted non-EV web sites from being scanned. So that is a step in the right direction. However, I personally believe and have previously stated the following. All vendors who perform SSL scanned need to be certified that their scanning methods 100% comply with existing browser SSL processing methods. Until that exists, the user has no way of knowing if the vendor SSL scanning is indeed safe and secure. Unfortunately, I do not believe any compliance like organization is willing to get involved with doing so. Because, the act of scanning encrypted browser communication violates the purpose for which it was created for. That is, secure point to point communication.

 

Absolutely brilliant points that you've made and also very well said. They should all be required to follow the same standards 100% without any deviations from specifications or not be permitted to scan SSL/TLS encrypted communications at all. As you said, having some type of neutral standards organization monitoring/certifying/revoking these MITM interception methods and ensuring that they stay on top of any changes to specifications would be great, but sadly I don't see that happening either.

Regardless, I am glad that there is more light shining on the topic of encrypted communications interception/scanning lately by security researchers and reported on by some news sites.

 

There is a rough approximate way to test a security vendor's SSL protocol scanning capability.

Note: The following web site test does not perform basic browser SSL validation activity such as checking for certificate validation or revokation. Nor does it provide any analysis as to if SSL certificate pinning is being performed properly all the time. So keep that in mind.

The QUALS Client SSL test: https://www.ssllabs.com/ssltest/viewMyClient.html is designed to test your browser's SSL protocol compliance capability. You can use this test to also compare the vendor's SSL scanning compliance to that given by your browser.

Note: This web site uses non-standard HTTP and HTTPS ports i.e. 80,443 to connect. So you will have to make temporary adjustments to your outbound firewall rules if you filter outbound firewall traffic.​

Do the following:

1. Disable security vendor SLL protocol scanning option.
2. Browse to the Quals SSL Client test site. Make any firewall adjustments if needed.
3. Record all results for further analysis.
4. Exit your browser and clear all web cache, temporary browser files, etc..
5. Enable security vendor SLL protocol scanning option.
6. Repeat above steps steps 2 and 3.
7. Compare the results from both tests.

If the results are equal, then the vendor's SSL protocol scanning option is not interferring with the browser's SSL processing capability in regards to activity tested.

 

From https://manage.norton.com/beta
"IPS support for https

Norton Security's Intrusion Prevention System (IPS) blocks threats originating from your network, before those threats take up residence on a device. To help protect customer's data, financial institutions and other organizations that deal with your personal information use https - the encrypted version of http. Unfortunately, suspect sites have followed suit and are using https as well. The IPS included in Norton Security now detects attacks using https connections, and stops those attacks before they take up residence on the device."

I'm interpreting this to mean Norton will be implementing this as well. Will be interesting to see how their works.

 

I done more analysis on emsisoft and I think I know what they doing.

They not actually scanning web traffic, they just checking the destination and looking up the hosts list, they have a massive list of malware domains in the software to block. If its a match it gets blocked, if its not then its allowed, then they will scan files in the temp internet folder and rely on their behaviour blocker to protect the system, and if combined with HMPA there is memory protection.

This I think is a better system than ESET, and I now sort of regret getting my eset licenses in the past couple of weeks instead of emsisoft. What I havent tested yet on emsisoft tho is performance impact on system (only used in VM which isnt good way to test performance), web browsing speeds dont seem impacted tho and it doesnt have the blocky loading impact of http content like ESET does.

 

Since I am on a roll today pertaining to vendor SSL protocol scanning, here's a list that I beleive security vendors should be doing instead:

1. Perform certificate pinning validation to prevent external man-in-the-middle and phishing attacks. EMET already has this capability. Unfortunately, there is no easy way to do this automatically. However, some vendors already have the capabilty built-in through their certificate SSL scanning exclusion feature.

2. Anti-keylogging, screen capture/scraping, and like protection. Surprising how many vendors are still lacking in this area.

3. Aggressive IP address/domain name blacklist blocking of bad HTTPS web sites.

3. Browser and other Internet facing apps hardenning to prevent any disk or memory based modification, hook setting, and like activities.

4. Auto sandboxing of all Internet facing apps, e-mail clients, etc. and their resultant downloads.

 

Ref #1, they need to really stop proxying https traffic.

Off the top of my head these are all what is currently wrong with ESET (and other similar vendor proxying) https (the list will keep growing as https is having lots of changes lately).

no http/2 support
no key pinning
no HSTS
no revocation checks
no chacha20 ciphers
no gcm ciphers
doesnt maintain negotiated ciphers all way from server to client
no OCSP alerts
no content security header passthru (not strictly https related)

Since I manage servers for a living, I see this straight away when testing with nod32 http(s) scanning enabled, it causes all sorts of breakage and weaken's security significantly.

Chrome and firefox do pinning validation without EMET natively, the pinning EMET does is just for IE (and possibly edge).

Alll this stuff should be handled by the web client, there should be no intermediate client between the web browser and the server. Emsisoft who seem to get excellent results on every detection test have proven you dont need to intercept http traffic during transit to detect malware.

 

Chrome and I also assume Firefox have issues with certification pinning as noted here: https://news.ycombinator.com/item?id=9073068

 

certificate pinning is where a header is sent by the web server for the hash of the authorised certificate, the browser then saves the hash for the duration of the ttl, if it receives a certificate that doesnt match the hash then it will be rejected without a overide option presented to the end user. Typically pinning is not used for root certificates but either for CA's or the certificate of the site.
There is also an option for preloading of pinning where chrome will add the hash to a preload internal list which is automatically sent to all users of chrome, meaning they will have the pin even before they first visit the site.

So what you linked to isnt an issue. A compromised CA issuing a new cert for google would get rejected providing there is a pin for the google domain.

The future for all this as well as revocation checking is DANE dns records as part of DNSSEC, when that takes off, then pinning and revocation checks will be a thing of the past.

Also that post is over a year old, chrome development is very rapid and a lot of https stuff has changed in 12 months.

 

That's exactly the problem with browser based certificate pinning.

When you pin a certificate in EMET, you pin the thumbprint of the web site's issuing root CA certificate. This assures a man-in-the-middle hasn't installed his root CA certificate and is intercepting your encrypted web traffic and decrypting it with his root CA certificate. This is what I recommended security vendors do in place of SSL protocol scanning.

When a security vendor is performing SSL protocol scanning, they likewise do the same. As such, the vendor is responsible for certificate pinning validations. They can only do that through an external lookup to ensure the pinned certificate chain is identical to that done by the browser for SSL connections.

Using Eset for an example, I noticed that ver. 8 was only storing the web site and it's associated intermediate CA certificate when I excluded a web site from SSL protocol scanning. That indicated they were not properly performing certificate chain pinning. I complained about that and they are now storing the entire web site pinning path i.e. web site, intermediate CA, and root CA certificates.

 

You have misunderstood how it is supposed to work.

Pinning the root certificate is bad, because all one needs to do is get a cert signed by that root provider and it will work.

So ESET are doing things wrong, especially if they are deciding what to pin.

Pinning works by what the admin of the website chooses to pin, not the client software. The vast majority of sites on the internet dont have pinning.

Chrome will pin the root certificate if thats what is in the pin headers, but hardly anyone does that because its not the right way to use pinning.

Have you confused chaining with pinning? v8 of eset has no support for pinning at all.

 

A good explaination is:

Typically certificates are validated by checking the signature hierarchy; MyCert is signed by IntermediateCert which is signed by RootCert, and RootCert is listed in my computer's "certificates to trust" store.

Certificate Pinning is where you ignore that whole thing, and say trust this certificate only or perhaps trust only certificates signed by this certificate.

So for example, if you go to google.com, your browser will trust the certificate if it's signed by Verisign, Digicert, Thawte, or the Hong Kong Post Office (and dozens others). But if you use (on newer versions) Microsoft Windows Update, it will ONLY trust certificates signed by Microsoft. No Verisign, no Digicert, no Hong Kong Post office.

Also, some newer browsers (Chrome, for example) will do a variation of certificate pinning using the HSTS mechanism. They preload a specific set of public key hashes into this the HSTS configuration, which limits the valid certificates to only those which indicate the specified public key.

Ref.: http://security.stackexchange.com/questions/29988/what-is-certificate-pinning
​

The first paragraph describes the browser's default behavior. This behavior can be overridden however by a local host proxy which can intercept the outgoing SSL traffic and decrypt it using its own previously install root CA certificate. The only way to detect this activity is by independently associating the web site's certificate with its real root CA certificate and verifying the web site's root CA certificate upon connection to the web site is indeed the one its supposed to be i.e. certificate pinning.

It should be noted that if the destination web site used an EV issued certificate, proxy interception can be visually detected by the green background missing in the browser URL address area. Use of stolen/hacked EV certificates is non-existent as far as I am aware of. However, many HTTPS web sites do not use EV certificates due to their higher cost.

​

 

Just discovered example of a botnet using local proxy:

The malware responsible for this botnet's rise is called Redirector.Paco. Once it reaches and infects a computer, Paco will modify the computer's local registry keys, adding two entries disguised as "Adobe Flash Scheduler" and "Adobe Flash Update," which will make sure the malware starts after every PC boot-up.

Additionally, the malware also modifies Internet Explorer proxy settings, adding a PAC (Proxy Auto Configuration) script that hijacks all Web traffic through a local proxy server on port 9090.

This redirection allows the malware to sniff all Web traffic originating from the PC. Paco will look for queries made to popular search engines like Google, Bing or Yahoo, and show fake Web pages in their place, mimicking their real UI.

Malware comes with its own certificate to disguise HTTPS traffic. A local certificate allows the malware to avoid showing HTTPS errors in the user's browser, but if the user has the presence of mind to press the lock icon in their address bar, they'll see the true source of their certificate being different from what it is supposed to be.

After the user enters their search queries, the malware will return fake search results that replace many of the real links with others obtained from a Google custom search.

Ref.: http://news.softpedia.com/news/mill...sults-for-popular-search-engines-504108.shtml​

 

I would say thats wrong.

if a certificate is pinned but the CA provider isnt trusted, you will still get a warning. Likewise for things like expired certs and mismatched hostnames.

Pinning has no negative affect on the normal check's, what it does is allow the web site administrator/developer to only allow specific certificates to authorise that site, whilst with no pinning any certificate from a trusted CA providing it has a matching common name. So pinning basically is like a whitelist for certificates.

You can test this yourself very easy, setup a domain on https, make a self signed cert (non trusted CA) and pin it. The browser will alert you.

 

Came across an interesting article about Public Key Pinning Extension for HTTP (HPKP). If you're using a browser such as Firefox or Chrome that supports it, appears that it won't afford you much protection against a MITM:

Notably, very few sites are making use of HPKP: Only 0.09% of the certificates in Netcraft's March 2016 SSL Survey are served with HPKP headers, which equates to fewer than 4,100 certificates in total.
​

Worse, of the few sites using it, many are performing it improperly:

But more surprisingly, around a third of these sites are using the HPKP header incorrectly, which effectively disables HPKP. Consequently, the total number of certificates that are actually using HPKP is effectively less than 3,000.
​

Ref.: https://forums.freebsd.org/threads/55668/

So I guess an argument can actually be made that AV vendor use of their own root CA cert. which by default disables HPKP is not that much of a big deal:

According to Böck, all of the security products he tested break Public Key Pinning Extension for HTTP (HPKP), a security feature designed to prevent MitM attacks leveraging forged certificates by instructing the web client to associate a cryptographic key with a certain web server.

“Browsers made a compromise when introducing HPKP. They won't enable the feature for manually installed certificates. The reason for that is simple (although I don't like it): If they hadn't done that they would've broken all TLS interception software like these antivirus applications. But the applications could do the HPKP checking themselves. They just don't do it,” the expert explained in a blog post.
​

Ref.: https://blog.hboeck.de/archives/869...irus-software-lowers-your-HTTPS-security.html

​

 

The HTTP Public Key Pinning: You’re doing it wrong! article posted at that forums.freebsd.org link mentions an alternative. Just glanced at it, but noticed one thing worth surfacing:

Internet-Draft: TLS Server Identity Pinning with Tickets
https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/

 

HPKP is low adoption but that adoption will grow over time. So yes it is a big deal.

It is a bit like saying the vast majority of TLS connection have no MITM attacker so there is no need for MITM mitigation security.

Or maybe the vast majority of people wont come across malware so there is no need for an a/v

you get my point?

 

I already stated in reply #13 what AV vendors should be doing instead of intercepting encrypted browser traffic. That is provide certificate pinning validation similar to that currently being performed in EMET. I have already suggested this to Eset.

Most of the existing AV vendors which scan encrypted traffic have an ability to exclude associated web site certificates from be scanned. This feature could be utilized to store the thumbprint of the web site's root CA captured through independent lookup using their servers. Then upon browser access to the web site, validate that the web site's root CA thumbprint shown in the browser matches that previously stored. The user would simple enter the domain name for web sites they wish to manually pin and the AV solution would store retrieve and store the associated root CA thumbprint. The user could then also independently audit the stored thumbprints to ensure the vendor performed the original lookup properly.

In reality, the AV vendors that scan encrypted web site data are or should be doing the certificate pinning validation since the browser can no longer do so due to the use of the vendor's root CA certificate. The problem is, there is no way to determine if they are doing this validation properly.