STARTTLS Considered Harmful

Blog

August 12, 2014

STARTTLS Considered Harmful

There are two ways that otherwise plain text protocols can provide encryption with TLS. The first way is to listen on two ports: one port that is always plain text, and a second port that is always encrypted with TLS. The other way is to use a single port on which communication starts out unencrypted, but can be "upgraded" to a TLS encrypted connection using an application-level command specific to the protocol. HTTP/HTTPS uses exclusively the first approach, with ports 80 and 443. The second approach, called STARTTLS, is used by SMTP, XMPP, IMAP, and POP3, though several of those protocols also support the first approach.

There's a clear bias for STARTTLS in the IETF's email standards. The use of alternative TLS-only ports for IMAP, POP3, and SMTP was never formally standardized: people just started doing it that way, and although port numbers were registered for the purpose, the registration of the encrypted SMTP (SMTPS) port (465) was later rescinded. When the IETF finally standardized the use of TLS with IMAP and POP3 in 1999, they prescribed the use of STARTTLS and gave several reasons why STARTTLS should be used instead of an alternative TLS-only port. Briefly, the reasons are:

Separate ports lead to a separate URL scheme, which means the user has to choose between them. The software is often more capable of making this choice than the user.
Separate ports imply a model of either "secure" or "not secure," which can be misleading. For example, the "secure" port might be insecure because it's using export-crippled ciphers, or the normal port might be using a SASL mechanism which includes a security layer.
Separate ports has caused clients to implement only two security policies: use TLS or don't use TLS. The desirable security policy "use TLS when available" would be cumbersome with the separate port model, but is simple with STARTTLS.
Port numbers are a limited resource.

Except for reason four, these reasons are pretty terrible. Reason one is not very true: unless the software keeps a database of hosts which should use TLS, the software is incapable of making the choice between TLS and non-TLS on behalf of the user without being susceptible to active attacks. (Interestingly, web browsers have recently started keeping a database of HTTPS-only websites with HSTS preload lists, but this doesn't scale.)

Reason three is similarly dubious because "use TLS when available" is also susceptible to active attacks. (If the software detects that TLS is not available, it doesn't know if that's because the server doesn't support it or if it's because an active attacker is blocking it.)

Reason two may have made some sense in 1999, but it certainly doesn't today. The export cipher concern was mooted when export controls were lifted in 2000, leading to the demise of export-crippled ciphers. I have no idea how viable SASL security layers were in 1999, but in the last ten years TLS has clearly won.

So STARTTLS is really no better than using an alternative TLS-only port. But that's not all. There are several reasons why STARTTLS is actually worse for security.

The first reason is that STARTTLS makes it impossible to terminate TLS in a protocol-agnostic way. It's trivial to terminate a separate-port protocol like HTTPS in a software proxy like titus or in a hardware load balancer: you simply accept a TLS connection and proxy the plain text stream to the backend's non-TLS port. Terminating a STARTTLS protocol, on the other hand, requires the TLS terminator to understand the protocol being proxied, so it can watch for the STARTTLS command and only upgrade to TLS once the command is sent. Supporting IMAP/POP3/SMTP isn't too difficult since they are simple line-based text protocols. (Though you have to be careful - you don't want the TLS terminator to misfire if it sees the string "STARTTLS" inside the body of an email!) XMPP, on the other hand, is an XML-based protocol, and do you really want your TLS terminator to contain an XML parser?

I care about this because I'd like to terminate TLS for my SMTP, IMAP, and XMPP servers in the highly-sandboxed environment provided by titus, so that a vulnerability in the TLS implementation can't compromise the state of my SMTP, IMAP, and XMPP servers. STARTTLS makes it needlessly difficult to do this.

Another way that STARTTLS harms security is by adding complexity. Complexity is a fertile source of security vulnerabilities. Consider CVE-2011-0411, a vulnerability caused by SMTP implementations failing to discard SMTP commands pipelined with the STARTTLS command. This vulnerability allowed attackers to inject SMTP commands that would be executed by the server during the phase of the connection that was supposed to be protected with TLS. Such a vulnerability is impossible when the connection uses TLS from the beginning.

STARTTLS also adds another potential avenue for a protocol downgrade attack. An active attacker can strip out the server's advertisement of STARTTLS support, and a poorly-programmed client would fall back to using the protocol without TLS. Although it's trivial for a properly-programmed client to protect against this downgrade attack, there are already enough ways for programmers to mess up TLS client code and it's a bad idea to add yet another way. It's better to avoid this pitfall entirely by connecting to a port that talks only TLS.

