4 ms·
> 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 e
by yid 11y ago
> 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.
- mschuster91 11y ago> 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.
- darkr 11y agoSMTPS 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 agoBut STARTTLS is a step backwards because a MITM can disable crypto by not advertising STARTTLS
- 0x0 11y agoA 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 agoMy 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 agoWell, 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 agoYes, 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 agoThat'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 agoWhat 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.