7

After reading about STARTTLS and SSL and performing a scan/pentest at our server I have the next question regarding security: Is this STARTTLS warning below a security-vulnerability? And if so why?

As far I understand STARTTLS, it means:

Encrypt if both sides support encryption, else use unencrypted connection

and SSL:

Always use encryption, if one side of the connection does not support SSL don't connect at all.

My scan resulted in the next warning:

The remote SMTP service supports the use of the 'STARTTLS' command to switch from a plaintext to an encrypted communications channel.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Rob
  • 381
  • 3
  • 12

4 Answers4

8

SMTP with STARTTLS itself is not a vulnerability, though it offers a larger attack surface given the complexity of the typical TLS implementation. If you don't need it, turn it off (NIST SP800-123 §4.2.1 PDF).

If you're relying on SMTP+STARTTLS alone for communications confidentially, it's easy to get it wrong.

STARTTLS protocols (LDAP, FTP more or less, POP3 & IMAP, even HTTP which Apache supports, though it never caught on) are inherently trickier to manage from security policy and firewall perspectives. For example if you have a rule permitting HTTPS to a correctly configured web server, all a firewall need do is verify/enforce SSL/TLS records.

With STARTTLS protocols, to ensure encryption with a similar level of confidence you must have either greater protocol inspection (may not be available on your firewall, may require a proxy); or a far greater faith in the client and server implementations (e.g. to prevent sending or accepting plain text credentials).

The above point is more or less what the warning was about: with a strict TLS protocol like HTTPS you can be more confident (NULL ciphers aside) in the connection encryption than with STARTTLS and the possibly optional negotiation of encryption. It is a risk that needs to be evaluated, not a vulnerability.

The typical (non-client auth) SMTP+STARTTLS configuration (from my experience) is:

  • opportunistic STARTTLS
  • fall back to clear text on error, or when STARTTLS missing
  • has poor defaults (cipher selection, certificate validation)

To properly use STARTTLS to increase communication security you have to consider DNS, the elphant in the room, MX backups and MX override ("mailertable").

A client-auth (SMTPAUTH) server with STARTTLS is easier to secure if it's just to enable roaming client authenticate securely (via client certificate, username/password, or both) for relaying purposes.

An ideal secure channel implementation offers (at least) three things:

  1. confidentiality/privacy (encryption)
  2. authenticity (proof of identity of one or both parties)
  3. integrity (tamper-proof, or tamper-evident)

SMTP+STARTTLS deviates from this:

  • since the communication starts over, and relies on, an unauthenticated, corruptable plain text channel, there is scope for MITM interference. If STARTTLS is opportunistic, this means it could be trivially subverted (if you've ever seen a Cisco PIX or ASA doing its SMTP protocol "fixups" you'll have seen something similar in action). Similar problem if certificate validation is lax.
  • SMTP is a store-and-forward protocol, the TLS capability is only point to point, there is no HTTP proxy-like "CONNECT" feature. i.e. this is not end-to-end encryption. Confidentiality, authentication and integrity are limited to the connection(s), not the message, which might not be what a user expects or requires. See also How can a non-technical user verify a message was sent "securely"? ...or over TLS?
Community
  • 1
mr.spuratic
  • 7,937
  • 25
  • 37
2

The idea is that you should enable SSL by default and not allow for plain text communication. STARTTLS means you have to explicitly tell the server to use SSL if you want to.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • 1
    This does not help if some applications do not work with ssl. – Rob Mar 14 '14 at 21:39
  • There's nothing conceptually wrong with starting a plaintext connection and then doing STARTTLS, compared to using TLS from the start. However it sounds like it's rarely implemented correctly. – user253751 Nov 07 '17 at 02:42
2

Technically, yes, offering an unencrypted channel means that information may be transmitted to/from your server insecurely. The problem is that not all mail servers provide encryption and if you want to receive from/send to a mail server that doesn't support encryption, you have to allow for this.

This does potentially allow a middle man to pretend like each end point doesn't support encryption and inject itself in the middle, but the alternative is, unfortunately, to fail a large portion of mail delivery.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
0

Before STARTTLS, initial handshake happens over plaintext, hence attacker sitting on the same network can forge server response and make the user feel that TLS handshake is unavailable with the server. That can result into a flaw.

FrOgY
  • 309
  • 1
  • 10