Killed by Proxy: Analyzing Client-end TLS Interception Software

remember pinning is just one of many things broken by the MITM method. EMET pinning is actually very poor, it just validates pins for the few big sites and its only used by internet explorer, if you dont use a microsoft browser such as chrome or firefox, they dont use EMET for pinning checks, they have their own mechanisms and actually check pinning for 'all' sites.

When I get emsisoft next week I am even considering uninstalling nod32 completely, I was planning to keep it for manual hips rules and the email scanning (as emsisoft seems to have no outlook email scanning options). But I dont want to create a mess on my system by having duplicated tools in place. To replace hips I can use rehips.

Eset has blocked about 20 infected emails in the past 24 hours alone to one of my inboxes. Shame they a mess on the http(s) and cloud side of things.

 

You have to add manually any web site you want pinned.

You enter the URL for the web site to be pinned. Then you associate that web site to its issuing root CA authority certificate by selecting the same from the Win root CA certificate store.

Problems only arise when the needed root CA certificate doesn't exist in the Win root CA certificate store. Then you have to import said root certificate into the Win root CA store. I never had to do that for any sites I had pinned. Also if the web site changes it's root CA certificate, you have to replace the existing pinned one in EMET with the new certificate.

I specifically asked Emsisoft about client e-mail scanning a while back. The response per Fabian was that they feel most people use web mail and have no plans for adding client e-mail scanning.

So I believe you're starting to get the picture why I use both Emsisoft Anti-malware and Eset Smart Security together.

 

Another point worth noting is if you are using IE and expect that it will provide the visual clue of displaying a green color in the toolbar for EV certificates. This is your first clue that a MITM interception has occurred. Well, that is broken as noted in this Gibson Research article: https://www.grc.com/ssl/ev.htm . So certificate pinning capability of your critical banking web sites is a must if your using IE.

 

Downloaded EMET 5.5. Presently just using it for certificate pinning. Took a grand total of 5 mins. to set up the 6 EV certs. my bank uses. All certs. use the same root CA cert., so only one setup was needed for that. Then just pinned the 6 URLs for the EV certs. to that one CA root cert. rule.

As a side note, I forgot EMET has detours protection. Most anti-execs don't protect against that activity.

BTW - since most AV SSL protocol scanning is bypassing EV certs., you don't have any pinning protection using it other than that provided by the browser.

 

thank you for this information, then yes eset will stay on my system then as I consider email scanning perhaps even more important than www security considering the amount of bad emails I have got over the years.

Also yes you correct that you can add pins to EMET,. although thats clearly only something advanced users such as yourself will bother with.

 

At first, pinning appears to be a bit intimidating. However, it actually is very straight forward and easy to do. A HTTPS URL can only be associated with one root CA certificate. This can easily be determined by clicking on the browser toolbar lock symbol and displaying the root CA certificate i.e. the one at the top of the chain. Then all you do is write down the thumbprint value associated with the certificate; usually the first 10 or so characters is sufficient to uniquely id the string. However, the safer way to determine the root CA certificate thumbprint for possibly infected PCs is to use a web site like QUALS SSL server check to independently get the root CA certificate associated with the URL.

Then open EMET cert. pinning. Next create a pinning rule for the above determined root CA certificate. All that is entailed for this is to use EMET's certificate import function to copy the certificate identified by thumbprint from the Windows root CA certificate store into EMET. You then associate one or more web site URLs to the previous created certificate pinning rule. -EDIT- Make sure you use the text from the "CN=" field of the web site certificate if it is different from URL for the web site.

The only issue that can arise is if for some reason, the web site uses a root CA certificate that does not exist in the Windows root CA certificate store. In that instance prior to creating an EMET pinning rule, the certificate must be imported into the Windows root CA certificate store using for example certmgr.msc. -EDIT- Will also add that extreme caution needs to be exercised when importing any external root CA certificate into the Windows root CA certificate store.

 

Is it certain that EMET's certificate pinning does not work with Chrome? The reason why I ask is because I noticed that EMET was injecting EMET_CE64.dll into the main chrome.exe process. It was originally intended that EMET_CE64.dll would only be injected into iexplore.exe for certificate pinning.

 

If you go through the EMET thread, I believe it was possible to use certificate pinning in Chrome and Firefox prior to EMET 5.5 by making registry changes. I suspect that with EMET 5.5, MS just incorporated those changes into it?

You can test if its functional in Chrome by creating a pinning rule in EMET using the wrong root CA certificate for a HTTPS web site. If it is functional, you should get a certificate mismatch alert from EMET 5.5. According to this: https://www.winhelp.us/microsoft-emet.html cert. pinning only works for IE.

-EDIT- I reviewed the EMET 5.5 user manual and found no wording that stated certificate pinning was only valid in IE.

 

This is off topic but I noticed something about EMET 5.5 that is extremely important to me:

Banned functions: By enabling this option, EMET will block calls to ntdll!LdrHotPatchRoutine to mitigate potential exploits abusing this API.
​

