Email encryption is here – use STARTTLS everywhere • Hacker News Board

Re: Email encryption is here – use STARTTLS everywhere

#71

Post by apple4ever » Sun, Jul 29, 2018, 2:12 PM UTC

jlgaddis wrote: post #67

__david__ wrote: post #19

So I support more encryption everywhere, but this is acting like there's something new? I know I've been using STARTLS on SMTP for almost 20 years… Am I missing something?

> ... there's something new? The "STARTTLS Everywhere" project [0] -- the one thing this entire article is talking about -- is what's new. > ... I've been using STARTLS on SMTP for almost 20 years ... That's great -- I have too -- but I have some bad news for you: not everybody else has been! (I know, right!?) The EFF is simply trying to bang the drums to get everyone's attention and then convince those that aren't a…

It seems to be dead.

I submitted my domain and it’s not on the list, and there has been no communication about why or why not (given that it passes their security checker and requirements).

Re: Email encryption is here – use STARTTLS everywhere

#72

Post by fowl2 » Mon, Jul 30, 2018, 2:41 AM UTC

sydli wrote: post #13

fowl2 wrote: post #9

So this is kinda like the HSTS preload list, but includes MX server names, and is supposed to be updated every 48 hours. Couldn't we just put this in DNS?

That would be fine, too, and reflects in part what MTA-STS is trying to do. A point that may be obvious, but I would like to make explicit, is that unlike on web, end-users have no good way to express whether they prefer security over deliverability on a connection, which makes downgrade attacks more difficult to deal with. Everyone defaults to preferring deliverablity (falling back to plaintext). In the absence of u…

What would be more/also interesting would be a way of expressing this intent by a sender.

Seems like (with absolutely no thought here) a new header could me minted for this - eg. "Transport-Security: Require". Tough part as usual would be getting MTA and client support, but switching to a per message approach would at least allow incremental rollout - and critically I think - allow introspection by following bounces.

Re: Email encryption is here – use STARTTLS everywhere

#73

Post by mike-cardwell » Mon, Jul 30, 2018, 10:24 PM UTC

drudru11 wrote: post #64

mike-cardwell wrote: post #57

Earlier quoted context omitted.

Because it's not backwards compatible, and would prevent delivery of a large amount of email. We just need a way for domain owners to signal that their domains definitely accept email over STARTTLS. At that point, senders which recognise those signals can start to enforce that mail which they send to those domains MUST use STARTTLS. Fortunately, those signalling methods are beginning to rise to the surface. We have M…

All you need is another port in addition to the regular SMTP port. They are not mutually exclusive.

That is completely insecure. A MITM would just block access to the tls-on-connect port, forcing the sending host to retry on port 25, where they would strip the STARTTLS advertisement.

Unless you're recommending to not fall back to port 25 after a failed connection to the tls-on-connect port. In which case, see the comment you were replying to where I said it would be backwards incompatible.

Both of the solutions I mentioned are backwards compatible, and protected from a similar downgrade situation.

Re: Email encryption is here – use STARTTLS everywhere

#74

Post by drudru11 » Tue, Jul 31, 2018, 5:54 PM UTC

mike-cardwell wrote: post #73

drudru11 wrote: post #64

Earlier quoted context omitted.

All you need is another port in addition to the regular SMTP port. They are not mutually exclusive.

That is completely insecure. A MITM would just block access to the tls-on-connect port, forcing the sending host to retry on port 25, where they would strip the STARTTLS advertisement. Unless you're recommending to not fall back to port 25 after a failed connection to the tls-on-connect port. In which case, see the comment you were replying to where I said it would be backwards incompatible. Both of the solutions I m…

Right, I should have said that I was recommending not ever sending on 25. The STARTTLS mitm is just too easy for large attackers.

IMHO, being backwards compatible is necessary for a transition period. The messaging to SMTP operators should be... get on board, or you are going to start losing mail in 1 year.

Even Chrome is going to show all http as insecure in the very near future. Which reminds me... I need to get all my sites upgraded.