This will be the first of many posts I do about this topic,
For those who haven’t heard, Mastodon is a social media platform in the same concept as Twitter (Microblogging) but instead of there being one central authority and one team of administrators it is a collection of servers called instances that house the local users of that instance and their data that also communicate with other instances through a shared protocol called ActivityPub. This makes for a very robust and fault-tolerant social network.
Mastodon’s default UI is very similar to Twitter’s Tweetdeck where you have four different panels (Settings / Toot, Home, Notifications, Federated Timeline) Where you can compose messages called toots (if your coming from Twitter: a tweet) which can be as long as 500 characters on some instances.
I host a general, furry-related, mastodon instance over at puppo.space where I stay mostly active and communicate with other users both on the instance and out on the Internet. So far the instance has run smoothly over the last two months and I’m constantly looking for things to improve upon, both the interface, backend, and at the infrastructure level.
Being someone who values privacy and security above all else I looked towards everything I could possibly implement in order to provide the absolute best security going forward and this is what that looks like from me:
Cloudflare CDN –
I decided to use Cloudflare right from the get-go because I utilize origin servers who’s pipes only go up to 100 Mbps, while my hosting provider offers DDoS protection I had more faith in Cloudflare’s offering since they were able to mitigate the world’s largest DDoS attack in history and from prior experience I liked the offerings they had available. Cloudflare is also responsible for providing the world’s fastest DNS resolvers (220.127.116.11, 18.104.22.168) so it made sense for me to want to take full advantage of having them also deliver my DNS entries.
Since I manage my own email servers I realized I had to make sure that emails sent from Puppo Space made it to user’s inboxes instead of spam so I implemented a standard Postfix mail server and configured it to automatically sign emails sent from puppo.space email addresses with the domain’s DKIM key. This proves to other email providers that my server was the one to send out this message. SPF (Sender Policy Framework) allowed me to restrict which servers were authorized to send email on behalf of the domain. DMARC allowed me to tell other email providers what to do should they receive an email from my domain that happened to fail ether the DKIM or SPF test or both, to discard the message. I had also configured the DMARC record with a reporting email so that I can ensure emails sent to users are really coming from my servers.
This is a gimme, any modern website should at least be making an attempt to encrypt the communications between the client and the server. Going back to Cloudflare for a second, the communications between you, the user, and Cloudflare’s CDN network supports TLS version 1.3 which is currently the most secure version of TLS available with no known breaches or security vulnerabilities reported to its name but has been under active scrutiny and research for the past 8 years. By utilizing Cloudflare I am able to give users TLS 1.3 connectivity between their device and the CDN but from Cloudflare down to the origin server it is dropping back to TLS 1.2 due to Cloudflare’s limitation of not providing TLS 1.3 connectivity between origin servers and them, however, use of strong TLS 1.2 ciphers and SSL certificates on the origin servers provide SSL/TLS for the last mile from Cloudflare back to the origin servers.
Another security recommendation was to restrict the providers capable of issuing SSL certificates for the domain. The point of this is two-fold. Certificate Authorities are trusted universally where they are installed and because there are many of them out there it is quite possible for a skilled attacker to break in and have false certificates issued. By restricting which CA’s can issue certificates to the domain if a rogue authority did issue a certificate on the domain your browser would display the big red insecure page due to the CA not being in the domain’s CAA list. While the possibility an attacker going to such lengths for a site like mine is negligible at best, I sleep easier at night knowing not even a rogue self-signed root certificate installed by a hacker would be able to issue a working (green) SSL certificates for my domain.
HTTP Public Key Pinning works in tandem with CAA in that now not only am I restricting what CA’s can issue certificates for my domain, now I am telling the client to only trust my website if the SSL certificate sent to the user and its chain match a predefined list. While Chrome has deprecated this feature as of Chrome version 69 I have left it enabled. The big major problem with pinning is the fact that it is very easy to break your website should you fail to configure pinning properly. Since HPKP also has a configurable max-age it is entirely possible for an administrator to accidentally configure their max-age longer than their certificate has left. It is required that you configure a backup key that can be used should such an event occur. For my case, I pinned my dedicated SSL certificate and Cloudflare’s free SNI certificate. Since the site is constantly sitting behind Cloudflare and I can’t upload certificates from LetsEncrypt without a business plan I went for the best options.
HTTP Strict Transport Security allows me to tell the browser to not only force the HTTPS protocol but to require it. This is another security feature not immediately enabled due to the potential to break sites. Like HPKP it to has a configurable max-age, say you told the browser to remember that your site requires HTTPS for 6 months (the recommended TTL by Cloudflare) but after 3 months need to use http on a subdomain of the same url. The browser is unfortunately going to break your site. Even if you try to wipe out the setting from the server you will have to manually remove the entry in the browser before being able to access the site again.
While I realize a lot of this added security on top of the site raises the changes that I could potentially introduce a change that breaks the site, I think in the grand scheme of things its better to over prepared than to have something come up months later that could have been easily prevented.
Below I’ve included reports from a few of the scanners I used to bring site security up to where it is and where you may feel free to review for yourself. I also challenge you to plug in other sites that you use on a daily basis and see where they stack up. Remember that just because a site doesn’t match up 100% doesn’t necessarily mean a site is dangerous/bad or not because different sites have different security needs.