Security and speed going hand in hand with QUIC

"Security and speed does not go hand in hand".

If you also think so, you have to explore QUIC (Quick UDP Internet Connection), a "new" transport protocol for the internet communication.

At many places, I read that QUIC is also considered as HTTP3 (or Google's QUIC). So for this read may also be applicable for HTTP3

Problems with TCP + TLS

Imagine you are king of ancient times and you have hired human "messengers" to send and recieve messages, and you want a friend, who stays in different city, to answer a secret question.

Would you ask the messenger to

1. First make couple of round trips to make sure your friend and you both are alive?
2. Then another couple of round trips to exchange the idea about encrypting message and then exchanging actual encryption key as well?
3. Then another round trip to exchange encrypted question and encrypted answer?

Damn, don't you think its gonna take so long with soooooo many round trips?

Yes, thats exactly what happens with standard TCP + TLS.

Below picture will give better understanding.

Another problem with TCP +TLS is connection drop when you switch from wifi to mobile network. Oh i do understand those few seconds of "Why God..!"

How is that so fast?

QUIC handshakes requires zero or one handshake before sending the actual payload, compared to 3 round trips for standard TCP + TLS. For subsequent connections, client can use the cached credentials from the previous connection to immediately send encrypted requests to the server.

Second reason, IMO, why is so fast is because of, no kernel involvement. Yes QUIC implementation lives in userspace, so not much back and forth from user-kernel space, hence fast. Tribute to the coders of QUIC to re-write some of kernel logic.

How is that secure too?

Well QUIC uses TLS too, so it brings authentication and encryption right from transport protocol itself, Which provides authentication of the end-points as well as negotiation of cryptographic parameters. However QUIC replaces the TLS record layer with its own framing format

By the way, QUIC also has its own QUIC Crypto design (https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit)

But later it leveraged TLS 1.3 only

Any bonus points?

Of course, because of ground up design, it has many bonus points.

• Connection migration: QUIC connections are identified by a 64 bit connection ID, randomly generated by the client. This means that if a client changes IP addresses (Above "Why God..!" hahaha) or ports (if a NAT box loses and rebinds the port association). It can continue to use the old connection ID from the new IP address without interrupting any in-flight requests
• Improved congestion control: because of pluggable congestion control, it provides provides richer information for congestion. For example, each packet, both original and retransmitted, carries a new sequence number. Hence distinguished ACKs.
• Multiplexing without head-of-line blocking and Compression: its based on HTTP2, so yeah. It can multiplex different HTTP requests onto the same TCP connection. This allows HTTP/2 applications to process requests concurrently and better utilize the network bandwidth available to them. Also compression advantage is coming form HTTP/2 only.
• Forward error correction: since its based on UDP, it can recover from lost packets without waiting for a retransmission, and only the part that was lost

There must be some cons

1. Firewall and Hops : The main bottlenecks are hops (eg routers, firewall, loadbalancers etc) which might drop or does not handle the packets of UDP correctly, if port is 443. (Yes QUIC uses same 443 port)
2. Deflecting Reflection: UDP has been taken as point of target. For example, attacker tricks an otherwise innocent server into sending large amounts of data to a third-party victim, by spoofing the source IP address of packets targeted to the server to make them look like they came from the victim. https://blog.cloudflare.com/reflections-on-reflections
3. Existing hardware and software: deployed in the wild not being able to understand it

What should i do?

Google and chrome already have implemented and using these in our day to day browsing of google services. However they fallback to TCP if intermediate hops create blockers.

As a developer, Learn https://www.chromium.org/quic/playing-with-quic to implment next set of services in QUIC and let your users enjoy security as well as speed.

Hope you got some new things to read

Thank you for reading my write up, that i concluded from below refs

https://blog.cloudflare.com/the-road-to-quic/

https://www.chromium.org/quic