This is being used by a current especially nasty malware to modify the knownddls and knowndlls32 tables in the kernel global root area. As far as I am aware of, no security software has this capability for x64 Win OSes. So I have enabled EMET for all my Internet facing apps. So far zip issues with either Eset or Emsisoft. Also, unlike EMET 5.2, ver. 5.5 has no impact on my web page rendering.

-EDIT- Here's the reference to the "hot patching" vulnerability: http://arstechnica.com/security/201...-used-windows-own-patching-system-against-it/ . Applies to Vista and Win 7. MS removed the capability starting with Win 8 and thereafter.

 

as I said before do "not" pin root certificates. Also its best to pin the key not the certificate.

First choice would be key for site certificate, second choice would maybe be CA cert.

EMET pinning is only used by microsoft applications. Defenitly IE, possibly also edge. Seems you want to think I am wrong, go ahead, but firefox and chrome simply honour pinning headers.

Pinning works by a header system, HPKP headers, google it. https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning

 

HPKP pinning was commented on in reply #22. Fewer than 1% of web sites use it and a third of those are doing it wrong which invalidates its functionality. Also IE does not support HSTS.

 

yes which is why EMET key pinning is only for IE, that I already told you.

However you are wrong about invalidation, the (proper) browsers check for the presence of the header, if its there it is enforced, if its not there, no harm done.

 

I hope that this is an appropriate thread to place this. The following is an excellent whitepaper on the dangers of HTTPS interception, led by several universities along with Cloudflare, Mozilla, Google and more:


The Security Impact of HTTPS Interception
Link (.pdf): https://zakird.com/papers/https_interception.pdf

 

I read the report twice and could not determine the criteria or find an explanation for two major evaluation categories; certificate validation and cyphers. They also missed a lot of software, or didn't realize, that products like Adguard and Ad-Aware for example also perform SSL protocol scanning.

I use Eset's SSL protocol scanning on its latest ver. 10 product - note the report was for ver. 9. I use QUALS SSL Browser test here for validation: https://www.ssllabs.com/ssltest/viewMyClient.html and it shows zip issues for IE11 when Eset's SSL protocol scanning is enabled.

Additionally, most of the AV products shown in the report do not scan all HTTPS web sites. Eset for example excludes all sites with EV issued certificates and sites they have determined to be safe using an internal whitelist.

 

Here is a follow up article regarding the study that was done:

Google and Mozilla's message to AV and security firms: Stop trashing HTTPS
Researchers call out antivirus and security appliance vendors for dangerous SSL inspection practises.

Link: http://www.zdnet.com/article/google...to-av-and-security-firms-stop-trashing-https/

I have not read the study in it's entirety as of yet, therefore I can't really comment on it at the moment.

 

In regards to this report: https://zakird.com/papers/https_interception.pdf, it has been removed from the web. I usually take these reports with a "grain of salt" when they are initially released since they are full of inaccuracies. Will wait for the revised edition if and when it is released.

 

For those who question who question the need for SSL scanning, here is a recently published Zscaler report on the subject: https://www.zscaler.com/blogs/research/rise-ssl-based-threats-1

 

Bringing this up from the dead to ask some layman questions:

Did some research, and it looks like a select few AV vendors don't touch HTTPS traffic at all, those being:

Avira (beta testing a "scan on all ports" feature, unsure if it includes SSL)
Panda
Webroot
Norton
F-Secure
G-Data
Trend Micro
Tencent
360
Mcafee

Rather than stick to these vendors, is the solution just to untick the "scan SSL/HTTPS" box in AV brand X and move on with your life? Or is there something deeper we should be concerned with?

 

Yes. Most if not all the AV vendors have an option to disable SSL protocol scanning if you so wish.

Also many of the AV vendors that scan SSL traffic, do not by default scan all HTTPS web sites. Eset for example does not scan sites with EV certificates. They also maintain an internal whitelist of "safe" web sites and do not scan those. Additionally for Eset, you can manually exclude any web site that you do not want SSL scanning performed. This is recommended for privacy sensitive web sites such as healthcare providers and the like.

Finally, other software does SSL scanning. Ad blockers such as Ad-a-ware scan SSL traffic. Also it is difficult or impossible to disable SSL scanning in these products.

Anyone concerned about if their AV product is properly performing the required SSL certificate validations when SSL protocol scanning is enabled should do what CERT recently recommended. Go to this web site: https://badssl.com/dashboard/ . For each alert generated by your AV about certificate issues, select block. At the end of the test, a report will be generated about any issues encountered with certificate validations. You should also perform the same test with SSL protocol disabled which will tell you the native SSL certificate validations your browser alone is performing and use that as a benchmark.

 

Understanding the prevalence of web traffic interception

Link: https://blog.cloudflare.com/understanding-the-prevalence-of-web-traffic-interception/

 

That's the trade-off, isn't it?

 

Whilst interesting, I always find it amusing when CloudFlare of all companies starts talking about man in the middle techniques, being that, MITM is exactly what CloudFlare is.

I frequently find it curious why so many websites just openly trust this company with private keys.

 

See my post related to cert fingerprints in the polls section please also do the poll.