The impact on network security through encrypted protocols – QUIC
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.
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”
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.
One of the important changes is that the QUIC crypto protocol is planned to be replaced with TLS 1.3: