Hacker News Reader

Comment by yid | Hacker News Reader

> However the stakeholders simply don't care enough to do anything about it,

Perhaps that's a sign that "it" (smtp) now works well enough with the decades of engineering investment put into spam detection, access, standardization and inter-operability that have been put into it to not justify the massive investment that an "SMTP update fit for 2015" would involve.

View on HN

> spam detection, access, standardization and inter-operability

Spam detection works on a higher level than transport security, it is independent from transport (although a spam classifier might favor mails from SMTP servers sent with SSL and a client certificate signed by a CA for its domain name).

Access... well, that's IMAP/POP3's job, both support SSL for ages.

Standardization/interop, uh we already have SMTPS. The standard is there, what's lacking is support for inter-server encryption.

SMTPS has been deprecated since forever (late 90's or thereabouts). The standards for encrypted SMTP are: STARTTLS over port 25 for transfer/relay and STARTTLS over port 587 for submission.

But STARTTLS is a step backwards because a MITM can disable crypto by not advertising STARTTLS

A MITM could also deny SMTPS ports. If you want to ensure STARTTLS is in use then most smtp software has a setting to force STARTTLS or drop the connection.

My understanding that the issue is that attackers will then just do STARTTLS with their own self-signed certificate, as checking the common name of the certificate is difficult in the context of SMTP.

Well, use DNSSEC and add a new field in the DNS (e.g. CRYPTINFO = FORCE-HTTPS, FORCE-SMTPS). That would take time to spread, yes, but it would be a perfect solution for a lot of "prevent MITM downgrade" issues.

Yes, it would take a long time to spread considering there's a whopping 388 domains out there using DNSSSEC for SMTP, the majority of them run by neckbeards and not commerical email services.

    388 	Zones have deployed TLSA for SMTP with STARTTLS (Port 587)

I don't expect this to catch on, ever.

http://secspider.verisignlabs.com/stats.html

That's fine. They can deny it. At least you won't be MITM. I'd rather have no service than compromised service.

Look at Fastmail. They don't even offer STARTTLS. Why? Because of downgrade attacks!

    SSL/TLS Encryption	Enabled, but not STARTTLS

https://www.fastmail.com/help/technical/servernamesandports....

What I'm saying is that there's no difference in STARTTLS and SMTPS. In either case, the client should drop the connection if it doesn't manage to negotiate the desired transport encryption.

Whether that happens because it doesn't get the expected response to STARTTLS or because the SMTPS port fails to respond with a proper TLS handshake is the same.

A "downgrade attack" only works if the client decides to keep going after failing to establish encryption. This is a client policy configuration issue, and has nothing to do with whether one uses the bytes "HELO server\r\nSTARTTLS\r\n" or a raw TLS handshake to negotiate the connection after opening the TCP port.

STARTTLS exists as an opportunistic encryption upgrade, not enforcement. If a MITM strips the advertisement of STARTTLS (very, very simple to do) the client and server will both happily continue plaintext communications.

This is the default for every mail server I've ever seen.

This is the default for every mail client I've ever seen.

How are people not terrified of this?

Mind you, this is literally what a Cisco PIX/ASA firewall does when you enable the "esmtp inspect" feature. It strips the STARTTLS so everyone falls back to plaintext and it can "scan" your email communications for Bad Things^TM.

    When Cisco ASA is configured for ESMTP inspection, the ASA is not able to examine
    the TLS session because it is encrypted. Therefore the ASA will prevent the 
    establishment of the STARTTLS session and allow the SMTP endpoints to determine
    whether the SMTP session should continue in clear text (that is, with no privacy).

This is very normal. I can't remember the last time I encountered a small business with a Cisco PIX/ASA that didn't have this enabled.

http://www.cisco.com/web/about/security/intelligence/asa_esm...

edit: Oh hey, look at Postfix's documentation

    Mandatory TLS encryption: announce STARTTLS support to remote SMTP clients,
    and require that clients use TLS encryption. According to RFC 2487 this 
    MUST NOT be applied in case of a publicly-referenced SMTP server. Instead,
    this option should be used only on dedicated servers.

http://www.postfix.org/postconf.5.html#smtpd_tls_security_le...

There's literally an RFC that says DO NOT ENFORCE TLS ENCRYPTION WITH STARTTLS TO THE PUBLIC INTERNET

   A publicly-referenced SMTP server MUST NOT require use of the
   STARTTLS extension in order to deliver mail locally.

Case closed, SMTP security is broken. The deprecation of SMTPS was either a mistake or a carefully crafted NSA move. Who knows?

It's configurable, as you say. Maybe I don't understand your argument "at least you won't be MITM'ed". Almost nobody runs SMTPS anyways. I'm just saying that if someone decides they want to enforce encrypted SMTP, it really doesn't matter if that is implemented as mandatory STARTSSL vs SMTPS. One is not more suspectible to MITM than the other.

You missed my edit. The RFC clearly states you are not to enforce encrypted SMTP with STARTTLS to the public internet.

You don't enforce STARTTLS receiver-side (smtpd). You enforce it sender-side (smtp) by looking up the receiver's policy using DNSSEC/DANE. This is allowed by the RFC and is implemented in Postfix. I've been running this on my personal mailservers for over a year.

All you need is a DNSSEC resolver and two lines of Postfix configuration to get it working:

    smtp_dns_support_level = dnssec
    smtp_tls_security_level = dane

http://www.postfix.org/postconf.5.html#smtp_tls_security_lev...

Reply on news.ycombinator.com