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. It's backwards compatible and opt-in. There seems to be some testing already going on [2].
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.
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.)
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 ?
* The SMTP RFC says that mail servers MUST NOT require STARTTLS to receive mail. Postfix (and I imagine most other production grade SMTP servers) has an option to require STARTTLS anyway, so if you really want STARTTLS you can already require that clients have it enabled, despite the braindead standard.
* STARTTLS ensures that mail was encrypted only in the final hop, from the last server to your server. That usually means it transited the public internet encrypted, but it definitely does not assure it.
There are interesting email security efforts afoot, notably the draft standard called "SMTP Require TLS": https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-... . Unfortunately the reality is that the internet mail infrastructure evolves at an incredibly glacial pace. The entire SMTP protocol would benefit greatly from the adoption of an SMTP/2 protocol, rethought with modern security practices in mind.
How did these committees think that optional, downgradable encryption was preferable to a standalone, encrypted only port (465)? Were they trying to save server ports, like if it was a precious resource? Any design decision I have seen regarding email since 2000 defies common sense. Like I heard most SMTP implementations do not validate certificates. What good is an unvalidated certificate? SPF is treated as indicative only or ignored.
We are managing to replace http1.1 with http2, it will take time but it is on the way. I am not even aware that an actual SMTP2 draft protocol that would solve all these design flaws (unverified sender, unencrypted).
And SMTP has a benefit http didn’t have. Most people access their emails through webmails, smartphones or enterprise outlook/exchange servers. For webmails and exchange only the server needs to be updated, and for smartphones, their short life ensures that older versions are pretty much all retired within 5 years. In addition, a handful of big players (google yahoo apple msft) have such a concentration of recipient accounts (retail users) that they can force a change on the market with the threat of your mail being classified as junk by them. So we could achieve a pretty quick transition.
The email RFCs require supporting a lot of things that are now horrendously outdated, and forbid doing a lot of things that should now be best practices.
Except it’s not like let’s encrypt at all. This appears to test your mail server for starttls functionality, but it doesn’t issue certs or anything like that.
I think the title of the submission is mis-editorialized. The comparison that my colleagues working on this project make is that it's like HTTPS Everywhere, or even more like the HSTS preload list, rather than like Let's Encrypt. I don't think you'll find the comparison to Let's Encrypt on the site itself.
(Edit: in addition to the site tester that you noticed, there is also a public policy list and some forthcoming tools to enforce STARTTLS on the client MTA side when delivering e-mail, preventing downgrade and MITM attacks.)
However, you can also use Let's Encrypt to make this more useful by getting a publicly-trusted certificate for the TLS service on your mail server, and then listing your mail server with this list!
The introductions my colleagues posted about this today are at
Out of ~6.5 million SMTP servers [1] on the Internet roughly 2.7 million support STARTTLS [2]. However, 1 million of them also support SSLv3 and ~200,000 still allow SSLv2.
Since proper email transport encryption is finally getting some momentum with DANE and MTA-STS, I'm surprised that STARTTLS Everywhere doesn't mention them.
DANE is being recommended (mandated?) by the European Union, and is on the rise. MTA-STS is backed by Gmail, Microsoft and many others, which is likely to give it traction.
To sum up from that post, we think STARTTLS Everywhere is a stop-gap measure until DNSSEC is fully deployed, and STARTTLS Everywhere can act as a preload list for MTA-STS (to prevent DNS downgrade attacks).
From my understanding, this is pretty much the same thing as the HSTS preload list[1], except for SMTP servers instead of HTTPS servers. It has two main goals. First, encourage cert validations. If you don't validate a cert, it means nothing. Second, help prevent MITM downgrade attacks. If your server is on the list, it means it should always use a secure cert. If it isnt, then don't connect. Same thing as HSTS preload list.
You write that "If you don't validate a cert, it means nothing". I should clarify that in this situation you get opportunistic encryption. I think you understood that, but the way it's phrased isn't clear. The situation is that we get secrecy, but we don't actually know who we're talking to since we didn't validate the cert. This genuinely is better than nothing.
If we were talking to a bad guy then we're screwed. But if we are talking to our intended recipient, even if their cert is bogus, our connection is protected from bad guys on the path. The bad guys can't choose later to access that communication after all, their only opportunity is to guess we're doing opportunistic encryption and intercept the original connection to play MitM, and if they guessed wrong their hand is shown by doing that.
This situation is unpalatable even for nation state adversaries like the NSA, because they would prefer not to be seen to be meddling. Even for something like the FSB, which scarcely cares if it's seen to be meddling, it does force them to make a decision they'd rather leave until after the fact. MitM everybody (and be known to do it) or leave them alone and maybe regret that later.
Under 'about', the rationale for STARTTLS is listed, which includes, but isn't exclusive to the HSTS like list:
- Increase STARTTLS adoption
- Increase the number of mailservers that actually validate certificates
- Maintain a STARTTLS Policy List to help prevent downgrade attacks on email services.
States "Couldn't connect to grepular.com. We couldn't find any MX records for grepular.com! Did you make a typo or enter the wrong email domain? Make sure to enter the part of your email address after the @!"
Then proceeds to show results for the MX anyway. With a single error: "Does not use a secure TLS version Error: Could not establish connection with hostname %!s(MISSING)"
The main problem with this is that STARTTLS is not anywhere near good enough, but if it sees high adoption, nobody may bother with something better in the future because they'll all think "Mission Accomplished."
There is never something that is "good enough" to solve all problems. In addition, stronger approaches are often harder to adopt (which is why they often don't get adopted). This effort to encourage STARTTLS everywhere provides reasonable protection against bulk passive monitoring, at very low effort. I think encouraging the use of TLS for all email traffic is a good idea.
I find it odd that the tester gets mad if it can't connect to the naked domain, even when the naked domain has MX records.
Other than that this is really cool!
It made me sad though -- I checked all the domains that I used to run mail for at some point in my career, and not one of them passed all the tests. When I managed email, I always made sure that our servers met all the current standards.
My email server passed, but the test mentioned, it could be better by adding it to the EFF's STARTTLS policy list [1].
The only problem being that that list is currently practically empty.
So while I was considering adding that email server which I maintain, when I saw the items on the list it makes me reconsider.
The only email servers currently on the list are : google, yandex, yahoo, icloud, outlook, comcast, eff, qq and facebook.
So while it might be an opportunity to get your server on the list early, personally I worry more about what it will break as to what it will help.
In conclusion, it looks like a great initiative, but it will have to be in production for a while before I would recommend anybody to add their server to that list.
One of the nice features of the policy list is that you can put your server on it in testing mode. In testing mode, any failure in TLS negotiation is logged and reported, but the message is sent over the insecure communication. So it shouldn't cause any breakage.
The checker concludes that because my server doesn't allow TLSv1.0 and TLSv1.1 it “Does not use a secure TLS version”, when in fact it does allow/require TLSv1.2 (and the checker does connect via TLSv1.2 later on). Is that an intentional conclusion or a bummer?
I appreciate what they're trying to do, and it may improve the status quo, but we've learned that the push away from implicit SSL/TLS and towards STARTTLS was wrong. Using one insecure aspect (DNS) to note that you SHOULD be able to do TLS with my mail server isn't a great solution.
We need to revisit the STARTTLS vs implicit TLS debate in light of the obvious vulnerability and overhead of starting with plain TCP connections and then hopefully signalling towards security. HTTPS is obviously implicit TLS and it works great. We know STARTTLS has issues. Can we not keep going down the STARTTLS road for email, while going down the implicit TLS road for other things?
The problem is partly because we don't have an assigned port for MTA2MTA implicit TLS. Otoh DANE also already provides a way to have mandatory TLS for MTA2MTA traffic.
I'm surprised to see the opposition to self-signed certificates from the EFF. Pushing people towards centralized certificate authorities seems to be anti-freedom. Maybe there is a decentralized approach instead.
We spent a lot of time thinking about this before we started building Let's Encrypt. In the case of the Web we didn't think there was a way to make self-signed certificates workable for anything because older browsers will always error on them. In the case of mailservers, self-signed certificates work for enabling TLS, and that's great, but you're extremely vulnerable to MITM attacks. So this project offers a way to prevent the MITMs, if you want it.
If there aren't major technical obstacles we might be willing to take pull requests for STARTTLS Everywhere that allow mailservers to announce self-signing policies, but it hasn't been a priority thus far because LE certs are so easy to get and are slightly more authenticated.
The problem with STARTTLS is a mitm downgrade attack. Self-signed certs are exposed to the same kind of mitm attack.
Mail is very sensitive communication. It is reasonable for the EFF to worry the risk of evedropping. Some websites are still sending passwords by email!
But you can chose to disregard the RFCs and disallow servers that will not encrypt to send you any mail. No downgrade attack then. It requires some manual changes. It may cause you to not receive email from some servers.
You can also only accept mail on port 465, which in practice is used for SMTP over SSL. You will receive even less mails.
The starttls-everywhere IP connects, tries a bunch of commands which don't look at all like a regular mail connection. It cycles through a bunch of tls settings and never sends an email.
In short, it got itself blocked by anti-spam measures.
[+] [-] xyziemba|7 years ago|reply
[1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-21
[2] https://mta-sts.gmail.com/.well-known/mta-sts.txt
[+] [-] cm2187|7 years ago|reply
[+] [-] ivanr|7 years ago|reply
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/...
[2] https://www.eff.org/deeplinks/2018/06/technical-deep-dive-st...
[3] https://www.hardenize.com/blog/mta-sts
[+] [-] znpy|7 years ago|reply
[+] [-] Boulth|7 years ago|reply
[+] [-] eklitzke|7 years ago|reply
* The SMTP RFC says that mail servers MUST NOT require STARTTLS to receive mail. Postfix (and I imagine most other production grade SMTP servers) has an option to require STARTTLS anyway, so if you really want STARTTLS you can already require that clients have it enabled, despite the braindead standard.
* STARTTLS ensures that mail was encrypted only in the final hop, from the last server to your server. That usually means it transited the public internet encrypted, but it definitely does not assure it.
There are interesting email security efforts afoot, notably the draft standard called "SMTP Require TLS": https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-... . Unfortunately the reality is that the internet mail infrastructure evolves at an incredibly glacial pace. The entire SMTP protocol would benefit greatly from the adoption of an SMTP/2 protocol, rethought with modern security practices in mind.
[+] [-] cm2187|7 years ago|reply
We are managing to replace http1.1 with http2, it will take time but it is on the way. I am not even aware that an actual SMTP2 draft protocol that would solve all these design flaws (unverified sender, unencrypted).
And SMTP has a benefit http didn’t have. Most people access their emails through webmails, smartphones or enterprise outlook/exchange servers. For webmails and exchange only the server needs to be updated, and for smartphones, their short life ensures that older versions are pretty much all retired within 5 years. In addition, a handful of big players (google yahoo apple msft) have such a concentration of recipient accounts (retail users) that they can force a change on the market with the threat of your mail being classified as junk by them. So we could achieve a pretty quick transition.
[+] [-] devereaux|7 years ago|reply
With many ISPs (and even some VPS) now blocking port 25, it could have been an opportunity to migrate naturally towards the "new" unencumbered port.
[+] [-] ubernostrum|7 years ago|reply
The email RFCs require supporting a lot of things that are now horrendously outdated, and forbid doing a lot of things that should now be best practices.
The RFCs should lose that battle.
[+] [-] schoen|7 years ago|reply
https://news.ycombinator.com/item?id=17397816
[+] [-] djrogers|7 years ago|reply
[+] [-] schoen|7 years ago|reply
(Edit: in addition to the site tester that you noticed, there is also a public policy list and some forthcoming tools to enforce STARTTLS on the client MTA side when delivering e-mail, preventing downgrade and MITM attacks.)
However, you can also use Let's Encrypt to make this more useful by getting a publicly-trusted certificate for the TLS service on your mail server, and then listing your mail server with this list!
The introductions my colleagues posted about this today are at
https://www.eff.org/deeplinks/2018/06/announcing-starttls-ev...
https://www.eff.org/deeplinks/2018/06/technical-deep-dive-st...
which will hopefully give a clearer explanation of what the service is meant for.
[+] [-] achillean|7 years ago|reply
[1] https://www.shodan.io/search?query=port%3A25
[2] https://www.shodan.io/report/PIHm43GP
[+] [-] peter_tonoli|7 years ago|reply
[+] [-] soetis1|7 years ago|reply
DANE is being recommended (mandated?) by the European Union, and is on the rise. MTA-STS is backed by Gmail, Microsoft and many others, which is likely to give it traction.
[+] [-] the_zeroth_law|7 years ago|reply
To sum up from that post, we think STARTTLS Everywhere is a stop-gap measure until DNSSEC is fully deployed, and STARTTLS Everywhere can act as a preload list for MTA-STS (to prevent DNS downgrade attacks).
[+] [-] move-on-by|7 years ago|reply
[1] https://hstspreload.org/
[+] [-] tialaramex|7 years ago|reply
If we were talking to a bad guy then we're screwed. But if we are talking to our intended recipient, even if their cert is bogus, our connection is protected from bad guys on the path. The bad guys can't choose later to access that communication after all, their only opportunity is to guess we're doing opportunistic encryption and intercept the original connection to play MitM, and if they guessed wrong their hand is shown by doing that.
This situation is unpalatable even for nation state adversaries like the NSA, because they would prefer not to be seen to be meddling. Even for something like the FSB, which scarcely cares if it's seen to be meddling, it does force them to make a decision they'd rather leave until after the fact. MitM everybody (and be known to do it) or leave them alone and maybe regret that later.
[+] [-] peter_tonoli|7 years ago|reply
[+] [-] mike-cardwell|7 years ago|reply
Then proceeds to show results for the MX anyway. With a single error: "Does not use a secure TLS version Error: Could not establish connection with hostname %!s(MISSING)"
Seems a bit broken to me.
[+] [-] the_zeroth_law|7 years ago|reply
[+] [-] mtgx|7 years ago|reply
[+] [-] dwheeler|7 years ago|reply
[+] [-] snvzz|7 years ago|reply
[+] [-] jlgaddis|7 years ago|reply
[+] [-] peter_tonoli|7 years ago|reply
[+] [-] schoen|7 years ago|reply
[+] [-] jedberg|7 years ago|reply
Other than that this is really cool!
It made me sad though -- I checked all the domains that I used to run mail for at some point in my career, and not one of them passed all the tests. When I managed email, I always made sure that our servers met all the current standards.
[+] [-] wila|7 years ago|reply
The only problem being that that list is currently practically empty.
So while I was considering adding that email server which I maintain, when I saw the items on the list it makes me reconsider.
The only email servers currently on the list are : google, yandex, yahoo, icloud, outlook, comcast, eff, qq and facebook.
So while it might be an opportunity to get your server on the list early, personally I worry more about what it will break as to what it will help.
In conclusion, it looks like a great initiative, but it will have to be in production for a while before I would recommend anybody to add their server to that list.
[1] https://dl.eff.org/starttls-everywhere.policy.json
[+] [-] the_zeroth_law|7 years ago|reply
See https://github.com/EFForg/starttls-everywhere/blob/master/RU... for more info.
[+] [-] kseistrup|7 years ago|reply
[+] [-] the_zeroth_law|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] jgowdy|7 years ago|reply
We need to revisit the STARTTLS vs implicit TLS debate in light of the obvious vulnerability and overhead of starting with plain TCP connections and then hopefully signalling towards security. HTTPS is obviously implicit TLS and it works great. We know STARTTLS has issues. Can we not keep going down the STARTTLS road for email, while going down the implicit TLS road for other things?
[+] [-] johnp_|7 years ago|reply
The problem is partly because we don't have an assigned port for MTA2MTA implicit TLS. Otoh DANE also already provides a way to have mandatory TLS for MTA2MTA traffic.
[+] [-] mailr|7 years ago|reply
[+] [-] pde3|7 years ago|reply
If there aren't major technical obstacles we might be willing to take pull requests for STARTTLS Everywhere that allow mailservers to announce self-signing policies, but it hasn't been a priority thus far because LE certs are so easy to get and are slightly more authenticated.
[+] [-] cm2187|7 years ago|reply
Mail is very sensitive communication. It is reasonable for the EFF to worry the risk of evedropping. Some websites are still sending passwords by email!
[+] [-] all_blue_chucks|7 years ago|reply
[+] [-] devereaux|7 years ago|reply
But you can chose to disregard the RFCs and disallow servers that will not encrypt to send you any mail. No downgrade attack then. It requires some manual changes. It may cause you to not receive email from some servers.
You can also only accept mail on port 465, which in practice is used for SMTP over SSL. You will receive even less mails.
Cf another reply I made today about that: https://news.ycombinator.com/item?id=17397500
[+] [-] teilo|7 years ago|reply
[+] [-] chrismorgan|7 years ago|reply
[+] [-] marcbradshaw|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] mailr|7 years ago|reply