10

There are a bunch of people in the anti-surveillance movement who are virtually demanding that I enable SMTP STARTTLS support in my environment, in order to enable opportunistic MTA-to-MTA encryption. The same anti-surveillance people are meanwhile complaining that OpenSSL is poor-quality code with a high likelihood of severe undiscovered vulnerabilities.

Is exposing OpenSSL (most MTAs including ours only support OpenSSL) to the Internet a worthwhile risk, for the benefit of opportunistically preventing eavesdropping? It seems like the risk of people eavesdropping on email in transit pales in comparison to the risk of OpenSSL being exploited on the mail server to steal stored data or install a persistent back door.

Improve this question

3 Answers 3

Reset to default
25

I think you're overestimating the risk of enabling STARTTLS. Sure, there have been some incidents with OpenSSL recently, but does it mean we should all stop using HTTPS?

In your situation, here is the trade-off:

  • Using STARTTLS may open up security holes on your machines
  • Not using STARTTLS will allow anyone snooping (on the network, on underwater cables...) to read the e-mails effortlessly. (Contrary to what you imply, this is not a risk - it's happening, as Snowden's documents have proven.)

Basically, you have to choose between mitigating possible future security issues and defending against current attacks.

Unless you are are a high-profile target and fear that 0days may be used against you, I'd advise you to go with STARTTLS. Alternately, if you really don't trust OpenSSL, you can probably look into GnuTLS (although it had its share of problems too) or wait for OpenBSD's LibReSSL.

UPDATE : A portable version of LibReSSL has just been released by OpenBSD... It still lacks testing, but this means you could yet get the best of both worlds, provided you trust them more than OpenSSL's developers.

Improve this answer
6
  • 7
    +1 SSL as a protocol is still secure, when deployed correctly. Heartbleed still only effected a certain range of versions of openssl (remember the number of heartbleed vulnerable servers went UP initially as sys admins frantically upgraded openssl - from a safe version to a vulnerable one).
    – AlexH
    Jul 11, 2014 at 9:05
  • Also true: Not using STARTTLS will reduce my chance of exposing security holes to the whole net. Using STARTTLS may prevent snooping by a few entities in privileged positions.
    – ruief
    Jul 11, 2014 at 18:13
  • Also, yes I am a high-profile target, but that doesn't necessarily mean I face a different risk balance of 0day exploitation vs passive surveillance.
    – ruief
    Jul 11, 2014 at 18:16
  • @ruief note that 'entity in privileged position' includes anyone who knows how to sniff wifi in local cafe/hotel if you don't have a support for TLS in POP/IMAP/SMTP. If you do then you don't exactly expose a new surface.
    – Maja Piechotka
    Jul 12, 2014 at 0:49
  • 1
    @ruief: I maintain that using STARTTLS will hinder some passive surveillance, because said surveillance is taking place on a global scale. And "will reduce the chances of exposing security holes" is a "may reduce the attack surface". Worthy of mention: a portable version of LibReSSL has just been released by OpenBSD.
    – executifs
    Jul 12, 2014 at 19:19
5

Firstly, you're confusing SSL/TLS and its implementations. Your server might use OpenSSL, but that doesn't mean the clients that connect to it will. Potential vulnerabilities depend very much on the context. If you're worried about OpenSSL-specific zero-day vulnerabilities, you might be able to find a mail server that uses another stack.

In addition, OpenSSL has had bad publicity because of the Heartbleed bug, but this is perhaps a blessing in disguise, since, as a consequence, some large firms seem to have decided to provide the project with substantial funding (which it didn't have). I'm not sure whether other implementations (e.g. GnuTLS, Mozilla's NSS, even Java's JSSE, ...) would have the same sort of budget allocated to them.

It's still generally a good idea to enable STARTTLS on your mail server, since it should protect the connection between the client and the mail server (MSA). At the very least, it's good to protect the user's password (they're often re-used in practice). Like any other piece of software, it's worth upgrading to a newer version whenever there's a security update. Nothing is perfect, unfortunately.

As a side note, STARTTLS will help between the client and the MSA (your server), but will be of little help between MTAs in general (that is, once it leaves your server to go to a different server).

