Trust No One: Eliminating Trust in Tarnished Tale

Surely, you can’t be about to suggest it’s possible to eliminate trust in Online Gaming?

Don’t call me Shirley.

Not only is this possible, but it’s essential! The more the server trusts the client (or peers trust peers in p2p multiplayer games), the more a damage a malicious client/peer can do. Moreover, if a client spends too much time trusting the server, the more damage that can be done that way too.

Eliminating trust in a centralized-server TARPG like Tarnished Tale comes in a few different flavours. Ultimately some level of trust is required for the program to work, but we’re going to minimize it as much as possible. I’ve split the article up into two broad categories with subsections for ease of browsing.

Eliminating Trust of Clients

The client is the primary vehicle by which players and admins are intended to access the network. Someone talented could no doubt send packets directly to a TT instance’s TCP/IP listening port (default 5050), but most people are going to be using some version of a client, standalone or in-browser. Therefore, it’s important to balance the level of trust of the client observed by the server.

Strict Hosted Client Mode

In much the same way that the admin functions can be locked down such that only a admin_term instance running on the same machine as the server (as observed by the server machine’s network stack), server operators are intended to gain access to a configuration option that would force players attempting to access it to use only the version of the client hosted by that TT instance.

This would likely be done by cryptographically verifying the client during connection establishment, but the function itself is in the proposal stage and no exact method is yet defined.

In many ways the game is inherently designed so that the exact client used does not matter for game fairness, but forcing the use of the hosted client could help mitigate cheating involving input automation if the client itself was designed correctly.

Viewing the Server as Dungeon Master

If we approach the design of Tarnished Tale as being in a similar paradigm to a pen-and-paper RPG, it’s not unreasonable to think of the server as the Dungeon Master, a sort of super-player responsible for adjudication.

This is actally a mitigation inherant to all games I’m aware of - if the server, and the server alone - is responsbile for reporting and modifying game state, there’s little that can be done from the player-side to unfairly impact the outcome. Tarnished Tale therefore uses this model. Everything, from player position to random number generation, is done by the server. Clients don’t even store authentication state - authentication is currently managed by monitoring which user is authenticated to which one-per-connection socket object is authenticated to which account.

In that one specific case that could introduce some problems if a player’s IP is suddenly rotated (if they are part of an ISP that uses random IP dynamism), but this method also eliminates the problem of cookie theft, where one actor could steal another player’s session through a compromise of their browser.

Players as Threat Actors

Ultimately, all decisions about client design and which actions can be taken by clients, or which information can be safely provided to clients, needs to be informed by the idea that from the perspective of both the Server and other Players, the main threat actor is the player base itself.

Consider a scenario in which Alice, Bob, and Mallory had formed a player alliance and were instancing together. Bob, the party healer, drops many potatoes. The party wipes hard, several pieces of highly rare gear are destroyed as a result, and the argument that follows is highly acrimonious. Mallory, being the prick they are, wants to punish Bob for being an idiot. If Malory can gain the right sort of information from the server, they could harass Bob, mail them some unpleasant material, or, in this day and age, arrange a SWATting.

Some of that threat is mitigated by the current design of Tarnished Tale - great care is being taken not to store non-ephemeral identifying information about players. The server database doesn’t even collect emails. The rest is managed by using strict injection prevention to avoid what little data the server does maintain from being exposed to anyone but itself. Even someone with admin rights can’t use ATERM_MSG commands to display something as simple as a user’s IP - that sort of thing would require a compromise of the machine hosting the server process to retrieve a very particular logfile.

Eliminating Trust of the Server

Of course, the server can be malicious in and of itself - either by design or because it was previously compromised. For that reason, the Client has good reason not to trust the Server, either.

Client-Side Sanitization

The server, like any good server, already cleans up inputs from the clients, just to prevent injection attacks and other misuse. But in a minimum-trust model, the client shouldn’t trust this work to the server. Therefore, the client design should be such that if at all possible it also performs input sanitization against messages from the server.

Here’s the threat: Mallory is sitting on a browser or Javascript exploit that she can use to steal data from other users - perhaps some form of Cross Site Scripting attack. She includes the exploit code in her character’s description. Without client-side sanitization, if Mallory is also able to bypass the sanitation on the server (or some undertested patch breaks it), anyone who looks at her character would be exposed to the malicious javascript.

It’s not just script, either. The Websockets link between server and client can pass all manner of data, including files.

For that reason, it’s important the client should be at least secure enough to block the lion’s share of it. We shouldn’t be complacent and simply rely on the browser or on JavaScript (or any other framework) to be secure for us.

Certificate Pinning

When a player connects to Tarnished Tale using the web client, there are actually two connections in play: the websockets link between the client’s chat framework and the server, and an HTTP/S link between the browser and the accompanying web server.

In Chrome, these links are required to have the same SSL/TLS certificate associated with them. It’s been a while since I tested but I am fairly certain the same is true of other web browsers.

This solved a problem that would have been harder to solve if it weren’t already the case. Where the web client is pure javascript (react in the case of the under-development GenII client), it was semi-vulnerable to cross-site-scripting. It was possible to imagine an attack in which some malicious user corrupted the somettgame.net client to point at maliciouscollector.net’s instance of TT. This could even be covered up by instead pointing at some sort of relay server. It exposed player credentials to passive phishing!

With this sort of informal certificate pinning, however, those wishing to steal player credentials are instead limited to more obvious phishing/social-engineering attacks.

Of course, Tarnished Tale’s final release version will limit the effectiveness of phishing attacks by allowing for a 2FA arrangement, most likely via either U2F or OATH, or possibly both.

Open Source Requirement

A key licensing requirement of the TT platform is that software derived from it is open source. That includes server code. This provides players of a technical bent to audit the server code at their leisure and ensure it is, in fact, playing fair.

Eliminating Trust in the Network

Always remember: The Internet is a Malicious Network!

Radiative Network Architecture

While it may be desirable for some applications, TT does not include a Peer to Peer functionality in its model. While it’s possible, and indeed likely, to host TT on so light a machine that it could be concievably a part of someone’s home network, the only connections established in the game move between one player and the server.

This means that no player, at any time, ever has a direct connection to any other player’s network. No player is able to identify or locate another player based on their network parameters (IP and so on), because no player has access to that information.

Of course, that does provide one concern - direct messages between players are not truly secret as they first pass through the server. At no point is it intended for the server itself to have any kind of chat logging, least of all logging of direct messages.

However, if secret messaging is a concern for you, I might suggest not conversing via a video game.

The Internet is a Malicious Network

Yes, yes it is! This is less a concern than you might otherwise think, however! For testing purposes, it was made possible to disable TLS via the admin config file. However, this is strongly inadvisable to do this in deployment. SSL is a big part of the security model of the program. It protects against even two players on the same network sniffing each other’s passwords or other traffic.

I hope you liked this brief conversation about trust elimination, which has been an area of interest of mine for some time. It’s come up before for my other big project, Tapestry. If you liked this article, or some of my other content, I would appreciate it if you stopped by my ko-fi.com account and threw a tip in the coffee can.