Fortunately, despite the IETF's recommendation to use STARTTLS and the rescinding of the SMTPS port assignment, IMAP, POP3, and SMTP on dedicated TLS ports are still widely supported by both server and client email implementations, so you can easily avoid STARTTLS with these protocols. Unfortunately, the SMTPS port is only used for the submission of authenticated mail by mail clients. Opportunistic encryption between SMTP servers, which is extremely important for preventing passive eavesdropping of email, requires STARTTLS on port 25. And modern XMPP implementations support only STARTTLS.

Moving forward, this shouldn't even be a question for new protocols. To mitigate pervasive monitoring, new protocols should have only secure versions. They can be all TLS all the time. No need to choose between using STARTTLS and burning an extra port number. I just wish something could be done about the existing STARTTLS-only protocols.

Older (View Archive)

LibreSSL's PRNG is Unsafe on Linux [Update: LibreSSL fork fix]

Newer

SHA-1 Certificate Deprecation: No Easy Answers

Comments

Reader George on 2014-08-13 at 07:54:

With the recent backtracking of IETF from making HTTP 2.0 strictly HTTPS, I'm not too hopeful that new protocols would only have secure versionns.

Andrew Ayer on 2014-08-13 at 14:24:

You may be right, but HTTP 2.0 isn't a great example because it's not an all new protocol but rather an update to an existing protocol that has been widely deployed without TLS.

Reader Charles on 2014-08-13 at 11:41:

thanks. Very interesting. One question: how can a client protect itself against a TLS downgrade attack? How can it tell the difference between an SMTP server that has TLS but with a man in the middle and an SMTP server with no TLS?

Reader Charles on 2014-08-13 at 11:43:

And an additional question: do you know if smtp clients usually do have protections against downgrade attacks?

Andrew Ayer on 2014-08-13 at 14:41:

If by "SMTP client" you mean a mail user agent (MUA) like Thunderbird, Mail.app, Outlook, etc., then I think the popular ones probably do it correctly. I'd be concerned about less popular ones that have received less scrutiny.

If by "SMTP client" you mean a mail transfer agent (MTA) that's sending mail server-to-server, then they intentionally allow downgrades, because not all MTAs accept mail over TLS. Since this is intentional and currently unavoidable, I'm not really talking about this case. I'm more concerned with the client to server scenario which is virtually always expected to be secure.

Reader Charles on 2014-08-13 at 15:41:

I guess most of the MUA these days are mobile phones. I would be surprised if clients like Thunderbird are still used massively (and when they are, they are usually connected inside a protected corporate environment).

I was referring to both actually. Would the gmail MTA be exposed to MITM attacks when delivering an email to an smtp server? This is a pretty big weakness as we know private communications is the focus of sovereign spying. Is there any real danger these days to not allowing an unencrypted connection? Surely no reputable smtp MTA wouldn't support TLS, only spammer bots.

Andrew Ayer on 2014-08-14 at 03:38:

Would the gmail MTA be exposed to MITM attacks when delivering an email to an smtp server?

Yes, gmail's MTA intentionally lets itself downgrade, which is vulnerable to MITM attacks. Unfortunately many legitimate email servers still don't support TLS. Fortunately, Google is leading the way in trying to get other providers to support TLS <https://www.google.com/transparencyreport/saferemail/>.

Reader Charles on 2014-08-14 at 09:00:

The google link is a bit of an eye opener. These are pretty major ISP who don't bother crypting any of their customers correspondence. And would be curious to know how many of the ISP who crypt their traffic actually check the validity of the certificates.

Some see the NSA as a predator, but it is really a fox helping itself in an open henhouse!

Andrew Ayer on 2014-08-14 at 16:28:

You raise yet another issue, which is checking certificates. I would guess that virtually no email provider checks certificates. The problem is that there's no way to know what the name on the certificate should be. Ideally it would match the domain of the email address you're sending to, but this is rarely the case because domains usually delegate their mail to servers under other domains using MX records. And without DNSSEC, the MX delegation is completely unauthenticated, making it pointless to check that the certificate name matches the name in the MX record.

For example, gmail.com's smallest-priority MX server is `gmail-smtp-in.l.google.com`. The names on `gmail-smtp-in.l.google.com`'s certificate are:

