Private Email Servers are not an Exercise in Futility

This week we encountered a twitter conversation of great interest to the mission here at Start9: @ricburton was asking how he could run a private email server most effectively. The following thread by @relyt29 was a surprisingly comprehensive indictment of not only the practicality of the exercise but even the value of doing so. I’ve linked it here for the curious, but excerpts will be quoted in the rest of this post. On the whole, while the individual statements in the thread were accurate, the overarching message of the tweetstorm is, in our opinion here at Start9, unnecessarily bleak.

Why run private email?

The thread started off in exactly the place you would expect in any security conversation. To any security professional, the notion of binary designation of “secure” and “insecure” is misplaced. Every security conversation must start against the backdrop of a threat model. Threats can be adversarial agents (malicious individuals or organizations), natural phenomena (hardware failure, software failure, natural disasters), or even self-originated (the user threatening themselves, accidentally of course). And they correctly start from this idea.

First off you’ll need to think about your threat model. What is your primary concern / what are you trying to protect against? Why? Well email is a shit protocol from the 90s with absolute shit notions of security, so it’s like a leaky ship. You will be patching holes EVERYWHERE

@relyt29 has a point here. Email is one of the oldest Internet protocols still in heavy use today. And as they get to later, it does actually precede much of the modern security infrastructure of the internet (SSL/TLS). As such, email is one of the more painful problems we’ve worked on here at Start9 so far. Where this line of reasoning starts to fail is when it is translated to the assumption that because it IS painful, that it MUST BE painful. Additionally, they challenge the very reasons for doing so in the first place, and ultimately tries to make the argument that the benefits of running your own email are ultimately not worth the difficulty it takes to do it.

To alleviate a lot of the difficulty associated with keeping email servers secure and up to date, we, as a society largely outsourced it to providers such as GMail, Outlook, etc. There were good reasons to do this at the time, the expertise required to do so was relatively concentrated, and the risk of having these mega-platforms was not apparent. Since then, as we’ve seen with programs such as PRISM or the spat between Apple and the FBI over the San Bernardino case, as well as high profile breaches of other platforms. The path dependence of technological evolution means that technologies once fit for their environment may not sustain their fitness as the environment changes; and the environment where GMail was the optimal solution for email was one where we had not observed systemic “tail risks” associated with radical centralization of communication. The benefit of private email is entirely as a protection against tail risk. There are a few ways in which this risk presents.

Honeypot Effects

First, there is a “honeypot effect” where the value of compromising central email infrastructure outpaces the effectiveness of countermeasures. This is a point that @relyt29 misses in the following tweet:

“I don’t want the big bad US Gubment to read my emails! Hurr durr!” Lol. You think you’re going to be able to secure your shitbox on the Internet better than Google’s security team that has an office full of people working 9–5?

While it is true to say that in most cases, central email providers will be able to provide you with a better technical security posture than you would be able to on your own, it is a mistake to assume that implies that you are less likely to be compromised if you went with one. The drop in exposure that comes with not bundling your private information with everyone else’s, provides a meaningful reduction in risk despite not having a team of full-time security professionals keeping infrastructure up to date.

The main mistake here is to place more importance on the “strength of your security” than your overall exposure. The value of any given anonymous target is unknown, and spending effort without confidence in payoffs serves as a deterrent for adversaries. However, if these targets are bundled together massively, the confidence in payoffs skyrockets, justifying substantially larger effort expenditures. As a result, the average person can become collateral damage in attacks that would never have affected them had they chosen to unbundle themselves from valuable targets, even if there is a marginal reduction in the technical security properties.

People should be thinking about “exposure” as a relevant property of their security, which is necessarily positively correlated with the size of the provider that they use.

Government Demands

Secondly, by rounding up all of this sensitive data into a central location, it becomes increasingly enticing for governments to extrajudicially pressure email providers to assist them in endeavors of government interest. Since the providers often do not have a tremendous incentive to resist, they often comply even at times when they don’t need to for expediency’s sake. Ultimately, no one besides yourself will be a better steward of your own interests and, by extension, privacy.

