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

51–60 of 106 posts

Re: STARTTLS Everywhere

#51

Post by vbezhenar »

cm2187 wrote: post #46
UnrealIncident wrote: post #44

Earlier quoted context omitted.

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.

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's very natural to use cryptography there.

Re: STARTTLS Everywhere

#52

Post by JdeBP »

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…

IM2000 protocols have already been written. (-:

* http://jdebp.eu./Proposals/IM2000/

But of course you are already using a pull-style messaging system, that is right in front of you.

* https://news.ycombinator.com/item?id=10405864

Re: STARTTLS Everywhere

#53

Post by JdeBP »

cm2187 wrote: post #41
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 indicati…

The same has been pointed out about Web browsers using SRV DNS lookups to find servers.

* https://news.ycombinator.com/item?id=17395600

SPF, of course, should be used everywhere so that we reach the point of complete balkanization and collapse, and people realize that we can (and in fact in some ways already have) switch wholesale to different systems, faster. (-:

* http://jdebp.eu./FGA/smtp-spf-is-harmful.html

* https://news.ycombinator.com/item?id=10405864

Re: STARTTLS Everywhere

#54

Post by cm2187 »

JdeBP wrote: post #53
cm2187 wrote: post #41

Earlier quoted context omitted.

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

The same has been pointed out about Web browsers using SRV DNS lookups to find servers. * https://news.ycombinator.com/item?id=17395600 SPF, of course, should be used everywhere so that we reach the point of complete balkanization and collapse, and people realize that we can (and in fact in some ways already have ) switch wholesale to different systems, faster. (-: * http://jdebp.eu./FGA/smtp-spf-is-harmful.html * ht…

Not that I think that SPF is the ultimate solution (it is merely a thin layer of lipstick on the pig) but I don't agree with many of the assertion of your "spf is harmful" link.

- pre-delivery forwarding servers just need to be added to spf. If you use random third party smtp relays, then this is precisely what spf is trying to avoid.

- the way internal servers implement aliases is their problem, there is not necessarily a need to go through an smtp relay (my mail server doesn't)

- failover mail servers should check spf on incoming email and then have a trusted relationship with the primary server so that spf isn't enforced when the failover delivers to the primary (that's the way my mail server works)

- spf uses DNS. So what?

- ISP lock-in. If you control the domain/DNS entries, there is no lock in. If you don't, then you are already locked in anyway.

- doesn't allow dynamic IPs. I'd argue that 1) it is a good thing 2) it's not really the case, you can specify a domain in spf, and this domain can be a dyndns style domain with a short lived TTL resolving to your current dynamic ip. And in theory you could also dynamically update your spf as your ip changes with a short TTL (like a dyndns-style entry).

[edit] and actually what is going to kill you with a dynamic IP is not so much spf than the fact that the reverse dns of that IP won't resolve to your domain which is a big spam red flag for most smtp servers.

Re: STARTTLS Everywhere

#55

Post by flashmob »

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

Perhaps fixing STARTTLS is one of those problems where the solution adds even more problems (and moving parts).

BTW, what ever happened to SMTP on a dedicated TLS port (465)? Why did it get deprecated?

Re: STARTTLS Everywhere

#56

Post by cm2187 »

achillean wrote: post #38
peter_tonoli wrote: post #37

Earlier quoted context omitted.

And how many just use self-signed certificates?

I would assume that most of the certs w/ a chain length of 1 are self-signed so around 1.6 million (out of the 2.7 million).

And 400k with expired certificates. Depressing...

Re: STARTTLS Everywhere

#57

Post by aorth »

Cool. This tool made me realize that my domain's DNS records were messed up. Everything worked most of the time, but sometimes people wouldn't receive my emails! It turns out I was missing the latest MX and SPF records from my provider (Kolabnow).

Re: STARTTLS Everywhere

#58

Post by mike-cardwell »

Boulth wrote: post #36
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…

Yep, Google.com has the record too but I haven't seen them scanning my mta sts file...

You need to have a correctly formatted DNS TXT record at _mta-sts.example.com first. They'll check for that, and only if it exists will they bother attempting to fetch your mta-sts policy from https://mta-sts.example.com/.well-known/mta-sts.txt

Re: STARTTLS Everywhere

#59

Post by tialaramex »

flashmob wrote: post #55
vbezhenar wrote: post #51

Earlier quoted context omitted.

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

Perhaps fixing STARTTLS is one of those problems where the solution adds even more problems (and moving parts). BTW, what ever happened to SMTP on a dedicated TLS port (465)? Why did it get deprecated?

Port 465 is unnecessary once STARTTLS was invented. It has exactly the same upside / downside but it wastes an entire TCP port and an entire RTT plus maybe a timeout to signal (non-)availability.

So it makes sense to deprecate this use of port 465 and just tell people to use STARTTLS.

Re: STARTTLS Everywhere

#60

Post by cm2187 »

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.

Perhaps I miss your point but if you use one of the supported DNS providers [1] can't you use certbot with DNS authorization and export the key and certificate to your mail server? Otherwise the acmev2 protocol isn't horrible to implement if you want to integrate it with a custom infrastructure.

[1] https://certbot.eff.org/docs/using.html#dns-plugins

Post reply on HN