I have already written about two secure protocols that are impacting our network security.
The first was HTTP/2, the second one was TLS 1.3. Both posts can be found here:
Today I want to talk about another very important protocol, it is called QUIC.
QUIC stands for QUICK UDP INTERNET CONNECTIONS. It is an experimental protocol designed and deployed by Google. When you look at the existing protocols, we already optimized the application layer through HTTP/2 and the encryption layer through TLS 1.3. So the only thing that is now causing still delay is TCP.
Figure 1: Structure of QUIC
QUIC is built on UDP instead of TCP. The port it is using is UDP/443. And it also combines several features with HTTP/2.
HTTP/2 features such as connection multiplexing, stream prioritization or connection sharing across domains are features that QUIC is leveraging from HTTP/2.
Some other important features of QUIC:
- 1-RTT connection handshake
- 0-RTT re-established connections
- Connections survive IP address change
- Always encrypted and authenticated
- Loss Recovery
- Includes RTT Information in the packet
- Retransmits on frames, not on per packet basis
- FEC (Forward Error Correction) data recovery
The QUIC protocol tries to significantly reduce the number of round trips that are required to establish a connection. QUIC is not only using a 1-RTT handshake but can also use a 0-RTT session resumption. Connections are able to survive IP address changes, something that is making everyone in the mobile service provider space very happy. Think of roaming users.
And QUIC is always encrypted and authenticated. There is no cleartext version of QUIC.
Tests with QUIC have resulted in an improvement of 30% with regards to retransmission on sites like “youtube.com”.
The last point in this list is FEC.It is similar to a RAID system for the network. Imagine to transmit some info in addition to the payload to enable you to recreate packets that have been lost on the wire. Sounds useful but was not worth the overhead when tested in real life environments.
So where is QUIC used? As it is an experimental protocol by google, it is today used by a lot of google websites such as gmail.com, youtube.com, etc. Also the Chrome browser has QUIC built in and enabled.
You can check this on your own if you are using the Chrome browser:
Go to your Chrome browser and type “chrome://net-internals/#quic” in the toolbar. Then, open a second tab and browse to youtube.com, gmail.com and other google sites. If you are not behind a firewall that is blocking UDP/443, then some QUIC sessions might turn up.
Chrome is trying QUIC with a lot of sites and remembering, whether it was successful or not.
When connecting to a website, the server can send an “alt-svc” (=alternate service) header to the client, telling him to switch to QUIC.
You can see it on “chrome://net-internals/#alt-svc”
Figure 2: Mapping of QUIC Service to websites
QUIC is currently using a proprietary encryption and authentication protocol. But the IETF has picked up QUIC and is working on a standardized version of QUIC.
https://datatracker.ietf.org/wg/quic/documents/
One of the important changes is that the QUIC crypto protocol is planned to be replaced with TLS 1.3:
Figure 3: IETF QUIC working group , QUIC & TLS 1.3
Impact on your Security Gateway:
Your gateway currently might not understand QUIC. In addition, QUIC currently is not really able to be decrypted in the network. So, if your firewall is allowing UDP/443, there is not much it can inspect in the QUIC sessions. It might not even recognize it is dealing with QUIC as a protocol and just wonder where all those UDP packets come from….
If your gateway is blocking udp/443, Chrome will silently fall back to TCP. So there won’t be a user impact.
Just blocking udp/443 is for sure not a final solution. Gateways are and will be even more confronted with new and encrypted protocols in the present and near future. If we do not deploy an architecture that is capable to understand those protocols and deal with the overwhelming amount of encryption in the network, the security gateway on its own will go more and more blind.
If you want to learn more, I will be talking at CiscoLive! Barcelona in 2018, Breakout BRKSEC-3015.
Further links on QUIC:
https://datatracker.ietf.org/meeting/98/materials/slides-98-edu-sessf-quic-tutorial/
As always, a great summary on this topic. Keep your blog-posts coming, Tobias!
Since Cisco has several security gateways in their portfolio, is there a listing as to which ones can recognize and/or inspect QUIC?
Hi Ethan, to my knowledge, Firepower and Meraki MX can at least detect that QUIC is flowing. if UDP 443 is open. But currently I am not aware that any gateway on the market is providing a proxy for QUIC nor able to decrypt.
Tobias, Thank you, hopefully that is on the horizon as that seems to be a blind spot that should be addressed
What a fantastic post! This is comprehensive and helpful Post. Keep your blog-posts coming! – Adriel