@relyt29 tries to make the point that whether the government subpeonas the provider or you directly is inconsequential:

“But pen registers and subpoenas!” (I understand you’re UK, they prolly have similar shit) Oh boi. If Google’s getting
subpoenad for your data a) they already have it from the point above b) even if they didn’t, what are you going to do if
the government subpoenas you directly?

It is true that resisting a subpoena is not in your interests and subpoenas themselves are well within the “due process” we have in the United States. That said, the subpoena is not the only way governments try to obtain information these days and law enforcement has a long tradition of trying to circumvent 4th amendment rights, notably including so called “dragnet surveillance”, which to their credit, @relyt29 does address.

better idea, don’t do shit that gets you subpoenaed, eh? “but dragnet surveillance!” LOL Email in between endpoints, is often not encrypted, at all. Or if it is, SERVERS ACCEPT SELF SIGNED CERTIFICATES THIS IS STANDARD PRACTICE DONT BELIEVE ME? LOOK IT UP

Dragnet surveillance is just simply intractable if the locality of data is distributed. Having said that, the fact that email is not encrypted end to end endangers the effectiveness of a private server, a valid technical point I will address later.

Violations of Trust

Finally, there are risks related to violations of trust. As it stands today, Google has the capability to read 100% of your GMail emails at any time for any reason. By policy, there is presumably a process that gates which code and human eyes can view your conversations, but policies change somewhat frequently and verification of adherence to such policy is essentially impossible. In addition to that, even if you believe that the people running these large organizations represent your interests today, the turnover in any organization cannot ensure that those values are resilient. With Sergey and Larry stepping down last year, this is not just a hypothetical: Google has entered a new era. With the increasing incidence of public companies choosing their shareholders over customers when those interests diverge, these violations are becoming obvious to everyone, and rightfully deserve attention and open up the opportunity for creative destruction.

These violations of trust are one of the problems we take the most seriously here at Start9 Labs. It is not lost on us that the idea of a company selling you a product that supposedly protects you from violations of trust, must itself be able to credibly demonstrate that it is incapable of these same violations. This will be a common thread in the way we choose to design our products and technologies, and it is one of the main inspirations for designing our products in the first place. The full set of methods we are trying to accomplish this end is beyond the scope of this blog post, but it deserves its own post due to the importance of the issue to both us and our customers.

Okay, but is it Realistic?

Enough about why we should try and run private email servers. I imagine that by now, if you are not convinced it is at least marginally valuable, you may just not be the audience that will benefit from the rest of this discussion. And while we are confident that you will change your mind at some point, you can skip the rest of this post for now.

Here is where @relyt29 really starts to hit on some important issues. Running email, and more generally, server software, today, is HARD. Let’s break down some of the challenges that you face when trying to do this.

Constant Uptime

Okay. So you don’t trust le googs and you don’t trust le big bad gubment, so you’re going to host your own email server. Step 1: the computer you’re going to host your email on. This computer will need to be always online, to receive emails. we’re talkin 99% availability.

One of the fundamental problems that the Start9 Personal Server solves, is supply you with a computer that is designed to be constantly up, with the ability to listen for inbound connections. In the last two decades, the industry has done an incredible job delivering an amazing user experience for your phones and laptops, but the problem is that these computers are not expected to be on and listening all the time. The vast majority of people don’t have a computer dedicated to this task. Even if you HAD the hardware, because of the trends of the last 20 years, almost no work has gone into making server software easy to install, manage, and use, which won’t fly if we expect end users to run their own server software, and take back control of their digital selves.

We have developed a streamlined way to install and manage applications that, by their design, require constant uptime, and email is exactly that. This is because, as @relyt29 points out, if your server ever goes down, you will start missing emails, which undermines the value proposition of email. This makes reliability extremely important. It is also achievable, and it can be accomplished in a trustless, distributed manner.

Configuration Hell

As it turns out one of the near universal problems with server software is that their configurations can be maddeningly detailed, to the point where even an expert may not know deeply what every configuration option is for. For this reason, one of the design goals is that while you should be able to retain most if not all control over the configuration options, you should be able to run the software without having to input a single configuration option. We have spent significant effort refining this experience and it works quite nicely.

