6 ms·

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 STARTTL

• 0x0 11y ago
  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.
  • 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 ago
      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.
      • feld 11y ago
        You 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 ago
      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_level http://www.postfix.org/postconf.5.html#smtp_tls_security_lev...