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 <a href="https://<domain>/.well-known/mta-sts.txt" rel="nofollow">https://<domain>/.well-known/mta-sts.txt</a>. It's backwards compatible and opt-in. There seems to be some testing already going on [2].<p>[1] <a href="https://tools.ietf.org/html/draft-ietf-uta-mta-sts-21" rel="nofollow">https://tools.ietf.org/html/draft-ietf-uta-mta-sts-21</a><p>[2] <a href="https://mta-sts.gmail.com/.well-known/mta-sts.txt" rel="nofollow">https://mta-sts.gmail.com/.well-known/mta-sts.txt</a>
This is far too little, too late:<p>* 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.<p>* 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.<p>There are interesting email security efforts afoot, notably the draft standard called "SMTP Require TLS": <a href="https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-02" rel="nofollow">https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-...</a> . 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.
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.
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.<p>[1] <a href="https://www.shodan.io/search?query=port%3A25" rel="nofollow">https://www.shodan.io/search?query=port%3A25</a><p>[2] <a href="https://www.shodan.io/report/PIHm43GP" rel="nofollow">https://www.shodan.io/report/PIHm43GP</a>
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.<p>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.
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.<p>[1] <a href="https://hstspreload.org/" rel="nofollow">https://hstspreload.org/</a>
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 @!"<p>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)"<p>Seems a bit broken to me.
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."
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.<p>Other than that this is really cool!<p>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].<p>The only problem being that that list is currently practically empty.<p>So while I was considering adding that email server which I maintain, when I saw the items on the list it makes me reconsider.<p>The only email servers currently on the list are : google, yandex, yahoo, icloud, outlook, comcast, eff, qq and facebook.<p>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.<p>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.<p>[1] <a href="https://dl.eff.org/starttls-everywhere.policy.json" rel="nofollow">https://dl.eff.org/starttls-everywhere.policy.json</a>
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.<p>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?
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.
This doesn’t seem to be working properly. Domains that I try are saying “couldn’t connect”, e.g. <a href="https://starttls-everywhere.org/results/?fastmail.com" rel="nofollow">https://starttls-everywhere.org/results/?fastmail.com</a>
Cool. This tool made me realize that my domain's DNS records were messed up. Everything worked most of the time, but sometimes people wouldn't receive my emails! It turns out I was missing the latest MX and SPF records from my provider (Kolabnow).
Hmm. X.509 subject names aren't meant to be case-sensitive, right? I just realised one of the domains I manage have MX records in all-caps, and the cert checker fails on that, even though Gmail's SMTP servers have valid certs.
I'm still using a self-signed certificate because I'm using DANE / DNSSEC. I don't know of any tool that can properly help me automate the rollover of a let's encrypt certificate.