3 ms·
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
by feld 11y ago
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_esmtp_starttls.html 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_level 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?
- 0x0 11y agoIt'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.
- feld 11y agoYou missed my edit. The RFC clearly states you are not to enforce encrypted SMTP with STARTTLS to the public internet.
- deleted 11y ago[deleted]
- dlitz 11y agoYou 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_level http://www.postfix.org/postconf.5.html#smtp_tls_security_lev...