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

41–50 of 106 posts

Re: STARTTLS Everywhere

#41

Post by cm2187 »

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…

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.

Re: STARTTLS Everywhere

#42

Post by cm2187 »

xyziemba wrote: post #22

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.t…

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.

Re: STARTTLS Everywhere

#43

Post by mtgx »

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

Re: STARTTLS Everywhere

#44

Post by UnrealIncident »

cm2187 wrote: post #42
xyziemba wrote: post #22

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.t…

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.

I assume the problem is that most domains don't have DNSSEC. So if you can MITM the SMTP stream you can MITM the DNS request.

Re: STARTTLS Everywhere

#45

Post by cm2187 »

mailr wrote: post #16

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.

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!

Re: STARTTLS Everywhere

#46

Post by cm2187 »

UnrealIncident wrote: post #44
cm2187 wrote: post #42

Earlier quoted context omitted.

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.

I assume the problem is that most domains don't have DNSSEC. So if you can MITM the SMTP stream you can MITM the DNS request.

Agree and I am not saying it’s good. Just saying that you pulled the MX domain you are connecting to from an unsecure DNS entry so if DNS is mitm-ed, the attacker might as well make you submit the email to its own server then deliver it to the recipient.

[edit] actually looking at the RFC it relies on a TXT record before the https policy is even fetched.

Re: STARTTLS Everywhere

#47

Post by J-Kuhn »

kroeckx wrote: post #40

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.

certbot?

You can edit the cron job for certbot and add a script that should be called when certificates were renewed.

Re: STARTTLS Everywhere

#48

Post by belorn »

devereaux wrote: post #12
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 toda…

465 used to be deprecated since 1998 when STARTTLS was created, and it was only kept in use since older Microsoft applications (including Entourage v10.0 and its successor, Outlook for Mac 2011) did not support STARTTLS.

However in January this year, the proposed RFC 8314 reinstate the registration of port 465 for implicitly encrypted mail submission. I think it is a bit early to close down port 25, but a great idea to make sure 465 is correctly configured if it isn't already.

Re: STARTTLS Everywhere

#49

Post by jlgaddis »

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.

Yeah, he is having a different issue.

He's entering "fastmail.com" into the form on the web site then the EFF's server is trying to connect to (at least one of) FastMail's MX hosts but is unable to establish a connection.

As OP said, what he is seeing has nothing to do with SPF.

(Side note: I'm a mail admin and I'm pretty strict, but even I don't drop anyone after HELO/EHLO. I'm not surprised you're having issues.)

Re: STARTTLS Everywhere

#50

Post by rossy »

kroeckx wrote: post #40

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.

You can put a hash of your public key in the TLSA record (TLSA 3 1 1). Unlike the full certificate hash (TLSA 3 0 1,) the public key hash shouldn't change when your LE certs rollover.

See: https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3...

Post reply on HN