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

101–106 of 106 posts

Re: STARTTLS Everywhere

#101

Post by cm2187 »

vbezhenar wrote: post #51
cm2187 wrote: post #46

Earlier quoted context omitted.

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.

You're requesting /.well-known/mta-sts.txt" rel="nofollow">https:// /.well-known/mta-sts.txt . If you've got that info, then A dns record was correct and you must use STARTTLS on MX record. Even if attacker replaced MX record, he can't MITM TLS session, so connection is safe. I think that it's pretty secure setup. But yes, so much hoops instead of deploying dnssec everywhere, it's a shame. DNS is hierarchical and it'…

But if you can mitm the DNS query you can suppress the MTA DNS record and/or point the MX to your own servers.

Re: STARTTLS Everywhere

#102

Post by kroeckx »

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.

There are multiple ways to set it up: - Reuse the key, set up the TLSA record using the public key. Certbot really doesn't seem to support this in an automated way. It requires that you generate a CSR, but there doesn't seem to be a way to renew this automatically. - Generate a new key for each certificate, which is what certbot. You would first need to add both the old and the new certificate to DNS, wait for the TTL of the old to expire, change to the new certificate, remove the old from DNS. There doesn't seem to be a tool to do this. - Set up the TLSA record to say you trust the CA.

Re: STARTTLS Everywhere

#103

Post by johnp_ »

jgowdy wrote: post #99

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. We need to revisit the STARTTLS vs implicit TLS debate in light of the obvious vulnerability and overhead of starting with plain TCP con…

Implicit TLS is already favored for Email submission and access per RFC8314: https://tools.ietf.org/html/rfc8314

The problem is partly because we don't have an assigned port for MTA2MTA implicit TLS. Otoh DANE also already provides a way to have mandatory TLS for MTA2MTA traffic.

Re: STARTTLS Everywhere

#104

Post by avaika »

axaxs wrote: post #30
ubernostrum wrote: post #27

Earlier quoted context omitted.

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

smtp might be broken, but it would be extremely hard to replace it to something incompatible, as it's a very core of the nowadays internet.

Moreover it has the advantage no other popular communication service has: people somehow managed to agree on protocol standard so anyone is able to run own smtp server. In modern days of huge corporations a new popular standard like this seems impossible.

Re: STARTTLS Everywhere

#105

Post by ivanr »

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…

Additionally, MTA-STS has recently been approved as Proposed Standard, so we may see increased support for it in the near future. [1]

The key advantage of MTA-STS is that it can be deployed quickly, without almost any disruption of the already-deployed infrastructure. Of course DNSSEC and DANE already solve the same problem, but MTA-STS is the designed by and for people who don't want to use DNSSEC.

The EFF's efforts are complementary to MTA-STS. As schoen mentioned elsewhere on this thread, in the early days it's probably useful to have a preload list. (That said, I am not sure why they feel it necessary to cast MTA-STS in negative light: "[...] so the sender will never know the recipient supports STARTTLS." [2] They should explain that there MTA-STS is trust on first use and has a memory effect, exactly like the well-accepted HTTP Strict Transport Security.)

We added support for MTA-STS testing to Hardenize just today, along with a blog post that explains the background and explains how to deploy it. [3] (Disclaimer: Hardenize founder.)

[1] https://www.ietf.org/mail-archive/web/ietf-announce/current/...

[2] https://www.eff.org/deeplinks/2018/06/technical-deep-dive-st...

[3] https://www.hardenize.com/blog/mta-sts

Re: STARTTLS Everywhere

#106

Post by the_zeroth_law »

tialaramex wrote: post #86
auscompgeek wrote: post #82

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.

X.509 subject names are human readable text and probably you shouldn't try to reason about them beyond the simplest exact bit-for-bit comparison. Where the subject name is the name of a something on the Internet it should use the Internet's defined "Subject Alternative Name" (SAN) mechanism, rather than trying to squeeze into the X.500 system's hierarchical directory. For compatibility, and to save the X.509 subject…

Yep. This looks like a bug in STARTTLS Everywhere, and we're working on it!
Post reply on HN