Verification is a process in which a client can with authority claim the source is valid by means of passing secrets that only both know the answer to. It doesn’t necessarily mean the source carries any weight/value, just that the source the client is connected with is who they claim to be. If your reading this site its because of your interest in running a blogging website yourself and you’re most likely already aware of a common source of verification, your Secure Socket Layer (SSL) certificate running on your site.
While I won’t delve into the specific workings of SSL certification, those reading this are probably aware of how to go about obtaining one. Usually either through means of a paid provider like Comodo or obtaining a free (Domain Validation only) certificate via LetsEncrypt. This is an effective way of communicating between client and server securely, passing information back and forth between sessions.
But you probably heard me state that the free version from LetsEncrypt and most basic paid certs are for Domain Validation or DV only. Meaning they only verify that the domain you have visited is indeed the domain serving the website you are visiting. It does not however verify the owner, this is done with an Organization cert, where the person/company running the site is verified, but the cert name is still listed from the issuer, or an Extended validation cert, where not only is the person/company verified, but the certificate itself lists the full owner of said cert, and not the issuer.
Sounds a bit confusing and you’re probably asking how is this related to Mastodon verification how? Well, the issue with its current form of verification, it leaves it up to the hosted Mastodon instance to verify who they say they are. The client does not do the verification process, only the server does. The verification documentation on the Mastodon website details:
If you put an HTTPS link in your profile metadata, Mastodon checks if that link resolves to a web page that links back to your Mastodon profile with a special
rel=meattribute. If so, you get a verification checkmark next to that link, since you are confirmed as the owner.1
It also states that Mastodon doesn’t have a real way to do verification and that the best course of action:
Because Mastodon can be self-hosted, there is no better way to verify your identity than to host Mastodon on your own domain, which people already trust.
And this would be one of the best ways to verify who owns what. If most large companies ran their own server, like they do now with email, this would solve some of these issues. I mean, you would know [email protected] really works for Microsoft.
But not everyone wants to do this and this still doesn’t solves issues around similar naming but not authentic domain names being used. If you’re tech savoy enough you’ll check the SSL cert to see who actually owns werealmostmicrosoftbutnotreally.com cert (I’m doubting Microsoft) besides doing a WhoIs lookup on the domain name itself if in doubt.
But people today still fall for those scams and they already have the tools at their disposal to prevent it. How are we going to prevent this on Mastodon nodes?
And what about malicious nodes? There is nothing preventing a fake Mastodon instance from pretending that the user on their instance is really who they are since the verification comes from the server side.
Possible Solutions
We have to look towards another older and more tested federated service for solutions… email. See, email works very similar to the way the Fediverse works today. It’s decentralized, each email server has users under its own domain and depending upon the server settings, can send emails to other email servers besides local users under the same domain. Those remote email servers in return, can allow or deny those incoming emails and who gets what.
And for verification, the email server uses DNS records for verification. DMARC, DKIM and SPF2.
DomainKeys Identified Mail (DKIM) verifies emails by signing them before they leave the email server via the domain name of the email address, verifying that they are authentic from the email server. This is done by having a public key via a TXT record. The signature in this case is the private key, which is then verified by the accepting email server by looking up the public key via DNS.
Sender Policy Framework (SPF) is the list of all authenticated email servers from this domain that is allowed to send emails from. If an email comes from another IP address not listed on the SPF TXT record, follow the DMARC policy on what to do.
Domain-based Message Authentication Reporting and Conformance (DMARC) is the instruction set of what to do with those incoming emails if they fail DKIM and SPF. A TXT record is set by the domain the email are suppose to originate from and if not valid, what to do. In most cases, DMARC will instruct to reject or quarantine invalid emails. This is the verified email server saying to toss emails not coming from this email IP address via DNS lookup.
You can see where this is going right? There needs to be a way for the client to authenticate via the client side on whether the user they are visiting from a Mastodon instance on a domain is who they say they are via a DNS record lookup and if not real, what policy to perform. This can only be implemented either via an extension for browsers or even better, a new security protocol built into the browser.
Personally I would rather use DNS for verification instead of meta data on a website like the rel=”me” links on a page for verification just to prevent DDOS issues. Much more efficient looking up DNS records then loading people’s personal blogs and hoping the website loads.
I fear without these security measures being implemented it is only a matter of time before a group of people run malicious instances claiming to be people they are not, showing falsely “verified” links on fake accounts to obtain information from visitors or publish malware links. It will happen, it’s not if, just when.
We only need to look to the past in email to see the future in the Fediverse.
