Web Control behind a proxy not showing blocking page for https sites

[me myself and i 0]

10 minutes ago, itman said:

Have you tried to create rules on these firewalls to allow all inbound/outbound traffic from ekrn.exe?

The client-side firewall has the same settings as if the client is in the home office (there everything works fine)
The company firewall is of course in between if they are in the office, but that would not explain why everthing is working fine as long as the destination site is http.
provided that the exe works the same for http and https regarding the blocking of websites.

Wrong?

 

[Marcos 5,069]

Perhaps the following might shed more light:
- enable advanced Web control and Network protection logging in the adv. setup -> tools -> diagnostics
- start recording
- reproduce the issue
- stop recording and save the video
- stop logging
- collect logs with ESET Log Collector
- provide both ELC logs and the video for perusal.

[me myself and i 0]

OK.

did it like you told me.
Reproduced with Edge and Chrome (as you can see in the video (i zipped it))
 

video.zip ees_logs_full.zip

[itman 1,659]

On 1/21/2021 at 6:20 AM, me myself and i said:

the situation is:
if the client is offsite (HomeOffice) everything works fine and as expected.
if a website is blocked (http or https) the user gets a blocking page in the browser.
as soon, as the client is in the office he will connect to the internet via a proxy (Cisco WSA (http and https proxy enabled) or Bluecoat CAS (only http proxy enabled))

Here's something to ponder. I assume you are referring to notebook/laptop devices here?

If the device is offsite, it's obviously not using the office network proxy. How are these devices configured Eset-wise in regards to proxy settings? Is this setting enabled which I assume it is:

Quote

Use direct connection if proxy is not available – If ESET Internet Security is configured to connect via proxy and the proxy is unreachable, ESET Internet Security will bypass the proxy and communicate directly with ESET servers.

This would also explain why the client devices offsite have no Internet connectivity issues; they are not using a proxy. If client Eset device has an issue with using office proxy, it will fallback to a direct connection to Eset servers. This will fail due to office network settings requiring use of a proxy. Therefore the issue lies with either client Eset proxy settings or their interaction with office network proxy processing.

Edited February 2, 2021 by itman

[Marcos 5,069]

The video shows an ERR_TUNNEL_CONNECTION_FAILED error in Chrome. This is important to know.

If you open the website in Firefox or Edge, is the same error reported? If you disable Web Control, does the https website open in Chrome? Is it blocked by Web Control if you are connected directly and not through a proxy?

[itman 1,659]

2 hours ago, Marcos said:

The video shows an ERR_TUNNEL_CONNECTION_FAILED error in Chrome.

I already posted a mitigation to Chrome for this: https://forum.eset.com/topic/27097-web-control-behind-a-proxy-not-showing-blocking-page-for-https-sites/?do=findComment&comment=128003 . OP said it didn't help.

2 hours ago, Marcos said:

If you open the website in Firefox or Edge, is the same error reported?

OP stated previously its occurring with all browsers.

[Marcos 5,069]

Please reproduce the issue once again but now with all the following advanced logging enabled:
- advanced Web Control logging
- advanced Network protection logging
- advanced Protocol filtering logging

[me myself and i 0]

12 hours ago, itman said:

Here's something to ponder. I assume you are referring to notebook/laptop devices here?

If the device is offsite, it's obviously not using the office network proxy. How are these devices configured Eset-wise in regards to proxy settings? Is this setting enabled which I assume it is:

This would also explain why the client devices offsite have no Internet connectivity issues; they are not using a proxy. If client Eset device has an issue with using office proxy, it will fallback to a direct connection to Eset servers. This will fail due to office network settings requiring use of a proxy. Therefore the issue lies with either client Eset proxy settings or their interaction with office network proxy processing.

Hi itman,

 

i see your point. good idea!
but we have no proxy configured in ESET 😞
At least not under Tools > Proxy Server

 

[me myself and i 0]

All other (not blocked) https sites work well.

If i disable Webcontrol i can reach the unwantet websites and can open them (http and https)
Thats why i assume it is not an issue of the proxy.
Regarding Firefox, and Chrome Error: ERR_TUNNEL_CONNECTION_FAILED
As i stated before it happens in all browsers (the error messages vary)
In my initial post i already pointet out that this is the message from Chrome.

11 hours ago, Marcos said:

Is it blocked by Web Control if you are connected directly and not through a proxy?

As i told before, if the users are offsite everything works as expected, Websites are blocked and show the blocking page.

[me myself and i 0]

32 minutes ago, Marcos said:

Please reproduce the issue once again but now with all the following advanced logging enabled:
- advanced Web Control logging
- advanced Network protection logging
- advanced Protocol filtering logging

