8 ms·

It's nearly 2015, we are in a post-Snowden, and yet we are still considering the design pattern of "start with untrusted/unencrypted connection, and then just u

It's nearly 2015, we are in a post-Snowden, and yet we are still considering the design pattern of "start with untrusted/unencrypted connection, and then just use an optional 'upgrade' command to make it encrypted/secure" acceptable. One Word: SSLStrip We have had to completely overhaul HTTP/HTTPS because this "start insecure, go to secure" just does not work. And even then, its been a series of hacks like Strict Transport Security, preloading lists for HSTS into browsers, OSCP Stapling, hard coding revoke lists, etc. And now we need to go through all this pain again for mail?!?! This is incredibly stupid and short sighted. Any network protocol that is sending personal/private information, or sends authentication credentials, needs to do so over an encrypted channel. New protocols get a single port, encryption is required. Legacy protocols which do not have an encrypted channel, like SMTP, POP, IMAP, FTP, HTTP, need a separate, dedicated port number for the encrypted version.

huhtenberg 12y ago
STARTTLS is not an "optional upgrade command". Its support is routinely required and enforced by both clients and servers. Servers won't let clients do AUTH without STARTTLS first. Clients won't send emails if they are set to use it and it's not supported. One can certainly misconfigure the hell out of mail server, but then no "secure from start" will stand a chance against these leet skills either. Besides, STARTTLS dates back to 2002, so not sure what's up with your "?!?!" and "now we need to ..." comments. Looks like a basic rant to me :-/
- jlgaddis 12y ago
  With respect to the RFCs, it's not required to issue STARTTLS before AUTH so that's probably why billyhoffman said "optional". One is certainly free to use authentication without requiring encryption although, in practice, I'm not sure why you would want to do that (with an exception being when all MUA -> MTA traffic remains entirely within a private network, perhaps -- but even then, why not add encryption just for good measure?).
- rwg 12y ago
  I think you're underestimating the number of poorly configured/written SMTP clients and servers out there in the wild. As an example, here's smtp.comcast.net on tcp/587 (SMTP submission): Connection to smtp.comcast.net port 587 [tcp/submission] succeeded! 220 resomta-ch2-12v.sys.comcast.net comcast ESMTP server ready EHLO [2601:b:x:x:x:x:x:x] 250-resomta-ch2-12v.sys.comcast.net hello [2601:b:x:x:x:x:x:x], pleased to meet you 250-HELP 250-AUTH LOGIN PLAIN 250-SIZE 36700160 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-STARTTLS 250 OK AUTH LOGIN 334 VXNlcm5hbWU6 That's right, the customer-facing SMTP server for the largest ISP in North America will happily let clients authenticate via base64-encoded plaintext without doing STARTTLS first. At least with tcp/465 (SMTPS), the SMTP session (and the potential to send plaintext credentials) won't even start until the TLS session is up. That limits the attack surface to, "Does the client do something stupid with TLS, like not verify the peer's certificate or accept an aNULL/eNULL ciphersuite?" If the MUA has a "Use SSL?" checkbox in its SMTP settings and it's not checked, then the MUA will send its credentials in the clear on tcp/587 if the server advertises/accepts AUTH LOGIN/PLAIN/CRAM-MD5/etc. before/without SMARTTLS, like Comcast's SMTP servers do. This scenario can't happen with SMTPS.
