Refuting the need for cleartext

Today QUIC made it to the HackerNews headline, and in the comments I found links to “The hidden cost of QUIC and TOU”

The short version is that protocols that encrypt everything make debugging more difficult, and middleboxes can’t do their job anymore.

Let’s look into the details of these claims

The argument against encryption

The first big argument we find on the article about the hidden costs of encryption is that encrypting all the headers provide no benefits in privacy or security.

This is just plain wrong.

In TLS we can find the following problems in privacy and/or security that QUIC and Fenrir do not have:

SNI

The Service name indication, is a clear text field in TLS that lets the server know which service the user wants to connect to.

SSL did not have SNI support, and thus you are limited to one certificate per server. This means that you can not have a dedicated certificate per virtual host, but must either have one IP per virtual host, or a single certificate valid for all of your virtual hosts.
This was virtually impossible before letsencrypt, and unmanageable in any case.

By encrypting everything before the SNI is sent, we avoid a lot of user tracking, and therefore there is a big privacy gain. You can still try to infer the service being used by looking at the IP addresses, but once you pass through a proxy like Cloudflare all information is lost.

As far as I know this feature is unique to Fenrir. I am unsure if QUIC does something to hide the virtual host name, due to the simple usage of X.509 certificates it is probable it does nothing to hide it.

Connection resets

TLS is encrypted and authenticated, but what good does it do if anyone can spoof the TCP RST packet and drop the connection?

The requirements to do something like that for QUIC and Fenrir jump from “injecting the right packet” to “complete control of the network channel”

For one, injecting RST is a common method used by oppressive regimes to deny access to internet resources. Back when there was a big war against bittorrent some ISP spoofed TCP RST to throttle the users. This might still be true for a lot ISP worldwide.

This alone would make you want to (at the very least) authenticate your transport packets.

Alerts

TLS alerts and other data are in cleartext. This means that you can sniff and even cause errors like “Bad MAC”, “Decryption failed”, “Decompression failure” and others that can be (and have been) used as oracles for attacks.

Providing as many error messages as possible might seem useful at the beginning, but you also end up giving more information to the attacker. This information is only for the eyes of the endpoints of the connection, middleboxes should not be able to even look at those.

Both Fenrir and QUIC try to just drop packets silently to avoid giving information

Protocol feature negotiation

TCP is all cleartext, but today there is a big usage of the optional field to ask for more features that are not present in the older TCP implementation.

This can be a small privacy concern since just from those we can fingerprint what Operative System the user is running. It is speculated that many mobile operators use this method to understand if you are using your phone as an access point, and then they block you, or throttle you (for example because your data contract does explicitly forbids such usage). This was really common some time ago, might still be common in some countries.

Passive fingerprinting becomes much more difficult if the protocol is handled by the application, and even more if everything is encrypted.

The ambivalence towards middle boxes

The author seems ambivalent towards middleboxes. First he says that you want firewalls to inspect your traffic, then it agrees on the broken state of many middleboxes on the internet the keep causing problems due to bad implementations (or worse, due to misconfiguration I might add).

He also remembers the end-to-end principle of the internet: everything is a dump pipe, just push packets towards the destination, and do nothing.

I will also point out that by hiding as much information as possible, we are further forcing net neutrality, which is a positive thing for all of us.

But the author then links to a presentation that describes why and how much middleboxes are broken, and downplays it, saying the 20% failure recorded there is the failure of negotiation of an option, not a connection failure. Then points at the 8% connection failure of QUIC as a big number.

This is a bad analysis, since we are putting together the tests dome for the implementation of one TCP option against all the connection received by google. The author does not mention where the 8% comes from or how the connection drop was identified, so I am unable to check any of that. Even the timing of those anlysis are years apart.

The numbers still say that middleboxes still drop too much traffic, they are breaking the end-to-end principle of the internet. The solution therefore is to keep the broken things?

Personally I think that a big part of the dropped connection rate comes from big retarded organizations like some French universities, that drop any and all traffic that is not TCP, while intercepting DNS to keep things working. I have no hard numbers, however.

IMHO, that is not an acceptable behavior, developers get limited, and you break core assumptions of the network, and that offers absolutely no improvement in security while actively undermining any privacy consideration.

If QUIC (and later Fenrir I hope) are what it takes to make those middleboxes disappear, than I am only happier about that. They are breaking the rules. Why do I have to wear chains?

Debugging

Finally we get to the only argument the makes sense: Encryption makes debugging more difficult.

That is a tradeoff that I am personally willing to make, but maybe it’s just because I don’t have to diagnose many network failures.

Even then, many examples of the author have nothing to do with encryption, since they are about checking things while having complete access to both endpoints.

In this case the problem is not having encrypted traffic or not, but having proper debugging tools. On this note, I’ll try to remember to include a feature to get a cleartext dump of all packets in Fenrir (or you can remind me by pointing to this article ;p )

For advanced tool usage we can implement plugins that share the decryption keys between Wireshark nodes if this is so important, but this is a tool problem. QUIC is a new protocol (and Fenrir is even newer). It is no surprise that tools need to catch up.

Also, if we are forced to throw away the broken middle boxes, wouldn’t that mean that we also indirectly resolve a lot of other problems? I don’t see anyone throwing away middleboxes -even troublesome ones- without something big like QUIC (and hopefully Fenrir), and taking the middleboxes out of the equation would effectively simplify debugging.

So hopefully this is just a short-term vs long-term discussion.

-Luker