Version Assertion Aversion

Should a Mastodon site disclose to its visitors the version number of the software it is running?

The version number of software is used as a shorthand to quickly document the revision level of that software. We all like to be able to find out the version numbers of the software we use.

However, it's less clear-cut to me if it's a good idea to always disclose the version numbers of the software that runs internet-facing systems.

I recently suggested a feature that would make it easy for people who use the "Mastodon" microblogging software to hide its version number, and I was surprised that this idea received negative feedback.

I've been somewhat obsessed about this for the past couple of days, so I've written my first ever blog post to try and clarify my thoughts on the matter (and to ask you what you think).

I'll just add upfront that I'm not aware of any historical security incidents associated with specific version numbers of Mastodon, I haven't looked. Mea culpa. But as a long-time sysadmin, I'm familiar with web software often containing security vulnerabilities, which are fixed in later versions. I'd be surprised if this doesn't also happen with Mastodon.

Programmers love version numbers

I think the top reasons for this are:

• They help us when we are troubleshooting problems. We aren't all experts on every piece of software we use, and shouldn't necessarily be expected to understand and fix every bug we encounter. It is responsible to report problems we encounter, and it's really helpful if part of that report can include a version number
• For more technical users, especially where software is open-source, we want version numbers. We use them to know if we are affected by bugs (found in old versions and fixed in later ones) and to know if we have features that are only present in newer versions.

If everything is working fine, then I shouldn't need to know the specific version number of the software that I'm using. What I might want to know is the protocol version or API version, which is a subtly different thing.

Hacker's delight

A few days ago, I was pretty certain that you would simply never want to tell anyone the version number of the software that you are running on your website.

The reason is that telling the internet what version number of software you are running is like painting a target on your back. There are often security vulnerabilities in old versions of code, and these vulnerabilities are often (well, pretty much always) known before all the running instances of the code "in the wild" are fixed. So, a person (or script, agent, etc) who wished to hack a website could just do a web search for the version number of the vulnerable software, and attack any site which reported it was running that.

By not handing out the version number like candy, you are removing yourself from the pool of "easy marks", and might hope to achieve a little more security in doing so. Even if this is just postponing the inevitable. Yes, your site will eventually be hacked, but it won't be explicitly targetted because of its version number.

This approach (when used as the main method of providing security) is called "security by obscurity" and is almost universally considered to be suboptimal. However, it's also hard to argue that keeping your version number secret doesn't marginally improve your overall security posture, and it's easy to do, so it could reasonably be a part of a "defence in depth" security strategy.

You may well consider this to be such a marginal effect that it isn't worth thinking about, and any hand wringing about it is "security theatre".

Or you might try and take a very hardcore position, where you immediately take down your website when a new version is publicly released, until you've had a chance to update its code. Even if you were to do this, you are not safe in disclosing your version number. There is still a window of time in which your site is vulnerable because people may know about security vulnerabilities before updated software that fixes them is released.

Protocol version, or software version?

In distributed systems, protocols are used to communicate between system components. It's easy to conflate the software version number with the protocol version number, especially if (for example):

• There is only one piece of software that implements the protocol
• The protocol is poorly defined
• The protocol is unstable (i.e. it is subject to change)

In cases like this, you might require all participants in a distributed system to run the same version number of the software in order for the system to work.

However, in principle, if a protocol is well-defined and stable, then it should be possible for software to implement a specific version of the protocol and communicate with other pieces of software that implement the same protocol. This is the approach traditionally taken with the IETF's "RFC" documents for defining internet standards, for example, and seems to work quite well.

The underlying protocol currently used by Mastodon is (currently) a partial implementation of ActivityPub.

I chose my words carefully when I said, "a (partial) implementation of". Here's a comparison of the feature sets of different ActivityPub implementations:

https://activitypub.rocks/implementation-report/

The definition of the ActivityPub protocol allows a large amount of "wiggle room" in how features are implemented. The wiggle room is so great that it would surprise me if any random ActivityPub implementation, just following the W3C protocol recommendation document, worked with another such implementation. Dennis Schubert summed up my feelings on this very well here:

https://overengineer.dev/blog/2019/01/13/activitypub-final-thoughts-one-year-later.html

But Mastodon works, right?

Some people (including me!) would rather talk about "the Fediverse" than Mastodon. I've been asked, perhaps not unreasonably, what software I use to communicate with other users of the microblogging network in which I participate. For example, there's an allegedly compatible stack called "Plemora" which looks kind of cool.

