Google QUIC Protocol & How to block in Palo Alto

Google QUIC is a new protocol which is designed to make the web faster, QUIC stands for Quick UDP Internet Connection, commonly used in streaming media, VoIP services and gaming. This protocol is activated by default in Google Chrome and it’s also growing by a list of websites who have implemented this protocol. But why do we want to block this protocol in our firewalls? Most of the firewalls do not fully support or recognize QUIC traffic properly as “web traffic”, therefore it can’t log, report or inspect the traffic which is leaving us with a gap in our network’s security. I will cover a bit about QUIC and how you can secure your network by using Palo Alto Networks to block Google’s QUIC protocol.

Everyone probably knows that Google always want to chase speed, make the web more efficient and faster every year. The different between QUIC and SPDY & HTTP/2 is that HTTP/2 using HTTP over TCP when QUIC uses a different approach with UDP as the transport protocol. Basically HTTP/2 over UPD and since late 2018 the QUIC working group decided to call the HTTP mapping over QUIC “HTTP/3” to try advance in making it a worldwide standard.

SPDY is a deprecated open-source transmission protocol that was developed primarily at Google’s Chromium group for transporting web content with particular goals of reducing load latency and improving web security.

Why and how does QUIC impact our network security

There is no issue with the protocol itself, it’s making the web communication more efficient but the problem is as I stated before it’s not fully supported by all firewalls or other security appliances yet.

Your firewall probably has all the extensive functionality to deal with HTTP/HTTPS traffic. HTTP traffic is detected then it goes through web filtering and deep packet inspection etc. Firewalls can interpret HTTP from layer4 up to layer7 which will give the HTTP traffic some special treatments such as malware scanning for example.

QUIC protocol also uses the regular HTTP port of 80 & 443 but this is the only similarities. Server and browsers that is supporting QUIC does not have any problem to process it as web traffic meanwhile our security appliances in between will have a hard time to determine the application protocol and switches to treat the traffic as any generic layer4 UDP therefore QUIC traffic will not be handled as it should neither is it forwarded to the appliances web protection features.

The actual problem implications of QUIC traffic is that we are not able to restrict access to sites like Facebook, YouTube or enforce Google Search to be safe, through to virus or ransomware being downloaded through any other QUIC enabled website. So you will likely not be aware of any issues in your network because of the logging and reporting engines tied to the web protection features are not in effect at all.

Check if QUIC is active in your browser

The simplest way to test if QUIC is enabled in your network environment is to start the Developer Tool in your Google Chrome browser (F12 or Ctrl+Shift+J), go to network tab and add Protocol column, check disabled cache box and fire away browsing to https://google.com to check.

 

Google’s QUIC protocol blocked

Google’s QUIC protocol enabled

Blocking QUIC using Palo Alto Networks

With QUIC traffic getting blocked, the Chrome browser will automatic fall back on using traditional TLS/SSL. This will not affect you user to lose any kind of functionality on their browser.

  • Start with creating two services for QUIC with protocol UDP and destination port 443 & 80.
    • Objects > Services > Add
  • Create two policies, one for blocking the services and one to block the application.
    • Policies > Security > Add
Palo Alto

Add services for QUIC UPD port 443 & 80

Palo Alto

Create policies for services and application to block QUIC protocol

Remember to always check in your network environment before if it’s safe to block UDP on port 443.

 

 

More information about how to block QUIC can be found on Palo Alto Networks

If you have any question, feel free to email me at jimmy.dao@xenit.se or comment down below.

Disclaimer: All information on this blog is offered "as is" with no warranty. It is strongly recommended that you verify all information and validate all scripts in isolated test environments before using them in production environments.