6 ms·

I assume the problem is that most domains don't have DNSSEC. So if you can MITM the SMTP stream you can MITM the DNS request.

• cm2187 8y ago
  Agree and I am not saying it’s good. Just saying that you pulled the MX domain you are connecting to from an unsecure DNS entry so if DNS is mitm-ed, the attacker might as well make you submit the email to its own server then deliver it to the recipient. [edit] actually looking at the RFC it relies on a TXT record before the https policy is even fetched.
  • vbezhenar 8y ago
    You're requesting https://<domain>/.well-known/mta-sts.txt https://<domain>/.well-known/mta-sts.txt. If you've got that info, then A dns record was correct and you must use STARTTLS on MX record. Even if attacker replaced MX record, he can't MITM TLS session, so connection is safe. I think that it's pretty secure setup. But yes, so much hoops instead of deploying dnssec everywhere, it's a shame. DNS is hierarchical and it's very natural to use cryptography there.
    • flashmob 8y ago
      Perhaps fixing STARTTLS is one of those problems where the solution adds even more problems (and moving parts). BTW, what ever happened to SMTP on a dedicated TLS port (465)? Why did it get deprecated?
      • tialaramex 8y ago
        Port 465 is unnecessary once STARTTLS was invented. It has exactly the same upside / downside but it wastes an entire TCP port and an entire RTT plus maybe a timeout to signal (non-)availability. So it makes sense to deprecate this use of port 465 and just tell people to use STARTTLS.
        • flashmob 8y ago
          The STARTTLS vulnerability to downgrade attacks is a significant downside that port 465 doesn't have (if using modern TLS protocols at least). My opinion is that perhaps the severity of the STARTTLS downgrade attack wasn't that much considered when port 465 was deprecated.
          • cm2187 8y ago
            The only (weak) argument I can find is that since servers that had a port 465 open also had to keep a port 25 open for compatibility, you could perform the same downgrade attack by blocking connections to port 465, which would result in a submission to the port 25. But that's a "if it's broken let's make sure it remains broken" kind of argument.
            • flashmob 8y ago
              Yes - it's a weak argument, and one that's probably been debunked by looking the way https lifted off recently. My view is if port 465 was still around today, it would probably get the same level of attention as port 443 has. We could have been at a stage where port 25 could be made intentionally unavailable (same way we move browsers from http to https) and everything forced to 465. Email agent developers would be forced to update their practices as well, no email should be sent over plaintext. At present, there is no good way to tell your clients you're not accepting plaintext. STARTTS is from a world where 99% of emails were plaintext.
              • tialaramex 8y ago
                You've confused the submission port (which is usually TLS encrypted on 587) with SMTP relay (done via port 25 with optional STARTTLS) It's OK, lots of people don't know about this. Really the only problem is that you've assumed since you know nothing about this you're an expert, that'd be Dunning-Kruger or a related effect at work. For submission it really can work to upgrade end user mail agent software. We're a long way from useful encryption capable agents being ubiquitous, but we've made progress and most popular systems today ship with such a client. These systems also use TLS directly for IMAP (to receive email) and can share a lot of logic across the two systems, so that's nice. In maybe a decade we'll be where HTTPS is today. For submission. What distinguishes a submission port is that it's authenticated. You can only send email via the submission server as Alice if you prove to the submission server that you're Alice. But SMTPS (obsolete SMTP over TLS on port 465) and the STARTTLS SMTP (on port 25) are for email relay. Authentication makes no sense in this scenario because the relays are neither sender nor recipient, the transmitting relay can't prove that it's Alice, and the receiving relay can't prove that it is Bob, because they're not, they are merely relays. These are servers, so they upgrade much more slowly (often only on hardware replacement) and the priority is reliability of delivery, not security, if your proposed solution drops 1% of email on the floor that's far too much and nobody would adopt it. Hence the situation we have today, and hence STARTTLS Everywhere. Your imagined alternate universe makes no sense except because you've misunderstood how email works.
      • mike-cardwell 8y ago
        Port 465 is for mail submission. It's there for authenticated communication between clients and servers. It has never been used for communication from server to server and was never intended to be. Port 587 has the same purpose (mail submission), but has a plain text protocol specific negotiation at the beginning which matches that for server to server mail transfer on port 25.
        • flashmob 8y ago
          Oops, I see, was assuming it was used for MTA too! So there was never really a dedicated TLS port for MTA to begin with?
        • lvh 8y ago
          True, but the underlying question is still interesting: why isn't there a similar TLS-only port for MTA-MTA and we all agree to try to connect there first
    • cm2187 8y ago
      But if you can mitm the DNS query you can suppress the MTA DNS record and/or point the MX to your own servers.