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

21–30 of 106 posts

Re: STARTTLS Everywhere

#21

Post by devereaux »

schoen wrote: post #15
devereaux wrote: post #14

Earlier quoted context omitted.

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

I agree with you, STARTTLS Everywhere is not "a problem". It is not a solution either - at best a minor improvement.

The problem is not the MTA who will chose to be listed, but those who won't be listed - the immense majority. "Scalability limitation" is certainly a more polite way to say that.

I'm sorry if my message was too blunt, but I am not sure it was worth downvoting my technical explanation just for this.

Re: STARTTLS Everywhere

#22

Post by xyziemba »

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 /.well-known/mta-sts.txt" rel="nofollow">https:///.well-known/mta-sts.txt. It's backwards compatible and opt-in. There seems to be some testing already going on [2].

[1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-21

[2] https://mta-sts.gmail.com/.well-known/mta-sts.txt

Re: STARTTLS Everywhere

#23

Post by chrismorgan »

mailr wrote: post #19
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.

I’m confused. This is nothing to do with SPF (it’s failing to connect in the first place), and what domain is that SPF record for anyway?

Re: STARTTLS Everywhere

#24

Post by mailr »

chrismorgan wrote: post #23
mailr wrote: post #19

Earlier quoted context omitted.

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.

I’m confused. This is nothing to do with SPF (it’s failing to connect in the first place), and what domain is that SPF record for anyway?

dig txt starttls-everywhere.org ;; ANSWER SECTION: starttls-everywhere.org. 599 IN TXT "v=spf1 ip4:67.212.170.242 -all"

My server was dropping the connection after EHLO because they were connecting from a different IP address and specified -all in the SPF record. Maybe you are seeing a different issue.

Re: STARTTLS Everywhere

#25

Post by [deleted] »

mailr wrote: post #24
chrismorgan wrote: post #23

Earlier quoted context omitted.

I’m confused. This is nothing to do with SPF (it’s failing to connect in the first place), and what domain is that SPF record for anyway?

dig txt starttls-everywhere.org ;; ANSWER SECTION: starttls-everywhere.org. 599 IN TXT "v=spf1 ip4:67.212.170.242 -all" My server was dropping the connection after EHLO because they were connecting from a different IP address and specified -all in the SPF record. Maybe you are seeing a different issue.

[deleted]

Re: STARTTLS Everywhere

#26

Post by schoen »

devereaux wrote: post #21
schoen wrote: post #15

Earlier quoted context omitted.

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

I agree with you, STARTTLS Everywhere is not "a problem". It is not a solution either - at best a minor improvement. The problem is not the MTA who will chose to be listed, but those who won't be listed - the immense majority. "Scalability limitation" is certainly a more polite way to say that. I'm sorry if my message was too blunt, but I am not sure it was worth downvoting my technical explanation just for this.

I didn't downvote you; I'm sorry someone else did.

The HSTS preload list also has a huge scalability problem, but it's also improved the situation about HTTPS downgrades a lot!

Re: STARTTLS Everywhere

#27

Post by ubernostrum »

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…

The SMTP RFC says that mail servers MUST NOT

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.

Re: STARTTLS Everywhere

#29

Post by pde3 »

devereaux wrote: post #21
schoen wrote: post #15

Earlier quoted context omitted.

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

I agree with you, STARTTLS Everywhere is not "a problem". It is not a solution either - at best a minor improvement. The problem is not the MTA who will chose to be listed, but those who won't be listed - the immense majority. "Scalability limitation" is certainly a more polite way to say that. I'm sorry if my message was too blunt, but I am not sure it was worth downvoting my technical explanation just for this.

We think we can make a huge difference even by listing a few dozen or a few hundred of the highest-traffic email domains.

Re: STARTTLS Everywhere

#30

Post by axaxs »

ubernostrum wrote: post #27
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…

The SMTP RFC says that mail servers MUST NOT 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.

See, at surface value I agree. But at a deeper level I don't. The problem is too many broken protocols exist via RFC only (dns, smtp, etc). Rather than violate that, or force it into something it's not, we should be writing newer, better protocols. The friction against this is huge, mainly by those who capped out at the previous RFCs, though. Email(well, smtp) itself is so outdated and broken, I can't believe it's still so widely used.
Post reply on HN