jlgaddis 12y ago
In reality, it doesn't really matter much if TLS is used. Most MTAs will use TLS by default when it is available (i.e. if it sees the "STARTTLS" verb in the server's response) but (also by default) most won't attempt to validate the SSL certificate provided by the server -- it can be self-signed, expired, have a messed up certificate chain, or have a hostname mismatch and it will still be accepted. Proper validation can be enabled, of course, but it is typically not by default. Of course, connecting over a "plain text" connection and then "upgrading" to TLS has its own problems, as you pointed out. The most significant is that a man-in-the-middle can simply filter out the "250-STARTTLS" response from the server and the client will not attempt to use encryption. Unfortunately, in order to be RFC-compliant, an MTA cannot refuse to transfer mail just because encryption (TLS) is not available. I wholeheartedly agree that the e-mail protocols need updated -- or perhaps even completely overhauled -- but I think it will be a long time before we see that happen. Besides, even if new protocols were introduced tomorrow that fixed all of this, it would be years before there was 100% adoption meaning that we'd still have to support the current protocols until then. I don't think you can say, fairly, that "this is incredibly stupid and short sighted", though. I've been working professionally in I.T. for nearly 20 years and SMTP was still around way way before that. The problems that we are currently trying to solve simply did not exist then and almost certainly could not have even been imagined that long ago (recall that RFC733 was authored in November 1977 and RFC822 in August 1982). Overall, SMTP has proven to be a fairly robust protocol but, as with anything, it needs to adapt.
- cesarb 12y ago
  I had to configure Thunderbird for a coworker last week, connecting to the dreamhost mail servers, and it does validate the server certificates. You have to either add an exception (works, but not ideal), or find the exact hostname which will pass Thunderbird's certificate validation (dreamhost uses a wildcard certificate for * .mail.dreamhost.com, so after digging on its wiki you find out that the correct alternative is in the form of subn.mail.dreamhost.com, where n is the same number on the mail server's real hostname, which you cannot use because it has two components where the * can match only one). (Edit: can't make the asterisks show up correctly.) (Edit: misread MTA as MUA. Yeah, most MTA's can't validate the certificates.)
- 12y ago
deleted 12y ago
[deleted]
russjones 12y ago
Russell from Mailgun here. From our perspective, most people start (or at least should start) with the premise that email is not secure. There are things that we can do to make email more secure, but as an email service provider, we have to balance delivery with security. Most customers would rather have their email delivered to an inbox than us only deliver to an inbox where we can validate the TLS certificate presented by the server. In-fact, delivery is the entire reason companies like Mailgun exist. That doesn't mean we don't care about security. We've rolled out opportunistic TLS about a year ago, we're working on rolling out mandatory TLS soon (with strict certificate verification), and have a slew of security feature coming down the pipeline that I think (some) customers will be really excited about. However, when it comes to delivery, the truth is that features like mandatory TLS are not really requested or demanded by customers. In the email world, delivery trumps security which is not surprising when you work from the premise that it is not secure to begin with.
- IgorPartola 12y ago
  So it's sort of a chicken-and-egg situation then, huh? "It's not secure" => "Can't make security mandatory" => "It's not secure". Off topic: Another thing I don't get is how do the relays validate each others' certs? You can get a postfix box up and running with a single command, no CA's involved. How does Mailgun know that it's talking to my mail server at mail.example.com? Or is that what DKIM doing? If so, then aren't we just relying on DNS to distribute public key info, which is not secure? Also, what if I don't publish DKIM?
- billyhoffman 12y ago
  Russell, Please don't take my comments as a knock on Mailgun. You guys rock. It was more the frustration with the idea that 1) encryption is optional for certain network protocols, and that 2) you upgrade a plaintext connection to a secure connection. This simply fails in practice, and we have seen this time and again with HTTP/HTTPS. 1) is changing, which is good. 2) is something people keep pushing for because it should work. Afterall you can configure your server to require a STARTTLS, and have all your client's configured to always use STARTTLS and abort out if it doesn't become secure. Stop that. You are already making this to complicated. Crypto is hard enough as is. (See lower comment re: Comcast and STARTTLS). Ignoring the fact that you are mixing Layer 5/6 concepts into your Layer 7 application prototol, you are creating an insecure-by-default system. Its plaintext, unless you do these things. Stop that. You are doing it backwards. Make it a separate port, and SSL/TLS happens before the application protocol is even accessed. "Is this connection secure" and tracking state and transition into/out of that is not the job of an application protocol. Make this simple and boolean.
pjc50 12y ago
There is a strong argument that encrypted links between cleartext relay stations is of very limited use, and what should be encrypted is the message body. We could do with another attempt to redefine email, even if it's unlikely to get deployed. It might be worth considering how to unify email with IM in the process.

huhtenberg 12y ago

STARTTLS is not an "optional upgrade command". Its support is routinely required and enforced by both clients and servers. Servers won't let clients do AUTH without STARTTLS first. Clients won't send emails if they are set to use it and it's not supported. One can certainly misconfigure the hell out of mail server, but then no "secure from start" will stand a chance against these leet skills either. Besides, STARTTLS dates back to 2002, so not sure what's up with your "?!?!" and "now we need to ..." comments. Looks like a basic rant to me :-/

jlgaddis 12y ago
With respect to the RFCs, it's not required to issue STARTTLS before AUTH so that's probably why billyhoffman said "optional". One is certainly free to use authentication without requiring encryption although, in practice, I'm not sure why you would want to do that (with an exception being when all MUA -> MTA traffic remains entirely within a private network, perhaps -- but even then, why not add encryption just for good measure?).
rwg 12y ago
I think you're underestimating the number of poorly configured/written SMTP clients and servers out there in the wild. As an example, here's smtp.comcast.net on tcp/587 (SMTP submission): Connection to smtp.comcast.net port 587 [tcp/submission] succeeded! 220 resomta-ch2-12v.sys.comcast.net comcast ESMTP server ready EHLO [2601:b:x:x:x:x:x:x] 250-resomta-ch2-12v.sys.comcast.net hello [2601:b:x:x:x:x:x:x], pleased to meet you 250-HELP 250-AUTH LOGIN PLAIN 250-SIZE 36700160 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-STARTTLS 250 OK AUTH LOGIN 334 VXNlcm5hbWU6 That's right, the customer-facing SMTP server for the largest ISP in North America will happily let clients authenticate via base64-encoded plaintext without doing STARTTLS first. At least with tcp/465 (SMTPS), the SMTP session (and the potential to send plaintext credentials) won't even start until the TLS session is up. That limits the attack surface to, "Does the client do something stupid with TLS, like not verify the peer's certificate or accept an aNULL/eNULL ciphersuite?" If the MUA has a "Use SSL?" checkbox in its SMTP settings and it's not checked, then the MUA will send its credentials in the clear on tcp/587 if the server advertises/accepts AUTH LOGIN/PLAIN/CRAM-MD5/etc. before/without SMARTTLS, like Comcast's SMTP servers do. This scenario can't happen with SMTPS.

jlgaddis 12y ago

In reality, it doesn't really matter much if TLS is used. Most MTAs will use TLS by default when it is available (i.e. if it sees the "STARTTLS" verb in the server's response) but (also by default) most won't attempt to validate the SSL certificate provided by the server -- it can be self-signed, expired, have a messed up certificate chain, or have a hostname mismatch and it will still be accepted. Proper validation can be enabled, of course, but it is typically not by default. Of course, connecting over a "plain text" connection and then "upgrading" to TLS has its own problems, as you pointed out. The most significant is that a man-in-the-middle can simply filter out the "250-STARTTLS" response from the server and the client will not attempt to use encryption. Unfortunately, in order to be RFC-compliant, an MTA cannot refuse to transfer mail just because encryption (TLS) is not available. I wholeheartedly agree that the e-mail protocols need updated -- or perhaps even completely overhauled -- but I think it will be a long time before we see that happen. Besides, even if new protocols were introduced tomorrow that fixed all of this, it would be years before there was 100% adoption meaning that we'd still have to support the current protocols until then. I don't think you can say, fairly, that "this is incredibly stupid and short sighted", though. I've been working professionally in I.T. for nearly 20 years and SMTP was still around way way before that. The problems that we are currently trying to solve simply did not exist then and almost certainly could not have even been imagined that long ago (recall that RFC733 was authored in November 1977 and RFC822 in August 1982). Overall, SMTP has proven to be a fairly robust protocol but, as with anything, it needs to adapt.