But it would be disingenuous to suggest that Mastodon was not responsible for the recent (late 2022) massive growth of the Fediverse. The explosion of Fediverse users in the last couple of months has almost exclusively been driven by an exodus of Twitter users to Mastodon. People want something exactly like Twitter, but don't want to be on Twitter, and Mastodon meets that need.

Currently, I feel like the only possible response to this, as someone wanting to implement compatible software, is to kowtow to the whims of the Mastodon developers (however well-intentioned, or otherwise, they may be) and try and "follow the leader" as they modify their protocol implementation. Network effects mean that Mastodon has won, and other Fediverse microblogging implementations are all just playing in their paddling pool.

The result is that there is a de facto "shadow protocol" which looks quite similar to "whatever the current version of mastodon implements". Let's call it Mastodon-ActivityPub. This has really unpleasant implications for the future of the Fediverse, namely:

• If you want to participate in the largest open microblogging network, you must implement Mastodon-ActivityPub.
• Mastodon-ActivityPub is defined by the behaviour of the Mastodon source tree, right now.
• Mastodon-ActivityPub is not otherwise defined and may change unexpectedly.
• Mastodon developers have no inherent interest in standardising their own protocol. Doing so would make them win less. It would take time that they could otherwise use to win more, or watch TV. It would force them to be "less agile", because every time they wanted to implement a new protocol-level feature they'd need to update the protocol specification, and so on.
• There is now a walled garden. People running the latest Mastodon are "inside the wall". People running other ActivityPub implementations outside. You can briefly get "inside the wall" in-between Mastodon releases, if you track Mastodon development and quickly reimplement anything they add in your own Mastodon-ActivityPub implementation.

I dislike this, and would be interested in any effort to standardise, or at least stabilise, the Mastodon-ActivityPub protocol.

Back to version numbers

So version numbers have become a shorthand for protocol version. If you know the version number of the software, you have a solid chance of being able to communicate with it. If you don't, all bets are off.

Or are they?

Plemora "works with Mastodon", so there is at least one, currently under-defined, "other protocol" at work here, which could be expressed as the shared set of features supported by both these platforms. Perhaps there are other ActivityPub implementations that also interoperate correctly. The invisible hand of the Fediverse itself has written a microblogging protocol based on ActivityPub, but not yet documented it.

We could call that other protocol ActivityPub-Microblog.

It seems to me like it would be a good idea for anyone interested in developing microblogging software for the Fediverse to put some effort into documenting that, and sticking a big ActivityPub-Microblog Protocol Version 1.0 number on it.

Meanwhile, back in the real world, there's one obvious approach that people are trying to use to help understand the supported protocol: tell everyone what version you are running.

Version publicity

Some people advocate that all Mastodon instances must disclose their version number (as far as I can tell, I'm the first person to suggest anywhere that they shouldn't).

By default, Mastodon puts your version number in a public website that anyone can view, as well as in the public API that is used for machine communication.

There have been claims that this version number can be used:

• To guarantee compatibility
• To avoid communicating with instances running insecure software, or as a metric for whether an instance is trustworthy.

These are somewhat related, but worth addressing individually.

Observing your version number helps me ensure compatibility?

Let's get one thing out of the way immediately. There's currently nothing that guarantees "the version number that my Mastodon instance is telling you is true". In fact, right now, I can tell you it 100% isn't true because I hacked it to be something ludicrous and totally made up. We'll come back to this, but just be aware for now that you can't trust the version number that a site tells you.

The result is that if you think that you can do stuff to my Mastodon instance based on my version number, you might be wrong. But this shouldn't be news to you, because this is a distributed system that lives on the internet. In general, you should be expecting actions that you take to fail in strange ways, and you should be able to handle that gracefully.

If you don't fail gracefully when you try to do things, and they don't work, that's a bit rubbish, and is your fault, not mine.

If your third-party system implements one of the latest features of Mastodon, I don't mind not having that feature, and would expect that feature to fail gracefully when used against an instance that doesn't support it (e.g. a Plemora instance).

If your third-party system is "just broken" because it only supports the latest Mastodon-ActivityPub protocol, and in doing so, that means it does not support ActivityPub-Microblog, then the worst has happened. Mastodon developers have upgraded their walled garden to kick out second-class citizens who are not running Mastodon. If that happens regularly, I'd hope that the community begins to scrutinise the behaviour of Mastodon developers more closely, and perhaps becomes more focussed on writing that ActivityPub-Microblog specification document I asked for.

(but, all that said, how else do I know how to communicate with you?)

Observing your version number helps me improve security?

