6 ms·

It's worth also mentioning MTA-STS [1], currently a draft. It provides a mechanism for domains to declare a STARTTLS requirement via a file at https://<domain>/

It's worth also mentioning MTA-STS [1], currently a draft. It provides a mechanism for domains to declare a STARTTLS requirement via a file at https://<domain>/.well-known/mta-sts.txt https://<domain>/.well-known/mta-sts.txt. It's backwards compatible and opt-in. There seems to be some testing already going on [2]. [1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-21 https://tools.ietf.org/html/draft-ietf-uta-mta-sts-21 [2] https://mta-sts.gmail.com/.well-known/mta-sts.txt https://mta-sts.gmail.com/.well-known/mta-sts.txt

Boulth 8y ago
Yep, Google.com has the record too but I haven't seen them scanning my mta sts file...
- mike-cardwell 8y ago
  You need to have a correctly formatted DNS TXT record at _mta-sts.example.com first. They'll check for that, and only if it exists will they bother attempting to fetch your mta-sts policy from https://mta-sts.example.com/.well-known/mta-sts.txt https://mta-sts.example.com/.well-known/mta-sts.txt
cm2187 8y ago
I am curious as for why they would use https for that. It sounds like something that should be better stored in DNS. Unencrypted but your MX entries are not more encrypted.
- UnrealIncident 8y ago
  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.
znpy 8y ago
This is interesting, I have been wondering for a while if I could disable plaintext email delivery on port 25 and just leave encrypted submission on port 465.. Would I be losing mail ?
- kalleboo 8y ago
  Gmail says 89% of inbound email is encrypted (up from 60% 2 years ago). So theoretically you'd lose 11% of your mail. https://transparencyreport.google.com/safer-email/overview?hl=en https://transparencyreport.google.com/safer-email/overview?h...
- flashmob 8y ago
  Yes, unfortunately you'd be losing email. Port 465 has been deprecated a while back (1997). I guess that's the problem - there is no practical way to disable plaintext email from the start. You may always need to accept the connection, see if the client will STARTTLS, disconnect if they do not and hope they don't re-try and keep hammering your servers with the same message, the error message "hey, i'm not accepting plaintext" will most likely get ignored.
ivanr 8y ago
Additionally, MTA-STS has recently been approved as Proposed Standard, so we may see increased support for it in the near future. [1] The key advantage of MTA-STS is that it can be deployed quickly, without almost any disruption of the already-deployed infrastructure. Of course DNSSEC and DANE already solve the same problem, but MTA-STS is the designed by and for people who don't want to use DNSSEC. The EFF's efforts are complementary to MTA-STS. As schoen mentioned elsewhere on this thread, in the early days it's probably useful to have a preload list. (That said, I am not sure why they feel it necessary to cast MTA-STS in negative light: "[...] so the sender will never know the recipient supports STARTTLS." [2] They should explain that there MTA-STS is trust on first use and has a memory effect, exactly like the well-accepted HTTP Strict Transport Security.) We added support for MTA-STS testing to Hardenize just today, along with a blog post that explains the background and explains how to deploy it. [3] (Disclaimer: Hardenize founder.) [1] https://www.ietf.org/mail-archive/web/ietf-announce/current/msg17830.html https://www.ietf.org/mail-archive/web/ietf-announce/current/... [2] https://www.eff.org/deeplinks/2018/06/technical-deep-dive-starttls-everywhere https://www.eff.org/deeplinks/2018/06/technical-deep-dive-st... [3] https://www.hardenize.com/blog/mta-sts https://www.hardenize.com/blog/mta-sts

Boulth 8y ago

Yep, Google.com has the record too but I haven't seen them scanning my mta sts file...

mike-cardwell 8y ago
You need to have a correctly formatted DNS TXT record at _mta-sts.example.com first. They'll check for that, and only if it exists will they bother attempting to fetch your mta-sts policy from https://mta-sts.example.com/.well-known/mta-sts.txt https://mta-sts.example.com/.well-known/mta-sts.txt

cm2187 8y ago

I am curious as for why they would use https for that. It sounds like something that should be better stored in DNS. Unencrypted but your MX entries are not more encrypted.

UnrealIncident 8y ago
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.

znpy 8y ago

This is interesting, I have been wondering for a while if I could disable plaintext email delivery on port 25 and just leave encrypted submission on port 465.. Would I be losing mail ?

kalleboo 8y ago
Gmail says 89% of inbound email is encrypted (up from 60% 2 years ago). So theoretically you'd lose 11% of your mail. https://transparencyreport.google.com/safer-email/overview?hl=en https://transparencyreport.google.com/safer-email/overview?h...
flashmob 8y ago
Yes, unfortunately you'd be losing email. Port 465 has been deprecated a while back (1997). I guess that's the problem - there is no practical way to disable plaintext email from the start. You may always need to accept the connection, see if the client will STARTTLS, disconnect if they do not and hope they don't re-try and keep hammering your servers with the same message, the error message "hey, i'm not accepting plaintext" will most likely get ignored.

ivanr 8y ago

Additionally, MTA-STS has recently been approved as Proposed Standard, so we may see increased support for it in the near future. [1] The key advantage of MTA-STS is that it can be deployed quickly, without almost any disruption of the already-deployed infrastructure. Of course DNSSEC and DANE already solve the same problem, but MTA-STS is the designed by and for people who don't want to use DNSSEC. The EFF's efforts are complementary to MTA-STS. As schoen mentioned elsewhere on this thread, in the early days it's probably useful to have a preload list. (That said, I am not sure why they feel it necessary to cast MTA-STS in negative light: "[...] so the sender will never know the recipient supports STARTTLS." [2] They should explain that there MTA-STS is trust on first use and has a memory effect, exactly like the well-accepted HTTP Strict Transport Security.) We added support for MTA-STS testing to Hardenize just today, along with a blog post that explains the background and explains how to deploy it. [3] (Disclaimer: Hardenize founder.) [1] https://www.ietf.org/mail-archive/web/ietf-announce/current/msg17830.html https://www.ietf.org/mail-archive/web/ietf-announce/current/... [2] https://www.eff.org/deeplinks/2018/06/technical-deep-dive-starttls-everywhere https://www.eff.org/deeplinks/2018/06/technical-deep-dive-st... [3] https://www.hardenize.com/blog/mta-sts https://www.hardenize.com/blog/mta-sts