cesarb 12y ago
I had to configure Thunderbird for a coworker last week, connecting to the dreamhost mail servers, and it does validate the server certificates. You have to either add an exception (works, but not ideal), or find the exact hostname which will pass Thunderbird's certificate validation (dreamhost uses a wildcard certificate for * .mail.dreamhost.com, so after digging on its wiki you find out that the correct alternative is in the form of subn.mail.dreamhost.com, where n is the same number on the mail server's real hostname, which you cannot use because it has two components where the * can match only one). (Edit: can't make the asterisks show up correctly.) (Edit: misread MTA as MUA. Yeah, most MTA's can't validate the certificates.)
12y ago

deleted 12y ago

[deleted]

russjones 12y ago

Russell from Mailgun here. From our perspective, most people start (or at least should start) with the premise that email is not secure. There are things that we can do to make email more secure, but as an email service provider, we have to balance delivery with security. Most customers would rather have their email delivered to an inbox than us only deliver to an inbox where we can validate the TLS certificate presented by the server. In-fact, delivery is the entire reason companies like Mailgun exist. That doesn't mean we don't care about security. We've rolled out opportunistic TLS about a year ago, we're working on rolling out mandatory TLS soon (with strict certificate verification), and have a slew of security feature coming down the pipeline that I think (some) customers will be really excited about. However, when it comes to delivery, the truth is that features like mandatory TLS are not really requested or demanded by customers. In the email world, delivery trumps security which is not surprising when you work from the premise that it is not secure to begin with.

IgorPartola 12y ago
So it's sort of a chicken-and-egg situation then, huh? "It's not secure" => "Can't make security mandatory" => "It's not secure". Off topic: Another thing I don't get is how do the relays validate each others' certs? You can get a postfix box up and running with a single command, no CA's involved. How does Mailgun know that it's talking to my mail server at mail.example.com? Or is that what DKIM doing? If so, then aren't we just relying on DNS to distribute public key info, which is not secure? Also, what if I don't publish DKIM?
billyhoffman 12y ago
Russell, Please don't take my comments as a knock on Mailgun. You guys rock. It was more the frustration with the idea that 1) encryption is optional for certain network protocols, and that 2) you upgrade a plaintext connection to a secure connection. This simply fails in practice, and we have seen this time and again with HTTP/HTTPS. 1) is changing, which is good. 2) is something people keep pushing for because it should work. Afterall you can configure your server to require a STARTTLS, and have all your client's configured to always use STARTTLS and abort out if it doesn't become secure. Stop that. You are already making this to complicated. Crypto is hard enough as is. (See lower comment re: Comcast and STARTTLS). Ignoring the fact that you are mixing Layer 5/6 concepts into your Layer 7 application prototol, you are creating an insecure-by-default system. Its plaintext, unless you do these things. Stop that. You are doing it backwards. Make it a separate port, and SSL/TLS happens before the application protocol is even accessed. "Is this connection secure" and tracking state and transition into/out of that is not the job of an application protocol. Make this simple and boolean.

pjc50 12y ago

There is a strong argument that encrypted links between cleartext relay stations is of very limited use, and what should be encrypted is the message body. We could do with another attempt to redefine email, even if it's unlikely to get deployed. It might be worth considering how to unify email with IM in the process.