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?
STARTTLS Everywhere
91–100 of 106 posts
Re: STARTTLS Everywhere
#92The 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.
Re: STARTTLS Everywhere
#93I'm not a big fan of STARTTLS, I'd rather just have implicit TLS (All or nothing) from the get go.
Re: STARTTLS Everywhere
#94Earlier quoted context omitted.
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…
Ok, we've changed the title above to the hopefully least controversial part of the article's original title. (Submitted title was "STARTTLS Everywhere: HTTPS Everywhere, but for SMTP".)
Oh, the submitter had already changed it. The original submitted title was "STARTTLS Everywhere: Let's Encrypt, but for SMTP").
Re: STARTTLS Everywhere
#95Since 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.
We do mention both: see https://www.eff.org/deeplinks/2018/06/technical-deep-dive-st...
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).
Re: STARTTLS Everywhere
#96The 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'm an EFF technologist, and we're looking into this!
Re: STARTTLS Everywhere
#97States "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)" Seems a bit broken to me.
Thanks for catching that! We definitely still have some bugs to work out.
Re: STARTTLS Everywhere
#98My 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,…
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.
See https://github.com/EFForg/starttls-everywhere/blob/master/RU... for more info.
Re: STARTTLS Everywhere
#99I 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?
Re: STARTTLS Everywhere
#100My 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,…
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. See https://github.com/EFForg/starttls-everywhere/blob/master/RU... for more info.
OK, that's interesting and does indeed help in taking away that concern.
Another question if I may.
The site mentions:
> the STARTTLS Policy List gives mail servers another point of reference to discover whether other mail servers support STARTTLS
Is there any email provider, email server component or email client that already uses this policy list?
Because that's another thing I miss from the FAQ.