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.

user1
  • 3
  • 1
ruief
  • 883
  • 4
  • 11

3 Answers3

26

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.

executifs
  • 4,772
  • 4
  • 23
  • 25
  • 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 '14 at 09: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 '14 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 '14 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. – Maciej Piechotka Jul 12 '14 at 00: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](http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/) by OpenBSD. – executifs Jul 12 '14 at 19:19
  • Not having a mail server at all will reduce the attack surface even more (and also avoids anyone snooping on traffic, as there is none). – Paŭlo Ebermann Sep 24 '19 at 18:41
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).

Community
  • 1
Bruno
  • 10,765
  • 1
  • 39
  • 59
  • 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 '14 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 '14 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 '14 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 '14 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. – Maciej Piechotka Jul 12 '14 at 10:26
  • @MaciejPiechotka Again, this is about MTA-to-MTA, not users submitting messages or anything else. – ruief Jul 13 '14 at 03:45
  • @ruief, as I was saying in a comment on by SF answer just now, the problem with MTA-to-MTA, is that you'll never be in control of all the hops. I'd guess attackers who are in a position to eavesdrop between MTAs are also very likely to be in a position to mount a MITM attacks, and prevent the opportunistic upgrade: at that level, the networks would tend to be within the hands of professionals exclusively, who'd certainly be in charge of the routers, etc. – Bruno Jul 13 '14 at 13:58
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.)

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • "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 '14 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 '14 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 '14 at 18:53
  • @ruief Oh, and `/bin/cat` is very secure! – Volker Siegel Jul 12 '14 at 02:08
  • 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 '14 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 '14 at 20:53
  • @supercat Yes it could, especially if there is a separate process for every TLS session. – ruief Jul 13 '14 at 03:47
  • @ruief: Any idea what the performance implications would be for such a design, and whether it would increase susceptibility to denial-of-service attacks (even if handshakes would normally be a small part of system loading, a denial-of-service attacker could request an excessive number of handshakes). – supercat Jul 13 '14 at 16:36
  • Private key operations take time about 1ms or so (depending on algorithm, key length, type of CPU, clock rate...). Context-switching and sending a short data element (e.g. a hash to be signed, or a signature) between two process on the same machine, or between a process and the kernel, is more a matter of a few _micro_-seconds, so we are talking about an overhead of less than 1% here, even when the CPU spends most of its time doing asymmetric crypto (which is a DoS situation, not something normal). – Tom Leek Jul 13 '14 at 16:41
  • @TomLeek: In addition to the task-switching overhead, I would think there would also be some overhead with having the cryptography daemon ensure that it was only performing signing operations for legitimate clients. BTW, I just had another thought: would it be practical to have the crypto daemon, when system loading is high, switch to a mode where every few minutes it would generate and certify a new "temporary" private key, with a very short expiration, which it would then make available to clients? I would think that a key which only had to be valid for a few minutes... – supercat Jul 13 '14 at 16:46
  • ...could be quite a bit shorter than one which was supposed to remain unbreakable for years [my understanding is that SSL uses Diffie-Hellman for session-key exchange, so it remains forward secrecy even if the authentication key is broken--is that right?] Would SSL support such a design, or would too many clients be unable to enforce a short expiration time for keys (as an allowance for clock skew, etc.)? – supercat Jul 13 '14 at 16:48
  • @supercat: well, you have just described "DHE" cipher suites as commonly used in SSL. With a DHE cipher suite, the server sends a DH public key that the server signs with its "permanent" private key (often some RSA private key). The server can create a new DH key pair for each connection ! It is not very expensive, and clients don't expect the key to stay the same; they don't record it anywhere. – Tom Leek Jul 13 '14 at 16:52
  • @TomLeek: Interesting. Would a DH key be required for each connection, or would it be acceptable to share them among all connections that are performed within a certain period of time? If the latter, that would seem like it could help guard against DOS attacks, since the effort spent creating DH keys would be constant, and I would expect the effort to sign session keys would be less than with conventional means. – supercat Jul 13 '14 at 17:19
  • The (RSA) signature must be made anew for each connection, because that which is signed includes the DH public key, but also the client and server "randoms" (from the `ClientHello` and `ServerHello` messages), which change for each handshake. However, the DH key can be shared and reused (though the point of DHE is that the DH private key is never saved on a non-volatile medium). Since cost of generating a new DH key pair is similar to that of a RSA signature, and so is finalizing the DH key exchange, making a new key-pair for each handshake would account for at most 1/3rd of total cost. – Tom Leek Jul 13 '14 at 17:30