As you may or may not know, the internet is an absolute no man’s land. A wilderness where you can do anything you please. It is like a Finnish tourist getting drunk in Tallinn. Or any tourist visiting Las Vegas, as I have heard.
I am, of course, talking about protocol violations.
I mean, you have a very specific set of rules which to follow, called RFC’s. They specify what you can and cannot do. Follow the RFC, and you shall find salvation.
Unfortunately, that is not exactly the case. Just like people, each implementation of a protocol is a unique snowflake. The biggest reason for this unfortunate state of affairs is often considered to be this little paragraph in RFC 760, written in 1980, which specifies the Internet Protocol:
In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.
Postel, Jon, “Internet Protocol”, RFC 760, 1980
This is often referred to as Postel’s Law or the Robustness Principle. In principle, by stating that all implementations should be accepting of traffic which does not exactly follow the protocol specification, it gives a free pass to all the lazy people who do not care to check that their code produces valid output. As long as it is accepted by the recipient, what does it matter?
The thing is, from a security researcher’s perspective, it is not always clear whether that “invalid protocol field” is a byproduct of a lazy implementation or an attempt to exploit a vulnerability in the receiving software. On one hand, you cannot block legitimate traffic. But on the other hand, you cannot let traffic through that could potentially compromise the recipient’s machine. You are forced to try and find your balance on the thin edge between the two.
So, to vent my frustration, let me present to you four examples of moronic protocol violations by legitimate software, observed in my home network within the past week. I bet the developers of these software components leave their computers unlocked when they leave the room and use “admin / admin” as their default username / password.
Content conflict
In this first example of gross negligence, we have the Steam gaming platform. I have been playing Witcher 3, and happened to make a quick-save. The game wishes to upload a small image of the point in time where my game was during the quick-save. Fair enough… But what is this – instead of a legitimate “Content-type: image/png”, Steam decides to claim that this image file is a HTML file! What kind of anarchy is this?! It is like saying “yeah, here is your pizza” and giving them an apple.
TCP SYN Options conflict
The next one baffles me. I can guarantee you that I would not use Edge voluntarily, so this one is Windows doing its magic on the background. We can see that Edge is making a TCP connection to a legitimate Microsoft IP, to the HTTPS port 443. However, we can see that the SYN-ACK packet sent by the server used different options than the original SYN packet sent by the client. Honestly, I understand that you own the client and you own the server so it is a wild wild west of endless possibilities – but come on, you cannot even agree on the TCP options?! It is like you and your mate have a secret handshake, but each of you uses a different one!
SNI Mismatch
This one is another success for Microsoft, Cortana this time. Again, this one happened in the background. Cortana initiates a TLS connection to a legitimate Microsoft IP, using the domain name “exo-ring.msedge.net”. But what do you know – the certificate for this server has nothing to do with exo-ring.msedge.net, instead it lists these domains as legitimate domain names:
Again, I understand that you own both the client and the server, and thus have no need to behave like a protocol-abiding software component. But would it be too difficult to try even a little bit? When you go to a conference, do you deal out other people’s business cards as your own?!
Request timeout for HTTP 1.0
The last one is another great example of absolute defiance for any rules. I imagine that the developer of this server software walks directly to the counter at a store and demands immediate service instead of standing in the queue. They use the bus lane when they drive a regular passenger car. They throw their trash on the ground instead of the trash can that is right next to them.
The Chrome browser has opened a TLS connection to a server, but after the TLS connection has been established, the client has not sent any data. At a certain point, the server gets bored and wants to close the unused connection to free up room for someone with actual needs. So they decide to send a “408 Request Timeout” reply to the client. But what do we see here?! They use HTTP/1.0 as the version! “408 Request Timeout” is only a valid response code in version 1.1! That is a bit like saying that your favorite character in The Fellowship of the Ring is Éowyn. Yeah, she is cool, but she is not introduced until in The Two Towers!
—
In all seriousness, I know that the developers are often under massive time pressure, do not have enough resources, or may be inexperienced. It is not really the developer of the broken software component who is at fault here – my finger of blame points at the robustness principle.
I am not the fist person to criticise the robustness principle. In this internet draft, Martin Thomson recommends that the robustness principle can and should be avoided in any actively maintained protocol. And in this paper the researchers Florentin Rochet and Olivier Pereira present a method which exploits the robustness principle to compromise the anonymity of the Tor network. The robustness principle is also a big reason why evasions exist and are so powerful.
Getting rid of the robustness principle altogether is, in my book, a worthy objective.
Thank you again for reading, and see you next time!
Nygetin Paikka | The Place of the Nygetti 