DNS:aspmx.l.google.com, DNS:alt1.aspmx.l.google.com, DNS:alt2.aspmx.l.google.com, DNS:alt3.aspmx.l.google.com, DNS:alt4.aspmx.l.google.com, DNS:gmail-smtp-in.l.google.com, DNS:alt1.gmail-smtp-in.l.google.com, DNS:alt2.gmail-smtp-in.l.google.com, DNS:alt3.gmail-smtp-in.l.google.com, DNS:alt4.gmail-smtp-in.l.google.com, DNS:gmr-smtp-in.l.google.com, DNS:alt1.gmr-smtp-in.l.google.com, DNS:alt2.gmr-smtp-in.l.google.com, DNS:alt3.gmr-smtp-in.l.google.com, DNS:alt4.gmr-smtp-in.l.google.com, DNS:mx.google.com, DNS:aspmx2.googlemail.com, DNS:aspmx3.googlemail.com, DNS:aspmx4.googlemail.com, DNS:aspmx5.googlemail.com.

gmail.com doesn't appear anywhere in that list. So even though the name of the MX server does appear in that list, since the MX record lookup was unauthenticated, a program has no way of knowing that `gmail-smtp-in.l.google.com` is `gmail.com`'s true MX server, and not a bogus server set up by an active attacker who can manipulate DNS.

Reader Jarek on 2014-08-13 at 13:30:

One question: how can a client protect itself against a TLS downgrade attack? How can it tell the difference between an SMTP server that has TLS but with a man in the middle and an SMTP server with no TLS?

Using DANE records in DNSSEC. It's quite recent thing, and DNSSEC still isn't such widely deployed, but it's supported by both Postfix and Exim SMTP servers (I think it's disabled by default, though).

Reader Charles on 2014-08-13 at 14:25:

So am I right to understand that the DANE record would say "this SMTP server supports TLS" and therefore a client would not accept an unencrypted connection with this server even if the server responds it does not support TLS.

But the article says that "it's trivial for a properly-programmed client to protect against this downgrade attack". I presume the author wasn't referring to using DANE records (which as you point is not widely supported)?

Reader Jarek on 2014-08-13 at 21:59:

Yes, DANE can do that. Also, it can specify CA signing the server certificate (because even if TLS is enforced, attacker can MITM the connection, as certificates aren't validated. Without DANE they can't, because there is no common database of trusted CAs and each server trusting other CAs would lead to chaos and unreliability). For instance, for the Postfix implementation see http://www.postfix.org/TLS_README.html#client_tls_dane.

It's not only not trivial, but also impossible for a client to protect against downgrade attacks without additional tricks. Those tricks can include DANE, manual configuration (not scalable) and some magic caching (but I wouldn't say it'd be a properly-programmed client, what would happen if remote server simply turns off TLS?). And even with the insane-magic-caching, we still have the common trust anchor problem. So well... the author is wrong here (at least in SMTP case, interactive clients or freshly designed protocols might be in better position).

As for wide support... It's supported by two very (most?) popular SMTP servers (Postfix and Exim), so it's not that bad. But it appeared only recently (is available only in relatively fresh versions) and requires additional configuration (especially validating DNSSEC resolver). But bigger problem is on the other side (target) -- it's not widely deployed.

But it has to ba said, that even the opportunistic encryption with possible downgrade attacks is beneficial. Often the monitoring is passive (attacker just sniffs received traffic without tampering it) and downgrade attacks require active MITMing. So, while not perfect, it's still better than nothing.

Reader Lie on 2016-04-26 at 15:33:

Downgrade attack is trivial to protect, a client will simply require STARTTLS and simply drops the connection when the server does not support ESMTP and encryption.

DNSSEC and DANE protects against different vulnerabilities, which is that MUAs and MTAs can't reliably verify the server certificates. In the DNSSEC and DANE scenario, the attacker MITM the encrypted connection and it receives encrypted connection from the client and then makes encrypted connection to the mail server. In other words, even if both client and server refuses unencrypted connection, that is all futile if the client cannot verify the server's certificate. DNSSEC signs DNS record to protect DNS record from being tampered by malicious or compromised recursive DNS resolvers, and DANE embeds the TLS certificate inside DNSSEC-signed records to avoid reliance on CA, whose security model is totally broken for emails. Additionally, there's also DNSCrypt/DNSCurve that encrypts the connection to the DNS server to protect privacy against eavesdropping.

Andrew Ayer on 2014-08-13 at 14:35:

The client has to know that the server supports TLS somehow. Someone else mentioned DNSSEC+DANE, but that's not widely deployed and it's questionable whether it ever will be.

In practice the way it works with mail clients is you tell it when configuring your account. For example Thunderbird has a drop-down box called "Connection Security" with the options "None", "STARTTLS", and "SSL/TLS". (Many mail clients have something similar.) The concern is that the "STARTTLS" would be vulnerable to the downgrade attack, while "SSL/TLS" wouldn't be. (Note: I'm extremely confident Thunderbird does this correctly. The concern is with other, less widely used software.)

Reader Pino on 2017-12-09 at 17:49:

