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:
- confidentiality/privacy (encryption)
- authenticity (proof of identity of one or both parties)
- 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?