Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

STARTTLS Everywhere

starttls-everywhere.org

Post reply on HN
Print view View original

11–20 of 106 posts

Re: STARTTLS Everywhere

#11

Post by peter_tonoli »

move-on-by wrote: post #8

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 prelo…

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.

Re: STARTTLS Everywhere

#12

Post by devereaux »

all_blue_chucks wrote: post #9

SRTTLS is vulnerable to downgrade attacks. It's better than nothing, but if someone wants to intercept it they can.

Yes, because SSL is optional on port 25 and 487.

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

Re: STARTTLS Everywhere

#13

Post by eklitzke »

This is far too little, too late:

* 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.

Re: STARTTLS Everywhere

#14

Post by devereaux »

schoen wrote: post #3
djrogers wrote: post #2

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…

I'm sorry, but the problem is more complicated than that.

SSL is not mandatory on either port 25 or 587, and SSL can not be made mandatory if you follow the RFCs (it can be made mandatory if you tweak your MTA, but you may lose some mail). Advertising for SSL over DNS means you trust the DNS records - which you shouldn't without DNSSEC. Even with it, there can be workarounds that in practice will allow MITMs.

The only real solution is making SSL mandatory, and doing SMTP over SSL as in the good old days of using stunnel on port 465 to decrypt, then netcat to forward the output to the MTA running on localhost:25

But that is not standard. Maybe the efforts would be better invested by changing the standards to have a port where SMTP can not happen at all without SSL - just like port 465 was, over 10 years ago.

Re: STARTTLS Everywhere

#15

Post by schoen »

devereaux wrote: post #14
schoen wrote: post #3

Earlier 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…

I'm sorry, but the problem is more complicated than that. SSL is not mandatory on either port 25 or 587, and SSL can not be made mandatory if you follow the RFCs (it can be made mandatory if you tweak your MTA, but you may lose some mail). Advertising for SSL over DNS means you trust the DNS records - which you shouldn't without DNSSEC. Even with it, there can be workarounds that in practice will allow MITMs. The onl…

> SSL is not mandatory on either port 25 or 587, and can not be made mandatory if you follow the RFCs.

I'm well-aware of the RFC difficulty, but I don't think that the current approach of STARTTLS Everywhere is really a problem because it's effectively opt-in on both ends. The enforcement is requested by the receiving side and then implemented by the sending side.

* The receiving MTA has to proactively choose to be listed.

* The sending MTA has to proactively choose to make use of the list.

So, with the current version of STARTTLS Everywhere, only sites that deliberately choose to enforce STARTTLS will do so, and they will only do it when communicating with sites that have specifically asked them to enforce it! This would only be an RFC violation if we thought that the RFC meant to categorically forbid sites from separately agreeing to a stricter security policy.

This approach might have its scalability limitations, but I won't try to speak for my colleagues about any future steps.

Re: STARTTLS Everywhere

#16

Post by mailr »

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.

Re: STARTTLS Everywhere

#17

Post by devereaux »

eklitzke wrote: post #13

This is far too little, too late: * 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 s…

I fully agree. It will not achieve anything. FYI, "SMTP Require TLS" was running on port 465 many years ago.

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.

Re: STARTTLS Everywhere

#19

Post by mailr »

chrismorgan wrote: post #18

This doesn’t seem to be working properly. Domains that I try are saying “couldn’t connect”, e.g. https://starttls-everywhere.org/results/?fastmail.com

I think there is an error in their SPF configuration. "v=spf1 ip4:67.212.170.242 -all" But verification connections come from a different address.

Re: STARTTLS Everywhere

#20

Post by schoen »

eklitzke wrote: post #13

This is far too little, too late: * 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 s…

Please see my reply downthread:

https://news.ycombinator.com/item?id=17397816

Post reply on HN