Maybe.

This is probably the most interesting issue here, to me, and is the main reason I originally started writing this post.

First, does it tell you that my site is secure because it is reporting that it is running the latest version of the Mastodon software? I hope that everyone knows the answer here is "No!" because we can easily report a fake version number. If the software informs you that it is running the "current" version number, that must not be used to assert anything about the software that is reporting that version number.

Second, does it tell you that my site is insecure because it is reporting something other than the current version number? You might immediately think that the answer to this is "how could it?" because we've established that the version number has nothing to do with what is running on the site.

However, if I visit a website that looks like it is running Mastodon, and I see it states that it is running an old (known-vulnerable) version of Mastodon, I could reasonably expect that instance to suffer from that known security vulnerability.

That smells like we might be able to use the reported version number as part of some kind of metric for how secure an instance is. We could imagine a sliding scale, like this:

• Green - Reports it is running the current version of Mastodon
• Yellow - Reports it is running a version number from a "known-good version numbers list". This list could include versions of Mastodon that didn't contain known security vulnerabilities, and potentially also include other version numbers of known-compatible implementations that also don't contain known security vulnerabilities.
• Orange - Does not report a version number, or reports an unknown version number
• Red - Reports a known-insecure version number

How, exactly, this list would be constructed, is a matter for endless debate. For example, you could easily argue that the "Orange" and "Red" categories should be combined. Or you could make a "rival" list, which prefers "orange list" instances.

How such a list should actually be used is also open to debate.

For example, in an extreme case, Mastodon developers could build this functionality in to the next version of ActivityPub-Mastodon, making the walled garden extremely official. Mastodon could actively block communication with "Red list" instances. Developers of compatible implementations would need to petition the Mastodon developers to be included in the "Yellow list". Mastodon developers would need to carefully track any "Yellow list" implementation for vulnerabilities and update their list accordingly. They might consider implementing this as a "feed" on an authoritative website, signed with a PGP key, or something.

Or as more of a middle-ground, a community could form around the idea of creating a "more secure" ad-hoc walled garden, in which individual instance admins explicitly block (or otherwise modulate) communication with "Red list" instances. To a certain extent, this is already happening, but based on instance policy rather than instance software security (for example, LGBT instances probably choose not to interconnect their instances with far-right / Nazi instances). This could offer a more nuanced approach, for example the community could collectively decide to create a block for an instance that was observed to be erroneously reporting the current version of Mastodon while actually running buggy software. Human interaction would be required, and it would probably need to operate like an email trust metric, where nothing is set in stone, old rules may age out, and instances can be added and removed in a fluid fashion.

I dislike either of these because I'd end up on the naughty list for wanting to hide my version number!

What would be the security benefit?

My take is that all of this is navel-gazing because Mastodon never pretended to be secure, and you should never assume that anything that happens on Mastodon is in any way secret. At best, you're on an instance that is run by someone who you trust not to look in the database. Any other instance that you communicate with is highly questionable.

Is my Mastodon instance at risk from connecting to an "evil" instance? The answer to this is either "no" or "wow, please stop using Mastodon right now and submit a confidential bug report."

Should we try to keep what is posted on Mastodon secret by e.g. not federating with evil instances? I think Mastodon is so far from being the right platform for this, and the version number is so far from being related to that, the question isn't even worth asking. You might want to consider using PGP if you care about this (you can do it now!). There's probably a fun project for someone to write a PGP add-on for Mastodon. It likely wouldn't even be a lot of work.

Is there value in trying to be secure? Yes, inasmuch as we don't want hacked systems out there on the internet doing evil things. But the best way to do that right now is to not tell people our version number.

Is there value in trying not to communicate with insecure instances? Not really. If you're not using trusted computing, you must use a higher-layer security protocol like PGP.

Final thoughts

There's no security benefit worth considering from disclosing your Mastodon version number. Any attempt to use the version number to create a "secure network" is misguided, and would only serve to further fragment the "microblogging bit" of the Fediverse.

There's a conversation to be had, more generally, about version numbers and trust metrics. It's an open question if you should change how much you trust me because I tell you a fake version number. My gut says "it should make you trust me less" because it means I've lied to you about something, so what's to prevent me lying about something else? Objectively, the reason I did this was because it was easier than disabling version numbers altogether, and if that was an easy option, then I'd just do that.

The elephant in the room, which this has unwrapped for me, is that we've all collectively started using a protocol that nobody has properly documented. We should probably try to do something about fixing that, unless we all want to be running Mastodon forever.