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

81–90 of 106 posts

Re: STARTTLS Everywhere

#81

Post by kilburn »

cm2187 wrote: post #74
kilburn wrote: post #73

Earlier quoted context omitted.

> 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 huge problem here is "forward all e-mail I receive to my gmail account" or similar. If you do that pre-delivery, you break SPF. If you do it post-delivery, gmail makes you responsible for any junk that gets through. If you make your filters harsher, the use…

> gmail makes you responsible for any junk that gets through I'd argue this is the fair and correct behavior. Effectively you created a kind of open relay server. Since you accept external traffic, you should be filtering for spam there. > the message is rejected because of your SPF policy and their usage of internal relays I'd assume that if it is an internal relay server, then it shouldn't be checking for spf inter…

> I'd argue this is the fair and correct behavior.

A behavior that breaks how the mail system has been working since forever, and that people expect and use all the time.

It may not be right, but it is used and not even the big players (such as gmail) are willing to break it (hence why gmail actually tells other admins to use pre-delivery forwards disregarding SPF, but respecting DKIM wich is broken if you use post-delivery aliases) [1].

[1] https://support.google.com/mail/answer/175365?hl=en

> Sounds like a misconfiguration.

A misconfiguration you cannot fix (because it is on the receiver end, not on your end). But the client pays you for the service, and understandably asks you for a solution. What would you tell them?

I understand your points, and mostly agree with them. However, this approach only works in an ideal world where users understand that e-mail should have some limitations it hasn't had for the last 30 years, and all administrators are "good citizens" (they know their stuff, acknowledge their issues and work to quickly fix them).

The real world is different: clients will demand solutions, and other admins will oftentimes be either ignorant, powerless or even adversarial.

Re: STARTTLS Everywhere

#82

Post by auscompgeek »

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.

Re: STARTTLS Everywhere

#83

Post by axaxs »

JdeBP wrote: post #52
axaxs wrote: post #30

Earlier quoted context omitted.

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

Fair point, but I was thinking something like Signal, WhatsApp, or the like. So, I like to think of email as a bit dated, not only in security but in model. That said, the beauty of email is that you have a unique identifier that doesn't force the other party into your walled garden. If we could develop something akin to Signal, but that didn't require the second party to have to sign up explicitly for that service, I think that could finally start the process. Which, of course, would also require some level of initial adoption, probably the hard part.

Re: STARTTLS Everywhere

#84

Post by flashmob »

znpy wrote: post #69
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 ?

Yes, unfortunately you'd be losing email. Port 465 has been deprecated a while back (1997).

I guess that's the problem - there is no practical way to disable plaintext email from the start. You may always need to accept the connection, see if the client will STARTTLS, disconnect if they do not and hope they don't re-try and keep hammering your servers with the same message, the error message "hey, i'm not accepting plaintext" will most likely get ignored.

Re: STARTTLS Everywhere

#85

Post by flashmob »

mike-cardwell wrote: post #67
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 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.

Oops, I see, was assuming it was used for MTA too! So there was never really a dedicated TLS port for MTA to begin with?

Re: STARTTLS Everywhere

#86

Post by tialaramex »

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 being empty which confuses some software, you may write one of the DNS names or IP addresses into the X.509 Subject's Common Name (CN) field as human readable text, but you should always write all DNS names and IP addresses into SANs.

The dnsName SAN is defined like a DNS record, so it's case-insensitive and (if it's an IDN) Punycoded, it's also deliberately defined with a single encoding that is too narrow for anything much beyond an actual (Punycoded if appropriate) DNS name, to avoid people trying to write "extended ASCII" characters into this field by mistake.

Re: STARTTLS Everywhere

#87

Post by wila »

My email server passed, but the test mentioned, it could be better by adding it to the EFF's STARTTLS policy list [1].

The only problem being that that list is currently practically empty.

So while I was considering adding that email server which I maintain, when I saw the items on the list it makes me reconsider.

The only email servers currently on the list are : google, yandex, yahoo, icloud, outlook, comcast, eff, qq and facebook.

So while it might be an opportunity to get your server on the list early, personally I worry more about what it will break as to what it will help.

In conclusion, it looks like a great initiative, but it will have to be in production for a while before I would recommend anybody to add their server to that list.

[1] https://dl.eff.org/starttls-everywhere.policy.json

Re: STARTTLS Everywhere

#88

Post by lvh »

mike-cardwell wrote: post #67
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 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.

True, but the underlying question is still interesting: why isn't there a similar TLS-only port for MTA-MTA and we all agree to try to connect there first

Re: STARTTLS Everywhere

#89

Post by lvh »

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…

Apparently 465 is only for mail submission, not MTA-MTA -- but of course that still leaves the obvious questions of a) why? b) if it must be a different port, why not make that TLS-only?

Re: STARTTLS Everywhere

#90

Post by move-on-by »

tialaramex wrote: post #61
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. Bu…

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

You acknowledge that you don't know who you are talking to. That alone proves my point. If the cert is bogus/unvalidated then its trivial for the bad guy to intercept and supply their own bogus cert instead. You are correct that its encrypted, but that means nothing when you do not know who you are talking to. It could even be a string of bad guys all capturing and injecting another bad cert. Encryption without validation means nothing.

> they would prefer not to be seen to be meddling

Time and time again ISPs have been caught injecting javascript/cookies/html inside unencrypted traffic. If ISPs are willing to do that, then why should nation states be afraid to? The point of 'bad guys' is that they can't be trusted to not do bad things.

Besides the point that bogus/unvalidated certs do nothing, it would be easier to just perform a downgrade attack if the client isn't doing any validations. Downgrade to unencrypted and easily see everything. That is why they are creating a list of services that should only allow valid encrypted connections.

Post reply on HN