EIS 17.1.9.0 and HTTP/3 Scanning

[itman 1,662]

Had to disable it since it was trashing my IPv6 connection.

[Enrico 3]

Had to disable it since it was trashing my IPv4 LAN.

[Marcos 5,078]

Please elaborate more on the issue and provide logs collected as follows which are essential to determine the root cause of the issue:

1. Enable advanced logging under Help and support -> Technical support
2. Reproduce the issue
3. Stop logging
4. Collect logs with ESET Log Collector and upload the generated archive here.

 

[Enrico 3]

I've started the logging with HTTP3 scan enabled, tried to reach a network share, disabled the scan, restarted the network, opened a shared folder, quit the logging.essp_logs.zip

[itman 1,662]

In my case, just getting Eset networking to function properly with my IPv6 network processing has always been a major hassle. My ISP's network uses 6rd tunneling to transmit IPv6 traffic on its IPv6 network. The IPv6 tunnel broker addresses are loaded on the WAN side of its issued gateways with connectivity to these addresses done via corresponding IPv6 multicast addresses assigned on the LAN side of the gateway. Also implied is DNS64/NAT64 is being deployed for IPv6 DNS processing. Once 6rd IPv6 processing has been fully initialized, two local subnet IPv6 DNS server addresses; both identical in value, are assigned.

The first Eset bork of the above with HTTP/3 scanning enabled is when I open Firefox with DoH enabled w/maximum protection. Shortly thereafter, one of the two local subnet IPv6 DNS server assigned addresses is dropped resulting in loss of IPv6 Internet connectivity. I still have local subnet IPv6 connectivity.

The second Eset bork occurs at IPv6 lease renewal time. Of note is the gateway uses mDNS for lease renewal activities.  Shortly thereafter, one of the two local subnet IPv6 DNS server assigned addresses is dropped resulting in loss of IPv6 Internet connectivity. I still have local subnet IPv6 connectivity.

Edited April 5 by itman

[itman 1,662]

As far as QUIC processing goes, I connected to a web site, Nkiri.com, known to use QUIC. All I observed was tunneled TCPv6 network traffic.

[iKirby 0]

I'm also having issues with IPv6 connectivity after updating to 17.1.9.0. In my case, my device would lose IPv6 connectivity after 10~20 minutes. When it happens, IPv6 gateway becomes empty. I had to disable and re-enable ethernet adapter or restart Windows to get it to work again.

Disabling HTTP/3 scanning fixed the issue for me.

I also found that when HTTP/3 scanning is on, I can't ping IPv6 addresses even if I can access IPv6 websites (before IPv6 connectivity drops). IPv6 uses ICMP for router advertisement and other things, so I guess this is the issue.

eis_logs.zip

[itman 1,662]

I will also note that with HTTP/3 enabled in Firefox, these tests: https://cloudflare-quic.com/ ,https://quic.nginx.org/ ,  https://http3.is show it is not. I don't know if this is because Eset HTTP/3 scanning in disabled status also disabled Firefox HTTP/3 processing, but it appears to be the case. In any event, presently having the setting disabled in Eset possess no security risk.

Edited April 7 by itman

[PassingBy 5]

My Internet remains slow with HTTTP/3 on or off. It's just not as it used to be. Works well with EIS disabled.

Edited April 6 by PassingBy

[Marcos 5,078]

20 hours ago, PassingBy said:

My Internet remains slow with HTTTP/3 on or off. It's just not as it used to be. Works well with EIS disabled.

Could you please uninstall v17.1.9 and install v17.0.16 from https://forum.eset.com/files/file/133-eset-security-17016/ ?
Does the speed issue actually go away and returns as soon as you upgrade to v17.1.19 and disabling http/3 makes no difference? What about disabling Network traffic scanner?

[Israeli 8]

Same HTTP/3 problem happens on VPN...

 

[itman 1,662]

More testing last night. What a mess. But, a lot of progress.

First is I found out why QUIC sites weren't processing in Firefox. Somehow there were two network.http.http3.enabled settings were present in about:config. The first instance was set to false and the second one set to true. Deleted the false instance and now the above posted QUIC test sites all show QUIC is enabled.

Next, I disabled DoH in Firefox resulting in use of my ISP assigned DNS servers.

I then proceeded to test and observe what was happening network-wise when I accessed the QUIC test sites. No UDP 80/443 connections whatsoever. But for IPv6 connections, the expected TCP 6rd tunnel connection to tunnel broker IP addresses being made.

Bottom line - the QUIC UDP traffic is immediately being converted to IPv6 TCP 6rd tunnel traffic. Eset HTTP/3 scanning is interfering with the 6rd TCP tunneling processing resulting in the IPv6 existing 6rd tunnel configuration being borked. Since I have not encountered any issues to date with Eset processing the TCP 6rd tunnel network connections, I assume it can detect any malicious QUIC network traffic embedded within. Further proof of this was when access to https://crackingpatching.com ; discussed at length in two other forum threads, was tested. Eset blocked access as noted below. The point to note is the connection was made via IPv6 whereas in the past, connection was made via IPv4 when HTTP/3 was disable in Firefox;

Quote

Time;URL;Status;Detection;Application;User;IP address;Hash
4/8/2024 1:54:15 PM;https://crackingpatching.com;Blocked;Internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxxxxx;2606:4700:3030::ac43:db5f;27BB8D2FC02CD2BBC184D07357AAA9903D88B425