So historically, while configurations have been tough to wrangle, it is not only unnecessary for applications on the Start9 Server, but even if you wanted to, configuration is much more intuitive experience than it has been traditionally.

Static Addresses

The above concerns apply to pretty much all server software, but there are some additional issues when dealing with email specifically. One of these is that you need some sort of static address to which people can send emails. If you don’t have this, no one can know how to reach you, and you may as well pack it in. Typically, ISP’s don’t give consumers dedicated IPv4 addresses unless they are requested. When they are requested, you typically have to pay a lot more than you want for the privilege. @relyt29 gives names two options here:

but anyways, back to the server you’ll host your email on. You’ll need it to be always available. Will you rent a VPS from a cloud provider or will you toss a shitbox in your basement corner and pay your ISP 100+ bucks a month for a static IP address?

We agree, VPS is not the way to go. And paying for static IPs and never moving again is also not something anyone is going to do. But as it happens these aren’t our only options. One of the ways this can be dealt with is by implementing all addresses as Tor Hidden Services. This bypasses the need for port forwarding and other router configuration and gives you a static address at which you can be reached, despite having a dynamically assigned IP address. As a bonus it also gives us free end-to-end encryption of the communication as well as the anonymity of the sender and receiver.

The skeptical reader might ask, “Are users going to tolerate typing in Tor Hidden Service URLs as email addresses? Aren’t those 54 characters of random letters and numbers?”. There are a few ways to address this on the usability front: Adding the addresses to a “contact”, on the application side, and you can sacrifice anonymity by putting the “.onion” address into an MX record and send an email to something like “me@example.com” and it will translate under the hood.

This sounds great, here’s the problem: email is a protocol that many different providers use, and I’m pretty sure none of them support “.onion” service resolution. So, in order for someone, to send you an email using traditional means, you would need to have a proxy address through a “clearnet gateway” that takes mail from clearnet and forwards it to the correct Tor service. It should be noted that this is a trusted component. It should also be noted that it is not necessary for email senders that can also connect to Tor Hidden Services. And because emails are not encrypted end-to-end, the clearnet
gateway does have the capacity to inspect the contents of the emails it is relaying. Defeating this is possible with GPG but there have been numerous attempts to get GPG adoption with not terribly encouraging results.

Counterparty Security

This leaves us with the last main point that @relyt29 talks about:

Are you concerned that Google’s reading your emails? Answer: 80% of everyone you will email to will be on GMail. They may not have *your* emails but they’ll have the conversation thread on your contact’s side, so they’ll read them anyways. Same with MS, Apple, etc.

This is undeniable. The Silicon Valley Mega platforms have a very large user base, and any communication you send to those on GMail will still be read by GMail. This doesn’t invalidate the proposition of running a private email server, though. The first reason is that it is substantially more work (though probably being done) to construct shadow profiles of non-users by stitching together their communications with actual users. Additionally, a 20% reduction in the amount of data that is read by Google, is meaningful, especially because risk is not uniformly distributed over communications or the counterparties with whom you communicate. Finally, by offering the existence of a usable alternative, that 80% figure is likely to erode over time for the use cases where it matters, and in that case your security/privacy posture will improve over time.

Conclusion

I’ll end this where @relyt29 and Start9 Labs agree:

you know what I do on my saturday nights? Live my life, because life is too short to be fucking with postfix configs.

Life IS too short to be fucking with postfix configs. But if we do our job right, you won’t have to.

I don’t want to downplay the challenges here, but the point I’m making is that these things are solvable, have potential for great user experiences, and provide very meaningful benefits. It is tempting to say that if this problem were solvable, it would have been done already, but a common refrain from our CEO applies here.

“Often times the only reason something hasn’t been done before is because YOU haven’t done it yet.”

We are doing it, we intend to do it well, and we hope that when it is finished, that it will deliver another dimension of digital sovereignty without compromising usability.

— Keagan McClelland, Head of Product at Start9Labs