will do as soon as possible

[me myself and i 0]

here they are...

ees_logs.zip

[itman 1,659]

Since the issue is HTTPS related and the Cisco WSA appliance is the only one performing HTTPS proxy activities, the issue with Eset lies there. I was reviewing this section "HTTPS Request Failures" in Cisco documentation: https://www.cisco.com/c/en/us/td/docs/security/wsa/wsa11-8/user_guide/b_WSA_UserGuide_11_8/b_WSA_UserGuide_11_7_appendix_010111.html#con_1316710 but nothing "smacked me in the face" there. However, I really know zip when it comes to use and configuration of this product.

[me myself and i 0]

10 minutes ago, itman said:

Since the issue is HTTPS related and the Cisco WSA appliance is the only one performing HTTPS proxy activities, the issue with Eset lies there.

Hi itman,

that's what I thought at first too, but....
if I configure the client to use the bluecoat proxy that passes https requests through, it's exactly the same behavior on the client.
So I don't think it has anything to do with the WSA itself. That's why I think it's an Eset problem if the Eset is behind a proxy (any proxy).
As mentioned before, ESET is able to block the page (I receive an email about it), it's just not able to display the blocking page.

[itman 1,659]

I haven't researched the Bluecoat appliance capability.

In regards to the Cisco WSA appliance, it is not your run of the mill firewall appliance. It is a full feature security protection product having web access protection capability equal to that of Eset. It also incorporates a real-time AV scanner using both McAfee and Sophos engines it appears.

What is known about Eset's SSL/TLS protocol scanning is that it "doesn't play well" with other installed security products that do the same that use the Windows Filtering Platform interface. The installed version of Adguard is one known conflicting example.

I guess it has to be determined how Cisco WSA does its SSL/TLS protocol scanning  in regards to client devices interfacing with it. Namely is it using the Windows Filtering Platform to do so versus a network adapter mini-port driver filer.

Perhaps the best way to proceed further is to contact Cisco about the issues you are having with Eset'sSSL/TLS protocol scanning enabled.

Edited February 3, 2021 by itman

[me myself and i 0]

ok...

may i need some help here to understand...
If the website is in a category which is not blocked, all is fine (via the proxy)
If the website is in a category which is blocked, it is blocked (via the proxy) and i (the administrator) receive an email notification about the blocking like:

2/3/2021 17:27:09 PM - During execution of  on the computer XYZ, the following event occurred: Web control:

Web page blocked by category rule.

URL:

hxxp://WHATEVER-IS_BLOCKED.COM:443

for me it looks like the website is blocked absolutly fine... the only thing what is not showing up is the blocking page in the browser.
Assuming that the blocking page is stored localy on the client, how can that be an issue with the cisco or the bluecoat?

pls help me to understand... i'm a bit lost.

 

[itman 1,659]

36 minutes ago, me myself and i said:

If the website is in a category which is blocked, it is blocked (via the proxy) and i (the administrator) receive an email notification about the blocking like:

I assume you're referring to blocking by the Cisco WSA appliance?

37 minutes ago, me myself and i said:

for me it looks like the website is blocked absolutly fine... the only thing what is not showing up is the blocking page in the browser.

My answer is Cisco WSA blocked the network traffic to/from the browser. Hence from a browser perspective, it would appear that a connection attempt to the domain was never made.

[me myself and i 0]

4 minutes ago, itman said:

I assume you're referring to blocking by the Cisco WSA appliance?

No, the notification is from ESET.

 

5 minutes ago, itman said:

My answer is Cisco WSA blocked the network traffic to/from the browser. Hence from a browser perspective, it would appear that a connection attempt to the domain was never made.

why should the WSA block that traffic? there are no blocking rules in WSA defined.

[itman 1,659]

2 hours ago, me myself and i said:

2 hours ago, itman said:

I assume you're referring to blocking by the Cisco WSA appliance?

No, the notification is from ESET.

What is causing confusion at least for me is you are referring to both the proxy; i.e. perimeter network appliance and Eset together.

3 hours ago, me myself and i said:

for me it looks like the website is blocked absolutly fine... the only thing what is not showing up is the blocking page in the browser.

We can therefore state the following:

1. HTTPS web site attempted connectio is blocked by Eset.

2. Eset records web site blockage via e-mail, etc. and records the reason as web control setting.

You state:

3 hours ago, me myself and i said:

the only thing what is not showing up is the blocking page in the browser.

Does this mean that the web site site Eset says it blocked does actually display in the browser?

