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

61–70 of 106 posts

Re: STARTTLS Everywhere

#61

Post by tialaramex »

move-on-by wrote: post #8

From my understanding, this is pretty much the same thing as the HSTS preload list[1], except for SMTP servers instead of HTTPS servers. It has two main goals. First, encourage cert validations. If you don't validate a cert, it means nothing. Second, help prevent MITM downgrade attacks. If your server is on the list, it means it should always use a secure cert. If it isnt, then don't connect. Same thing as HSTS prelo…

You write that "If you don't validate a cert, it means nothing". I should clarify that in this situation you get opportunistic encryption. I think you understood that, but the way it's phrased isn't clear. The situation is that we get secrecy, but we don't actually know who we're talking to since we didn't validate the cert. This genuinely is better than nothing.

If we were talking to a bad guy then we're screwed. But if we are talking to our intended recipient, even if their cert is bogus, our connection is protected from bad guys on the path. The bad guys can't choose later to access that communication after all, their only opportunity is to guess we're doing opportunistic encryption and intercept the original connection to play MitM, and if they guessed wrong their hand is shown by doing that.

This situation is unpalatable even for nation state adversaries like the NSA, because they would prefer not to be seen to be meddling. Even for something like the FSB, which scarcely cares if it's seen to be meddling, it does force them to make a decision they'd rather leave until after the fact. MitM everybody (and be known to do it) or leave them alone and maybe regret that later.

Re: STARTTLS Everywhere

#62

Post by flashmob »

tialaramex wrote: post #59
flashmob wrote: post #55

Earlier quoted context omitted.

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.

The STARTTLS vulnerability to downgrade attacks is a significant downside that port 465 doesn't have (if using modern TLS protocols at least). My opinion is that perhaps the severity of the STARTTLS downgrade attack wasn't that much considered when port 465 was deprecated.

Re: STARTTLS Everywhere

#63

Post by tialaramex »

rossy wrote: post #50
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...

Note that if doing this you may need to explicitly tell Certbot (or whatever client you use) not to keep replacing your key pair when renewing certificates.

If you set things up to involve CSRs this problem goes away because the CSR binds to a key pair, just don't change the CSR unless your DNS names change. But if you use CSRs, Certbot forces you to take charge of ensuring the renewal schedule etcetera, since it has no way to be sure if the same CSR can be used next time.

Mail servers can do more here to help automate this. Also, maybe we can imagine that TLS-ALPN-01 (a forthcoming Let's Encrypt proof of control method) could work with SMTP STARTTLS. That would let a mail server take responsibility for getting its own certs (port 25 is on the short list of "Authorized ports" for the Ten Blessed Methods) by telling its own TLS implementation "Hey, when asked for ALPN, offer this extra ALPN feature and repeat everything I tell you" to prove it is really who it says it is.

I think the above could work, but it would need effort from Let's Encrypt and TLS-ALPN-01 itself isn't finished yet.

Re: STARTTLS Everywhere

#64

Post by marcbradshaw »

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

The starttls-everywhere IP connects, tries a bunch of commands which don't look at all like a regular mail connection. It cycles through a bunch of tls settings and never sends an email. In short, it got itself blocked by anti-spam measures.

Re: STARTTLS Everywhere

#65

Post by cm2187 »

flashmob wrote: post #62
tialaramex wrote: post #59

Earlier quoted context omitted.

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.

The STARTTLS vulnerability to downgrade attacks is a significant downside that port 465 doesn't have (if using modern TLS protocols at least). My opinion is that perhaps the severity of the STARTTLS downgrade attack wasn't that much considered when port 465 was deprecated.

The only (weak) argument I can find is that since servers that had a port 465 open also had to keep a port 25 open for compatibility, you could perform the same downgrade attack by blocking connections to port 465, which would result in a submission to the port 25. But that's a "if it's broken let's make sure it remains broken" kind of argument.

Re: STARTTLS Everywhere

#67

Post by mike-cardwell »

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 for mail submission. It's there for authenticated communication between clients and servers. It has never been used for communication from server to server and was never intended to be. Port 587 has the same purpose (mail submission), but has a plain text protocol specific negotiation at the beginning which matches that for server to server mail transfer on port 25.

Re: STARTTLS Everywhere

#68

Post by mike-cardwell »

flashmob wrote: post #62
tialaramex wrote: post #59

Earlier quoted context omitted.

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.

The STARTTLS vulnerability to downgrade attacks is a significant downside that port 465 doesn't have (if using modern TLS protocols at least). My opinion is that perhaps the severity of the STARTTLS downgrade attack wasn't that much considered when port 465 was deprecated.

Downgrade attacks are no easier for STARTTLS than for TLS-on-connect. If you were deploying TLS-on-connect you'd have to do it in one of two ways:

1. Senders should first try TLS-on-connect, and if it's not available, fall back to STARTTLS.

2. Senders should only do TLS-on-connect with no fallback

If you do #1, then a downgrade attack still exists because an attacker can just block port 465 and then interfere with the traffic on port 25 (or put a fake SMTP server on that port if one doesn't exist).

If you do #2, that's no easier than just mandating that STARTTLS on port 25 is required.

The alternative to all of this is to find some out of band method for a receiver to state that TLS should be available (TLSA / MTA-STS), and if it's not then something is being tampered with. That way, a sender can look up that information and then choose to do #2 for that particular receiver. Again, in that scenario it makes no difference if we're talking TLS-on-connect or STARTTLS. Given we can't make the whole World switch to "must always be encrypted" at the same time, this is the only practical way forward.

Re: STARTTLS Everywhere

#69

Post by znpy »

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…

This is interesting, I have been wondering for a while if I could disable plaintext email delivery on port 25 and just leave encrypted submission on port 465.. Would I be losing mail ?
Post reply on HN