By the time this post has been published, the Oxmail relays will most likely be using opportunistic encryption to encrypt outgoing emails, in response to actions by cloud mail providers. However, we would like to make it clear that we have always known that we had encryption disabled and that our reasons for enabling it have nothing to do with addressing privacy concerns. This post should hopefully explain all this along with some relevant history.
What is SMTP?
Simple Mail Transport Protocol is the de-facto standard for email transfer between servers. SMTP is an old standard and at its inception the internet was a happier place with less need for security and thus no security was built into the protocol. Mail delivery is via a hop by hop mechanism, which is to say that if I fire off an email to fred.bloggs@example.org, my mail client does not necessarily contact Fred’s mailstore directly, rather it contacts a server it thinks is better suited to deliver the mail to Fred. It is a very similar concept to 6 degrees of separation. The Oxmail relays are one hop in the chain from the sender, you at your laptop (other devices are available), and the destination server which houses the mailbox of Fred Bloggs.
This is just an example of the many servers that need to participate to get an email from your laptop to a recipient. The number of servers is variable and you do not necessarily know the number when sending an email.
What is TLS?
TLS, or Transport Layer Security to give its full name, is a mechanism by which each hop is encrypted so that eavesdroppers in the middle of the connection cannot listen in on the transfer. To be clear, routers and most firewalls are not considered endpoints in this context, it’s just the mail servers that are set up to route mail to particular destinations, and as such these routers and firewalls are exactly the devices for which this mechanism is designed to protect against.
Why did the Oxmails not encrypt mail?
I should start by saying that there was nothing inherently stopping the Oxmail relays from initiating an encrypted communication when sending mail. The software that we run is capable of encrypting communications, and in fact we require it for incoming external connections to smtp.ox.ac.uk, so as to protect password credentials from being harvested. However, we have reservations with the concept of TLS encryption for a few reasons:
- Since SMTP is a hop-by-hop protocol with an email traversing multiple servers A through to G, just because the communication between F and G is secure you know absolutely nothing about how secure your email is. For G to know that the email received is actually from A and is unaltered, every point needs to be encrypted, and yet there is no way of telling G that this is the case. All G knows is that the last hop was secure.
- As almost a repetition of the last sentence, TLS does not necessarily make communications any safer and pretending otherwise is bordering deceitful. Similarly, if the mail received by G is set to be forwarded to another mailbox H, and this is done via an encrypted channel, is that now secure?
- The battle may already be lost on this since its uptake is so small, but there is a technology that was designed to solve this: GPG. Using GPG, you encrypt the email using your laptop and only Fred can decrypt it, unlike TLS where each hop has access to every email’s contents. The truly security conscious should be using GPG to encrypt mail as only the recipient and sender can see the message. The necessary data to decrypt the message is stored locally on your computer.
To summarize these points, we did not encrypt outgoing mail as we considered it a pointless exercise that would only give people the illusion of security without actually doing anything.
Why are we now enabling opportunistic encryption on the Oxmail relays?
Following the actions of cloud service providers, where emails received unencrypted were flagged to the person reading the mail, we were presented with two options:
- Do nothing.
- Implement TLS.
The former may have been our stance, but recently we have been receiving complaints that sent emails’ privacy has been violated when sent to certain mail providers. Rather than argue the point that email as an entire concept is insecure (after all there is nothing stopping cloud mail providers from reading your emails for account profiling and targeted advertising), the change is relatively minor our end and so we took the conscious decision to enable outgoing TLS when available, so as to remove the flag on mail sent to these cloud providers.
Are there better solutions available?
Yes! Even better, some of these solutions can be used today without any change on any infrastructure (except perhaps your mail client). I mentioned GPG above which is completely compatible with the existing infrastructure used around the world. You could even post your emails onto a public share using a service such as Dropbox with a link to it on Twitter and still only the recipient can read it. I must admit that usage of GPG is minimal despite its relative maturity and perhaps going into the reasons is not beneficial to the current discussion. There is also an encryption mechanism called S/MIME which has the same overall effect as GPG, even though its method is quite different. S/MIME reportedly is better supported by more mail clients, but requires purchasing a digital certificate and is thus potentially more expensive than GPG [update: this is incorrect. They can be obtained free of charge. See comments].
Added to GPG and S/MIME there are SPF and DKIM which can help verify servers’ authenticities (they do not encrypt). These technologies themselves are not well suited to our (the University’s) devolved environment as outlined in an excellent blog post by my predecessor Guy Edwards.
Conclusion
I hope this helps explain our thoughts on TLS encryption, and that our recent change to use encrypted communications is not a reaction to a mistake we discovered we were making. If there is anything you wish to add, please do add a comment, or contact the IT Services helpdesk for further information.
Your argument against encryption is essentially that TLS encryption between just two hops may not offer the degree of privacy that users might expect. I see your point that the gain in privacy is unsatisfying, however, it also clearly not zero. Even if the other hops are out of your control, there is a chance that they will be encrypted. Therefore, your decision not to encrypt incoming connections can effectively render some transmissions insecure that would otherwise be secure.
In other words, just because there may be a weak link in the chain, you are deliberately choosing to be the weakest possible link.
Secondly, your argument against encrypting mail transfer could also be used against any other privacy measure because no measure is ever 100% watertight. For example, your argument also applies to PGP which you explicitly recommend in the linked article. If I send PGP-encrypted mail to someone, there is no guarantee whatsoever that their computer is free of spyware that could steal the message after the recipient decrypts it. Yet, we would all agree that encrypting a sensitive message with PGP is better than to send it as clear text.
Finally, and most importantly, I think you are missing an important point. By refusing to accept encrypted connections, you are not just degrading privacy for your users. In fact, for some users you are disrupting the email service altogether. More and more email providers are transmitting emails only via encrypted connections. Users of these providers, for example myself, cannot send emails to ox.ax.uk addresses at all – at least not without jumping through hoops. I doubt that this is what you want. So even though you argument against encryption of mail transmissions may have been valid at some point (I doubt it), it’s clearly not valid anymore in a world where pretty much everyone else is moving to encryption. In sum, I think your are doing your users and their peers a disservice in multiple ways and I would like to urge you to reconsider your policy.
Firstly Titus, thank you for taking the time to comment on the issue. We always welcome discourse and you raise many interesting points. Unfortunately responding inline is not possible using the comments system on this blog so please accept this blob as a response and hopefully you will see me try to respond to your points directly. I will probably start with the conclusion in that people have many different views on what makes communication secure, with the extremes differing wildly. Choosing one stance for any particular organization, particularly one as heterogeneous at the University of Oxford is going to annoy someone, and every change to behaviour to a public facing service carries a risk of unintended consequences.
In regards to your points, where you state that we are choosing to be the weakest point in the link, that’s only true when viewing TLS in isolation and to say we’re choosing to be is disingenuous. It’s no good invoking TLS when any hop has been compromised, or if data is leaking from any hop. We can definitely agree that were we to turn on TLS on our servers then some of your communication is more secure, but you have no idea what that means. To tighten up the terminology, what’s the risk of a third party reading email currently? Is is better were we to turn on TLS? Is it quantifiable?
For your second point, you raise the idea that PGP is insecure because malicious code on the client could still access the emails. This is a good point and there is no refutation of it. However, and this comes down to the sliding scale of acceptability, there is definitely a distinction between PGP security and TLS. With the former, you are assuming that the endpoint (i.e. your recipient) has a secure means of reading the email. With the former, you are assuming this as well as every hop on the way to the destination. To change the perspective of your argument, if we’re resigned to the fact that no security is 100% watertight, why not use PGP and ignore the issue of plain text communication between hops? PGP is more secure at the conceptual level than TLS.
Thirdly, if we are failing to receive emails from recipients that do not do unencrypted communications, that is regrettable. I would say that these providers would be in the minority and all the major players in the emailing world communicate with us fine. Perhaps also in the minority, but something we found very quickly in testing, are providers that request TLS when trying to send to us, then send invalid data forcing a connection close. We found no subsequent retry in plaintext. Whether the retry behaviour is desired or not is beside the point; we’re damned if we do, damned if we don’t. I’d be interested for sources to your claim that more and more email providers are transmitting TLS only because I couldn’t find anything online.
The world may be moving to encryption, but we here would like people to be aware of what that means. Of course we would never dismiss anyone for wanting something more secure, but our argument is that TLS encryption is no more secure so there’s no point enabling it. Your argument seems to be that it is no less secure, so there’s no reason to not use it. I would say both are valid viewpoints, As it currently stands, we have no plans to enable inbound encryption, for reasons outlined both in the post and this comment, but we will certainly review this should any major changes happen to the emailing landscape.
Certificates for S/MIME are in fact free.
And it’s easier to use than PGP.
See yourself.
https://bravenewworld2014.wordpress.com/2014/05/12/secure-email/
Thanks Michal, I didn’t realize that S/MIME certificates are offered free from some CAs. Noted in post.