Or the web page does not display in the browser but there is no indication in the browser that the web site connection was actually blocked? For reference and assuming no Web Control message customization was performed, the following is displayed when Web Control blocks something:

And you are stating this alert is not appearing for Web Control blocked HTTPS traffic.? However, this alert will be displayed for blocked HTTP traffic?

Edited February 3, 2021 by itman

[itman 1,659]

On 1/21/2021 at 9:52 AM, me myself and i said:

/21/2021 15:36:42 PM - During execution of  on the computer <ClientName>, the following event occurred: Web control:

Web page blocked by category rule.

URL:

hxxp://<blockedSite>.de:443

i would expect:

https://<blockedSite>.de

Let's get back to this.

First of note is none of your client devices have Eset proxy settings enabled and configured. As such, Eset is unaware that a proxy is being deployed on the corporate network.

It appears the default proxy port for the Cisco WSA appliance is port 80; the same as Windows uses. What appears to be happening is the Cisco WSA is forwarding all incoming network traffic using its port 80; i.e. HTTP, with a port specification. The port specification in the case of HTTPS traffic would be 443. Hence, Eset is just reporting in the log entry the network traffic as it received it.

I also believe the above is why you are seeing Eset block alerts for always HTTP network traffic when the browser is used versus HTTPS blocked alerts.

[me myself and i 0]

Hi itman,

as i am on vacation today I'll get back to this tomorrow.

Just a quick question: are you able to watch the video i uploaded?
 

Best

[itman 1,659]

4 hours ago, me myself and i said:

Just a quick question: are you able to watch the video i uploaded?

No. Only Eset moderators can view forum attachments. You will have to upload the video to a file sharing site and post the link for me to access it.

[itman 1,659]

This posting might be informative as to why you are seeing port specification attached to URL's : https://stackoverflow.com/questions/50888270/why-do-we-need-to-specify-a-port-number-while-using-http-protocol . This lends further credence that it is originating from the proxy servers you have deployed.

There is also a way to verify all this. As a test, configure Eset proxy settings on a client device used at home to match those for the Cisco WSA proxy. When this device is used on the corporate network, does Eset perform as expected in regards to logged and blocked Web Content HTTPS browser initiated network traffic?

Edited February 4, 2021 by itman

[Marcos 5,069]

Currently we don't need anything else. The issue is visible in last logs but we don't know yet why it happens.

[itman 1,659]

Think I found the issue and it confirms my earlier suspicions.

The Cisco WSA has two types of HTTPS proxies; explicit and transparent.

If an explicit proxy is setup, everything being routed to/from the HTTPS proxy is using port 80:

If a transparent HTTPS proxy is set up, everything being routed to/from the HTTPS proxy is using expected HTTPS formatted port 443 network traffic:

My guess is if a transparent proxy was used, there would be no issues with Eset since it would be examining expected port 443 HTTPS traffic.

Ref.: https://www.cisco.com/c/en/us/products/collateral/security/web-security-appliance/guide-c07-742373.html#_Toc10022546

Some additional info on the differences between explicit and transparent HTTPS proxy:

Quote

When requests are being redirected to the WSA transparently, the WSA must pretend to be the OCS (origin content server), since the client is unaware of the existence of a proxy. On the contrary, if a request is explicitly sent to the WSA, the WSA will respond with it's own IP information.

There are a few differences between explicit and transparent client HTTP requests:

1. An explicit request has a destination IP address of the configured proxy. A transparent request has a destination IP address of the intended web server (DNS resolved by the client).

2. The URI for a transparent request does not contain the protocol with the host:

Transparent	GET / HTTP/1.1
Explicit	GET http://www.google.com/ HTTP/1.1

Both will contain an HTTP Host header that specifies the DNS host.

WSA Configuration

The WSA can be configured for "transparent" or "forward". This is slightly misleading, as this is really "transparent" or "explicit" mode, both of which are forward proxy deployments. Reverse proxy is where the proxy is intended to be on the same network as the HTTP servers and its purpose is to serve up content for these HTTP servers.

The only major difference between transparent and forward mode on the WSA is that in transparent mode, the WSA will respond to both transparent and explicit HTTP requests. Whereas in explicit, the WSA ONLY responds to explicit HTTP requests.
 

https://www.cisco.com/c/en/us/support/docs/security/web-security-appliance/117940-qa-wsa-00.html

Edited February 5, 2021 by itman

[me myself and i 0]

18 hours ago, Marcos said:

Currently we don't need anything else. The issue is visible in last logs but we don't know yet why it happens.

Okay,
if i can help you, please let me know.

Will you get back to me as soon as you've figured out what the problem is?
(hopefully with a solution?)