I would expect "STARTTLS" to mean "Connect unencrypted, and disconnect if STARTTLS fails." Is that what happens in current Thunderbird?

Anonymous on 2014-08-13 at 12:32:

"prescribed", not "proscribed". They're opposites.

Andrew Ayer on 2014-08-13 at 14:20:

Thanks for the correction!

Reader Bron Gondwana on 2014-08-13 at 21:31:

Nice to see more awareness of this issue. We have blogged on this at FastMail as well, and it's the reason that we ONLY support the SSL ports for IMAP and POP3.

https://www.fastmail.fm/help/technical/ssltlsstarttls.html

Cheers,

Bron.

Reader Dave Cridland on 2014-10-18 at 20:04:

OK, so I think you're wrong, but where to start? Mostly, I think you've decided that you want to write Titus in a certain way, and since STARTTLS doesn't allow you to do this, therefore STARTTLS is bad.

So first off: Most protocols using STARTTLS involve relatively few client/server pairings. It's not clear whether STARTTLS would have been useful on the web - I suspect it would have been, but history didn't go that way - but the web does have the issue that there are a vast number of services to track. But an XMPP client (or an MUA) can, trivially, know which services offer TLS. STARTTLS allows clients to discover this trivially, without user interaction, and additionally allows this information to be cached. It's best to think of STARTTLS advertising as - like SASL mechanism advertising - a once-only, account-configuration thing. After that mental adjustment, you're really down the the counter-argument that it's an additional round-trip, and I can argue that one with you as well if you really want.

A key factor in the "different URI" debate is that I have no way of knowing whether https://www.google.co.uk/ is the same service as http://www.google.co.uk/ - the differing scheme actually imposes that a client must assume otherwise. On the other hand, STARTTLS protocols are effectively mandated to offer the same service (though many refuse access to non-protected sessions).

Finally, while SNI has helped, there are protocols which need application data to select the correct certificate to use.

I do agree that TLS is now the only interesting security layer, however - while GSSAPI still gives you good security, most people will want TLS.

It might help, though, to understand that there's lots of other things Titus can't do because of its nature. It can't handle outgoing sessions, it can't handle certificate selection outside SNI, it can't handle client authentication, it cannot let a server note an improper TLS shutdown, it prevents channel binding, and so on. Every one of these things is important.

Many of these things are impossible to implement if Titus is the dumb pass-through it currently is. I shall leave it as a trivial exercise to the reader to figure out an architecture that supports them - and incidentally support STARTTLS - without including a protocol parser.

Andrew Ayer on 2014-10-23 at 03:07:

OK, so I think you're wrong, but where to start? Mostly, I think you've decided that you want to write Titus in a certain way, and since STARTTLS doesn't allow you to do this, therefore STARTTLS is bad.

titus was the impetus for this blog post, but I had disliked STARTTLS long before I wrote titus, and I present other, unrelated arguments for why STARTTLS is a bad idea.

But an XMPP client (or an MUA) can, trivially, know which services offer TLS. STARTTLS allows clients to discover this trivially, without user interaction, and additionally allows this information to be cached. It's best to think of STARTTLS advertising as - like SASL mechanism advertising - a once-only, account-configuration thing.

This isn't secure, because a MitM can strip the STARTTLS advertisement, so a user has to know, and specify, whether a service supports TLS or not. It's OK for opportunistic encryption, and caching does help, but you don't need STARTTLS for this. The insecure service could advertise the presence of a secure service on a different port, and the client could then reconnect with TLS on that port. This is essentially how HTTP and HTTPS work, when you redirect a HTTP connection to a HTTPS URI.

A key factor in the "different URI" debate is that I have no way of knowing whether https://www.google.co.uk/ is the same service as http://www.google.co.uk/ - the differing scheme actually imposes that a client must assume otherwise

I really don't think that's a practical concern, and it's already a widely-followed convention that these different URIs are the same service. Besides, moving forward we should be phasing out our insecure services, so there will only be one URI anyways.

Finally, while SNI has helped, there are protocols which need application data to select the correct certificate to use.

SNI should definitely handle that, especially if proposals to encrypt the SNI name come to fruition.

It might help, though, to understand that there's lots of other things Titus can't do because of its nature. It can't handle outgoing sessions, it can't handle certificate selection outside SNI, it can't handle client authentication, it cannot let a server note an improper TLS shutdown, it prevents channel binding, and so on. Every one of these things is important.

It's true that titus can't handle these but fortunately they aren't that important. Can you point to a widely-used protocol on the Internet where any of these things are important? (I'll concede outgoing SMTP connections over TLS.)

