Interestingly, this is another security issue with STARTTLS. The whole concept of first establishing an unencrypted connection and only then upgrading to encryption is fragile in multiple ways.
Admittedly, this is a pet peeve of mine, as I've co-authored a paper about it. I wonder why mailbox.org does not recommend that users switch from STARTTLS to implicit TLS for SMTP/POP3/IMAP, as this would mitigate such issues more generally. This is also in line with current RFCs (RFC 8314).
Thank you for writing this, I use it as a reference when explaining the difference STARTTLS and implicit TLS and why people should choose one over the other.
Another nice one is that implicit TLS is SNI routable (and thus much easier to route) -- this is the main reason for me, and I wish the standard had been updated to encourage more people to try 465 (or have a way to specify port in DNS records for example). Huge missed opportunity.
It's not just explicit vs. implicit TLS that's an issue with MUAs. Assuming good implicit TLS configuration there's still no proper way to harden such connections against an active MITM - we don't have an usable MUA-STS standard.
Comments
Interestingly, this is another security issue with STARTTLS. The whole concept of first establishing an unencrypted connection and only then upgrading to encryption is fragile in multiple ways.
Admittedly, this is a pet peeve of mine, as I've co-authored a paper about it. I wonder why mailbox.org does not recommend that users switch from STARTTLS to implicit TLS for SMTP/POP3/IMAP, as this would mitigate such issues more generally. This is also in line with current RFCs (RFC 8314).
https://nostarttls.secvuln.info/
Thank you for writing this, I use it as a reference when explaining the difference STARTTLS and implicit TLS and why people should choose one over the other.
Another nice one is that implicit TLS is SNI routable (and thus much easier to route) -- this is the main reason for me, and I wish the standard had been updated to encourage more people to try 465 (or have a way to specify port in DNS records for example). Huge missed opportunity.
https://www.fastmail.help/hc/en-us/articles/360060591153-Man... under "Client email auto-discovery"
Though support for these are...
TIL about those DNS configurations.
It does look like they are actually for clients (i.e. MUAs doing IMAP & Submission), not for relay (i.e. MTAs doing SMTP/SMTPS).
I've used MTA-STS and XML to enable auto-config for my stuff:
https://vadosware.io/post/thunderbird-autoconfig-for-your-se...
Oh and it looks like MTA-STS might be the solution:
https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#...
Turns out there's an excellent guide by the UK government:
https://www.ncsc.gov.uk/collection/email-security-and-anti-s...
https://www.security.gov.uk/guidance/email-guidance/mta-sts/...
Relevant RFC:
https://datatracker.ietf.org/doc/html/rfc8461
And as one of my co-authors just pointed out to me, we also found a few security issues in mymail, yet they closed them as "not applicable"...
It's not just explicit vs. implicit TLS that's an issue with MUAs. Assuming good implicit TLS configuration there's still no proper way to harden such connections against an active MITM - we don't have an usable MUA-STS standard.
Was that the buffered input during starttls connection? Man thanks for that. I had to go and update my code due to that paper.
And the mess I had unavoidably made around the sockets and starttls just made that worse. And there was no real way to unit test it.