QUIC is a new protocol designed by Google to make the web faster and more efficient. It’s on by default in Google Chrome and used by a growing list of websites. Unfortunately, most, if not all, firewalls do not currently recognize QUIC traffic as ‘web’ traffic, therefore it is not inspected, logged or reported on, leaving a gaping hole in your network’s security.
This article describes how QUIC works, its current consequences on network security and reporting, and how you can resolve the issues associated with QUIC.
About QUIC
Google has always been obsessed with speed and over the years they have made numerous efforts to make the web more efficient and more performant. The new kid on the block for performance improvement is a protocol named QUIC. Where SPDY and HTTP/2 were iterative improvements on HTTP over TCP, QUIC is a different approach using UDP as the transport protocol.
QUIC is essentially HTTP/2 over UDP which is a new layer4 protocol.
At the time of writing this article, QUIC is still ‘experimental’, but is enabled by default in Google Chrome, and can be enabled in Opera 16. Other browsers will surely follow once the protocol is finalized. It is implemented on all Google web properties such as Google Search, YouTube, Gmail, Drive etc, and is being adopted by a growing list of other websites.
How QUIC Impacts Network Security
The issue is not with the protocol or the technology itself. The supposed upside of QUIC is that it makes web communications more efficient and faster. The problem is that it is not supported by security appliances such as firewalls yet, and has therefore inadvertently created a security hole for many organizations.
Most firewalls have extensive functionality when dealing with HTTP and HTTPS traffic. In most architectures, when HTTP traffic is detected, it is passed on to a web protection module that performs web filtering, deep packet inspection etc. HTTP traffic gets special treatment because the firewalls can interpret the traffic from Layer4 up to layer 7. This special treatment includes malware scanning and in most cases, enhanced reporting.
QUIC uses the traditional HTTP ports of 80 and 443 but that is where the similarities end. The supporting browsers and servers support this new protocol and are able to process it as web traffic, but the network device in between cannot determine the application protocol and switches to treating it like any generic layer 4 UDP traffic.
QUIC traffic is therefore not scrutinized as it should be and it is not forwarded to the firewall’s web protection features.
The images below compare the Wireshark capture of traditional HTTPS TLS traffic with QUIC.
The real world implications of QUIC traffic range from not being able to restrict access to YouTube or enforce Google Safe Search, through to malware or ransomware being downloaded through Gmail or any other QUIC enabled website.
To compound the issue, you will most likely not be aware of any problems since the logging and reporting engines tied to the web protection features are also affected.
To further complicate things, the standards have not been locked down yet and the protocol is frequently revised, which is a reason why firewalls have not yet caught up.
How QUIC Impacts Logging and Reporting
From a reporting perspective, this means you cannot log and report on the full URLs of QUIC traffic, such as Google Search or YouTube, meaning search term alerts, or viewing a list of YouTube videos watched is not possible when QUIC is enabled.
Since the different firewalls do not recognize QUIC traffic as web traffic, they typically only log the traffic in their firewall log as generic UDP traffic. This means that the rich logging data we expect from HTTP traffic is not generated, logged or sent out via syslog.
Here is an example of normal TCP web traffic being detected by the Sophos XG firewall module and being passed onto the web protection module. Note how the firewall log contains relatively little data compared to the Webfilter log that records details such as URL, site cetegory etc.
Here is an example of the same site being accessed using QUIC. The firewall logging is still there but the web logging is not. All of the rich logging information is gone.
Products such as Fastvue Reporter rely on the ability of the firewall to correctly identify and log the web traffic. If you have seen a recent decline in traffic to and from Google sites (including YouTube, Gmail, Drive etc) there is a high probability that your firewall is allowing QUIC.
Did you know: Fastvue Reporter produces clean, simple, web usage reports using log data from your UTM or firewall that you can confidently send to department managers and HR team. It also helps to to support IT and network security teams with managing bandwith, reducing IT workload and troubleshooting with ease thanks to live alerts, dashboards and scheduled reports.
Resolving the QUIC issue
The good news is that if QUIC communication does not work between a client and a server, the traffic will fall back to traditional HTTP/HTTPS over TCP, where it can be inspected, controlled, logged and reported on as usual.
At the time of writing, the advice from most firewall vendors is to block QUIC until support is officially added to their products. This recommended method will vary from firewall to firewall. Some firewalls allow QUIC by default while others block it by default, but all firewalls are able to allow or block it.
Common methods are to block either a defined QUIC protocol, QUIC application type, or create a firewall rule to block UDP on port 80 and 443. We suggest you seek guidance from your firewall manufacturer for recommended actions.
Here are some guides on blocking QUIC with some popular firewalls:
- How to Block QUIC with SonicWall
- How to Block QUIC with Sophos XG
- How to Block QUIC with Fortinet Fortigate
- How to Block QUIC with Palo Alto Networks
- How to Block QUIC with WatchGuard
Before you block UDP on port 443 consider the following. Using HTTP packets over UDP is not new or even unique to QUIC. OpenVPN which provides SSL VPN is capable of using either TCP or UDP as the transport. Have a look at the UDP users on the network and determine if it is safe to block all UDP traffic on port 443.
The Growing Use of QUIC
At the time of writing this article, QUIC is enabled by default when you use the Google Chrome browser, and you can enable QUIC in Opera 16. All the other major browsers do not yet support QUIC. But as Chrome currently claims 60% of the web browser market, this is not a point to ignore.
There was a time when only Google properties were implementing QUIC, such as Google Search, YouTube, Gmail and so on. However as it is an open protocol, it is now in use by a growing list of popular websites (such as meetup.com), as well a growing list of bad actors as they catch on to the fact that QUIC is a great way to effectively bypass malware scanners and content filters. So this point especially cannot be ignored!
How to check if you have QUIC
Depending on the configuration of your browser and firewall, you may be using QUIC without even knowing it. The simplest test to see if you QUIC is enabled in your environment is to use the Developer Tools native in the Chrome browser. Go to the Network tab, ensure you include the Protocol column, and then browse to any of the Google sites such as https://www.google.com
If you see items with the Protocol http/2+quic/39 then you are using QUIC.
You can also view active QUIC sessions by entering chrome://net-internals/#quic in your address bar. Alternatively, you can add a Chrome browser extension to indicate which pages are served by QUIC.
You can also disable QUIC in your browser, by going to entering chrome://flags in your address bar, and setting the Experimental QUIC protocol option to Disabled.
Are there downsides to disabling or blocking QUIC?
Despite everything above, QUIC is generally a good thing for the world as it makes web communications more efficient and faster between a browser and the server, and who doesn’t want their web pages to load faster, and to have less buffering when watching adorable puppy videos on YouTube?
However, the general consensus (at least for now) is that there is no noticeable difference for the average user when QUIC is enabled.
The websites will still work, so you might as well choose security over a tiny increase in performance.
Summary
To summarize, QUIC is a new protocol designed by Google to make the web faster and more efficient. It’s on by default in Google Chrome and used by a growing list of websites. Unfortunately, most, if not all, firewalls do not currently recognize QUIC traffic as ‘web’ traffic, therefore it is not inspected, logged or reported on, leaving a gaping hole in your network’s security.
Blocking QUIC at the firewall will force the browser and server to fall back to standard HTTP/HTTPS, allowing the traffic to be inspected, protected and reported on as usual.
Take the pain out of reporting on Web Usage and Network Traffic.
Now that you’re clued in on QUIC, why not make your life easier and setup Fastvue Reporter? Fastvue Reporter consumes syslog data from UTMs and Firewalls and produces clean, simple, web usage reports that you can confidently send to department managers and HR team. Automate reports and get the job of reporting on web usage off your desk and into the hands of people that need it. Take a look at the benefits and features available to IT and network security teams to fully understand the capabilities of Fastvue Reporter and how it can assist your business.
Great article, thanks very much. Did some testing on our network and it looks like QUIC is being blocked by our Barracuda NextGen Firewall by default. With QUIC enabled in Chrome, and visiting https://www.google.com, the Developer tool shows the connection using HTTPS and Net-Internas show no QUIC sessions. All good news!
Great article indeed – short addition: Consider using GPOs to block the QUIC traffic at its root and spare the firewall / network from processing the requests.
(Source: https://www.theitcave.com/post/527)
chrome://net-internals hence chrome://net-internals/#quic is no longer available in Google Chrome. You’ll get a page saying:
The net-internals events viewer and related functionality has been removed. Please use chrome://net-export to save netlogs and the external catapult netlog_viewer to view them. There are extensions (that I have not trialed) that are supposed to indicate if the connection is via HTTP2, SPDY, or QUIC, like https://chrome.google.com/webstore/search/spdy%20http2%20quic. Obviously those are only client-side tools where the user can see what protocol their web browser is using. Of course, the suggestion to use chrome://net-internals/#quic was also a client-side tool but is no longer available in Chrome.
>AHow QUIC Impacts Network Security
>The issue is not with the protocol or the technology itself. The supposed upside of QUIC is that it makes web communications more efficient and faster. The problem is that it is not supported by security appliances such as firewalls yet, and has therefore inadvertently created a security hole for many organizations.
It’s a sad excuse. I personally always use udp/443 on my VPN to escape mostly any neglected firewall just because so many idiots just open 443(both) for “https” and call it a day.
So the protocol was developed to make the web faster and more responsive, but because our firewall may not log it properly we should block it?
Why not go the whole way and issue quill pens and parchment?
Hey Gareth. Hopefully, firewall vendors get their heads around it and log the traffic properly soon. I’m not sure what the technical issues are, but I am sure there are plenty – which is why we haven’t seen any good solutions so far. Either way, you certainly don’t have to block it if the firewall logging issues don’t bother you. Personally, as someone that uses Gsuite all day, Google search and a decent amount of YouTube, I haven’t ‘noticed’ a measurable performance benefit, so blocking QUIC, at least for now, is fine with me.
Anti firewall or loging is a safe feature to me
Can anyone confirm, from my testing Quic is NOT enabled by default in Chrome?
replace your cheap firewall with PA!
Even Palo Alto recommends blocking QUIC: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC
PCNSE here with 12+ years experience with PA. It’s not just a firewall issue. I’d suggest getting in touch with your SE for additional information, but just switching to a PA won’t help. I personally block quic for my 100k global users on all my edge firewalls.
I I think it is not fair that others have control over my account or network. I feel like my privacy is being violated and I am not going to allow this
Hey Angela. This is only an issue in a corporate network where a company issued firewall or web gateway is protecting you from threats, viruses etc. For these devices to protect you from malware when visiting HTTPS website (most sites these days), then QUIC needs to be blocked so that their usual security features work correctly with a QUIC enabled server.
Interesting, applying network security practices from the 80s in this day and age really leads to interesting situations…
If by “security” you mean “crude web censoring”, then yes what you say sort of makes sense: bypassing that would require extra resources and knowledge casual users would generally not access. But I would prefer you call censoring by its name…
If you mean “security” as “making things harder for an attacker”, I’m laughing. If you mean “security” as “preventing attacks”, this is too much, my jaw is gonna fall and my ribs are hurting greatly from the laugh.
“Reporting” is correct, nothing to say there.
Hey Jake – by security, we mean the security features enabled by corporate firewalls, such as virus and malware scanning. It is easy for a bad actor to spin up a QUIC enabled HTTPS website, host malware on it and drive traffic towards it. As QUIC is still not interpreted as normal HTTPS traffic by most firewalls, it will bypass the security features responsible for scanning malware and sail straight through the corporate firewall. Blocking QUIC at the firewall simply lets this traffic fall back to normal HTTPS, allowing the security features of your corporate firewall to function correctly.