No Starttls

https://nostarttls.secvuln.info/

by edward • 5 years ago

47 22 5 years ago

nostarttls.secvuln.info

korethr• 5 years ago

The situation with SMPTS and port 465 is a fun one. By my understanding, at present, implicit TLS for submission isn't standard. Now, a lot of mail server operators listen on port 465 for SMTPS anyway, because very breifly, that was the standard port for such. But there are other operators who are stickler for the letter of the standard, and when asked to support SMTPS on port 465, respond with "That's not standard. STARTTLS on 587 is. Use STARTTLS." I will confess to having been one of those operators in the past. Reflecting, I suspect that was at least partly because in insisting on strict standard compliance, I cut down on the amount of spam I had to deal with (you would be amazed at the sheer volume of poorly coded bots that imediately throw a LOGIN or MESSAGE FROM at you upon establishing a connection, not even bothering to forge a HELO or EHLO).

I totally support RFC 8314's attempt to standardize existing practice, and get port 465 officialy recognized. https://datatracker.ietf.org/doc/html/rfc8314 Once done, what is "standard" will no longer be an excuse. Though, updating out-of-support middleboxen will probably still take a while.

deathanatos• 5 years ago

Similarly, I have my personal SSH server configured to only accept "modern" crypto. A fair number of attacking clients fail to negotiate a cipher!

singlow• 5 years ago

Probably saves them time. You are not a soft target. What incentive do they have to add support when it only gains them access to more hardened systems that most likely are not vulnerable to their next phase.

cge• 5 years ago

I recently switched my SSH servers to only listen to IPv6. They're still on port 22, and still pointed to by DNS, yet, while they received bot connection attempts every few seconds when listening for IPv4, they haven't received a single bot connection attempt in the last week since I made the switch.

Bots apparently simply don't bother with IPv6.

soneil• 5 years ago

I was under the impression 8314 was a "done deal". IANA have listed 465 as submission over TLS since december 2017.

(The previous iteration was submission over SSL in the late 90s on the same port.)

silisili• 5 years ago

IIRC AWS SES has always worked this way. I remember complaining years ago it wasn't compatible with Go's SMTP library for that reason(it expected STARTTLS).

throwaway20371• 5 years ago

STARTTLS and its ilk are what happens when technology companies (& their minions) are pussies. It has been clear for decades that secure e-mail transport would be a good idea, but not if we had to actually upgrade software / systems to get it. This bullshit is so endemic that Google Mail has actually released two new standards in 2019, that depend on two other protocol stacks, just to advertise to SMTP servers that they support secure mail.

Thankfully, in 2018 someone had the balls to release RFC8314, which explicitly obsoletes cleartext for MUA <-> MSS <-> MAS mail. So why did Google release standards in 2019 that presume that some servers still won't talk TLS? My guess is they're terrified someone won't send them mail, and they'd lose some of that sweet sweet analytics money.

We clearly have an endemic problem in our technology culture related to breaking changes in order to fix shit. This is going to keep happening, unless we come up with new industry principles and practices to enforce breaking upgrades of legacy systems. If your system doesn't have a sunset date of less than 8 years, it should be considered broken out of the box. If it doesn't expect major feature overhaul after 4 years, it should be abandoned in favor of a system that does. Not having zero-downtime upgrades and rollbacks should be a non-starter too. Basically we need a "12 factor app" for protocols and systems.

0x000000001• 5 years ago

How important is this

This should be at the top of the post honestly

jchw2• 5 years ago

Somewhat OT: What is Meddler-in-the-Middle? I can’t find anything about it, is it just another term for MitM, or is it more nuanced?

AUSNA-ZI2• 5 years ago

Meddler is probably just more precise then Man.

sodality22• 5 years ago

Terrible choice, as "Meddler-in-the-Middle" yields some sort of style of teaching when searched.

sodality22• 5 years ago

It's probably just a gender-neutral term that still begins with M, so "MitM" still makes sense to use as an acronym (yes, grammar nerds, I pronounce it as "mittem", don't say it's an initialism).

jchw2• 5 years ago

I have no idea what the actual answer is, and instead it seems several posts about it got downvoted. Sincerely, what the fuck? Is this some secret code that can’t be discussed?

LinuxBender2• 5 years ago

I'm OK with StartTLS. What I think is missing is a DNS record that mail servers cache for a long time, similar to HSTS that says you MUST use encryption for this domain. Probably also a variation to the record to say to validate the cert chain. This would align with an existing capability in postfix that allows you to specify which domains must be encrypted, or mandatory cert chain validation and to what level. At least I think this would be the easiest path to a better security stance and probably the simplest to implement given the myriad of email servers, clients and client libraries. Perfect is the enemy of good, or so they say. Below is from postfix. There are many more options.

  smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

  example.net           secure  match=example.net:.example.net
  anotherexample.net    may     match=anotherexample.com:.anotherexample.com

gnabgib• 5 years ago

It sounds like you're asking for [MTA-STS](https://dmarcian.com/mta-sts/)

"MTA-STS is an inbound mail protocol designed to add a layer of encryption/security between sending and receiving mail servers."(..)

"The MTA-STS protocol works by having a DNS record that tells mail servers to fetch a policy file via HTTPS from a defined subdomain. This file contains a list of the receiver’s mail servers which are authenticated and approved to receive the messages and also what policy to apply to inbound messages."

LinuxBender2• 5 years ago

Maybe. Any time we ask a library or client to do HTTP fetches when it historically only did SMTP I become less optimistic about adoption. There are obvious easy wins like Thunderbird and Outlook and those could potentially use a plugin or add-on. Maybe that could be a good start and good enough.

transportheap• 5 years ago

someone should tell the openbsd guys https://github.com/OpenSMTPD/OpenSMTPD/issues/451 who explicitly tell certain users to use starttls

No Starttls

Related Stories