Many of these things are impossible to implement if Titus is the dumb pass-through it currently is. I shall leave it as a trivial exercise to the reader to figure out an architecture that supports them - and incidentally support STARTTLS - without including a protocol parser.

Any other solution would require modifications to the application. I am actually working on the design of a "libtitus" that would let applications easily initiate titus-secured outgoing connections, or accept incoming connections with client certificates. But modifying applications isn't always possible, and we've got many widely-used Internet protocols which don't typically use client certificates, channel binding, etc. where a dumb pass-through would be completely sufficient if not for the fact that they are needlessly using STARTTLS to immediately upgrade a connection which could have been TLS in the first place.

Anonymous on 2014-11-18 at 23:01:

Hi Andrew

Yes, downgrade attacks are already done by at least one ISP: http://arstechnica.com/tech-policy/2014/11/condemnation-mounts-against-isp-that-sabotaged-users-e-mail-encryption/

This line caught my eye from your post Andrew: "Opportunistic encryption between SMTP servers, which is extremely important for preventing passive eavesdropping of email, requires STARTTLS on port 25"

Now, I have been using 465 port with SSL for ages when sending mail.

So does this mean that unless I use port 25 with STARTTLS there is never going to be opportunistic encryption between SMTP servers if I continue using 465 ? I mean, even tought my mail will be encrypted between my client and server, the continuing server-to-server delivery is not going to be encrypted if not using port 25?

Andrew Ayer on 2014-11-19 at 16:55:

So does this mean that unless I use port 25 with STARTTLS there is never going to be opportunistic encryption between SMTP servers if I continue using 465 ? I mean, even tought my mail will be encrypted between my client and server, the continuing server-to-server delivery is not going to be encrypted if not using port 25?

Generally mail servers don't accept mail from other MTAs over port 465, just mail from authenticated MUAs, so if you try to use it for server-to-server delivery your mail might be encrypted but it won't go anywhere. I doubt this will change, especially since port 465 is unofficial and has actually been reassigned by IANA.

That makes port 25 the only viable option for server-to-server delivery. Some mail servers don't support STARTTLS on port 25 at all, in which case your mail to them will be unencrypted. Others servers support STARTTLS, but if your ISP or another active attacker MitMs the connection, your mail to that server will be compromised. This is regardless of what port your MUA uses to submit mail.

The status quo is that there is approximately zero authenticated encryption of server-to-server email delivery because of backwards compatibility with mail servers that don't support any encryption, as well as a lack of a standard for how certificates names for SMTP servers should work. Possible solutions are DNSSEC+DANE (which Postfix already supports) and/or the EFF's STARTTLS Everywhere project: https://github.com/EFForg/starttls-everywhere

Reader Gary Mort on 2015-05-05 at 16:06:

There is an invalid premise, you have assumed that using TLS means the communication is secure. Due to the root certificate structure, in the real world TLS security is situational. Since a certificate issued by ANY root CA is considered just as valid as any other root CA, it is simple to compromise[implementation may or may not be difficult, but the technical process itself is simple]. The long running CNNIC controversy shows that the root process is flawed and it took 5 years to reach the point where they got sloppy and were exposed. [Since they control much of the TCP/IP infrastructure in their country, it is trivial for them to provide redirect traffic to their own proxies and provide fake certificates only for targeted individuals - something they have already been caught doing in the past]

As such, using the word "secure" when referring to any central authority registration scheme is demonstrably false. What so called security experts mean is "it is secure, assuming that...." and their long standing avoidance of mentioning the assumptions they based it on makes most security professionals opinions worthless.

Starttls is an interesting protocol in that it gives the end user simple access to make a choice of how "secure" they want their communications to be, Always use, Prefer to use, or Do not use.

Most of the other "options" built into TLS and other protocols are not provided in any meaningful way for the end user[who is the one who should be making the decisions about what they want].

Andrew Ayer on 2015-05-05 at 16:30:

Security nihilism at its finest.

In reality, there is a large class of attackers who are thwarted by mandatory, authenticated encryption, but have no problem at all attacking opportunistic encryption. To suggest that we aim for the lesser level of security because there may be some attackers who can break the higher level of security is ridiculous.

Reader Mike Spooner on 2017-08-27 at 11:23:

Re "dedicated TLS ports are still widely supported by ... client email implementations".

On the desktop and perhaps tablets too, that assertion is mostly accurate, but on mobile ('droid phones, iOS) it really isn't, even as late as 2017... most such apps give encryption config choices of "TLS", "TLS (dont check certificate)" or "None" - however, this almost always actually means "STARTTLS" or "None", and not straight TLS.

Frustrating!

Andrew Ayer

Sections

Blog