5 ms·

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

by darkr 11y ago

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.

feld 11y ago
But STARTTLS is a step backwards because a MITM can disable crypto by not advertising STARTTLS
- 0x0 11y ago
  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.
  - lox 11y ago
    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.
  - mschuster91 11y ago
    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.
    - feld 11y ago
      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 http://secspider.verisignlabs.com/stats.html
  - feld 11y ago
    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.html https://www.fastmail.com/help/technical/servernamesandports....
    - 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?

by darkr 11y ago

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.

feld 11y ago

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

0x0 11y ago
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.
- lox 11y ago
  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.
- mschuster91 11y ago
  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.
  - feld 11y ago
    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 http://secspider.verisignlabs.com/stats.html
- feld 11y ago
  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.html https://www.fastmail.com/help/technical/servernamesandports....
  - 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?