As far as access to QUIC IPv4 web sites, I will just have to live with the risk. I believe that is minimal due to Windows preferring IPv6. What Eset needs to do is provide an option to only scan IPv4 QUIC traffic.

Edited April 8 by itman

[itman 1,662]

One more test and this one is the most interesting one to date.

I created an Eset firewall rule to block any in/out network traffic for UDP, remote ports 80,443,8443. Moved the rule to the top of the rule set. Connected again to QUIC test web sites.

Guess what happened? Appears Eset forum uses QUIC. In any case, QUIC UDP traffic is being detected by the firewall but I never see it showing up in TCPView.

Edited April 8 by itman

[Marcos 5,078]

We kindly ask you to reproduce the issue while capturing the network communication with Wireshark and advanced network traffic scanning enabled at the same time in the advanced setup -> Tools -> Diagnostics:

 

After reproducing the issue, please disabled advanced logging and only then collect logs with ESET Log Collector.

[itman 1,662]

6 hours ago, Marcos said:

We kindly ask you to reproduce the issue while capturing the network communication with Wireshark and advanced network traffic scanning enabled

The problem is loss of IPv6 Internet connectivity doesn't happen immediately as described here: https://forum.eset.com/topic/40527-eis-17190-and-http3-scanning/?do=findComment&comment=182347 . Plus, you have to be constantly monitoring network traffic as to when this occurs.

Edited April 9 by itman

[itman 1,662]

I did more research into HTTP/3 processing by other security solutions with the following results.

Almost all require that HTTP/3 be disabled in the browser.

I could only find one security solution that actually is scanning HTTP/3 and it is Avast. The result of that scanning parallels Eset results to date with multiple comments in the Avast forum about all the app processing being borked when HTTP/3 scanning is enabled.

Kaspersky, somewhat to be expected, appears to be the only security solution handling HTTP/3 network traffic properly.  It internally blocks HTTP/3 which results in retransmission as HTTP/2 traffic. As such, no modification to internal browser HTTP/3 default setting is required.

In my case and I believe the other poster having IPv6  connectivity being disabled w/Eset HTTP3 scanning enabled, I am fairly convinced it is due to the 6rd processing being performed by the ISP. Everything points to the UDP traffic being converted to tunneled TCP traffic in transit. Then reconverted to UDP upon access by the browser. I am not surprised about this since getting Eset to function properly with the 6rd tunneling my ISP performs has been a nightmare for the 10 years I have used Eset.

Presently, I have disabled HTTP/3 processing in my browser and also Eset HTTP/3 scanning. It will probably remain this way for some time since I have zero confidence Eset will ever be able to resolve the 6rd tunneling conflict.

Edited April 11 by itman

[URBAN0 14]

Till few days ago I was only using IPv4 and Rogers modem was bridging my Asus routers that were set up in AiMesh system.

Today I have enabled IPv6 In my router and it worked good, but within an hour my connection was getting slower.

To troubleshoot I connected my cable directly to my modem and once again it was working nice, but started to act up shortly after, some sites would open OK and some would take noticeably longer.

After disabling HTTP/3 things where once again good and has been good since.

I had no idea till recently when I was faced with needing to change from IPv4 to IPv6 that with ESET HTTP/3 enabled there is that much connection issues and ESET is aware of that and can't find work around it😐

Edited April 12 by URBAN0

[Marcos 5,078]

Those who are having issues with HTTP/3 traffic scanning enabled and have not provided a Wireshark log aligned with an advanced network traffic scanning log, we kindly ask you to provide them to expedite analysis of the issue.

In particular, we would need you to:
1, Enable advanced network traffic scanner logging (advanced setup -> Tools -> Diagnostics)
2, Start capturing the network communication with Wireshark
3, Reproduce the issue
4, Stop logging and save the Wireshark log.
5, Collect logs with ESET Log Collector
6, Supply us with both ELC and Wireshark logs for perusal.

[PassingBy 5]

On 4/7/2024 at 11:49 AM, Marcos said:

Could you please uninstall v17.1.9 and install v17.0.16 from https://forum.eset.com/files/file/133-eset-security-17016/ ?
Does the speed issue actually go away and returns as soon as you upgrade to v17.1.19 and disabling http/3 makes no difference? What about disabling Network traffic scanner?

 

Sorry Marcos, i was late in seeing this. Connectivity seems more or less fine, except for moments of real slowdown and overheating. I suspect part of the initial slowness was due to the post-Quake issues in Taiwan. We had som 4g/5g issues for a few days after the quake. No disruptions, but slowdowns.

 

I will keep monitoring and if further issues arise i'll post here again.

 

Best.

 

E.

[itman 1,662]

I finally got HTTP/3 scanning to work w/o taking down my IPv6 Internet connection by pretty much rebuilding my local network - a long and arduous undertaking with some very ugly findings. Discussion on this for another day.

@Marcos, I have searched at length on the web for some way to test if Eset HTTP/3 scanning is working properly w/o success. Since the Eset forum uses HTTP/3 is it possible you could create a HTTP/3 web document with let's say, the eicar string embedded within. Then post a link on the forum to access it?

Edited April 18 by itman

[NewbyUser 74]

You could ask the same ofwicar.org. At the bottom f their tests page they offer contacting them to add new tests or capability.

https://www.wicar.org/test-malware.html