pipes 4 Posted September 23, 2020 Share Posted September 23, 2020 Does ESET recognize this protocol can I block it I do not use Google chrome so no need for it? Here is a link about QUIC Protocol: https://nordvpn.com/blog/what-is-quic-protocol/ "There are few downsides to the QUIC protocol. It improves web communications and reduces latency, but it’s still in its experimental stages. It’s not widely adopted by other websites or web servers, nor is it supported by cybersecurity tools such as firewalls. Because of this, experimental QUIC protocol can currently open a security loophole." Link to comment Share on other sites More sharing options...
Administrators Marcos 5,069 Posted September 23, 2020 Administrators Share Posted September 23, 2020 Since QUIC utilizes the traditional HTTP ports 80 and 443, it's not possible to block it by the firewall without blocking HTTP as well. Link to comment Share on other sites More sharing options...
itman 1,659 Posted September 23, 2020 Share Posted September 23, 2020 Quote An application that uses the QUIC protocol sends and receives packets using UDP port 443. https://blog.apnic.net/2019/03/04/a-quick-look-at-quic/ As I see it a malware app would have to be installed on a device that uses the QUIC protocol. So in reality it is no different from a malware app using TCP. Bottom line - if no malware app is installed in the first place, their is nothing to be worried about. As you mentioned I believe browser-wise, Chrome is the only one using QUIC and its an experimental feature there that can be disabled. I also believe older routers with firewalls will have an issue with this protocol since they will block external UDP traffic on port 443. Link to comment Share on other sites More sharing options...
itman 1,659 Posted September 23, 2020 Share Posted September 23, 2020 (edited) 12 minutes ago, itman said: https://blog.apnic.net/2019/03/04/a-quick-look-at-quic/ As I see it a malware app would have to be installed on a device that uses the QUIC protocol. So in reality it is no different from a malware app using TCP. Bottom line - if no malware app is installed in the first place, their is nothing to be worried about. As you mentioned I believe browser-wise, Chrome is the only one using QUIC and its an experimental feature there that can be disabled. I also believe older routers with firewalls will have an issue with this protocol since they will block external incoming UDP traffic on port 443. Of note is the following: Quote For those clients and servers that do not support QUIC, or for network paths where UDP port 443 is not supported, the common fallback is TCP. This implies that the router must also support incoming QUIC traffic. Edited September 23, 2020 by itman Link to comment Share on other sites More sharing options...
pipes 4 Posted September 23, 2020 Author Share Posted September 23, 2020 When I was using Windows Firewall Control 10 (Sphinx) and Windscribe VPN, I would see Windscribe was trying to use QUIC UDP-443, Sphinx has the option of blocking QUIC in-out. Also of course, has the option regular TCP-UPD. Windscribe VPN did not like it at first but after a couple re-starts it was normal. Gave me a more secure feeling. QUIC can do pretty much what it wants to do behind the firewalls back since it is not recognized. I do like the option, wish ESET had it. Link to comment Share on other sites More sharing options...
itman 1,659 Posted September 23, 2020 Share Posted September 23, 2020 (edited) 1 hour ago, pipes said: I would see Windscribe was trying to use QUIC UDP-443, Creating an Eset firewall rule for WindscribeService.exe to block any inbound/outbound traffic for UDP port 443 should do the trick. On the other hand, I believe Eset's SSL/TLS protocol scanning is monitoring all inbound TCP/UDP traffic regardless of port used. Assumed here is QUIC traffic has to pass through the Windows Filtering Platform. The point to be determined is if Eset can decrypt QUIC packets. Edited September 23, 2020 by itman Link to comment Share on other sites More sharing options...
pipes 4 Posted September 24, 2020 Author Share Posted September 24, 2020 21 hours ago, itman said: Creating an Eset firewall rule for WindscribeService.exe to block any inbound/outbound traffic for UDP port 443 should do the trick. It needs UDP port 443. It will fall back to UDP port 443 when QUIC is blocked. It will use QUIC when a firewall does not recognize it, to me that's not good. 21 hours ago, itman said: The point to be determined is if Eset can decrypt QUIC packets. That is the million dollar question! Thanks.😉 Link to comment Share on other sites More sharing options...
itman 1,659 Posted September 24, 2020 Share Posted September 24, 2020 (edited) I did a bit more research QUIC. Appears a firewall rule to block any inbound UDP traffic from remote ports 80, 443 will shut it down completely. Created such an Eset firewall rule w/o any alerts to date. The port 80 inclusion is to block HTTP/3 traffic. Note that anything Google based appears to be using QUIC such as G-mail. Also wonder about new Edge browser since it is Chromium based. Also UDP is not a statefull protocol. As such, I don't see how this traffic can get through a statefull router firewall regardless of the NAT baloney it is doing. Edited September 24, 2020 by itman Link to comment Share on other sites More sharing options...
pipes 4 Posted September 24, 2020 Author Share Posted September 24, 2020 Thanks very much for your help! Link to comment Share on other sites More sharing options...
itman 1,659 Posted September 25, 2020 Share Posted September 25, 2020 BTW - I did verify that Edge Chromium does use QUIC. Opening it up, not "a peep" from the Eset UDP rule I added. This validates my previous assumption that this UDP traffic is being blocked by my router's firewall. Only Edge incoming traffic was TCP and I didn't observe any noticeable slowdown in Edge web page rendering. Link to comment Share on other sites More sharing options...
pipes 4 Posted September 26, 2020 Author Share Posted September 26, 2020 Really i don't use chrome for the reason. Just to show how WFC10 works, Link to comment Share on other sites More sharing options...
pipes 4 Posted September 26, 2020 Author Share Posted September 26, 2020 I know this is about ESET , but i wanted to show what i was talking about Link to comment Share on other sites More sharing options...
itman 1,659 Posted September 26, 2020 Share Posted September 26, 2020 1 hour ago, pipes said: Just to show how WFC10 works, Personally, I don't care about outbound QUIC Internet traffic. If any malware tried to connect that way, any of its corresponding UDP inbound traffic would be blocked as I noted previously. Also Eset's TLS/SSL protocol processing only examines inbound network traffic. Finally, I don't use a VPN. I do concede that QUIC traffic via a VPN could be problematic since a pinhole would have been created in the router firewall to allow that traffic through unimpeded. Therefore an Eset firewall rule will be needed to block that inbound traffic. Link to comment Share on other sites More sharing options...
itman 1,659 Posted September 27, 2020 Share Posted September 27, 2020 BTW - here's the full "nitty gritty" on QUIC: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?include_text=1 Also, this standard is not yet officially approved. Additionally, everything I have read about QUIC indicates that these security concern articles about it are unfounded. Link to comment Share on other sites More sharing options...
pipes 4 Posted September 27, 2020 Author Share Posted September 27, 2020 When i make an inbound block rule it will not connect to VPN (protocol any) what would you suggest short of not using a VPN? thanks Link to comment Share on other sites More sharing options...
pipes 4 Posted September 27, 2020 Author Share Posted September 27, 2020 when i make an inbound block rule it will not connect to VPN (protocol any) what would you suggest short of not using a VPN? thanks Sorry about the mess above. Link to comment Share on other sites More sharing options...
Recommended Posts