LWN: Comments on "SMTP Strict Transport Security"

SMTP Strict Transport Security

robbe — Tue, 26 Apr 2016 11:48:45 +0000

> That forged policy would, by necessity, include an a field similarly
> doctored to direct the client to an attacker-controlled server when
> authenticating the policy.

This is prevented by the following requirement (from section 3.3 of the linked draft):

| [...], and MUST be served from an HTTPS endpoint at the domain
| matching that of the recipient domain.

Maybe „matching“ could do with a better definition (does https://infected.example.com/... „match“ for example.com?), but it’s not as easy as pointing the client to https://evil.org/ outright.

The real attack scenario, and the reason, why SSTS, like HSTS, relies on caching, is the MITM attacker filtering DNS requests, so that the client never gets the TXT record. If the attacker is able to do this outright, the client will never learn the server’s SSTS policy. But once an unfiltered connection is made, the policy is loaded, verified, and cached … which makes subsequent attacks of this type fail.

SMTP Strict Transport Security

jond — Mon, 25 Apr 2016 08:37:38 +0000

You'd also need a rough idea of how many users each SMTP server had, to get an idea of how important they were. Otherwise my tin-pot SMTPd would carry the same weight as one of Gmail's.

SMTP Strict Transport Security

jond — Mon, 25 Apr 2016 08:35:55 +0000

> which, by the way, has already been reallocated to a different protocol years ago

Oh wow. I noticed that it said something different in `/etc/services` recently, but I hadn't put two-and-two together. I never turned off SMTPS. I'm pretty surprised they reallocated that port, it seems a bit premature.

Not up to LWN standards

Nikratio — Sun, 24 Apr 2016 22:29:56 +0000

I'm a little disappointed by this article, it doesn't meet the standards I've come to expect from LWN. Apart from being difficult to follow (in particular when the "fields" are listed out of the blue) it's rather misleading in some places. For example, whether the client verifies certificates of proceeeds with a plain connection if STARTTLS is intercepted is up to the client, and not a drawback of STARTTLS.

SMTP Strict Transport Security

raven667 — Fri, 22 Apr 2016 16:01:04 +0000

Doesn't that just break compatibility with existing servers if clients start blindly refusing to communicate with servers unless they have SMTPS/STARTTLS, without caching some minimum expectation of the security features that the server should be providing. You want clients and servers to be able to negotiate and speak any generation of the protocol, without renegotiating every time as that opens you up to trivial protocol downgrades.

A better question is why not just have clients cache the highest level of protocol you've detected for any particular server, and not allow negotiations to any lower version of protocol, my guess is that this has been thought through more clearly by the implementers who found that explicit notification from the server to engage this behavior fixes some corner cases. Many servers who offer STARTTLS today do so with invalid or expired certificates, I'm not even sure it's well defined what should be verified in the certificate to validate a connection today, you would not want clients to reject invalid certificates deployed today, but you would want to reject invalid certificates if the server owner has signaled that they expect them to be valid. Even better is that this policy signalling is out of band, via HTTPS or DNSSEC, that is harder to MITM today.

SMTP Strict Transport Security

neilbrown — Fri, 22 Apr 2016 02:59:59 +0000

The client must have made a deliberate choice to use SMTPS rather than SMTP.
I don't see how that it different to a deliberate choice to abort a connection if STARTTLS isn't offered, or fails.

Both ends of the connection can choose which levels of security are acceptable. A MITM attacker can always force the connection to use the lowest mutually acceptable level. The particular details of the negotiation are only of interest to implementers.

SMTP Strict Transport Security

raven667 — Fri, 22 Apr 2016 02:43:56 +0000

The distinction isn't between SMTPS and STARTTLS though, it's between enforced SMTPS and a downgrade attack where you never see the STARTTLS signal so silently fall back to plain text.

SMTP Strict Transport Security

neilbrown — Thu, 21 Apr 2016 22:11:52 +0000

> How it would help? It would help by removing the plain text component entirely from the equation in the long run.

I don't think you remove it, just reduce and hide it.

The TCP connection to this new port starts with "SYN" "SYN-ACK" , "ACK", which are all plain "text".
So the client will always have to send some data which is open to snooping and accept some which is open to forging. The only difference between SMTPS and STARTTLS is how the secure components are encapsulated. That isn't a very interesting difference.

SMTP Strict Transport Security

fredrik — Thu, 21 Apr 2016 21:40:18 +0000

How it would help? It would help by removing the plain text component entirely from the equation in the long run.

Yes, short term it wouldn't be any better than today, or today plus a slightly modified version of the SMTP-STS proposal. And yes, we'd need to establish a new port number for STMPS. And indeed, in the short term we would probably have to support the STARTTLS upgrade negotiable, but initially plain text, communication channel on port 25 too. As a deprecated fallback.

But, after a while I'm suggesting that many email admins would say: Hey, apart from legacy spam bots, I don't get a whole lot of authentic email over port 25. It all goes to the new port XX25/TLS. You know what, I'm just going to stop accepting email on port 25.

As a poor analogy, your ssh client doesn't bother checking if it can fallback to the telnet or rlogin port if it fails on port 22. It just fails with connection refused. That's my future, no plain text fallback to anything, just encrypt or fail. And no pointless plain text upgrade when all servers have made STARTTLS mandatory anyway.

How to compromise DNSSEC

shane — Thu, 21 Apr 2016 18:21:51 +0000

The article mentions:

"Thus, an attacker would have to compromise the DNSSEC server in addition to intercepting the SMTP handshake."

Just to be clear, a DNS server may or may not be a "DNSSEC server" (this is not a term that is normally used in DNS).

DNSSEC is designed so that the DNS servers can be compromised and it would still not allow an attacker to send unauthorized answers. The DNS zones can be signed offline or with a HSM (hardware security module), and in either case compromising the DNS server would not help, since the keys needed to make an invalid version of the zone are not available.

Some DNS servers do online signing (PowerDNSSEC works this way, as does the proprietary CloudFlare DNS service). Also, a lot of DNS servers do keep the keys on unencrypted disks (I run my own servers like this, because the operational annoyance doesn't justify the additional security gained for my vanity domains). In all of these cases a compromise of the DNS server would indeed allow an attacker to send the DNS answers that it wants to complete the attack on the SMTP service.

SMTP Strict Transport Security

josh — Thu, 21 Apr 2016 15:01:26 +0000

Has anyone done a survey of existing mail servers, to find out:

- How many support direct SMTPS connections on the SMTPS port?

- How many only support STARTTLS?

- Of each of those two categories, how many use a certificate that doesn't validate for the mail server's domain?

SMTP Strict Transport Security

eduard.munteanu — Thu, 21 Apr 2016 14:53:26 +0000

I don't get it. If anything, a secured connection is client policy. If the server claims not to support it, then you have two scenarios:

1. You're an opportunistic user - you do choose to fall back to unsecured SMTP, but you don't really need a secure connection anyway

2. You mandate a secure connection - you don't fall back and do not use the service

A man in the middle can deny service, but we already knew that.

SMTP Strict Transport Security

raven667 — Thu, 21 Apr 2016 14:49:56 +0000

> You still need a way of knowing whether the server supports the new security protocol,

Thats where the reference to STS comes in, you add a new capability flag to EHLO that signifies that all further communication with that server should happen over TLS directly, so the first connection caches that information and all subsequent connections can't be downgraded because they aren't relying on checking for a cleartext STARTTLS flag every time. Of course if the first connection you make strips this info, then you can be downgraded, just like with SSH or other protocols that cache security relevant information on first connection, but that's a different kind of risk.

Over time you can switch clients to TLS by default and will see fewer and fewer clients who need the hinting or require the fall back cleartext protocol, giving you a real sense of when you can safely sunset to old protocol.

SMTP Strict Transport Security

grawity — Thu, 21 Apr 2016 08:44:29 +0000

How would it help?

You still need a way of knowing whether the server supports the new security protocol, whether it's STARTTLS or the traditional SMTPS-on-465 (which, by the way, has already been reallocated to a different protocol years ago).

If firewalls can strip the string "STARTTLS" from packet data, it's even easier to block all TCP port 465 connections. A fake TCP RST is nearly indistinguishable from a real one, and once you receive an -ECONNREFUSED, you have to fall back to regular port 25 anyway, because the world isn't going to enable SMTPS in a blink.

As for "the regular TLS certificate trust infrastructure for HTTPS, or DANE, could then be reused…", well, isn't that exactly the same as now?

SMTP Strict Transport Security

fredrik — Thu, 21 Apr 2016 07:21:42 +0000

Why not instead revive SMTPS, TLS-wrapped SMTP over port 465, again? The regular TLS certificate trust infrastructure for HTTPS, or DANE, could then be reused to secure email delivery too.

It seems a waste to use a legacy clear text protocol solely for the purpose to upgrade with STARTTLS, when you can just as well initiate TLS immediately on first connect.

I'm sure that if the big players agreed to use SMTPS by default, and deploy a HTST-like solution to deprecate the use of the regular port 25, the internet as a community could obsolete a clear text, downgrade and MIM attack vulnerable infrastructure in a few years.

I wouldn't have thought a large shift proposal like that was possible a few years ago. Through recent years trend to migrate to HTTPS by default on most big services, HTST, HTTP/2 being TLS mostly, and Lets encrypt, we've seen that better standards can be introduced very quickly when the big players agree on sensible non-proprietary solutions and lead the way.

Aside from that I'm happy to see that DANE is included in the proposal as an alternative to the use of the more or less broken certificate trust chain infrastructure.