4 ms·

TLS without the certificate verification is still vulnerable to MITM. You get basically the same security level with gpg and plaintext email as you do from emai

TLS without the certificate verification is still vulnerable to MITM. You get basically the same security level with gpg and plaintext email as you do from email over TLS if someone is trying to MITM. Even this REQUIRETLS that you mention that I didn't know about before looks iffy. If the problem is that upgrading all the world's email servers is too onerous, that still would pretty much have to happen here to support the new smtp extension. DNSSEC for the MX record or this MTA-STS record. It would require each hop in the path to be equally strict in implementing REQUIRETLS unless you want to randomly drop that assurance somewhere in the middle of the route. If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default? Not to mention that as a store and forward protocol, any server hop along the way may store or copy the message at rest in plaintext. If DKIM isn't used to checksum the message, it can be modified too unless there's some mechanism here for that that I'm missing. If every email server needs an infinity gauntlet full of plugins and extensions and DNS records to just have some assurance of the sender's or recipient's validity, how is that really better than just making something new? It's just not made to be a secure protocol. Someone please correct me if I'm misreading the RFC, but can we please, please let smtp die some day?

dane-pgp 4y ago
> If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default? The 80:20 solution here might be for the big email providers to declare a flag day (maybe with a 2 year countdown) saying that any email server they connect to after that date has to support TLS, or they will delay the processing of emails to/from that server by 5 minutes, doubling every 6 months. Also, such servers will be named and shamed in their webmail interfaces, so users get a nasty red warning whenever you try to send an email to an affected address or receive one from it. I bet the problem would actually be 99% solved before the flag day even arrived, and most of the remaining 1% would be spam anyway.
Beltalowda 4y ago
> TLS without the certificate verification is still vulnerable to MITM. By that standard all of https and ssh are insecure too...
- notabee 4y ago
  I'm not sure what you're getting at. Properly configured https verifies the certificate's CA signature. Now it's true that that's only as secure as the web of trust that is the certificate authority system, but that's a whole other ball of wax. Smtp with TLS just doesn't check, except perhaps this new REQUIRETLS if implemented with all that extra configuration. For most of the smtp TLS already in use out there, it doesn't care if it's a CA signed cert or a self-signed cert. It's not verifying anything about identity. With ssh it is trust on first use by default, so you kind of have a point with that, but: 1. Ssh then remembers that host key and alerts if it changes to protect against MITM of future connections, whereas smtp over TLS just... doesn't check as far as I'm aware. 2. Ssh implemented certificates a while back using an ssh certificate authority, and thus can work more like https where host key signatures are pre-trusted, or can even issue temporary credentials through something like Vault. These things are not the same.
  - Beltalowda 4y ago
    > Properly configured https verifies the certificate's CA signature. That's also what properly configured SMTP over TLS does. Maybe some clients don't verify the certificate, but that's on the clients and not the protocol.
    - notabee 4y ago
      Verification was not required as a matter of protocol until a new standard for MTA-STS was published in 2018. Without this new standard configured, as is going to be the case for most organizations out there not on the bleeding edge, TLS over smtp has been opportunistic and not verified the certificates or strictly enforced verification. https://www.digitalocean.com/community/tutorials/how-to-configure-mta-sts-and-tls-reporting-for-your-domain-using-apache-on-ubuntu-18-04 https://www.digitalocean.com/community/tutorials/how-to-conf... The additional daemon that it looks like postfix requires to support this new standard, postfix-mta-sts-resolver, had its 1.0.0 tagged version release in Jun 13, 2020. This does not and would not represent the vast majority of extant deployed smtp over TLS configurations out there. This right here is still in the README for postfix, one of the most popular MTAs in use: >Despite the potential for eliminating "man-in-the-middle" and other attacks, mandatory certificate trust chain and subject name verification is not viable as a default Internet mail delivery policy. Some MX hosts do not support TLS at all, and a significant portion of TLS-enabled MTAs use self-signed certificates, or certificates that are signed by a private Certification Authority. On a machine that delivers mail to the Internet, you should not configure mandatory server certificate verification as a default policy. That's a very load bearing "properly" in your sentence and I wonder just what you're referencing. Edit: and another good writeup. https://lwn.net/Articles/866481/ https://lwn.net/Articles/866481/

dane-pgp 4y ago

> If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default? The 80:20 solution here might be for the big email providers to declare a flag day (maybe with a 2 year countdown) saying that any email server they connect to after that date has to support TLS, or they will delay the processing of emails to/from that server by 5 minutes, doubling every 6 months. Also, such servers will be named and shamed in their webmail interfaces, so users get a nasty red warning whenever you try to send an email to an affected address or receive one from it. I bet the problem would actually be 99% solved before the flag day even arrived, and most of the remaining 1% would be spam anyway.

Beltalowda 4y ago

> TLS without the certificate verification is still vulnerable to MITM. By that standard all of https and ssh are insecure too...

notabee 4y ago
I'm not sure what you're getting at. Properly configured https verifies the certificate's CA signature. Now it's true that that's only as secure as the web of trust that is the certificate authority system, but that's a whole other ball of wax. Smtp with TLS just doesn't check, except perhaps this new REQUIRETLS if implemented with all that extra configuration. For most of the smtp TLS already in use out there, it doesn't care if it's a CA signed cert or a self-signed cert. It's not verifying anything about identity. With ssh it is trust on first use by default, so you kind of have a point with that, but: 1. Ssh then remembers that host key and alerts if it changes to protect against MITM of future connections, whereas smtp over TLS just... doesn't check as far as I'm aware. 2. Ssh implemented certificates a while back using an ssh certificate authority, and thus can work more like https where host key signatures are pre-trusted, or can even issue temporary credentials through something like Vault. These things are not the same.
- Beltalowda 4y ago
  > Properly configured https verifies the certificate's CA signature. That's also what properly configured SMTP over TLS does. Maybe some clients don't verify the certificate, but that's on the clients and not the protocol.
  - notabee 4y ago
    Verification was not required as a matter of protocol until a new standard for MTA-STS was published in 2018. Without this new standard configured, as is going to be the case for most organizations out there not on the bleeding edge, TLS over smtp has been opportunistic and not verified the certificates or strictly enforced verification. https://www.digitalocean.com/community/tutorials/how-to-configure-mta-sts-and-tls-reporting-for-your-domain-using-apache-on-ubuntu-18-04 https://www.digitalocean.com/community/tutorials/how-to-conf... The additional daemon that it looks like postfix requires to support this new standard, postfix-mta-sts-resolver, had its 1.0.0 tagged version release in Jun 13, 2020. This does not and would not represent the vast majority of extant deployed smtp over TLS configurations out there. This right here is still in the README for postfix, one of the most popular MTAs in use: >Despite the potential for eliminating "man-in-the-middle" and other attacks, mandatory certificate trust chain and subject name verification is not viable as a default Internet mail delivery policy. Some MX hosts do not support TLS at all, and a significant portion of TLS-enabled MTAs use self-signed certificates, or certificates that are signed by a private Certification Authority. On a machine that delivers mail to the Internet, you should not configure mandatory server certificate verification as a default policy. That's a very load bearing "properly" in your sentence and I wonder just what you're referencing. Edit: and another good writeup. https://lwn.net/Articles/866481/ https://lwn.net/Articles/866481/