0

Many suggestions on transfering emails securely can be found in this answer. But many of them (e.g. PGP) need support from recipient. I want to provide SMTP email server that will route emails of it's clients in the most secure way.

By security I mean:

  1. Presense of proof that is me who send this message
  2. No one man in the middle is able to read contents of message
  3. Preventing other email servers to send message with FROM address containing my domain name (I prefer those emails to be in Junk folder. I'm not sure it's possible)

What are the best ways that will give security without specific support from recipient? (i.e. recipient of email won't have to install plugin/specific program to read email. I know that SMTP itself doesn't offer security. Are there widespread extensions or something like that offer additional security?)

The only known to me way that increases security without recipient support is STARTTLS (it will give me 2 from the above list). But STARTTLS needs support from both ends. Very few major email providers support it nowadays (GMail supports). Does STARTTLS give the same level of protections as TLS in HTTP?

There are many known attacks against TLS in HTTP, e.g. BEAST. Do the same attacks apply to TLS (STARTTLS) as it is used in SMTP? What cipher suites are safe to use with STARTTLS?

Community
  • 1
Andrei Botalov
  • 5,267
  • 10
  • 45
  • 73
  • 7
    Don't want to prevent discussion, ideas, etc., but in other words you're asking "We know email wasn't built to be that secure, but it's still used. We know there's a lot of research about it, but all solutions need some change in the current model. Is there a magic solution to solve all those weakness in it's design without any change?" – woliveirajr Feb 03 '12 at 15:05
  • How do you mean create a server? Do you mean write a new one? Or configure an existing product? – Graham Hill Feb 03 '12 at 15:46

3 Answers3

6

Can't be done.

  • To achieve option 1, you need digital signing, and the receiving end has to check the signature.
  • To achieve option 2, you need encryption, and the receiving end has to decrypt.
  • To achieve option 3, you need the receiving end to check for a forged sender address.

You're always going to need stuff at the receiving end. Now, that could be in the server, or the client. But it needs to be there. And you have to decide what you want to happen if it's not there. Have the mail fail? Or allow it to go in an insecure fashion?

w.r.t STARTTLS, that is just an extension to the SMTP protocol allowing the originating server to ask the receiving server to use TLS for the connection. So basically it is TLS.

Graham Hill
  • 15,394
  • 37
  • 62
  • The question talks about setting up an email server. The server could potentially decrypt and verify incoming email and then send it to the client unencrypted. Then the clients communicate with the server via SSL. It wouldn't be an ideal solution, of course, but it would be better than nothing. – Jonathan Feb 03 '12 at 17:38
3

As was already said, there is no universal solution that doesn't depend on the other side taking steps as well.

With that said, SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) are somewhat well supported out there in the wild, and can help deal with parts 1 & 3 (they're really two sides of the same coin). The new DMARC (Domain-based Message Authentication, Reporting & Conformance) spec builds upon SPF & DKIM.

All of these are supported by the major email providers and many other services, so while it won't be supported by everyone that might receive your emails or send you some, it's a large step above stock SMTP. SPF/DKIM/DMARC doesn't guarantee the email isn't malicious/spam/important, as anyone can set up their own domain with that infrastructure in place.

Security is extremely hard to achieve when only part of the parties involved care about it.

Kitsune
  • 681
  • 6
  • 8
0

As stated before, you simply cannot do email security (or any security for that matter) without client-side support.

But you could put the client-side security on the client's server rather than his workstation. There exist solutions that automatically sign, encrypt, decrypt, etc., messages using PGP protocols as they pass though the device. Astaro's edge devices come to mind, but I'm sure there are others.

Bear in mind that this isn't the same level of usefulness, since the user will have no idea whether or not his messages are secure; instead you'd have to establish policies on the server as to accepting or rejecting messages based on security status. But then again, without making any changes to the user's workstation, he obviously couldn't have anything to do with his message security; so this isn't so much a downside as it is a design requirement.

tylerl
  • 82,225
  • 25
  • 148
  • 226