Improve this answer
7
  • I should have clarified that the supposed benefit is MTA-to-MTA opportunistic encryption, as our users don't pass credentials in SMTP.
    – ruief
    Jul 11, 2014 at 18:24
  • OpenSSL funding (real or expected) hasn't made a dent in its problems yet. I don't tend to deploy troubled software based on how good I expect it might be in the future.
    – ruief
    Jul 11, 2014 at 18:25
  • @rueif, "I don't tend to deploy troubled software based on how good I expect it might be in the future.". This sounds like speculation both ways anyway: we don't know what there is to improve (anything to substantiate the OpenSSL problems you've seen?) or what will be improved with this funding.
    – Bruno
    Jul 11, 2014 at 18:27
  • Regarding MTA-to-MTA opportunistic encryption, I don't think SSL there (in an opportunistic deployment, i.e. falling back in plain text when SSL doesn't work) will be an obstacle for anyone in a position to perform large scale eavesdropping.
    – Bruno
    Jul 11, 2014 at 18:30
  • 1
    @ruief "as our users don't pass credentials in SMTP." - there is much more to SSL then securing credentials - it secures the confidentially of emails as well and authenticates the server. Currently it's possible to DNS spoof your server for example and redirect all emails to /dev/null - yet for users it looks as if the mails were sent correctly (DoS attack). It is also possible to get the e-mails passing through the wire in plain text to SMTP server for anyone to see.
    – Maja Piechotka
    Jul 12, 2014 at 10:26
5

Though OpenSSL has some quality issues, it would be quite optimistic to believe that the rest of the software that you expose to the Internet fares better. OpenSSL is one of the most attacked pieces of software because it is a high-value target:

  • The same library is used in many servers of many types (HTTPS, SMTP, IMAP,...) so any vulnerability has a wide potential applicability range.

  • People think of SSL as "highly sensitive" so the associated bragging rights are huge. Technically, when you use SSL, it is to protect some sensitive data which is the true target of the attacker; an attacker who steals the private key of a server is not after the key for itself, but wants to run a fake server so as to obtain the credit card numbers of the users. SSL and its keys are merely enabling tools. However, private keys are terrific trophies; geekish attackers may gain much fame among their peers by flourishing a purloined RSA private key, bringing them closer to alpha male status.

One consequence is that OpenSSL is actually one of the most secure pieces of software around, because when vulnerabilities are found, they are widely publicized, and since there are so many systems using OpenSSL, risks that attackers apply the exploit to your server before you install the relevant security patch are very low.

Practical software security is a race between the discovery of vulnerabilities and their fixing. Using a library with a very large user base, and an history of efficient reactive patching (which is helped by the opensource status of OpenSSL), grants herd immunity. It works very well !

So don't fret about OpenSSL. In fact, use it. What really matters is that security fixes are promptly applied, which is a sysadmin issue. (On the other hand, using OpenSSL in embedded systems such as home routers, whose software is never really updated, is probably a not-so-good idea, for about the same reasons.)

Improve this answer
14
  • "OpenSSL is actually one of the most secure pieces of software around" is laughable. Its track record is much worse than any other FOSS code in our infrastructure, save for the Linux kernel.
    – ruief
    Jul 11, 2014 at 18:20
  • 1
    @ruief, it would be good if you could substantiate your claims. I'm not saying you're necessarily wrong, but a few facts would do no harm here. Nothing's perfect. It sounds like you're in an environment where an element of paranoia may drive the agenda.
    – Bruno
    Jul 11, 2014 at 18:37
  • We're not paranoid, but we're thoughtful. We don't deploy any FOSS software where we haven't found the coding style and visible community indicative of sound practices. We have repeatedly rejected OpenSSL based on this type of evaluation, which has proven to be a great predictor of security failings over almost two decades. We run no small amount of popular software.
    – ruief
    Jul 11, 2014 at 18:53
  • 1
    What would be the performance costs of keeping super-secret data out of the process space of any internet-facing process, and instead doing things like public-key operations on a separate process which communicates only with other processes on the same machine? Would such a design be effective in minimizing damage from future "heartbleed"-style bugs?
    – supercat
    Jul 12, 2014 at 16:53
  • 1
    The "damage" from Heartbleed was really due to the panic which submerged so many people, rather than a specific technical detail. Yet there is value in isolating private keys out of the process address space. This is why Microsoft is trying to replace their old CryptoAPI with a new API called "CNG", because the latter allows for private keys to be stored in kernel space, thus out of reach of some vulnerabilities (this also prevents the keys from leaking to swap space).
    – Tom Leek
    Jul 12, 2014 at 20:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .